道法術器 — DevOps 端到端部署流水線 V2.0

內容來源：2017年8月18日，DevOps時代聯合發起人張樂在「DevOpsDays 【主會場】」進行《DevOps 道法術器及全開源端到端部署流水線 2.0發佈》演講分享。IT 大咖說（ID：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：4497 | 4分鐘閱讀

嘉賓演講視頻地址：suo.im/4ywEH3

摘要

DevOps獨立顧問、DevOps時代聯合創始人張樂爲咱們帶來DevOps 道法術器及端到端部署流水線V2.0的分享。

VUCA新常態

在移動互聯網時代和即將到來的人工智能時代，咱們所處的商業格局和企業生態充滿了易變性、不肯定性、複雜性和模糊性，企業的創新能力依賴於可以頻繁地從真實用戶那裏獲得對商業假設的有效驗證，勝出者的特色是擁有快速交付價值、靈活應對變化的能力。

IT的技術革命

IT行業一直都在不斷地自我迭代、持續演進，咱們正在經歷一場IT的技術革命。

從應用架構的角度，多年前開發軟件，可能就是一個單體式的應用，全部的東西所有在運行一個進程裏面。後來咱們有了分層架構，把展現層、邏輯層、數據層作了很好的分離。近兩年咱們在提微服務的架構，但願每一個服務可以單一職責，服務之間可以很好的解耦，每一個服務都可以獨立地設計開發、測試和上線。

部署和打包的模式也發生了很大的變化。從基於物理機部署到基於虛擬機，再到如今不少應用運行在容器裏。咱們交付過程的產出已經再也不知足於交付一個可工做的軟件，而是但願每次交付都是一個可正常運行的系統，這是一個本質上的變化。

從應用的基礎設施來說，咱們原來關注的是數據中心，到後來咱們更多關注的是主機託管，如今咱們更關注如何在雲上把應用正常、高效、穩定的運行起來。

更爲重要的，軟件交付管理的模式也在發生着不少的變化。早在上個世紀6、七十年代，那個時候提出的軟件工程方法，是用一種結構性、系統化、重管控的流程和方法去控制整個軟件交付的過程，後來到了互聯網時代，以敏捷化、迭代式、增量化的交付逐步成爲主流，這會讓軟件交付過程更快、更靈活。到如今咱們講 DevOps，是但願經過研發和運維/運營的融合，在保證質量的前提下進一步提高交付效率。

全部以上這些維度構成了一場IT的技術革命。

DevOps已成爲發展趨勢

從Gartner的IT成熟度曲線圖能夠看出，DevOps已經跨越了概念認知的頂點，逐步向深化應用去發展。也就是說它在概念上獲得了認同，須要考慮的問題就是如何更高效地落地實施。

在今年發佈的《2017年DevOps現狀調查報告》中顯示，根據幾年的調查數據統計趨勢發現，DevOps團隊比例已經從2014年的16%提高到2015年的19%，2016年提高到22%，今年已經達到了27%，也就是說已經成爲事實上的技術趨勢。

DevOps強調爲業務目標服務

DevOps不是技術噱頭和工程師的工具箱，更須要面向業務目標，助力業務成功。DevOps須要有效應對VUCA 挑戰，高效、高質量交付價值，快速、靈活響應變化。

談到DevOps落地，曾經碰到很多朋友更多關注是使用什麼樣的工具去實現DevOps。有些人關注自動化，包括自動化測試和自動化部署；有人說DevOps是組織文化，重點是開發和運維的協同；也有人說DevOps要關注小批量的交付。這些關注點都對，可是可能不夠全面。

我把以前對DevOps的理解和實踐經驗，整理成一個體系化的實施框架：『DevOps道法術器』。

「道」是目標、價值觀，對價值的定位。快速交付價值，靈活響應變化，這是從價值層面的追求，或者是從第一性原理的角度來說，咱們作這個事情最終目標是什麼；

「法」是實現價值觀的戰略、方法，這個層次的主要思路是全局打通敏捷開發和高效運維。

「術」是戰術、技術，最佳實踐的層次，咱們要系統化的應用有效的方法、合適的技術，不少最佳實踐幫助咱們實現 DevOps 。

「器」是工具層次，主要思路是用工具提高效率，將複雜的問題簡單化。由於上面的層次有了很好的技術和方法，咱們最終要把它落地、固化到工具平臺上，而且但願實現整個軟件交付流程端到端相互融合和貫通。

