任何變革都需要時間，DevOps亦然。在經過數年的蟄伏期之後，DevOps終於成為了業界聚焦點；不過，從知其然到知其所以然，再到最終完美實現DevOps，依然前路漫漫。

在普元資訊高階軟體架構師胡帥看來：DevOps 概念很大，幾乎可以成為軟體工程的代名詞；但可惜的是，目前存在著“做好DevOps即是用好一種工具”的認知誤區。近日，國內著名技術社群InfoQ對胡帥進行了採訪，他認為DevOps是在理念層面對開發運維一體化進行倡導：好工具的運用誠然會對工作產生積極影響，但是更重要的是它會改變人的做事思維和人與人之間的協作方式，也只有這樣才能發揮DevOps的最終好處——打通軟體生命週期的資料鏈路。

一、DevOps的本質到底是什麼？

DevOps從本質來講只是倡導開發運維一體化的理念（MindSet）。這個理念的提出是為了解決很多企業面臨的轉型挑戰，也就是將業務數字化，並且縮短數字化業務上線的週期，快速試錯，快速佔領市場。

DevOps並沒有改變固有的軟體生命週期：需求，設計，開發，測試，交付。但伴隨著基礎設施，軟體設計方法等的改變，軟體開發的思路，或者方式產生了比較大的變化。

那麼DevOps帶來哪些改變呢？

• 以Viktor倡導的DevOps 2.0舉例，以PaaS平臺為基礎設施，用微服務的架構進行應用開發正當其時。當然這本書是以工具（Toolkit）的角度來講DevOps，如果再加上敏捷的心法，就更加有操作性了。
• 另外在以前，軟體過程實踐都會詳細定義每個階段的參與者、工件等。而敏捷並沒有這麼做，一個原因是敏捷會將不同階段打碎後揉在一起。但認真思考，我們發現這種大而化之的方式需要用例如Workitem等更快速的定義工作，並且建立工件之間的聯絡，貫穿軟體生產交付過程始終。

DevOps帶來的最大好處是，軟體生命週期資料鏈路的打通。

這不僅僅是運維和開發的結合。從頂層視角看，這是業務和生產的緊密結合。以前從業務和開發是脫節的。想要檢視需求的實現進度，需要大量的人工彙報，更別提運營了。而現在以一個微服務實現一個特性的粒度來看，可以從需求，開發，測試，部署一直追溯到這個特性運營情況。這也是DevOps成為數字化企業基因的原因，業務和生產實現了完美的結合。

從敏捷實踐的角度來講，你會發現開發組織中參與者好似生物體中的神經元，大家各司其職，自成一體，接受反饋，並向外主動反饋。團隊的自組織使得工作更加自然，能產生更大的效能。由以前的專案經理驅動，改為自我驅動的協作方式。每個人都可以給相關的團隊以及責任人提需求，大家有機的協調在一起。

二、DevOps適用所有企業嗎？

談到DevOps適用性的問題，其實DevOps並不存在不適用的問題，只有做的好不好的問題。試問哪個組織不想讓開發和業務結合的更緊密呢？我想這個問題更多的是如何選擇軟體過程的問題。用目前比較流行也飽受爭議的敏捷為例，我們知道敏捷的兩大精髓是“自組織文化，和集體責任感”。所以在實施敏捷之前我們必須考慮以下幾點：

• 需要嚴格設計和詳細文件的專案：敏捷利用逐步細化的方式來擁抱不斷變化的需求，也就是說敏捷不太適合需要一開始就將所有的需求分析，系統設計做的非常詳細的專案。
• 自組織文化：如果一個組織長期採用命令式的管理方式，一線團隊的開發人員沒有決定權，那敏捷是無法實行的。一個團隊中缺乏自主意識，自組織的文化很難形成。
• 快速試錯：用軟體模擬試錯的代價相對較小，但是用硬體試錯的代價比較大。所以是否能控制敏捷所帶來的成本風險，也是企業需要考慮的問題。

然而一些以前很傳統的企業，比如說銀行，汽車製造等瀑布模型的忠實粉絲們也正在逐步進行敏捷轉型，總之，沒有什麼是萬靈藥，要因地制宜的進行軟體過程，設計方法，以及工具平臺的選擇。

三、談談一個改造案例

這裡給大家分享一個改造案例，公司A存在的問題：

1. 軟體交付週期很長，一年只能交付一個大版本，以及一個小版本。

2. 人員分工不明確，一個決定的做出往往需要很多人蔘與。

3. 用大量的時間挖掘需求。在真正的開發期，會發現使用者的需求仍在改變。需求分析的時間被浪費。

4. 採用瀑布模式開發，在不同時期，某些角色的人員會無事可做。

5. 在軟體交付過程中，開發與運維人員需要花費大量的時間去協調產品安裝，配置中出現的問題。

改造步驟：

第一階段：

行動：為了實行DevOps，公司A為不同的生命週期購置了支撐工具，涵蓋JIRA, PagerDuty，GitHubEnterprise，Jenkins等。公司針對每個工具都進行了專門培訓，專人管理。

