▌背景

我經常喜歡舉的一個例子，學習DevOps有不同的方式，就像人類學習飛行時有鳥飛派和空氣動力學派。人類的飛行夢想始于古老而又遙遠的年代，但真正的飛行實踐起源于仿鳥飛行，即給自己裝上一對翅膀，學習鳥的撲翼動作而飛行，但大量長期的實踐證明這樣的嘗試都是失敗的。但還有另外一派，英國的科學家提出人造飛行器應該解決推進動力和升力等方面的問題，需要增強對空氣動力學理論體系的基本認知，這使很多人放棄了單純模仿鳥類飛行而逐漸接受和實踐固定翼飛行器的設計思路，并最終由萊特兄弟發明了完全受控、可持續飛行的載人飛行器。

DevOps的實踐和轉型也是一樣，我們很難照搬其他組織的成功，而是應該深入理解其背后的原理、原則和實踐，從正確的方向入手。本文主要內容來自Jez Humble在Devon Summit上的演講《Leading a DevOps Transformation》，重點介紹了DevOps轉型的五個誤區、五個實踐，以及轉型實施的具體建議。與之前的文章一樣，我會結合我的經驗和理解進行適當的內容擴展，而不僅限于演講內容，核心還是希望幫助大家少走彎路、避免踩坑，能夠更順利的走向DevOps成功之路。

另外再介紹一下Jez Humble，作為DevOps領域里公認的世界級領軍人物，他既是一位非常有影響力的軟件研究人員，也是一位屢獲殊榮的作家。他與其他作者合著的《持續交付》(Continuous Delivery) 一書曾獲Jot大獎，是學習DevOps的必讀書籍。Jez的其他暢銷書包括《精益企業》(LeanEnterprise)，以及DevOps Handbook，其中文譯本《DevOps實踐指南》將于5月5日在DevOpsDays北京站首發，大神Jez Humble也會來華與大家面對面暢談DevOps！

▌DevOps能夠幫助我們什么

傳統軟件交付方式的問題大家都清楚，比如很長的交付周期、很差的應變能力和低效的價值交付。所有很多組織進行了敏捷轉型，但敏捷轉型的歷程可能也并不是一帆風順。以開發為代表的工程師部門使用敏捷的方式運作，從瀑布轉向了Scrum快速迭代，并引入了TDD，做好了架構解耦，工作非常開心。

但組織里的其他部門也許就不是這樣想的了。比如運維團隊，原來一年做好幾次發布就可以了，現在隨時有上線包扔過來，隨時都需要準備發布，這個實在太可怕了。遇到這樣的問題，很自然的反應是建立起一個屏障，比如”變更管理流程”，而這個流程的職責就是限制變更。

DevOps的出現就是為了解決這樣的問題，可能很多人對DevOps的理解都不同，也可能并沒有一個統一的定義。但這并沒有關系，我們可以從DevOps的起源來思考。DevOps運動始于社區，一些人試圖解決某些從未被解決的問題：如何構建大規模、分布式、可靠、安全的系統，并且可以在持續、快速變更的情況下，讓系統一直保持安全和可靠。

在過去的五年時間中，通過對很多高效能企業的調研，可以發現投資于DevOps實踐所取得的眾多好處，首當其沖的就是軟件交付會對業務發展產生重大的影響，高效能企業有兩倍于其他企業的概率達到其利潤率、市場占有率、生產效率等業務目標。

接下來，我們從統計學的角度來分析IT效能，這里設計了兩大類四個指標。分別是度量吞吐量的指標（部署頻率、變更前置時間），以及度量穩定性的指標（MTTR、變更失敗率）。這些數據來自每年的DevOps現狀調查報告，我在去年也進行過多次線上、線下解讀和分享，這里暫不展開說明。但值得再次強調的是，從統計結果上來看，高效能的企業可以在吞吐量和穩定性方面兼得，而不是傳統意義上的為了提升效率而犧牲質量，或者為了質量而犧牲效率。

之前Facebook有句格言是”Move fast and break things”，意思是公司應該快速行動、打破陳規。但我覺得可以改成”Move fast and don’t break things“，即快速交付的同時必須要確保質量和安全性，這正是DevOps可以賦予給我們的能力。

▌DevOps轉型的五個誤區

Jez Humble提出了DevOps轉型的五個誤區：

下面我們來詳細分析一下：

1 ▏誤區一：放棄現有的系統管理員、測試人員，招聘新的DevOps專家

