電腦科學中的任何問題都可以通過創造一個概念來解決。如果一個不行，那就兩個！

Gartner 2016 年應用開發成熟度曲線上，DevOps 已入頂峰。毫無疑問，DevOps 自 2009 年誕生以來，一路高歌猛進，目前已然成為軟體行業的標準配置（最佳實踐）。

甚至近兩年的IT招聘中，DevOps 工程師已成為最火的崗位之一，而熟悉 DevOps 也成為研發人員或運維人員的技能要求。

相應的，作為新興技術概念繁榮的另一面，當我們談論 DevOps 時，對其認識也呈現出多種多樣的理解，並會按照自己的需要進行闡述：有的強調研發和運維流程改進，有的談論自動化運維，有的試圖建立起軟體開發全生命週期管理；

還有些甚至在 DevOps 的基礎上進行更為超前的擴充套件，比如，就某些具體的領域探討 NoOps 或者是圍繞人工智慧建立 AIOps，等等，真是亂花漸欲迷人眼。

今天，無論是作為網際網路行業的參與者，還是傳統IT企業的從業者，在這場 DevOps 運動浪潮中，我們要如何撥開重重迷霧來理解 DevOps，瞭解各種不同 DevOps 主張間的異同，從中選擇適合自己的方式落地，並最終建立起高效的研發運維體系？

另一方面，我們如何從 DevOps 的發展中理出隱藏在背後的動機和目標，從而在實踐過程中能夠超脫具體器用的限制，在面對未知問題時可以靈活的處理，甚而發展出自己的流程、系統和生態？……

對這些問題的探討正是本文目的之所在！但在開始我們的旅程前，我們需要先回答一個基本問題：DevOps 到底是什麼?

DevOps是什麼？

DevOps (a clipped compound of “development” and “operations”) is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops).

The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.

DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

如上是 wikipedia 上關於 DevOps 的最新描述【注1】，聊聊數語，似乎並不能讓我們建立對 DevOps 的清晰認知，而且也不能一窺DevOps已發展出的龐大體系。

為了要理解現今的 DevOps，我們最好順著歷史長河逆流而上，不過有別於關注那些發生在2009年左右的故事【注2】，這次讓我們先走的更遠些，看看那敏捷誕生時的事情。

2000年左右，軟體行業的主要工作是交付客戶定製的軟體應用，而軟體研發團隊被推薦使用像 CMM/CMMI、RUP 這樣的大型方法論來組織生產【注3】。

從事過大型交付專案的人應該對些方法論不陌生，拋開可能的操作差異——比如是瀑布還是迭代，它們有著一些共同的特徵：

• 通過詳細的流程規範軟體開發的各個方面
• 大量細節工作前置以預防後期變更
• 將文件作為軟體的產物和流程驗證工具

這些大型方法論效果並不理想，一方面甲乙雙方在需求變更上的扯皮不是影響交付日期就是交付後的產品不能真正解決客戶的問題，另一方面研發團隊又需要花費大量精力在準備流程需要的文件上面【注4】。

正因此，當時一些正在積極嘗試不同方法的軟體開發人員才會濟濟一堂，提出著名的《敏捷宣言》，如圖1。

圖1. 敏捷宣言

雖然敏捷宣言的提出者們委婉地肯定了一下右側各項的價值，但我們依然能夠從這些文字中體會出他們對大型方法論的不滿——右側各項都是與大型方法論緊密聯絡的實踐。

可以這樣說，敏捷方法的出現正是對大型方法論的反思和反抗。由於敏捷源自實踐，在這個概念剛剛提出時，其對應的理論體系尚不完備，人們對其認知也並不統一，所以開始時，敏捷涵蓋了與敏捷宣言相聯絡的多種方法論【注5】。

這裡，我們提及敏捷的原因在於幾點：

第一，作為 DevOps 的提出者，敏捷的視角和方法直接影響了早期 DevOps，我們需要理清這樣的影響在何處。

第二，DevOps 和敏捷，以及更早些的精益生產，都是先實踐，再形成理論，最後又以理論指導實踐。因此，瞭解了敏捷的誕生和發展過程，我們再看人們對 DevOps 概念認知的發展就不會感到困惑。

最後，DevOps 的產生和整個大環境的變化有著直接的關係，從敏捷到DevOps，我們通過梳理歷史發展的脈絡來從側面瞭解催生 DevOps 背後的原因。