結果：大家開始將不同的工具應用到軟體生產的各個環節中，統一的工具塑造了統一的工作方式，創造了工作契約。統一工具的運用確實對軟體交付帶來了一些積極的改變。

第二階段：

問題：各個工具仍舊是割裂的，程式碼管理和任務管理無法協調。開發人員宣告已經完成的工作，測試人員卻發現無法找到構建來完成測試。運維人員和開發人員只是利用了同一種工具，而沒有做到工作產物的共享。

行動：公司A開始關注工具所提供的能力而不是功能，將不同工具的關鍵交付物連線起來，形成可追溯的管理。開發人員發現提交的程式碼可以產生可用構建後才宣告功能完成。並且用同一個任務來追溯開發到上線的工作。尤在開發與運維結合方面，運維人員可以利用開發人員已經實現的部署設計，進行釋出演練，確保軟體平滑交付。

第三階段：

問題：有了好的工具，但是公司A發現雖然開發到運維的路通了，但是軟體質量卻難以保證，甚至在產品釋出日期鄰近的時候，仍有很多未完成的任務，測試團隊頂著很大的壓力，最終還是會發生不少測試逃逸，產品的技術欠債比較大。

行動：在開發階段採取分支開發的方法，功能實現並且通過一定的程式碼測試之後才能合併到主幹。開發人員負責部分的測試任務，由於對產品比較熟悉，所以加快了測試效率。專門的測試團隊會承擔例如效能測試等更加專業的測試任務。有節奏的控制軟體開發的進度，在軟體釋出的穩定期嚴格控制程式碼提交，每個新功能的開發負責人會和運維人員一起進行釋出演練，DevOps的好處終於開始見效。

第四階段：

問題：團隊前期在需求分析中會花費大量的時間進行文件編寫，但開發開始後，開發人員會花費大量的時間對文件進行理解，並且使用者對需求的調整最終導致文件失去維護的意義；大家的主動性不強，需要領導的督促才能進行工作安排。

行動：公司A意識到他們之前只是採用看似敏捷的方式，實際瀑布的方式做開發。比如說專案經理變成了Scrum主管，週會變成了每天的站會。在進行調研分析後，公司A決定開始進行敏捷實踐。分階段的按照重要程度以及優先順序進行需求規劃，週期性的互動使得客戶在第一時間可以看到期望的需求被逐步實現，雙方都避免最後一科的意外。開發人員發現可以對自己負責的任務有話語權之後，大大激發了積極性，大家開始主動的從Backlog中尋找重要的任務去實現。

其實從以上的例子可以看出，一個好工具的運用會對工作產生積極的影響，但是更核心的是人做事思維，以及人與人之間的協作方式才會體現DevOps的好處，我想從這點大家可以看到為什麼DevOps是一種Mindset。

四、也談談微服務、容器和DevOps的關係

怎麼看待微服務、容器對DevOps的重要性呢？其實並不是說DevOps就一定要以敏捷的軟體過程開發過程來驅動微服務開發，並且以容器為物理交付單位，執行在PaaS平臺上。而是他們結合在一起形成了一個敏捷化的企業軟體開發體系，為企業的業務敏捷提供了開發保障。

• 微服務只是一種設計思路，或者說他給出瞭如何用正確的方法來進行SOA的實施（SOAdone right）。理論上來講他的確和DevOps沒什麼關係，但是從如何實踐DevOps的角度來講，微服務是非常有意義的。此外，隨著諸如Spring Cloud以及微軟Fabric等SDK的完善，微服務開發模式也逐步完善，實現了概念的落地。
• Docker可謂是一種敏捷化的虛擬化技術（較之虛擬機器而言）。其實微軟Fabric或者CloudFoundry也都脫離開容器的概念提供了微服務開發的解決方案，所以這兩者並不是強繫結的關係。但是容器用不可變配置架構實現了微服務從開發到運維的質量保真度，這恰好解決了粒度小，數量多的微服務所帶來的運維難題。再加上K8S，Swarm等容器雲的支援，docker容器已經形成了事實上的標準。

• 如何利用這個強大的執行環境幫助企業敏捷，推進業務數字化，並且加快業務的投產？ DevOps為上面所說的開發模式提供了軟體生產線。

所以總結的來講，企業業務敏捷是DevOps發展的直接推動力，容器雲，以及微服務為DevOps提供了技術可行性。而敏捷幫助提高DevOps工作效能。

對於團隊的拆分，這個問題真的要結合產品規模來看。團隊的拆分有很多辦法，貝索斯說的two pizza team，是建議一個團隊中的人儘可能少，不要超過兩個Pizza能吃飽的規模。用敏捷實踐來講，可以分為多個特性團隊，以及維護團隊，不同的團隊各司其職，合理分工。在我以前的實踐中，三個人可以做一個Feature，來交付一個月迭代的工作量。

當然將原有的巨石應用分割成更小的微服務是挑戰很大的事情。