不得不說，這絕對是一個糟糕的想法，建議不要這樣做。從經驗來看，招聘新的DevOps專家是一件很困難的事情，我身邊的一些朋友都在尋找這樣的人才，但其實很難找到完美的人選。因為DevOps工程師或專家不是直接能夠培訓出來的，也沒有一所大學教授DevOps的課程，這些有經驗的人都是在工作中不斷遇到和解決問題的過程中逐漸成長起來的。

所以問題的關鍵在于，如何建立一個組織環境，讓員工可以在工作中學習，他們不會被刻意地限制在各自的角色中，而是被鼓勵在解決問題的過程中不斷學習新技能，并為整個組織服務。

2 ▏誤區二：進行大規模組織結構重組（Re-Org）

有的組織轉型很干脆，一上來就進行大規模的組織結構重組。但經驗告訴我們，組織結構重組是非常容易引起混亂的活動，組織通常會消耗數月時間和巨大的能量，員工需要重新熟悉新的組織結構和工作方式，這對組織生產力的打擊是非常大的。

值得注意的是，我們并不是說不需要對組織進行改進。我們都知道，跨職能團隊（比如面向服務或特性）會比按職能切分的團隊具有更高的生產力，所以建立跨職能團隊本身是非常有效的。但這里觀點是Re-Org并不是唯一的選擇。我們也可以用其他方式達到這個目標，比如讓這些不同角色的人員物理地聚在一起；或者下游職能團隊通過自動化的自服務平臺，把他們的能力賦予給上游的團隊使用（見下圖）。很多讓人敬佩的DevOps組織也沒有完全形成跨職能團隊（如Etsy，Google和GitHub），但他們的生產率同樣非常高。

3 ▏誤區三：重新編寫你的應用并遷移到云上

DevOps現狀調查報告中也顯示，DevOps適用于各種場景，包括Mainframe主機系統和商業套裝軟件（COTS）。

在我的上一篇文章 DevOps聽起來不錯，但適合你的企業么 ，我講到了在大型嵌入式軟件、保險公司的大型機系統上進行持續交付的案例。除此之外，在《DevOps Handbook》中也提到在傳統的POS機上，采用藍綠部署進行快速和低風險發布的例子。

所以，你不用等待漫長的應用重建并遷移到云上，而是可以在現有系統和組織環境中使用DevOps的思路進行逐步改進，最好的轉型啟動時間點就是現在！

4 ▏誤區四：購買一攬子DevOps工具

DevOps發展到今天，已經出現了非常多的支撐工具。我們認可好的工具可以對DevOps的實施提供出非常強有力的支持，但我們的觀點是：如果僅僅是購買工具，無法真正幫助你解決問題。

Jez Humble與Dave Farley在2005~2006年進行持續交付的工作時，并沒有上圖中展示的如此眾多的工具，很多自動化的工作都是由Bash腳本完成的，但也同樣獲得了非常顯著的效果。問題的關鍵在于你如何解決問題，而不是具體應用哪一款的工具。如果組織僅僅是購買工具而不改變工作流程，這樣不會改變任何事情。

我就曾經見過有人把Jira用成了管控型的傳統項目管理工具，把Jenkins用成了批處理任務的手動觸發器，只有工具而沒有方法和實踐的改變，是無法走上DevOps成功之路的。

5 ▏誤區五：給開發生產環境的完全訪問權限

有人說DevOps就是讓開發自己進行發布，所以需要給開發所有生產環境的權限。我們認為這是一種可怕的想法。理想情況下，任何人都不應該有生產環境的權限，所有生產環境的部署應該由人工觸發后，只通過自動化的方式進行。

只有在特殊的場景下，比如需要在生產環境進行診斷時，才可以允許有人登陸到生產環境。但這種情況下仍然需要特別小心，比如使用一次性的登陸口令，并將任何操作日志都記錄下來并發送給系統管理員。

▌DevOps轉型的五個實踐

以上介紹了DevOps轉型的五個誤區，那么正確的轉型打開方式是怎樣的呢？我們總結為以下五個實踐。

1 ▏實踐一：習慣小批量的方式工作（開發、架構、組織文化的演進）

持久的變革需要以小批量、持續的方式進行，通過反復實驗、根據反饋循環快速學習，找到最正確的實施路徑。這樣需要把大的問題拆成一系列小的問題逐個、漸進式解決，也許這樣沒有Big Bang式的變革令人激動，但這才是讓我們成功的正確姿勢。

