「作好DevOps便是用好一種工具」的認知誤區

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

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

1、DevOps的本質究竟是什麼？

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

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

那麼DevOps帶來哪些改變呢？

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

DevOps帶來的最大好處是，軟件生命週期數據鏈路的打通。

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

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

2、DevOps適用全部企業嗎？

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

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

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

3、談談一個改造案例

這裏給你們分享一個改造案例，公司A存在的問題：

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

2. 人員分工不明確，一個決定的作出每每須要不少人蔘與。

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

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

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

改造步驟：

第一階段：

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

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

第二階段：

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

行動：公司A開始關注工具所提供的能力而不是功能，將不一樣工具的關鍵交付物鏈接起來，造成可追溯的管理。開發人員發現提交的代碼能夠產生可用構建後才聲明功能完成。而且用同一個任務來追溯開發到上線的工做。尤在開發與運維結合方面，運維人員能夠利用開發人員已經實現的部署設計，進行發佈演練，確保軟件平滑交付。

第三階段：

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

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

第四階段：

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

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

其實從以上的例子能夠看出，一個好工具的運用會對工做產生積極的影響，可是更核心的是人作事思惟，以及人與人之間的協做方式纔會體現DevOps的好處，我想從這點你們能夠看到爲何DevOps是一種Mindset。

4、也談談微服務、容器和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，變成了能力。一個迷你服務提供一種能力，這種能力的提供也許是跨越多個域的。

• 最好的方法是以一個團隊能承擔的任務劃定微服務的界限比較好，這樣以來，不管是任務管理，代碼構建，產品部署都會比較好作。
• 更關注服務的能力，這樣也會減小由於跨域而帶來的復瑣事物處理。

5、但是，爲何落地DevOps仍是那麼難？

我認爲DevOps概念對市場的教育工做已經完成了，而且它宣傳在國內有點氾濫的趨勢，甚至一些之前作項目管理工具的廠商也宣傳他們在作DevOps。究其緣由在於DevOps的概念太大，幾乎能夠成爲軟件工程的代名詞。

至於落地的痛點，我以爲有如下幾個：

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

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

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

4.  認爲有了全生命週期的工具就是DevOps，忽略了軟件過程方法的運用，因此不少組織停留在用舊的方法使用新的工具上。

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

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

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

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

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

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

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

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

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

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

原文來自：https://www.linuxprobe.com/devops-tool.html