圖2. 敏捷與DevOps時間線

如圖2，敏捷提出後其關注過程和質量，而其要解決的問題則是如何快速交付客戶需要的軟體，或者我們更高大上地說，如何快速地交付價值！

一開始，這裡的交付有著相對狹窄的意義，也就是，它實際上指的是軟體外包公司和軟體需求方（甲方）之間的軟體研發和製品交付工作。

而後，隨著敏捷在一般企業內部推廣，其開始涵蓋軟體開發團隊和業務團隊之間的需求實現和軟體交付關係。此時，整個軟體的生命週期如圖3，交付是開發的終點（或者在任何迭代中作為階段性終點）。

由於此時多數是企業級應用開發，業務的穩定性和需求的演進速度尚不是問題，加之開發和運維在物理上的分離（通常分屬於不同的公司），因此，研發和運維之間的矛盾並未凸顯，需求頻繁變更、研發效率低下才是甲乙雙方頭痛的問題。

圖3. 傳統軟體生命週期

之後，如圖4，在網際網路高速發展的過程中，軟體開發成為企業業務整體運營中的一環，開發團隊階段性交付軟體後，並不能從總體上為業務立即帶來任何價值，軟體必須經過後續階段，直到被部署到生產環境並真正帶動業務運轉起來後，整個軟體研發工作才算交付了價值。

圖4. 面向運營的軟體生命週期

因此，在 DevOps 提出前，IT 行業中的主要問題不再僅僅是需求研發的問題，而且還有軟體變更高質量、快速上線的問題。

要讓業務快速產生價值，降低從需求到軟體上線的整體時間才是關鍵，如圖5，加之網際網路業務高速運轉的要求，這個效率對企業生存是至關重要的。

但是，由於傳統研發和運維定位的問題，即便在同一個企業中，由於工作性質和考核的方式的不同，研發和運維之間的部門牆對效率的提高有著很大阻礙（圖6）。

此時即便研發可以通過敏捷高效起來，但糟糕的交付過程依然會將業務交付整體拉回到低效的瀑布方式（圖6），甚至造成業務失敗，而這正是促使諮詢師 Patrick Debois 提出 DevOps 的關鍵所在。【注8】

圖5. 原生 DevOps 定位

圖6. 混亂之牆

圖7. 糟糕的交付讓敏捷回到瀑布

此時，讓我們站在圖1時間軸的2009年處，回看過去並眺望未來！向後看，敏捷已經有近10年的發展，圍繞持續整合的實踐已經比較成熟。

但傳統運維側的部署和運維領域裡的工具都尚待繁榮，而整個社群內只有為數不多的經驗可以用來指導 DevOps 實踐。

如 Flickr 的《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。

而向前看，2年後的2011年，《持續交付》這部重要的著作才會上市，業界和社群此時對持續交付尚缺統一的指導思想。

4年後，探討精益思想應用於開發運維工作中《鳳凰專案》才出版。在這種情況下，作為擅長流程改進的敏捷方法論祭出溝通和協作的大旗就順理成章了，而這也就反映在 DevOps 最初的圖中，如圖8。

另一方面，對文化的強調也得自於敏捷推廣過程中的經驗，自然地，這一部分也延續到了 DevOps上。

可以這麼說，早期 DevOps 就是敏捷通過開發向運維側延伸，它直接繼承了來自敏捷的諸多理念和實踐，尤其是許多年來精益思想在軟體行業的實踐，這一次在拉通整個價值流的過程中得到了更大的應用舞臺，如圖9。

圖8. 面向溝通與協作的DevOps

圖9. 來自IBM的DevOps

總結一下，在 DevOps 提出時，面對的問題從定製軟體的交付變成支撐業務的自研軟體的部署和運營，敏捷輕車熟路地將利益相關各方拉到一起，希望在統一業務目標的前提下，通過溝通和協作來消除部門間的隔閡，提高整個流程的效率。

有別於敏捷方法在處理軟體研發時所面對的情況，應用部署和運維是一個硬技術領域，其非常依賴工具和自動化，尤其是對於規模稍大的公司而言，源自持續整合的有關技術完全無法達到大規模 DevOps 預期的目標。

因此，溝通和協作帶來的效率提升在運維相關的工作上很快會達到天花板，接下來，一系列自動化工具的繁榮將會推動 DevOps 走到新的高度，同時，這也讓自動化運維成為 DevOps 的一種形態。