道、法、術、器自上而下是系統思考的層次，自下而上是解決問題的層次。我認爲 DevOps 的規劃和實施能夠用這四個層次來歸納。

1、道

應用性能、拓撲第三方組件；資源使用；異常堆棧；數據聚合、分析報警；自定義業務。

經常使用監控手段

首先是 「道」 的層次，主要目標是快速交付價值和靈活響應變化。談到敏捷，談到 DevOps，可能第一個訴求就是要快速交付價值。在互聯網的時代，交付的速度很是關鍵。原來的瀑布模型須要等到最後一個環節實施完成才向用戶交付價值，而敏捷和DevOps 倡導小批量、增量式的交付價值，這就使交付價值的速度、面向市場的頻率獲得大幅提高。

除此以外，還要關注什麼？還要關注端到端的交付價值，這纔是真正的交付價值。若是僅僅在開發、測試環節作局部的敏捷優化，而沒有考慮到後續的多服務集成場景，以及每次迭代後發佈和運維的場景，這樣就沒有真正作到端到端的價值交付，因此咱們須要作的是打通整個 IT 交付的全鏈條。
在價值交付這個層次，咱們最終但願達成一個目標，就是經過 DevOps 打造一條高度自動化的 IT 服務供應鏈，可以快速、高質量地交付用戶的價值。 DevOps 創始導師 Patrick 先生來華時給了咱們一些啓示，如何作到開發和運維的有效融合。

第一個維度是自動化，好比經過基礎設施即代碼的方式，將交付擴展到生產的環境；

第二個維度是度量，從運維側暴露一些日誌，監控數據等相關信息給到開發側，造成有效的反饋；

第三個維度是文化，創建責任共擔的機制，促進合做；

第四個維度是共享，將運維側獲取到的知識注入到開發側，好比把安全需求、監控需求等非功能需求，加入到產品的Backlog中；

這樣從四個維度將開發和運維之間作更好的融合，以上這些是 「道」 的層次。

2、法

「法」 的層次，咱們關注如何全局打通敏捷開發和高效運維。這裏面談到不少的方法，我認爲 DevOps 是一個集大成者，是不少優秀的方法的集合體，可是要更關注全局的總體優化而不只是某個局部的優化。

左側這張圖來自DevOps Master的知識體系，主要講敏捷、持續交付、精益、ITSM這些方法的適用範圍和相互關係。

敏捷重點關注從需求、開發到測試的範疇；持續交付重點關注工程實踐的範疇；在運維側仍是應用 ITSM 的方法，可是重點要關注如何將流程自動化並提高效率；另外還有一個貫穿始終的精益思想，它是以上諸多方法的基石。

右側這張圖來自Jenkins的創始人KK，很好的說明了敏捷、持續集成、持續交付、持續部署這些不一樣方法的效用和邊界在哪裏，以及各類方法之間的區別和相互融合關係。

下面是 DevOps 結構化方程模型，這個模型也很是有價值。

實施 DevOps 的過程當中，咱們常常會關注不少具體方法或技術的實現，好比測試和部署的自動化、分支模型、持續集成、架構解耦、自組織團隊等等，還包括精益產品管理相關的內容，好比小批量、實驗、反饋等。

可是每每咱們忽略了最左邊的一個部分，這個部分是變革領導力。什麼是變革領導力？

個人理解是從一個領導者的層面，如何構造一個良好的氛圍，助力 DevOps 的變革。好比說須要在安全空間範圍內倡導免責的文化，鼓勵改進冒險的行爲。其實全部的改進要從領導力的層面創建一個良好的氛圍，並滲透到團隊當中，當資源具有、氛圍創建起來，再和具體的技術、方法、實踐引入相匹配，相輔相成、共同做用才能把 DevOps 有效推動下去。

以上就是「法」 的層次，但願能給你們一些啓示，但這部分仍是偏理論一些，那麼下面咱們看看具體的技術和實踐。

3、術

「術」 的層次的主要思路是系統的應用各種技術、指導原則和最佳實踐。這個層次涵蓋的內容就很是多了，咱們能夠經過一張圖來展現。

首先把相關技術和最佳實踐分爲管理維度和工程維度兩個部分。

