企業實施DevOps的七大挑戰
DevOps 這個詞在近年來可謂大火。從 2014 年底我開始給一些企業做持續交付/DevOps 相關的評估和咨詢，似乎每個企業都表示想要推行 DevOps，或者說他們正在做 DevOps。這把火蔓延的速度遠遠超過當年敏捷在 IT 行業的傳播。然而有些企業管理者對 DevOps 的認知讓我們意識到，由于各種有意或無意的因素，這個概念不幸地成為了一個讓人困惑的 buzz word……
什么是 DevOps？
這里我想列出四種我們在市場上、企業咨詢以及社區交流過程中接觸到的認知：
- 一些企業的運維部門找我們，說要搞 DevOps。我請他們約開發部門的同事一起來溝通，卻得到類似于“不用管他們，我們自己搞……”的回復。再問那打算搞啥呢？答案可能是“我們想談談自動化運維……”。
- 另一種認知是，敏捷宣言提出了“業務和開發要緊密協作，擁抱變化，將變化視為提升價值的機會而非麻煩。”那么 DevOps 則是將敏捷思想向運維延伸，通過開發和運維的緊密協作，讓交付的最后一公里也能擁抱變化，兼顧吞吐量和穩定性。
- 進一步，有些企業提出了自運維“No-Ops”理念，讓運維的職能融入產品交付團隊，由團隊自主、自助地完成部署發布，同時自己承擔線上問題支持等工作，完全讓運維工作去中心化，實現“Who build it, who run it”。
- 我們還看到，一些咨詢或解決方案廠商的宣傳將 DevOps 刻畫成了一個全新的、從設計、需求到發布運維端到端的研發體系，似乎有了 DevOps 這把榔頭，軟件研發的各種問題都解決了。有了 DevOps，苦逼的程序員們就迎來解放了…
作為企業管理者，要在組織中引入 DevOps 并推動變革，首先要對 DevOps 的目標有清晰的認識，并明確 DevOps 在自己企業的上下文中意味著什么。我反對一些廠商將 DevOps 吹得太大，但這也絕不僅僅是運維單方面的目標。DevOps 運動本質上是關于開發（含測試）和運維的協作，在“為用戶創造最大化價值”的一致目標下，讓軟件交付給用戶并獲得反饋的過程更加敏捷。至于要不要將開發運維一體化，則取決于具體產品的特征，在不同場景下可以有不同的協作模式。
DevOps 行業報告提出了兩個頂層的用于衡量 IT 組織效能的指標：吞吐量和穩定性。在一些人看來，這兩個目標就像魚和熊掌不可兼得。追求交付吞吐量，就會帶來更大的不穩定性和風險；而傳統運維管理以穩定性為目標，就必然犧牲對變化的響應力。之所以會有這樣的悲觀認知，是因為僅僅站在當前的時空看待問題，而無法超越自己的能力局限。企業管理者需要理解，進行 DevOps 轉型，就是要超越自己的能力局限，超出當前的時空看問題，通過組織設計、過程改進和工程技術的提升讓組織能力上升到一個新的維度，我們完全可以做到同時提高 IT 交付的吞吐量和穩定性，而不是在兩者之間取舍平衡。
然而，要突破自身的能力局限，這并非易事。下面談到的實施 DevOps 過程中的七大挑戰中的每一個都需要組織下決心投入，并耐心等待回報，沒有足夠的認知轉變和卓越領導力難以實現。
挑戰一：自動化測試投入不足，收益低
敏捷宣言自提出時，就已經將自動化測試作為敏捷、極限編程的核心實踐來強調。然而這么多年過去了，在組織中真正有效進行自動化測試的并不多，各種問題都在影響著組織和團隊對自動化測試的信心。
要想同時提升吞吐量和穩定性，以自動化替代手工方式快速、頻繁的對軟件質量進行驗證是首要的手段。如果說在以往談論敏捷開發的時候，自動化測試是對團隊的較高要求，那么到了 DevOps 時代，這就是最基本的入門要求。毫不夸張的說，如果軟件系統沒有一套較完善的自動化測試體系，就請不要談 DevOps 了。
最直接的問題是投入不足。很多管理者意識里是將自動化測試看做一項額外的、可有可無的任務。他們關注的是短期的項目管理目標，而不是長期的產品持續演進，往往只有進度壓力不大的時候才投入人力來做一做，或者單獨聘請一個團隊來補充測試用例，然后離開，而不是作為開發團隊交付軟件產品的一部分。這樣的模式很難產生一套長期有效的測試套件，反過來進一步削弱了管理者對其進行投入的信心。
另外常見的一些問題包括：
- 缺乏對自動化測試策略的正確認知，過多集中在界面上做測試，缺少單元測試和 API 測試。界面功能測試案例的開發和維護成本高，執行速度慢；想想上千個案例全部執行完可能需要跑上半天、一天，然后有幾十個案例因為環境或網絡問題而執行失敗，卻不是因為代碼問題。結果是我們看到不少團隊從來沒有一次將所有案例全量執行過，只能每次手動挑選一部分案例來跑。
- 缺乏一套獨立的自動化測試環境，而是和手動測試共用一套環境。這種做法一方面會導致自動化測試和手動測試在資源和測試數據上相互影響，使得測試不穩定；另一方面自動化測試過多依賴外部集成環境，缺少必要的依賴隔離，使得測試案例執行不穩定、執行效率低。
- 自動化測試、手動測試和生產等各環境不一致，使得自動化測試的結果不夠可信。
- 由測試人員或單獨的團隊來寫自動化測試，而不是讓開發人員寫。這首先導致開發人員在設計和編碼時很少考慮為了更高效穩定的自動化測試進行優化，加大了測試開發的難度；其次測試人員必須等到開發基本編碼完成了才能開始寫測試案例，并且需要請開發人員講解 API 或界面元素的設計，這是一個低效的過程，浪費時間。
- 沒有將自動化測試納入持續交付流水線自動化地頻繁執行。我們看到不少團隊是在完成手動測試后、上線之前選擇性地執行自動化測試案例來進行回歸；這樣的用法沒有最大化其價值，對質量的反饋速度太慢。
要解決以上問題，并產生一套有效的自動化測試套件是一個巨大挑戰，需要管理者和團隊轉變質量意識；需要企業從項目化的管理轉向產品化的管理，人們才能真正長遠地去考慮對自動化測試的投資；需要影響業務人員在需求容量上的期望，為書寫自動化測試提供時間。
挑戰二：高度集中的 IT 基礎設施服務
在傳統模式下，像服務器申請、配置變更等 IT 服務是由高度集中的基礎設施管理團隊負責。產品交付團隊需要向集中的 IT 服務團隊提出申請；而該團隊往往承接著來自很多交付團隊的需求，于是只能將請求進行排隊依次處理，并且主要依靠手動處理；結果是交付團隊不得不長時間等待，才能得到所需資源。這個過程中的手動操作，使得經過一段時間后，基礎設施的配置變成了一個黑洞，沒人能夠說得清各個服務器之間的狀態差異，當問題出現時需要耗費很長時間來進行分析定位。我把這樣的時代稱之為 IT 基礎設施服務的“農耕時代”。
IT 基礎設施的管理要更加敏捷，提高變更吞吐量并同時提高穩定性，首先需要在基礎設施的管理上實現這四個目標：
- 標準化
- 腳本化
- 版本化
- 可視化
在此基礎上，基礎設施管理團隊不再排隊處理所有交付團隊的請求，而是專注于提供一個基于標準化、腳本化、版本化和可視化方式管理基礎設施的自助服務平臺；組織授權給各產品交付團隊利用平臺的能力，以代碼化的方式隨時按需進行基礎設施的準備和變更。縮短等待時間的同時，因為進入生產環境的基礎設施變更已經以一致的方式在各個測試環境經過了驗證，減少了人為手動操作可能引入的錯誤和遺漏，確保了各個環境的一致性；也讓前期的自動化和手動測試更加可信，從而使得系統的穩定性也得到提高。這樣一個模式我稱之為 IT 基礎設施服務的“云時代”。
對企業來說，從這種基礎設施管理集中式控制向去中心化授權的轉變也是一個巨大挑戰。首先基礎設施自助服務平臺的建設需要投入；更重要的是，能夠授權交付團隊依賴自動化方式，而非人工來保障基礎設施配置的質量，本身就需要管理者的思想轉變。在我看來，一些管理者傾向于依靠人來控制，而不信賴經過反復驗證的自動化過程，只有一個原因：人出了錯可以追責和懲罰，而自動化過程出了錯，不容易找到某個單一的人來擔責，總不至于懲罰機器。
這里還有一個挑戰不得不提，這種轉變帶來了傳統運維模式下運維人員的技能要求轉變，從以往手動的服務器操作，變成需要寫 DSL、需要會編程。這必然影響到一群人的職業發展，這會給變革帶來阻力；企業應當給這群人提供足夠的培訓，提供新的職業發展機會。
挑戰三：部署與發布未分離
在產品交付團隊追求頻繁變更、提升交付吞吐量的時候，即便進行了嚴格的同行評審、通過了完善的自動化測試、確保了基礎設施環境的一致性，但由于周期短、頻率高，要平衡投入產出的收益，在軟件進入生產環境時，還是有風險存在。因此一些管理者無論如何不敢在部署發布流程上進行放權，減少審批控制。這種不安全感是來自傳統的發布過程缺少一種安全性策略，也就是沒有將“部署”與“發布”分離。
“部署”和“發布”是兩個不同的詞，然而很多年里當提到將軟件最后發布給用戶使用時，兩個詞通常是混用的。為什么呢？以往，我們將軟件發布給用戶的手段很單一，就是將軟件部署到生產環境跑起來，用戶就可以用了，這兩個詞所代表的動作是同時完成的。
要讓發布環節變得更加安全，就需要將這兩個動作分離。“部署”即是讓新的或修改的軟件安裝到目標環境上運行起來。這應當是一個技術決策，即是否執行這個動作應當完全由技術團隊依靠對變更進行的同行評審和測試來決定，隨時可以執行。這個動作過程中，技術團隊重點關注的是：
- 部署過程自動化
- 版本更新過程對用戶無感知
- 能夠快速回滾。
而“發布”應當是一個業務決策，即允許業務和產品人員來控制新特性對用戶的可見性。首先對受控的小范圍用戶開放，經過一段時間的反饋信息收集，包括對系統穩定性和用戶行為、喜好的觀察，然后決定是否將其開放給更大范圍的用戶。如果系統存在質量或設計問題，可以很快關閉新特性，或回退到舊的版本。在這個發布的過程中，交付團隊和業務人員重點關注的是：
- 系統穩定性
- 用戶實驗反饋
要實現這樣的分離也是一個很大挑戰。首先技術上，需要引入藍綠部署、金絲雀發布，以及特性開關等手段；但要讓每個團隊都自己去建立這樣一套機制成本太高，企業需要從平臺戰略的角度提供這樣一種便捷的能力來實現靈活可配置的在線受控實驗；另一方面，這樣的分離意味著重新定義了在軟件部署發布過程中 IT 團隊和業務人員的職責，需要 IT 和業務的緊密協作。
挑戰四：缺少自助式的持續交付平臺
DevOps 不僅僅是關于運維的自動化，同時也是關于開發、測試到運維各個職能圍繞著每一次軟件變更的緊密協作。在這個過程中，開發關心的是代碼庫、編譯、構建；測試關心的是測試驗證和測試環境；運維關心的是部署與發布控制、監控及支持等，各個環節的任務涉及到一系列工具構成的工具鏈。然而在對很多客戶的調研中，我們發現普遍存在的現狀是：
- 開發、測試和運維各自有自己的一套工具來完成自己關心的任務，而這些工具既不相同，也不相互關聯；軟件包在不同工具之間的轉移更多依靠人工來完成；
- 由于工具上的割裂，每個人并不清楚同一個變更在其它角色哪里到底發生了什么，也不關心；
- 由于從獲取代碼、編譯、掃描、構建、測試、部署、發布到獲得反饋的整個過程中涉及到很多工具的運用，很難有哪個團隊能夠靠自身力量在每一個環節都做得成熟。
要在企業中實現 DevOps，有一定規模的 IT 企業非常需要給產品交付團隊提供一個軟件持續交付平臺，讓軟件從代碼提交構建到交付給用戶的整個過程得以在這個平臺上完成，包括所有自動化任務的配置和調度，支持信息可視化輻射，和內建一些必要的流程控制環節，例如操作權限和信息審計等。這樣一個平臺應納入 IT 企業的戰略性平臺之一，其價值我認為有幾點：
- 作為一個杠桿，在規模化的組織中撬動各個交付團隊的持續交付/DevOps 工程技術能力，將其快速拉到一個基線，大大降低各團隊自己實施的成本；
- 通過統一的部署流水線將從代碼提交到交付給用戶的整個過程高度可視化出來，信息透明；讓開發、測試和運維以高度一致的方式工作在同一個流水線上，真正建立起協作；
- 每一次的軟件變更在這個完整的流水線中得到充分的驗證，盡早發現有缺陷的變更；而經過了完整驗證的變更可以隨時部署出去；
- 在組織級能夠將一些必不可少的控制環節內建到自動化過程中，比如質量保障過程、過程度量、權限控制及過程審計信息等，從而弱化很多傳統依靠人為檢查的管理流程，實現精益敏捷的輕流程目標。
我們已經明顯看到有不少互聯網公司，比如阿里、騰訊在組織級提供類似這樣的交付平臺，然而更多 IT 企業還沒有跟上。
還有一個更重要的關鍵詞必須強調：“自助式”，這是平臺設計的前提。我們在有些組織看到確實有類似的持續集成、持續交付平臺。然而對這個平臺的使用就如同前面提到的集中式 IT 基礎設施服務一樣，當交付團隊需要為新的應用或服務建立一套新的自動化構建任務，或需要修改現有配置時，必須向平臺的負責部門提出申請，由集中式的團隊來幫助建立或修改配置。這些配置任務在集中式團隊排隊和等待，成為新的瓶頸。而產品交付團隊自身始終不具備自動化能力，每次變更配置都不得不等待，導致需要的自動化任務跟不上架構的變化，任務失敗后定位和解決問題很低效。最嚴重的是，團隊的開發、測試人員根本不關心持續集成的執行和結果。這種模式下，平臺其實遠遠發揮不了它應有的作用。
正確的做法是，平臺團隊只需要專注于提供自動化、自助式的持續交付平臺，將產品交付團隊當做自己的用戶，聽取使用反饋，持續演進；平臺的設計必須要兼顧過程的標準化和流水線配置的靈活性；該團隊不負責為各產品配置構建任務和流水線。這個配置工作應完全由各交付團隊自己來完成，必須要具備“在需要修改配置時隨時自己就可以修改”的能力。若沒有該能力，組織就要提供培訓和賦能。
挑戰五：IT 架構耦合度高
上圖左下方的這棟建筑，住著很多戶。如果其中某一戶對自己房子的布局和功能不滿意，想要重新設計，這時一個房間的設計改動必然影響到其它住戶，甚至可能危機整棟建筑。如果要想允許每一戶人隨時修改自己房子，不用太擔心危及整個系統，縮短整個改動的周期，就需要像圖中其它的小房子一樣，彼此之間松耦合，靠簡單、標準的道路來連接。
我們的 IT 系統也是一樣，要實現 DevOps 的目標，更快地響應業務變化、提高交付吞吐量，每個子系統的粒度就要小，彼此之間松耦合，各自可以獨立地進行測試和部署。很多企業多個系統因為耦合緊密不得不在同一時間點部署發布，為了確保每一次投產不出問題，需要投入大量人力來進行協調，投產部署過程要處理更大的復雜性，也更容易引入質量問題。
另一方面的影響是，若單一系統規模大、復雜性高、系統間耦合度高，就難以給予交付團隊更大授權、實現開發團隊自主運維。
DevOps 轉型過程中的這一挑戰在于，企業必須對現有 IT 系統進行解耦，將目前很多代碼級依賴、數據庫級依賴、或業務上的緊密依賴進行解耦，走向圍繞業務領域邊界建立的、靠輕量級服務和消息集成的服務化架構，要從設計上使得相互依賴的服務之間在升級時做到前向兼容，這是一個困難且耗時的過程；在這個過程中如果沒有恰當的架構演進策略，缺少正確的方法引導，導致在服務拆分不合理，或缺少與之配套的服務治理能力，結果可能適得其反。這方面我們有過很多經驗教訓。ThoughtWorks 在實踐 DevOps 的過程中，往往就伴隨著大量的向微服務方向進行架構拆分和改造的工作，這一過程可能長達數年，逐步演進。但絕不能知難而退，投入必不可少。
挑戰六：職能化組織中的開發運維部門墻
在多年以前，當傳統企業的業務發展對數字化的依賴程度還不高，當管理者將 IT 系統的開發視為一種耗費人力但又價值并不高的非核心能力時，快速膨脹的軟件研發隊伍紛紛從原有的業務部門中拆分出來，成為了獨立的部門或信息技術子公司；隨著軟件系統的復雜性越來越高，在專業化、流程化的考慮下，實現功能的開發、保障質量的測試和保障運行穩定的運維按職責和技能不同被拆分成了各自獨立、相互制衡的部門。結果是各部門有了自己的目標，彼此不同甚至相互沖突，都著眼于各自內部優化；但很不幸地，在這個過程中企業的終極目標——最大化為用戶/客戶創造價值，這個必須要所有職能作為一個有機的整體運作才能實現的目標——卻被弱化了。如下：
在這樣的組織設計中，各部分在一致目標下的協作不足，而更加注重過程控制和相互制衡，要真正實現 DevOps 是不可能的。舉幾個例子：
在給一些企業評估其持續交付和 DevOps 能力時，普遍的情況是開發完成的工作進入生產環境要經過冗長的審批過程，審批基于一大堆文檔；然而事實是（不要欺騙自己），那些并不了解產品細節和每一次變更細節的審批者，很少甚至從來沒有在審批過程中發現過潛藏的問題，但這一過程卻嚴重拉長了新版本上線獲得用戶反饋的周期；可以說，如果開發團隊在提交文檔時，某些文檔忘了修改、還保持和上一次申請時一模一樣，估計那些審批者也發現不了（或者根本就不會細看）；
另一個普遍的現實是前面提到過的，開發、測試和運維各自有一套工具來完成自己關心的任務，而這些工具相互割裂、重復建設，沒有協作。不一致的工作方式和工具既降低了交付吞吐量，也給質量保障引入了更大風險。
讓軟件開發的最后一公里——運維環節變得更加敏捷和適應變化，開發和運維職能的緊密協作是 DevOps 運動的最核心思想。要達到該目標，企業如何為開發和運維建立一致的目標，通過協作而非制衡的方式來共同面對同時提升吞吐量和保障穩定性的挑戰是企業實施 DevOps 最重要的命題！組織需要下面這樣一種治理結構：
圍繞著提供給用戶的產品和服務，建立包括產品設計、開發、測試和運維在內的產品交付團隊。這并不意味著組織一定要立即在匯報線的設置上做出改變，關鍵是如何設置目標和組織日常工作！除了各業務產品，同時集中的 IT 運維服務部門也應走向產品化，也就是從以往為各個業務產品提供運維支持，轉向專注于為業務產品交付團隊提供支撐其交付的平臺，以及進行運維監控、運營分析的平臺；可能也從用戶支持統一體驗的角度出發，給各業務產品提供面向最終用戶統一的支持、服務熱線和客戶服務渠道。
這種轉變對組織是很大的挑戰，涉及到多年形成的治理結構的改變。首先需要各級管理者思想上的改變，從基于不信任前提的控制型、分化制衡型管理思想，轉變為基于信任前提的服務型、協作型管理思想，這在 ThoughtWorks 提倡的適應性領導力中有深入探討。這種轉變從一開始，很難在組織大范圍開展，建議的是先建立特區，再逐步試點擴大，最后實現突破；在轉變的過程中必然會涉及到部門職責范圍、績效考評、人才能力模型等深層次的轉變。這種轉變需要組織管理者、轉型推動者發揮領導力，展現出變革的魄力和執行力才能得以成功。
挑戰七：缺少敏捷文化
前面談到的強職能化組織結構也深刻地影響著一個組織的文化。在與曾經咨詢過的一個客戶探討到如何進行 DevOps 轉型時，開發和運維部門坐在一起探討。大家就運維流程如何改變、自動化能力如何建設等都沒有異議，然而自始至終無法突破的終極問題就是：無論我們如何改變，如果萬一生產環境出了問題，誰承擔責任？因為 DevOps 能力的建設需要一個過程，開發團隊不敢承諾完全承擔責任；而運維因為弱化審批和控制力，也認為不該為其承擔責任。最終不了了之。
我認為，根本的問題出在文化，舊有的組織治理模式產生了各掃門前雪的官僚文化，沒有責任共擔，以及出現問題必然問責的文化。這種文化可能源自慣性的職能化思維，可能源自組織的績效考評和激勵制度。
現代關于“系統論”的研究已經在很多著作中強調，一個組織就是一個由人構成的復雜系統，組織中每一個人所能獲得的信息是有限的（包括最高管理者也是），每個人或團隊都只能基于自己有限的經驗、有限的信息做出決策和行動。如果系統發生失敗，例如生產環境出現問題，這必然是由于系統各個部分相互作用（從想法提出到軟件投產各個環節的相互作用、系統與其它系統間的相互作用）產生的結果，對其中任何局部進行懲罰無非是尋找替罪羊，有害而無益。這時候組織真正應該做的，是相信每一個人都已經做出了最大努力，將相關干系人拉到一起對問題的根因進行分析，找到能夠有效避免類似問題再次出現的解決方案，并確保該方案得到實施，對其效果進行驗證。
再舉一個例子，Petrik 曾經在 DevOpsDays 上提到了一個 DevOps 的優秀實踐：Chaos Monkey（混世魔猴）。這只自動化的猴子會每隔一段時間隨機將生產環境服務器關閉，以此來測試生產環境的快速恢復能力，促使各團隊提升系統的穩定性。我曾經和國內企業的開發、運維部門討論過這個實踐，有趣的是無論開發還是運維都跳出來反對該實踐，認為無法落地。如果沒有這只“猴子”，大家可以給領導講自己的系統很穩定（只要沒出問題）；然而這只“猴子”可能會隨時暴露出自己的系統并不像自己所宣稱的那樣穩定，會降低自己在上級心目中的“有能力”印象，隨之而來的可能就是問責、懲罰。這樣的文化下，大家真正關心的是如何給領導“表現”，而不是在真正的系統穩定性上追求卓越。
真正能夠實現 DevOps 的組織，我們認為需要具備下面這樣一些文化：
總結
無論是組織治理結構、管理流程、工程技術能力還是文化特征，DevOps 運動都和精益產品開發、敏捷宣言所倡導的理念一致。我認為一個組織如果沒有充分經歷過敏捷文化的熏陶，也很難實現 DevOps 的目標，充其量在自動化工具和技術能力上有所提升，收益很有限。
因此我們不應當將 DevOps 作為一個孤立的運動去看待，更不能僅僅從工具角度去實施，而是應當將 DevOps 作為企業在數字化進程中為追求創新和快速市場響應、為提升組織適應力所進行的精益敏捷組織轉型的一部分，這是一項系統工程。 盡管挑戰重重，只要管理者首先從自身的管理思想出發做出改變，從組織小范圍開始，將各種職能的人員聚攏到一起，設置共同的愿景和目標，打破束縛，給予足夠授權，以緊密協作、責任共擔的方式共同面對挑戰，就能取得成功。然后再將小范圍的經驗在更大的范圍逐步擴散，并適時地對企業深層次治理模式做出調整，就能夠在整個企業范圍內產生積極影響力，帶來組織效能的巨大提升。
更多精彩商業洞見，請關注微信公眾號：ThoughtWorks 商業洞見
姚安峰，ThoughtWorks 咨詢師，08 年起開始致力于敏捷的踐行和推廣，理論與實踐跨越敏捷、精益、持續交付和 DevOps 全流程各領域，幫助各行業客戶采納優秀且與企業環境相適應的管理和技術實踐交付高價值、高質量產品，提升創新能力，推動持續改進。主導翻譯了著作《精益企業》。