行文至此，讓我們再次回到最開始的問題，“DevOps是什麼？”。

與敏捷類似，DevOps 也沒有標準定義，我們只能對 DevOps 進行描述，這種描述或者如我們之前所做，陳述其發生發展的過程——從這一點上看，DevOps 就是一個運動；

或者是表述其預期的目標和作用的範圍，如開始處引用的 wikipedia 的描述。

在諸多類似的描述中，來自《DevOps: A Software Architect’s Perspective》的描述更為簡單直接——只要能夠在保證質量的前提下縮短程式碼提交到上線時間的實踐都是 DevOps：

DevOps is s set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

當從目標和範圍著手界定 DevOps 時，就會有所謂狹義 DevOps 和廣義 DevOps 的區分。

狹義 DevOps，如圖5所示，就是原生 DevOps，它只關心從程式碼變更提交到變更部署到生產系統並執行起來，其目標在於縮短這個週期時間；

而廣義的 DevOps，如圖10所示，它將整個軟體生命週期納入自己的範疇（即所謂的全生命週期管理），其目標在於提高整個業務的連續性。

此時，（廣義）DevOps 與敏捷的關係就變得微妙，這成為常常討論的主題，兩者的範圍似乎都可以包含對方。

其實，（廣義）DevOps 在具體工作層面上涵蓋了敏捷管理和研發方法，但在整個理論基礎上，敏捷思想（或精益）可以作為（廣義）DevOps 的理論基礎，用來指導整個軟體研發的全生命週期中的活動。

圖10. 廣義DevOps和全生命週期管理

2013年，Gene Kim、Kevin Behr和George Spafford 出版了《鳳凰專案 : 一個IT運維的傳奇故事》，這本書是敏捷和精益思想指導 DevOps 工作的里程碑式的著作。下面讓我們簡單回顧一下這本書。

《鳳凰專案》

這本書通過小說的形式，講述了無極限公司運維部的比爾在大神埃瑞克的幫助下，逐步將精益和 TOC 的諸多方法引入運維管理的過程。

這本書讀之親切的原因在於書中呈現的正是運維團隊的日常：大量的變更工作，混亂的流程，人員瓶頸，忙於緊急工作，以及研發與運維團隊糟糕的協同等等。作者通過一個個具體場景，為讀者演示了：

• 通過看板視覺化變更工作（精益）
• 通過發現約束點找出流程中待改進部分（TOC）
• 通過縮小批量和釋出間隔提高系統流動性（精益）
• 通過聚焦業務目標打破區域性優化（TOC）
• 通過減少在製品消除浪費（精益）
• 通過早期關注質量及避免缺陷傳遞來提高質量、消除浪費（精益）
• 通過分析問題根源來避免問題再次發生（精益）
• 通過標準化流程和工作來提高效率
• 通過區分工作性質來做合理的取捨
• 通過自動化降低人為錯誤的概率
• ……

更為重要的是，作者使用自創的三步工作法將這些套路組織在一個可以參考的框架內，並由此建立起一個從解決問題到建立反饋再到形成文化的整體流程。

毫無疑問，《鳳凰專案》通過假想的場景將精益思想可能帶給運維工作的變化描寫得深入淺出，而且還給出了從具體工作到文化建立的建議途徑，僅憑這幾點，其啟發意義和指導性就使本書很值得一讀。

當然，從關注業務連續性和精益思想的普適的角度看，將其歸於 DevOps 亦無不可，而且其方法完全可以作為過程改進型 DevOps 的典型代表。

但是，由於書中探討的場景僅僅侷限於運維組織內部而且通篇並無太多筆墨談及研發部分的運作方式以及研發和運維的協同、溝通方法，因此顯得美中不足【注10】。

之後，“鳳凰專案”還被設計成一款沙盤遊戲，以期讓參與者能夠在協作中切實地感知和體驗書本中的方法在整個故事場景中所帶來的作用。

雖然以遊戲化的方式建立初始認知是不錯的方法，但這樣的體驗對實際的操作有多大的指導作用則是見仁見智的事情了。

《鳳凰專案》可以說是精益（敏捷）思想向運維側擴充套件的代表。除此之外，研發和運維運維側的進步也演化出了不同的 DevOps 形態。接下來讓我們一起看看 DevOps 發展到今天形成了哪些不同的形態。

當前 DevOps 的幾種形態