因為理論上的微服務的設計對現有的團隊組織結構，以及工程師設計能力都帶來了一定的挑戰。有些組織按照DDD（領域驅動的設計）的方式去實踐微服務，會發現以前一個應用的複雜度變得很高，對專案管理來講也是一件頭疼的事情。現在有個比較新的看法就是，大家宣稱做微服務（MicroService）的時候，實際上做的是迷你服務（MiniService）。迷你服務的粒度較之微服務的粒度更粗一些，關注度由一個域Domain，變成了能力。一個迷你服務提供一種能力，這種能力的提供也許是跨越多個域的。

• 最好的方法是以一個團隊能承擔的任務劃定微服務的界限比較好，這樣以來，不論是任務管理，程式碼構建，產品部署都會比較好做。
• 更關注服務的能力，這樣也會減少因為跨域而帶來的複雜事物處理。

五、可是，為什麼落地DevOps還是那麼難？

我認為DevOps概念對市場的教育工作已經完成了，並且它宣傳在國內有點氾濫的趨勢，甚至一些以前做專案管理工具的廠商也宣傳他們在做DevOps。究其原因在於DevOps的概念太大，幾乎可以成為軟體工程的代名詞。

至於落地的痛點，我覺得有以下幾個：

1.  DevOps對於組織來講是一個系統工程化的投入，在貫徹的過程中，需要一個組織建立標準，統一紀律，而這個過程往往需要組織中的強力部門自始至終的貫徹執行。

2.  DevOps對組織現存的管理方式，或者人員知識結構多少帶來了一些挑戰。

3.  認為購置了工具就是DevOps，卻忽略了工具產物之間的聯絡。

4.  認為有了全生命週期的工具就是DevOps，忽略了軟體過程方法的運用，所以很多組織停留在用舊的方法使用新的工具上。

開啟DevOps工具和文化缺一不可。DevOps的最高目標是讓組織內的人都具有相同的工作理念，最終形成一種工作文化。而有些倡導者談到如何去培養這種文化就顯得有點空談了。我認為在形成DevOps文化的過程中，敏捷實踐必不可少。過去的敏捷實踐更多的是在開發階段，而現在DevOps的理念下，其實可以很順暢的將部署階段的事情也納入敏捷實踐中。讓合適的人去做合適的事。當然團隊文化的改變需要一個過程。有本說中說文化的改變很難，還是從行為的改變開始吧。我認為以敏捷方法為核心配合以下三個方面來開啟DevOps。

• 看板：以任務的狀態為核心，管理在製品的生產情況。任務是自組織團隊的工作契約。
• 基線：以工件的版本為核心，選取合格的交付物。比如說開發團隊決定哪個程式碼提交版本，或者編譯的構建版本為最終交付的版本。度量指導基線的產生。
• 流水線：以生命週期的階段為核心，控制基線交付物的投產。比如說一個合格的程式碼基線目前處於編譯態，還是部署態。自動化工具圍繞管道互相整合。

其實工具和文化最終的落實還是要靠人的提高，特別是通過上一段舉出的例子。

DevOps會重新塑造IT組織的研發系統，從工具到文化，再到方法。因此參與這個生態系統的所有人都應該關注。

• 從開發的角度看：開發人員會變得更加業務化，有更多的機會和客戶交流。開發人員將從以前對程式碼負責，轉向編譯構建負責，對測試負責，甚至對部署物負責。敏捷可以讓需求足夠的小，這樣就可以讓一個開發人員變得全生命週期化了。
• 從運維的角度看：其實運維的前景是有些悲觀了，至少運維的規模要縮減很多。原因有三。首先，自動化部署工具的發展，使得部署工作提前了，以前碎片化的指令碼，被更加規範化的部署設計代替，用設計驅動指令碼生成，這都是自動化的。其次，基礎環境的改善使得開發環境和生產環境的差異性極大縮小了，企業完全可以製造一個和生產環境一樣的預發環境，來保證交付的成功率。容器技術的不可變配置也保證了同樣的映象在不同的環境中不會出現太大的差異。最後，運維工作相對開發工作來講，可以自動化，甚至運用人工智慧的空間都比較大。我們已經看到百度已經開始AIOps。

六、寫在最後：用好DevOps這把雙刃劍

國內很多開發組織對於產品規劃和開發設計把控很嚴格。相反，對於開發過程管理不夠。不能認為使用了某個工具，就萬事大吉地實現了DevOps，這樣只能帶來更多的問題。

DevOps可以幫助企業的開發和業務緊密結合，加快數字化業務上線的時間，從而快速試錯、快速佔領市場。但是，速度快了並不一定可以確保質量。DevOps是一把雙刃劍：就好比有了好的廚房，並不意味著一定能做出一桌好的飯菜。關注點還是應該放到如何提高廚師技能方面來。

如何做才能避免DevOps所帶來的負面問題並把控好風險？

所謂的工程化，用標準和自動化來規避人員能力差異所帶來的風險，並且提高單個參與者的效能。工程化的重要途徑就是軟體度量，在文章開篇胡帥就闡明：DevOps帶來一個實質變化就是資料鏈路的形成。如何能利用好這些資料？如何向開發者和管理者提供決策支援？這是DevOps未來發展的一個重要方向。

文章來自微信公眾號：DevOps