管理維度主要關注管理的範疇，針對軟件生命週期不一樣的階段有不一樣的技術和實踐。好比目標肯定階段，能夠應用精益畫布和影響地圖的實踐；在版本的肯定階段，能夠應用用戶故事地圖和敏捷迭代管理的相關實踐；在迭代實施階段咱們能夠應用精益看板、每日站會、敏捷度量（燃盡圖、累積流圖、散點圖...）等實踐，以上這些技術和實踐能夠幫助咱們管理整個軟件研發的過程。

在工程維度也對應了不少的技術和實踐，包括配置管理、自動化測試、持續集成、持續交付、灰度發佈、持續監控等等。以上這些組成了咱們 「術」 的層次，下面咱們找一些重點的作下介紹。

3.1管理維度

在敏捷中 Scrum 模型已經很是廣泛，我這裏不詳細闡述。

這裏重點關注敏捷度量，好比用燃起圖度量總體進度；用累積流圖度量各個階段累積處理的需求數量，以及它們隨時間的變化趨勢，能夠從中分析出前置時間、交付速率的數據，以及協做模式的改進機會；經過散點圖能夠關注整個的交付過程當中，平均前置時間、收斂趨勢，以及經過對離羣點的分析，找到改進的機會。在敏捷項目管理過程當中，善用數據度量，是持續改進的前提。

3.2工程維度

下面來看一下工程維度的內容，首先是持續交付框架。

關於持續交付框架，我我的以前也分享過不少了，主要思路是以建設可靠、可重複的持續交付流水線爲核心，配合以相關實踐和技術的導入，讓整個軟件交付過程實現高度的自動化和自助化。

除了框架的指導，咱們還有不少最佳實踐的集合。

上圖是持續交付的光譜圖，發佈頻率從100天發佈一次到一天發佈屢次，所採用的分支模型、測試模式、系統架構、發佈模式、基礎設施和數據庫的管理模式，都會有不少的實踐須要變化。

我認爲做爲咱們從業者來說，是很是好的指導和參考，若是但願將交付的頻率變得更快，穩定性變得更高，須要把這些實踐調整和落地。

4、器

「器」 是指工具的層次，工具須要把上面層次提到的方法、實踐固化和落地。工具通用須要考慮不少維度，好比說管理維度、工程維度、基礎設施維度，而最重要的，是要把這些工具作很好地聯通和整合。

今年4月份，我發佈了全開源端到端交付流水線的1.0的版本。當時的目標是但願從社區的角度，咱們作一個解決方案提供給你們，從而幫助你們經過開源工具更好的把 DevOps 實現和落地。那麼效果怎樣呢？當時咱們作了一個演示視頻，介紹整個的流水線過程和實現細節。這個視頻到如今已經累計播放超過4.5萬次，咱們以爲仍是很欣慰的，但願社區可以幫助你們作一些事情。

固然，咱們也是在不斷迭代和自我改進的，咱們在 V1.0 版本的基礎上進一步完善和優化，如今提出端到端交付流水線 V2.0 版本。

新的版本但願覆蓋更多場景，包括APP發佈流程，支持多種語言，支持一些友好的商業工具，支持Mesos& Marathon 的部署，支持虛擬主機自動化配置，支持一鍵式自動進行工具間的集成等，也但願可以適配更多的場景下的不一樣需求。

能夠看到比上一個版本作了不少更新和完善，適配更復雜的場景。在需求側，咱們引入 Jira 作敏捷項目管理，依然經過Gitlab進行代碼託管，採用 Feature 分支的研發模型。使用 Jenkins 和 BlueOcean 作流水線的編排和展現，流水線分爲提交階段、驗收階段、準生產階段和生產階段。

在流水線中集成不少工具，包括 Maven 、 JUnit 、Sonar、Selenium、Jmeter、PACT、Appium等，鏡像管理使用 Harbor ，但也支持其餘鏡像倉庫。

部署上支持Ansible或SaltStack，容器集羣能夠兼容 K8S 或Mesos + Marathon。因此這也是一個解決方案，但願能幫助你們更好地經過工具落地 DevOps 。

今天咱們講的是 DevOps 的道、法、術、器四個層次，但願你們作 DevOps 規劃和實施不只關注工具、實踐，更要關注它的業務價值，自上而下的推進，自下而上的解決問題。

今天的分享就到這裏，謝謝你們！