如圖11，無論狹義 DevOps 還是廣義 DevOps，要提高整體流動性——無論區域性的程式碼提交到上線執行還是全域性的業務，我們需要處理兩種效率：

• 部門內部的效率
• 部門之間的效率

圖11. 軟體生命週期中的部門牆

我們應該先優化哪一種效率呢？從《目標》和《鳳凰專案》的經驗，我們應該首先找出制約點，也就是瓶頸，然後在瓶頸處進行優化。

否則，區域性優化有可能無法達到全域性優化的目的。舉個例子，如果研發團隊已經可以高質量快速地生產，那麼我們仍然一味地在研發部分投注資源去提高生產能力的話，只能造成更多的工作堆積到運維處（更多的在製品），全域性效率並不能得到提升。

然而，現實的情況是，很多被 DevOps 神奇功效所吸引的組織其自身研發還沒有梳理清晰，因此，這自然而然地就要將敏捷納入到 DevOps 的範疇之內。

也就是說，在研發自身還是問題的情況下，首先要處理研發內部的效率的問題，當研發效率提升後，瓶頸轉移至研發與運維的結合處，此時再次運用敏捷來進行協調，這就是 DevOps 的第一種形態：由敏捷落地，而後從研發向運維側擴充套件，如圖12。

圖12. 敏捷由研發向運維擴充套件

這種形態下，根據操作的方式的不同又可分成幾種形式：

第一種，最為原生的形式，專注在流程方面。

圖12. 敏捷匯入前軟體生命週期各階段的問題

這種方式通常會採用一些成熟的敏捷（或精益）實踐，對於研發和運維的之間的部門牆，則以提高溝通和協作為目標，建議嘗試《鳳凰專案》中的一些方法。

這種 DevOps 方式其本質就是敏捷，其適用於開始時研發側依然問題重重的情況，或者是運維被雜亂無章的工作束縛而使運維工作低效時。

這種方式的優點在於易操作、見效快，但缺點在於流程改進措施的天花板很快就會觸達，此時，自然就需要藉助第二種形態。

第二種，基於持續整合構建持續交付。

圖13. 敏捷匯入後，問題可能在於測試和運維部分低效

組織開始嘗試這種方式時已在內部採用了敏捷開發實踐，此時可能的問題常常在於測試團隊低效，如測試團隊仍然依賴大量人工進行迴歸測試，以及運維上線的低效。這種形式的主要指導思想是持續交付。

基於組織具體所處階段，其對持續交付實現的程度可能不盡相同，如圖14，對於小型網際網路公司，基於 Jenkins 的 pipeline 就可以快速搭建起可用的簡單持續交付環境。

圖14. 基於 Jenkins 的 pipeline 的極簡持續交付

但對於規模稍大、業務更為複雜的公司，可能就需要引入更多的開源工具，基於持續交付的理念來搭建整個持續交付工具鏈，如圖15。

近兩年環境和部署類工具的繁榮，使基於開源工具鏈的搭建越來越簡單，而 Jenkins 和 Docker 是其中最重要的兩個工具，目前，這是多數公司關注的階段。

對於規模更大的公司或者一些有著不同理念的企業，可能會有自研工具鏈生態的訴求，這個我們之後討論。

在此種形式下，有一點需要注意，即研發和運維團隊在生產上線過程中的職責劃分。

通常，出於安全和穩妥的考慮，會繼續將生產上線的職責放在運維團隊，並建立流程進行管控。

我們更建議儘量將整個應用運維的工作完全交給研發負責，包括生產環境的維護和上線，只要保證無關人員不直接登陸生產環境，以及保證資料安全性即可。

圖15. 基於Jenkins、Docker等開源工具的交付工具鏈

第三種，DevOps 認證

圖16. 證書的價值應該在於其能代表解決問題的能力

這是近兩年興起的事物，敏捷社群和大會上有關認證的討論至今尚無定論，而 DevOps 的認證加入則讓情況變得更為混亂，當然，這也從側面反映出 DevOps 的火熱程度【注11】。

不過，DevOps認證課程中源自《鳳凰專案》的沙盤推演確實可以像敏捷工作坊中的遊戲，幫助參與者瞭解套路後的理念、產生共鳴，但對於一個重技術的領域，這樣快餐式的佈道對實際工作的啟發和指導究竟能有多大作用，確實有待考證。