找到最重要的工作

最經典的例子就是項目管理，傳統上按半年或一年規劃并申請預算，這驅使我們工作在大型復雜項目上，大量時間花在特性在待辦清單（Backlog）中等待被分析、估算、批準和排優先級等事務性工作上。一份稱為”黑天鵝農場”的白皮書顯示，他們分析了3000個待辦清單中等待開發的不同需求，使用延遲成本（如果不做這個需求，每周損失的成本）的優先級決策方式。

他們發現，在待辦清單中有三個特性，如果不交付這些特性，每個特性每周給組織帶來200萬美金的損失。這幾個特性隱藏在龐大的待辦清單中，但確實極為關鍵的。他們意識到應當停掉手頭所有工作，以最快的速度交付這三個特性。從統計數據上看，這種情況符合冪律分布，如下圖所示。

所以我們的工作就是要在多個項目中間，找到那些真正重要的，這需要更加透明、更加清晰的優先級，以及組織中每個人的協作。

架構的持續演進

很普遍的情況是，很多組織擁有大量的遺留系統，一些軟件或硬件過于老舊，可能廠商已經不再支持了，有些組織的個別系統甚至沒有源代碼（可能在乙方手中或已丟失）。這類組織通常選擇通過長達一兩年的架構再造解決問題，而當進行到一年的時候，他們可能會說，系統復雜度實在太高，我們還需要額外的兩年！我本人就親歷過這樣的超大型項目，最后負責的CTO都換人了，項目還沒做完。

以上描述的場景，關鍵的問題是，大家的關注點常常在架構的技術層面而不是需要達到的結果上。調查數據顯示，如果以下問題的回答都是Yes，那么你更有可能做好持續交付和DevOps，成為高效能IT組織：

是否無需團隊外的某人或其他團隊授權就可以進行自身系統大范圍的設計變更？

是否無需與團隊外的其他人員進行細粒度的溝通就可以完成自身的工作？

是否可以獨立于其他依賴的服務或產品，按需部署和發布自身的產品或服務？

是否無需依賴復雜的集成測試環境，就可以按需進行大多數自身系統的測試？

是否可以在日常業務時段，執行無停機的部署？

你可以在老舊的遺留系統上實現以上全部這些效果，但也可能在充滿高科技、新技術的情況下，無法達到以上效果的任意一條。所以我們要關注的是架構演進的結果，而不僅僅是使用炫酷的技術。

關于演進式架構的更多內容，以及絞殺者模式的思路，我之前的文章也有介紹，其主要原則如下：

從交付業務所需的新功能開始（至少在初期是這樣），新功能使用面向服務的設計

不要重寫已有的功能，除非能夠使它持續簡化

通過不斷拆分，更快的進行交付

為可測試性和可部署性進行設計

新的架構運行在PaaS平臺上

組織文化的持續演進

組織和文化的變革同樣應用使用持續演進的方式。在組織中有各種各樣的員工，有些人對新方法和新技術非常感興趣，有些人則偏于保守，不愿意嘗試進行改變。

你不能一刀切地進行整個組織的變革，應該從最贊同DevOps的理念、方法和技術的人群開始。接受一個新想法，需要跨越鴻溝。我們先找到認同DevOps原則和實踐的團隊，聚焦在有一定風險承受能力的小組上，快速做出轉型的標桿效果，打好基礎、給人信心。我們不需要在早期花費大量時間用于轉化保守的人群，而最重要的是先要把第一槍打響。

2 ▏實踐二：創建反饋循環

在小批量工作的基礎上，我們要建立起反饋循環。反饋循環讓我們能夠持續學習，基于學習進行持續改進，這也是敏捷和學習型組織的關鍵原則。

持續交付流水線就是反饋循環的具體實現，可以提供多個層次、多個鏈路的反饋信息，并且可以在反饋效率和反饋完整性之間取得平衡。

以下是去年我與朋友合作的全開源持續交付流水線的設計圖和效果圖，充分體現了流水線的遞次晉級和反饋循環的原則。

全開源流水線只能滿足中小企業的需求，在大型企業中的流水線設計和實現更為復雜，我后面找時間再跟大家單獨介紹。

3 ▏實踐三：通過價值流進行跨職能協作

