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

摘要

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

VUCA新常態

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

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

從應用架構的角度，多年前開發軟體，可能就是一個單體式的應用，所有的東西全部在執行一個程式裡面。後來我們有了分層架構，把展示層、邏輯層、資料層做了很好的分離。近兩年我們在提微服務的架構，希望每個服務能夠單一職責，服務之間能夠很好的解耦，每個服務都能夠獨立地設計開發、測試和上線。

部署和打包的模式也發生了很大的變化。從基於物理機部署到基於虛擬機器，再到現在很多應用執行在容器裡。我們交付過程的產出已經不再滿足於交付一個可工作的軟體，而是希望每次交付都是一個可正常執行的系統，這是一個本質上的變化。

從應用的基礎設施來講，我們原來關注的是資料中心，到後來我們更多關注的是主機託管，現在我們更關注如何在雲上把應用正常、高效、穩定的執行起來。

更為重要的，軟體交付管理的模式也在發生著很多的變化。早在上個世紀六、七十年代，那個時候提出的軟體工程方法，是用一種結構性、系統化、重管控的流程和方法去控制整個軟體交付的過程，後來到了網際網路時代，以敏捷化、迭代式、增量化的交付逐步成為主流，這會讓軟體交付過程更快、更靈活。到現在我們講 DevOps，是希望通過研發和運維/運營的融合，在保證質量的前提下進一步提升交付效率。

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

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

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

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

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

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

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

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

“術”是戰術、技術，最佳實踐的層次，我們要系統化的應用有效的方法、合適的技術，很多最佳實踐幫助我們實現 DevOps 。

“器”是工具層次，主要思路是用工具提升效率，將複雜的問題簡單化。因為上面的層次有了很好的技術和方法，我們最終要把它落地、固化到工具平臺上，並且希望實現整個軟體交付流程端到端相互融合和貫通。

道、法、術、器自上而下是系統思考的層次，自下而上是解決問題的層次。我認為 DevOps 的規劃和實施可以用這四個層次來概括。

應用效能、拓撲第三方元件；資源使用；異常堆疊；資料聚合、分析報警；自定義業務。

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

除此之外，還要關注什麼？還要關注端到端的交付價值，這才是真正的交付價值。如果僅僅在開發、測試環節做區域性的敏捷優化，而沒有考慮到後續的多服務整合場景，以及每次迭代後釋出和運維的場景，這樣就沒有真正做到端到端的價值交付，所以我們需要做的是打通整個 IT 交付的全鏈條。
在價值交付這個層次，我們最終希望達成一個目標，就是通過 DevOps 打造一條高度自動化的 IT 服務供應鏈，能夠快速、高質量地交付使用者的價值。 DevOps 創始導師 Patrick 先生來華時給了我們一些啟示，如何做到開發和運維的有效融合。

第一個維度是自動化，比如通過基礎設施即程式碼的方式，將交付擴充套件到生產的環境；

第二個維度是度量，從運維側暴露一些日誌，監控資料等相關資訊給到開發側，形成有效的反饋；

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

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

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

“法” 的層次，我們關注如何全域性打通敏捷開發和高效運維。這裡面談到很多的方法，我認為 DevOps 是一個集大成者，是很多優秀的方法的集合體，但是要更關注全域性的整體優化而不僅是某個區域性的優化。

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

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

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

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

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

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

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

以上就是“法” 的層次，希望能給大家一些啟示，但這部分還是偏理論一些，那麼下面我們看看具體的技術和實踐。

“術” 的層次的主要思路是系統的應用各類技術、指導原則和最佳實踐。這個層次涵蓋的內容就非常多了，我們可以通過一張圖來展示。

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

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

在工程維度也對應了很多的技術和實踐，包括配置管理、自動化測試、持續整合、持續交付、灰度釋出、持續監控等等。以上這些組成了我們 “術” 的層次，下面我們找一些重點的做下介紹。

3.1管理維度

在敏捷中 Scrum 模型已經非常普遍，我這裡不詳細闡述。

這裡重點關注敏捷度量，比如用燃起圖度量整體進度；用累積流圖度量各個階段累積處理的需求數量，以及它們隨時間的變化趨勢，可以從中分析出前置時間、交付速率的資料，以及協作模式的改進機會；通過散點圖可以關注整個的交付過程中，平均前置時間、收斂趨勢，以及通過對離群點的分析，找到改進的機會。在敏捷專案管理過程中，善用資料度量，是持續改進的前提。

3.2工程維度

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

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

除了框架的指導，我們還有很多最佳實踐的集合。

上圖是持續交付的光譜圖，釋出頻率從100天釋出一次到一天釋出多次，所採用的分支模型、測試模式、系統架構、釋出模式、基礎設施和資料庫的管理模式，都會有很多的實踐需要變化。

我認為作為我們從業者來講，是非常好的指導和參考，如果希望將交付的頻率變得更快，穩定性變得更高，需要把這些實踐調整和落地。

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

今年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 規劃和實施不僅關注工具、實踐，更要關注它的業務價值，自上而下的推動，自下而上的解決問題。