因此，DevOps認證需要更多來自一線的真實實踐資料的支撐，否則其不過是某種形式的安慰劑。而且據目前的瞭解，參與DevOps的認證者多數是運維人員。

但就個人的看法而言，為了達到軟體全生命週期的最高效的運轉，DevOps的出發點和落腳點最後都應該在於研發本身，運維應該成為幕後英雄。

今天，秉持類似理念的公司早已將研發團隊打造成多能團隊，做到近萬系統的高效研發和運營，如果我們還在滿足於玩這種家家酒，那可以認為是一種懶惰了……

除了敏捷從研發側向運維側的擴充套件，另一個的改進來自於運維側的發展，如圖17，這種情況常見於規模較大的網際網路公司中，如騰訊的織雲系統和阿里的運維平臺，Google 的 Borg 系統及相配套的 SRE 制度多少也可以劃歸到這一類中。

通常，此類平臺需要多年積累和打磨，其成本驚人。但近幾年由於像 Puppet、Ansible 和 SaltStack 這類的配置管理工具及 Docker 和 K8s 這類環境管理和資源排程工具的成熟，普通公司也可以快速建立起一套可行的自動化運維平臺。

此類平臺通常要麼是基於傳統 CMDB 或 ITOM，將應用組成和環境資訊的元資料管理起來，並根據這些元資料指導新的應用和環境的部署（有人將其稱為CMDB中心化），要麼是直接解決部署和資源排程自動化的問題。

這樣的平臺一旦成功，相應的流程和實現標準就都會圍繞其設立。這種聚集作用會將研發側的工作吸引到平臺上，或者圍繞平臺構築更為強大的工具生態。

圖17. 運維側的平臺搭建可以將研發側拉入

在這樣的平臺上，應用運維工作對於研發人員而言可以成為一種自助服務，運維人員就可以從此類事務性工作中脫身出來並將精力投注到更有挑戰性的工作上。

如果運維團隊還提供了監控平臺，甚至是測試平臺，可想而知，研發人員獨自運營系統將並非難事，研發和運維在應用運營上將無需溝通和協調，正是所謂的，最高效的協作是無（需）協作，最好的溝通是不（用）溝通。

雖然開源軟體的出現降低的平臺關鍵技術的難度，但此類平臺成功的最大挑戰卻往往不在於此。一方面，如何能夠抽象出一套簡單的體系，使不同業務都可以涵蓋其中，當新業務出現時平臺無需或只要做很小的改變；

另一方面，平臺的擴充套件性如何，是否可以很好地與軟體生命週期中的其它工具很好地協作？最後一點，對於操作人員而言，平臺功能是否足夠簡單易用。

至此，我們已經看到研發側向運維側的敏捷擴張，也簡單審視了運維側自動化運維平臺對研發側的拉動。現在，讓我們看看與DevOps相關的其它嘗試。

首先，我們來了解一下自研系統的必要性。

如圖18，DevOps 涉及的工作極為龐雜，開發到運營的每一項工作，本身就具有單獨成為系統的可能。

當業務本身相對簡單時，如前所述，我們可以圍繞 Jenkins 構建整個 DevOps 交付工具鏈，但隨著規模的擴大，Jenkins 本身的弊端就會顯現。

如圖19，Jenkins 承擔了從CI到部署的諸多工作。雖然Jenkins本身是平臺，具體的工作交給了外掛完成，但外掛的邏輯往往通過 Jenkins 內的配置或指令碼實現。

這一方面不利於大規模情況下的複用，而且在一些需要更為複雜操作的情況則需要大量工作，甚至無能為力。

比如，以構建為例，除了打包和部署前測試工作，我們很可能希望基於包的依賴關係進行相容性檢查，並按配置的版本規則將所有使用者的構建觸發起來進行驗證，在執行的過程中更新元資料以便後期系統組裝時可以參閱等等，這樣的工作交給一個構建系統則更為方便。

而且獨立的系統更容易抽象出 DSL，從而將程式設計性的工作變成宣告性（配置）的工作，極大地提高工具的易用性。此外，獨立系統也能夠考慮更為細節的工作，並快速演化。

圖18. DevOps 相關工作

圖19. 承擔太多職責的Jenkins

另一個促使我們希望自研系統的原因可能是量化資料的獲取和建立軟體全生命週期的管理。