需求、開發、測試、信息安全、運維等角色需要在軟件交付價值流中協同工作。價值流圖是促進跨職能協作的關鍵工具。我們可以通過開展價值流梳理的Workshop，識別支撐價值流的各種角色以及角色之間的協作關系。我們不需要文檔化價值流中每一步的細枝末節，而是理解價值是如何傳遞的，各角色是如何協同工作的。

另外，這里還要強調跨職能協作時的質量管控部分。不僅僅是自動化測試，還要關注持續測試、持續安全檢查，讓這些活動在日常工作中反復進行，做到內建質量。

4 ▏實踐四：建立實驗的組織文化

調查表明，組織文化是可以被度量的，而且組織文化對IT效能和組織績效都有可度量的影響。我們使用Westrum模型來度量組織文化。該模型中有三種類型：

病態型組織（Pathological）的特征是存在大量恐懼和威脅。人們通常處于政治因素而隱藏或者壓制信息，甚至為了讓自己表面上看起來更好而扭曲事實。

官僚型組織（Bureaucratic）的特征是各部門自保。每個部門都想維護自己的一畝三分地兒，堅持自己的規則，通常會依照自己的章程按部就班地行事。

生機型組織（Generative）專注于自身的使命以及如何達到目標。任何因素都要讓位于高績效，團隊間高度合作、風險共擔、鼓勵聯結。面對失敗時需要嘗試發現系統中的問題根因，而不是尋找替罪羊或相互推諉。

根據統計結果發現，一個高度信任的生機型文化不僅對創造一個安全的工作環境非常重要，更是打造高績效組織的基礎。

以上模型不僅停留在理論層面，更可以應用在實踐領域。

1 ▏案例一. Google的災難恢復測試

Google在幾年之前進行過一項研究，如何打造一個優秀的團隊。他們調研了來自180個Google團隊的200位受訪者，觀察了超過250項不同的因素，比如團隊中有人取得博士學位、有性格外向的人，有人著迷于AngularJS等等。但他們最終發現打造高效能IT組織，排在第一位的因素是：心理上的安全感，即可以在團隊中承擔風險而不會感到不安全或者受到傷害。

我們需要構建一個安全的環境，讓失敗是可以接受的，并且作為組織學習的基礎。Google和Amazon都會在線上進行災難恢復測試，確保在發生嚴重故障時，故障恢復策略真正有效，系統仍然可以正常運轉。

Google有一整個團隊專注于計劃和實施災難恢復測試，甚至有一年模擬外星人侵入硅谷的場景，他們斷開山景城與外界的光纜連接、關閉數據中心并對基礎設施施加真實的影響，但要求團隊必須要維護服務級別目標。他們設計的災難恢復測試，需要由來自很多不同組、平時不在一起工作的工程師相互協作，那么在大規模災難真正來臨的時候，他們已經建立起了很強的工作關系。

2 ▏案例二. Etsy的”三只袖毛衣”獎勵

Etsy每年舉辦開發者大會，會發給過去一年中生產環境最大中斷的制造者一件”三只袖毛衣”作為獎勵。那么為什么獎勵是三只袖毛衣呢？因為Etsy的404頁面中有一張三只袖毛衣的圖片。

圖中這位身穿毛衣的同學就是Etsy去年最大故障的制造者Ryn，她把故障的過程記錄在了博客中，包括何時、什么原因造成了生產環境中斷。發生故障時，她馬上在Slack上尋求幫助，然后立即得到了身邊很多人的回復，然后他們一起蜂擁而上快速解決了問題。之后，他們開展了免責的事后故障分析會議，并給出了防止再次失敗、優化系統的具體措施。Ryn也因此獲得去年的獎勵，因為她促進了組織學習，讓系統的恢復能力變得更強。

3 ▏案例三. Netflix的Chaos Monkey和Simian Army

Netflix的這個工具不斷在生產環境上制造破壞，驗證系統是否具備良好的恢復能力，并幫助工程師構建更加健壯的系統。

4 ▏實踐四：持續消除浪費，優化價值流

DevOps需要持續改進，移除浪費，讓價值流動變得更加順暢。我近期輔導了一些團隊使用價值流圖的方式進行流程和問題梳理，發現這的確對組織認知和優化現有軟件交付過程非常有幫助。

我們可以邀請來自產品、開發、測試、運維、安全等不同部門的Leader參加價值流梳理活動，其實最難的部分是讓這些人在同一時間聚在一間會議室中。我們逐個梳理從需求提出到編碼、測試驗證再到部署、發布的過程，過程中會發現大家的認知并不一致，尤其是對前置時間、等待時間和C/A%（完整且準確比例）的估算。