今天，在運維側，與系統相關的資料獲取早已不是難題，通過 zabix，pinpiont，zipkin，ELK 等等工具，我們即可搭建起從資源到應用服務的全鏈路監控（雖然需要一些定製開發工作，而且效能可能也無法支撐大規模應用，但標準化的商用軟體非常成熟）。

而 DevOps 的工具鏈搭建似乎讓我們看到收集研發和部署資料，並將其與系統執行等資料拉通的可能性。

這個想法無比誘人，尤其是考慮到在這些資料上構建起的大資料應用，使我們有機會更深、更廣地瞭解研發和運維，從而真正對軟體全生命週期進行管理。

之前，基於開源工具搭建起的交付工具鏈可能並未考慮資料收集工作，而且其與軟體生命週期其它階段工具的配合也有問題。

此時，我們要麼需要對這些開源軟體進行定製化開發，要麼從頭開發我們自己的工具。

雖然處看起來，基於開源軟體的二次開發似乎更為經濟，但實際上，對大型企業而言，從頭開發往往才是捷徑。

其次，對於 DevOps 平臺我們該如何選擇？

如同我們之前討論，此類 DevOps 平臺也可分為研發側平臺和運維側平臺，研發側平臺通常集成了專案管理、持續整合、測試和釋出等功能，除了專案管理外，其它功能就是對 Jenkins 相關（外掛）功能的二次封裝；

而運維側平臺多數是在早期的 CMDB 基礎上，配備了元資料、測試和部署等功能，其實背後的引擎往往也是 Jenkins。

使用大一統的工具平臺可以幫助我們省去自己搭建和維護的成本，在好的情況下，還可以將最佳實踐通過工具固化下來，這對運維側的平臺尤其適合。

但對於研發側的平臺而言，我們就不得不考慮公司和團隊的現狀，因為需要遵循平臺給出的流程和使用方式，有時即便知道平臺給出的是最佳方案，但改變過於急進，失敗的風險很大。

研發人員是如此天生驕傲的人群，如果平臺不是公司為研發人員量身定製的，我們最好把搭建平臺的工作交給研發自己吧。

微服務與 DevOps2.0

DevOps 並不依賴微服務！ 這本來是兩個在各自世界裡獨立發展的概念。

微服務自誕生時起就被其所要求的獨立部署困擾，加之業務往往會拆分出大量微服務，這些服務的編排和治理也是難題。

這種狀況一直持續到基於 Docker 的不可變部署流水線出現後才得以改善，而這項技術是伴隨著 DevOps 運動發展起來的。因此，相對確切的表述是，微服務需要 DevOps 的相關技術來實現其部署和治理。

Viktor Farcic 在《The DevOps 2.0 Toolkit》中詳細介紹了使用基於容器的微服務來構築持續部署流水線。【注12】

DevOps下的團隊與角色

在敏捷的方法論中，我們以打造自治的全功能團隊為目標。在這樣的團隊中，我們通常會在團隊中配備儘可能全面的人員角色。

比如業務、產品、專案管理、開發、測試等等，由於部署和研發在組織上的分離以及我們對運維工作的傳統認識，運維人員通常不包含在這個團隊以軟體生產為目標的團隊中。

現實中，尤其在一些網際網路業務的公司內，功能上線的時間是在開發時就被強制確定下來的，這種情況下，為了保證之後研發與運維工作交接的順暢，以及讓運維人員及早做相應工作安排，在專案啟動時也會把運維人員拉人到啟動會議（或計劃會議）中。

圖20. 一種常見的全功能團隊組建方式

但在 DevOps 的情況中，系統的運維（運營）需求成為重要的需求，一個不易運維的系統最終將拖慢業務的連續性，因此運維人員的早期介入成為必然。

隨著整個工具鏈逐步成熟，這樣的全功能團隊中，最先受到衝擊的就是測試人員。

在部署流水線中，大量的測試將依賴自動化的技術完成，因此，對於通過人力密集型的方式進行測試的組織，精簡團隊勢在必然。甚至在某些技術產品中，測試團隊可以完全被取消，如圖21。

在我們企業的實際例子中，近百人的研發團隊中沒有設定任何測試崗位，測試工作要麼交由研發自身負責，要麼依賴自動化的分層測試解決。

在更為一般的情況下，研發團隊應該擔負起產品（或系統）的全部技術性測試工作，而精簡的測試團隊則應更專注於無法自動化的測試部分，如使用者體驗測試、可用性測試或者探索性測試等等。

圖21. DevOps 下的測試人員

其次，如我們之前探討，運維人員應該將應用運維的工作交由研發人員負責，這樣整個系統的研發和運營可以由最熟悉它們的人來全權負責——還是我們之前所說，最高效的協作是無協作。

如圖22，在這種組織結構方式下，我們對研發團隊的要求是盡力多能，當然這樣安排的前提在大型企業中，需要對應工作可以由自服務的工具很容易完成【注13】。

圖22. 研發多能下的組織結構

最後，讓我們再次強調，DevOps 應該起於研發，終於研發！

亞馬遜的啟示

組織的競爭優勢並不在於精益技術、盈利產品等解決方案本身，而是取決於組織根據現有條件制定恰當解決方案的能力。
——《豐田套路》

通常，我們認為 Google 的 SRE 是 DevOps，但當閱讀《SRE:Google運維解密》時，SRE 的負責人卻言之鑿鑿的說 SRE 是谷歌應對自己業務特點而創造出來的，雖然其形式在某些方面與 DevOps 暗合，但 SRE 本身不是 DevOps。

類似的情況也發生在亞馬遜身上，早在2005年亞馬遜已完成整個工具鏈和研發的全生命週期管理，當然，之後這個工具鏈的組成部分還是在不斷的演化。在2012年左右，內部構建系統基本每分鐘發起一次構建。

在2014年左右，亞馬遜內部的包（包括第三方依賴包）已超過12000個，假使50%是第三方包和陳舊的包，其它6000左右的專案包每兩個包組成一個獨立系統（一個應用包+一個配置包），整個亞馬遜保守估計有超過3000個生產系統在執行中，這些系統一般對應還有開發、測試等環境，也就是說有上萬的環境在運轉。

亞馬遜在沒有 DevOps 的指導下如何成功，以及伴隨這個問題的另一個有趣的問題——也可能是這篇文章中最為重要的問題就被提出來：在DevOps背後，最為重要的東西是什麼？

正如《豐田套路》中所說，隱藏在精益具體套路背後的分析和解決問題的思考方式和方法才是最重要的，因為，它可以幫助我們找出和建立起新的方法。因此，不要過於迷信 DevOps，看到自己的問題，義無反顧的思考並解決，共勉！

DevOps 再認識

最後，讓我們談談對 DevOps 的一些看法：

第一，軟體開發交付的應該是執行的系統。

由於執行的系統承載著運轉的業務，因此，從這個角度，研發團隊將對自身工作的定位有更為清晰的認識，圍繞研發的工作更容易統一目標。

圖23. 研發交付執行的系統

第二，誰構建，誰運營。

在這個理念下，建立多能的研發團隊，讓支援團隊從協作中逐步釋放職責。

當我們讓研發人員承擔起應用運維的工作時，就需要思考如何平衡研發和運維工作。Google 採用的是故障預算的方式，亞馬遜則由研發經理直接控制並使用卓越運營的方式進行調節。

圖24. 誰構建誰運維

第三，構建起兩個（反饋）閉環：

• 業務和研發（開發運維）的高效實施和反饋閉環，如圖24.
• 高效開發和運維的閉環（研發運維一體化），如圖25

圖24. 業務與研發閉環

圖25. 研發與運維閉環

第四，圍繞 DevOps 的文化、流程和系統要相互支撐，也就是說，在實施的過程中，要從業務出發，考慮組織和人員當前的情況，採用對應方式方法，不要急於求成。

當企業在初創階段，通過敏捷調理流程，基於CI構築CD可能就夠了；當業務上了臺階，需要更多的人員和支援系統時，可以基於開源軟體搭建工具生態，必要時構建自己和核心平臺（構建系統和部署系統等）；當企業規模更大時，自研完整的工具生態就非常必要了。

最後，優秀的 DevOps 工具鏈應該做到：

• 可配置、可重建、可追溯
• 自動化、視覺化、服務化
• 自服務
• 易用
• 資料驅動
• 自我演化

未來

隨著DevOps的成熟，下一階段的創新點在研發運維的資料運用，不難想象，一個全線拉通的體系不但能讓我們對業務和系統有更細粒度的洞察——建立全鏈路監控，甚至是全生命週期監控，而且人工智慧的引入還能讓我們構建出新的能力，如異常點檢測、根因分析等等，這就是智慧化運維（AIOps）。