讓所有人達成對整個價值流的理解和認知非常重要，但更重要的是確定未來如何改進的具體措施和預期目標。在不同的角色對目標達成一致意見的基礎上，定期（如一個月）進行回顧和持續的改進。在改進的過程中，并不是事無巨細的告訴團隊具體如何開展工作，而是明確目標并讓團隊深度參與、自主思考，通過不斷實驗和學習想辦法達到目標。（這映射了我們之前提到的誤區一）

▌DevOps轉型實施的具體建議

在過去五年對高效能企業的研究中，總結出了DevOps轉型的關鍵能力要素，如下圖所示。圖中共有四大領域，分別是軟件開發實踐、精益產品開發、精益管理、變革領導力，這些領域又細化出了20多個能力項。這些能力項的建設可以作為DevOps轉型實施的主要參照系，強烈推薦大家持續關注。

DevOps的轉型并不簡單，想要走上成功之路，這里還有幾個Tips：

對可度量的業務目標達成一致。制定”跳一跳可以達到”的目標，比如減少10%嚴重缺陷數、提升20%服務可用時長、達到2倍的發布頻率，或者其他混合的結果指標。

給團隊資源進行實驗并對學習進行激勵。團隊無法在日常工作照舊的前提下，”加班”進行改進的探索。改進是要有真實工作量投入的，這應當與開發新功能、修復缺陷以同樣的方式進行優先級排序。具體來講，可以使用看板管理WIP，指派專職的團隊全職做改進工作，或者每周給團隊一個特定時間用于做改進工作。

與其他團隊溝通，鼓勵協作。很多人經常提及合規、安全、治理等團隊，認為他們是改進的阻礙。但其實如果與這些團隊進行友好的溝通，你可能會發現他們非常期望討論獲得雙贏的具體措施。

取得速贏。你需要在一到兩個月做出改進的效果。具體來講有三個關鍵點：首先，通過價值流圖或約束理論，找到一個影響最大的、并且可以快速解決和可被度量效果的問題；其次，限制首次進行改進的范圍，最小化改進工作；然后，與對改進有興趣并有充足容量和能力的團隊合作，取得速贏。

分享成功經驗。為了獲得其他人的支持，你需要做好成功經驗的宣傳工作，吸引更多的人加入到改進工作中來。比如有的企業組織內部的DevOpsDays大會，跨部門進行經驗的推廣，這非常有效。另外午餐學習會、內部博客、郵件列表、Slack或HipChat頻道都是獲得參與者最好的渠道。還要對其他嘗試的人提供幫助，就像DevOps教練應該做的工作那樣。

持續改進。高效能的組織永遠追求改進的機會。就像豐田管理系統的締造者大野耐一所說的：”Kaizen [improvement] opportunities are infinite”，改進的機會是無窮無盡的。百度集團總裁兼COO陸奇在去年的一次演講中也講過：”Engineering Excellence 是一個永無止境的、個人的、團隊的，能力的追求和工具平臺的創新，綜合在一起可以帶給我們帶來的長期的、核心的競爭力”。Relentless pursuit of excellence，這是我們應該堅持的態度。

▌總結

今天我們從鳥飛派和空氣動力學派的類比說起，DevOps的轉型不能照搬其他組織的實施過程，而是應該深入理解其背后的原理、原則和實踐。

我們分別介紹了DevOps轉型的五個誤區、五個實踐，以及轉型實施的具體建議。

五個誤區。放棄現有人員而招聘新的DevOps專家、進行大規模組織結構重組、重新編寫應用并上云、購買一攬子DevOps工具、給開發生產環境完全訪問權限；

五個實踐。習慣小批量的工作方式（開發、架構、組織文化的演進）、創建反饋循環（流水線建設）、通過價值流進行跨職能協作、建立實驗的組織文化、持續消除浪費并優化價值流；

轉型實施具體建議。關注DevOps轉型的關鍵能力要素，對可度量的業務目標達成一致、給團隊資源進行實驗并對學習進行激勵、與其他團隊溝通并鼓勵協作、取得速贏、分享成功經驗、持續改進。

以上這些內容都是在很多企業中總結出來，是被證明過的、對提升組織效能最有效的方式。我們的目標是快速的發布、更高的可靠性、更好的恢復能力和更安全的系統，以及更人性化、持續改進和自我增強的組織。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業