毋庸多言，現代IT企業的發展走到了一個加速分化的階段。將優秀產品推向使用者的成本和速度將成為決定企業生存與否的關鍵因素之一。

優秀的網際網路企業已裝備精良並持續優化，新興企業是否還要日以繼夜的趕工，亦或趁此機會構建出自己的能力壁壘？

理論和工具已在手中，時不我待，行動起來……

註釋

注1： wikipedia 上對 DevOps 的描述本身也隨著業界對 DevOps 的認知在不斷的更新，如下所示是自2010年至2017年的 DevOps 描述內容。

通過對比我們不難發現，業界對 DevOps 的認知逐漸擺脫了早期敏捷的影響，例如，最新的描述已不再突出強調溝通和文化，轉而更為務實地將重心放在業務目標下的高效研發運維實踐層面！

2010年5月：

DevOps is a new term to describe the emerging understanding of the interdependence of development and operations for IT organizations to meet the business’ goal of producing timely software products.

It is an important topic where new development methodologies (such as agile) occur in a traditional organization with separate departments for dev, IT operations and QA.

Development and deployment activities that did not previously need deep cross-departmental integration with IT support or QA, now require intimate multi-departmental collaboration.

DevOps concerns more than just software deployments, however. It is a way of thinking about communication and collaboration between departments.

2010年9月：

DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering), Technology Operations and Quality Assurance (QA).

It relates to the emerging understanding of the interdependence of development and operations in meeting a business’ goal to producing timely software products and services.

2011年3月：

DevOps is an emerging set of principles, methods and practices, pioneered by network operations visionary Jordan Redner, for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals.

It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

2012年5月：

In computing, “DevOps” (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals.

It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

2014年9月：

DevOps (a portmanteau of “development” and “operations”) is a concept dealing, among other things with software development, operations and services.

It emphasizes communication, collaboration and integration between software developers and information technology (IT) operations personnel.

DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

2014年12月：

DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration and integration between software developers and Information Technology(IT) professionals.

DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

2015年1月：

DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement cooperation between software developers and other information-technology (IT) professionals.

DevOps acknowledges the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services and to improve operations performance – quality assurance.

2015年3月：

DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement of cooperation between software developers and other information-technology (IT) professionals.

DevOps acknowledges the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.

2015年5月：

DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.

2015年9月：

DevOps (a clipped compound of “development” and “operations”) is a software development method that emphasizes the roles of both software developers and other information-technology (IT) professionals.

2015年11月：

DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.

2016年11月：

DevOps (a clipped compound of development and operations) is a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

2017年6月：

DevOps (a clipped compound of “development” and “operations”) is a software delivery process that emphasizes communication and collaboration across the end-to-end value stream from concept to market, including product management, software development, and operations professionals;

while automating the process of software integration, testing, deployment and infrastructure changes.

It aims to establish a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

2017年7月：

DevOps (a clipped compound of “development” and “operations”) is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals.

It supports this by automating and monitoring the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

2017年9月：

DevOps (a clipped compound of “development” and “operations”) is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops).

The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.

DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

注2： ThoughtWorks的高階諮詢師有文章講DevOps提出的歷史，感興趣的請移步 DevOps 編年史(http://www.jianshu.com/p/f40209023006)。

注3： 國內通常稱為企業整合商。

注4： 《人件》裡就不無對大方法論的批評和戲謔：

Big M Methodology is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by the staff assigned to do the work.

(Big-M) Methodologies can do grievous damage to efforts in which the people are fully competent…
—- Peopleware Charpt 17, Tom Demarco & Timothy Lister

Process Improvement:
IS It Turning Us to the Dark Side?
—- Peopleware Charpt 29, Tom Demarco & Timothy Lister

注6： 這些方法有：

• XP | Extreme Programming（Kent Beck）
• SCRUM（Ken Schwaber）
• Lean Software Development（Mary Poppendieck）
• DSDM | Dynamic System Development Method（Dane Faulkner）
• FDD | Feature Driven Development（Jeff Deluca）
• Crystal（Alistair Cockburn）
• Adaptive Software Development（Jim Highsmith）

如今，主流的敏捷方法集中在 Lean、Kanban和Scrum上，雖然XP作為方法論的實踐者已寥寥，但 XP 提出的諸多優秀工程實踐卻被其它方法吸收到各自的體系中得以發揚光大，有些實踐甚至可以說自己都已經成為了單獨體系，比如持續整合。