什麼是DevOps的三步工作法？

作者介紹

張樂

DevOps時代聯合創始人，高效運維社群合夥人，DevOpsDays大會、GOPS全球運維大會金牌講師。國內首批DevOps Master，前百度資深敏捷教練、架構師。超過十四年敏捷轉型、工程效能提升和大型專案管理實踐經驗，曾主導數百人團隊實施DevOps轉型，在保證質量的前提下發布頻率提高數倍。 

本文將介紹《DevOps Handbook》全書的核心：三步工作法。《DevOps Handbook》全書就是從三步工作法的思路出發，進行知識體系的組織和實踐的編排。 

三步工作法是什麼？如何通過三步工作法來指導DevOps的整體實施？以及它的核心思路和基礎原則？

一、DevOps與其他管理運動

我們再來看一下DevOps與精益、敏捷和其他的管理運動的關係。

• 精益

  首先是精益，它是源自1980年代的豐田管理系統（TPS），關鍵實踐包括價值流、看板和統一生產率維護方法等，目標是提升效率、減少浪費，通過小批量的工作縮短整個Lead Time。精益的原則聚焦在如何通過系統思考為使用者創造價值。

• 敏捷

  再來看下敏捷，2001年提出了《敏捷宣言》，敏捷裡強調輕量級軟體開發，小批量、增量式的釋出，小的團隊提升組織的效率。然後是2009年Velocity大會，這個會上Flickr公司提出Dev和Ops如何做更好的協作，實現每天10次線上釋出。很多人包括Gene Kim、Patrick、John Willis都參加了這次大會，然後組建起來DevOps陣營。

• 持續交付

  持續交付是2009年由Jez Humble和David Farley共同提出的，把持續整合做邏輯上的延展，形成持續交付的新方法。持續交付的核心概念是部署流水線，就是我們經常講的Pipeline，Pipeline可以讓我們確保程式碼和基礎設施一直處於可部署的狀態，所有簽入到Trunk的程式碼都可以在安全的環境裡部署。

• 持續改進

  還有一個運動大家提得比較少，是2009年的TOYOTA KATA運動，這裡面提出一個困惑，這麼多公司去學習豐田，但是沒有一個學習豐田精益實踐的組織能夠複製豐田工廠觀察到的高效。

  大家都在學豐田，為什麼我們回來用他們的方法實踐，卻達不到豐田的高度呢？實際上我們遺漏了一個最重要的實踐：improvement kata，就是改進的模式。

  豐田之所以成功，因為他把改進作為日常工作的一部分，我們如果只是靜態學習，別人有什麼實踐，我學習什麼實踐，這樣不能達到卓越，我們需要保持持續改進。

• 在這裡向大家推薦一個測試學習交流群：175317069。

DevOps本身的方法以及它的技術、架構、文化實踐都參考了這些優秀的管理方法、管理運動、管理哲學，DevOps是以上這些方法的集大成者。

二、IT價值流與三步工作法

下面我們來具體看看如何提升效率，在說具體方法之前先解釋一個概念，什麼叫做價值流。圖中左邊是生產價值流，指的是生產製造領域中設計、開發和交付產品所需要的活動，包括資訊和材料的雙重流動。聚焦在創造平順和流式的工作，關注小批量，避免返工，減少在製品等。

右邊是技術的價值流，也就是IT的交付過程，從需求提出到開發、測試、部署、釋出、運營整個的過程。我們認為技術的價值流同樣可以採用在生產製造價值流中經過驗證有用的技術。技術價值流關注從商業的假設提出，到把它轉化成技術輔助服務，最終交付價值給使用者。

技術價值流的重點在於如何聚焦和縮短部署的前置時間，這裡面有兩個部分。首先是上游，設計、開發的部分。其次是下游，測試、運營的部分。

我們認為在設計、開發部分是精益產品開發過程，特點是高度的易變性和不確定性，需要有深度創新的工作。下游的測試和運營，我們希望它有更好的預測性和機械性，以最小的易變性完成工作。

怎麼達到這個目標？有兩個核心方法：

• 一個是避免大批量工作從設計、開發價值流傳遞到測試、運營價值流，如瀑布流程或長分支。

• 另外一個是，讓測試、運營與設計、開發同時進行，確保價值流快速流動和高質量。

如何加快速度，我們要關注Lead Time和Process Time。

Lead Time是前置時間，從需求提出到需求被滿足的整個週期。Process Time是從開始工作到工作結束，不包含在佇列裡等待的時間。Lead Time和Process Time之間的比率是非常重要的衡量效率指標，快速流動和縮短前置時間最重要的一個抓手就是要縮短佇列中的等待時間，這可能是我們日常工作中非常容易忽略的。

下面是兩個常見的場景：

• 一個是傳統的專案管理場景，大型複雜組織，緊耦合、單體應用，很稀有的整合測試環境，很長的測試和生產環境Lead Time，高度依賴手工測試，有特別多的審批流程。

  類似這種的大型專案基本結果都是一樣的，整個週期時間很長，普遍數週甚至數月。

• 另外一個場景，被認為是DevOps的典範，就像很多網際網路公司做到的一樣，在分鐘級就可以完成從程式碼提交到上線的整個過程，包括從提交到自動化構建、自動化測試、手工探索性測試以及生產部署，所有這些事情可以很快完成。

  如何做到？需要開發提交程式碼之後快速收到驗證反饋，可以讓這個反饋更快的指出什麼地方被破壞了、什麼地方存在問題，可以持續將小批量程式碼簽入程式碼庫，執行自動化測試，可以自動化做釋出、自動化部署。

  又因為整個系統模組都充分解耦，所以小團隊可以高度自治，可以快速完成端到端流程。今天談的是比較高階的思路，如何從更巨集觀的角度去解決問題，我剛才提到的每個部分，包括如何做技術架構解耦，如何做自組織的適配，如何做到開發的自服務，這些內容在後面的分享裡都會有詳細的展開。

下面我們進入到三步工作法最核心的部分。整個DevOps實施可以分解為三步：

• 第一步是從左到右快速流動

• 第二步是從右到左快速反饋

• 第三步是在整個過程中持續學習。

每個部分我都做了一張總圖，把核心思路做了梳理。

三、三步工作法的核心思路

3.1、三步工作法核心思路-Flow

第一部分是Flow，讓價值快速流動，其中有六個實踐，分別是：視覺化、限制在製品、減少規模、減少交接數量、持續識別和擴充約束，以及在價值流中消除浪費。

3.1.1 讓工作視覺化

讓工作視覺化。技術價值流和生產製造價值流的區別是工作不可視，工廠裡面有物料的流動和堆積，如果發現大量堆積，說明這裡有瓶頸、有排隊。而IT交付價值流裡看不到顯而易見的堆積，很多問題被隱藏掉，直到最後爆出更大的問題。

在DevOps領域裡，包括敏捷、精益的理念，都在提視覺化，通過視覺化去管理價值流動。

圖中左下角是一個典型的看板，看板裡把整個軟體的生命週期分成需求調研、需求就緒，開發進行中、開發完成，測試過程中、測試完成，以及UAT測試、準生產、釋出等不同的列。通過這些列的劃分，管理工作單元的流動，快速發現問題和解決問題。

通過看板可以讓工作視覺化、管理流動，並度量整個交付週期，看板一定要跨越整個價值流。

在這裡推薦一本書，何勉老師最近編寫的《精益產品開發》，前一個月剛上市，我認為是在國內做看板比較權威和完整的理論與實踐相結合的書，強烈推薦大家閱讀，裡面會講很多看板的方法和原則，如何建立、如何實踐。

這裡還要強調，做工作的視覺化要考慮全域性而不是區域性，如果僅僅度量開發的完成率、度量測試發現了多少缺陷、度量系統的可用性，這些都是區域性的目標。

我們更關注全域性、端到端的價值流動，如何整體加快從需求提出到生產部署的時間，去增加服務的可靠性和質量。精益裡講全域性的改進大於區域性的優化。這是視覺化的概述，看板也有很多方法和實踐，後面的分享裡再逐步分解。

3.1.2 限制在製品

限制在製品。剛才講了很多Handbook裡面的內容，下面講兩個小的故事，來理解在製品的概念。

• 第一個故事是“束水攻沙”，黃河千年以來都是由上游流下來很多泥沙，因為上游主要是在黃土高原，植被稀疏，泥沙不斷流入黃河，導致黃河的河床不斷抬高，所以我們叫黃河地上河，經常會有洪災。

  明朝時一個很有名的水利專家叫潘季馴，提出“束水攻沙”的治黃方針，通過收緊河道，利用水的衝擊力去衝擊河底的泥沙，從而達到清淤防洪的目的。更科學的理解，如果我們把河道的橫截面收窄，水流的量是固定的，河流的河道收窄，河流的速度會加快，會提升水流攜帶沙的能力，解決泥沙淤積的問題。

  “束水攻沙”，約束河道寬窄，把泥沙沖走，加快流速。在看板裡很關鍵一個實踐就是限制在製品，通過限制並行的任務數量，可以加速價值流動速度，並且幫助我們快速發現和解決問題。

• 第二個故事是“水落石出”，這個詞最早出現在蘇軾的一首詩裡，另外我們也可以把它演繹成湖水岩石效應。當一個湖裡有很多水，水面很高，湖中的石塊都被這些水覆蓋，這時即使有大的暗礁人也看不到。當水量逐步減小，一些大的石塊暴露出來，如果水量進一步減少，中等石塊、小石塊也逐步被發現。

  舉一個親身的例子，幾年前我去一個銀行參加他們新一代核心系統建設的工作，當時要求所有人996工作制，全銀行包括外包都是怎麼做的。但在具體執行的時候，雖然工作確實是早9點到晚9點，有些員工中午吃飯後去散散步，晚上去遊游泳，保證時間跨度是在12個小時，但實際產出是不一樣的。

  從領導的角度來講，要求所有的員工996，可能很難看到哪塊有瓶頸、哪塊有問題，因為從表面上看所有人都很忙。

  更好的思路也許是稍微降低一下工作的負荷，從996加班慢慢恢復到一個正常水平，之後可能會發現有的部門比較輕鬆正常的完成工作，有的部門還在不斷的堆積工作，在主動的加班，這時候瓶頸就發現了。我們叫“水落石出”，意思是說你降低了水面，問題自然就暴露了。

  限制WIP的概念給我們一個啟示，如果限制了我們正在並行處理工作的數量，可能自然而然會產生排隊，可以看到問題到底在哪裡。今天這兩個故事“束水攻沙”和“水落石出”，希望大家能夠更形象的理解，對大家去實施看板裡的限制在製品會有一些幫助。

我們來看一個實際的看板，為什麼要限制在製品？因為我們的工作來自於很多渠道，尤其是那些共享的職能部門，比如開發中心、測試中心、運維中心，我們有正常的任務，有工單、有郵件、有電話，也有老闆臨時派下來的緊急任務，日常工作經常會被打斷，切換成本非常高。

以前有過一個大致的統計，如果同時做兩個任務，每個任務所花的時間並不是50%，而是40%，因為有20%在做任務的上下文切換。

如果同時在做三個任務，花在每個任務上的時間只有20%，因為有40%的時間在做任務的切換。參照“束水攻沙”的思路，限制在製品，增加流速，讓整個流動速度加快，並且更快的發現問題。

參照“水落石出”的故事引申，因為限制了在製品，會發現某些下游環節（可能是測試、或者部署等）發生排隊，發現了阻塞就可以針對性的去解決問題。圖中右上角還有一些tips，如果已經產生堆積，這時候你處理的策略是什麼？這裡面有非常經典的一句話，”Stop starting，Start finishing”，我們要暫緩開始、聚焦完成。

我前一陣在北京的望京工作，這邊有個大山子十字路口，這個路口經常會堵車，那麼如果交警發現雙向車道已經堵死，他會怎麼處理？我相信交警第一步處理的動作是暫緩開始，所有的車不要再進入這個路口，然後他要把中間已經堆積的車一輛一輛疏通掉。這就是一個暫緩開始、聚焦完成的例子。

3.1.3 減少批量規模

減少批量規模。這裡面有一個簡單的實驗，如果有十封信要發，每封信製作需要四個步驟，分別是摺紙、插入信封、封口、貼郵票。

有兩種製作的方式:

• 第一種方式是大批量，先折完十張紙，把十張紙統一插入信封，統一封口，再把十個封口的信封統一貼上郵票。這麼做下來，所有事情完成是310秒。但如果後期發現錯誤，比如在第200秒要做第四個步驟的時候，才發現與之前的步驟不匹配，那麼這個時候前面所有的東西都要返工。

• 第二種方式，小批量策略，第一封信做完四個步驟再開始製作第二封信，以此類推，那麼第一封信全部做完所有步驟只花費40秒時間，比方式一第一次完成交付要快8倍。如果第四個步驟發現前面的步驟有錯，只需要把第一個信封的幾個步驟重做，就可以在代價非常小的情況下修正錯誤。

所以很多人認為敏捷是一種快速交付軟體的技術，其實並不是很準確，應該說它是一種能夠更早交付價值的技術，讓我能夠更早的交付軟體、靈活應對變化。

圖中右上角有一些tips，小批量給我們很多好處，更快的前置時間，更快的發現錯誤和解決問題，更少的返工。通過這個小的實驗，類比到IT交付價值流裡，我們關注的方法叫做單件流，持續部署就是單件流的一種實現，只要程式碼提交入庫，就自動做編譯、測試、部署與釋出，只要在我們的流水線裡完成了所有驗證，我們就認為這是一個潛在的可釋出的版本。我們要減少批量的規模，頻繁提交程式碼、頻繁整合和驗證，才能更早的進行交付。

3.1.4 減少交接數量

減少交接數量。這也是非常關鍵的一個實踐，程式碼從提交版本庫到執行在生產環境要經歷很多過程，有很多部門要跨越。

部門之間交接是非常痛苦的事情，交接意味著有人要發出請求，有人要去響應，要做很多解釋、說明，要做排期、排序，要解決衝突、做測試驗證等等，整個過程是非常耗時並且痛苦的。

過多的交接一定會導致整體效率的下降，只要壓力一上來，各個部門都是滿負荷運作，一定會出現排隊，就會導致前置週期加長，為了按時交付就需要向上升級，找到老闆干涉專案，臨時調整優先順序，這會造成更多混亂。

DevOps怎麼解決這個問題？最有效的方法是右下角這個圖，即實現自服務，我們要建設一個自服務的平臺賦能給開發。要提高整體生產效率，開發需要通過API和自服務的方式，自助完成常見的場景，比如申請環境、部署上線等。

在技術價值流裡關注兩個詞，自動和自助，自動是系統或平臺自動化的幫你完成日常操作，自助是給上游的開發人員賦能，讓他願意用運維做的系統或平臺完成一些任務。

之前看到一個挺不錯的文章，說DevOps分成四個階段:

• 第一個是隻有Dev沒有Ops，所有的事情開發自己搞定。

• 第二個階段是有Dev也有Ops，他們相互獨立，Ops承接了開發程式碼之外所有的工作。

• 第三個階段叫Dev+Ops，Ops做了一些自動化的工具提升效率，但主要是給自己去用，開發不用。

• 第四個階段才是DevOps，在上游工作的開發願意使用下游的運維提供的系統或平臺，通過API自助、自動的完成相應的工作。

這個描述非常容易理解，大家可以記住右下角這張圖，通過自服務和自助化，破解過多交接帶來的消耗。

3.1.5 持續識別和擴充約束

持續識別和擴充約束。為了縮短前置時間並增加吞吐量，我們需要找到瓶頸點，只有在瓶頸點處的改進才是真正有效的。

我們來看一個視訊，這個視訊在模擬日常工作場景，每個人有不同的容量，有的人工作容量高，有的人低一些。經常會發現工作會堆積在整個價值流裡工作容量最低的那個人或者部門頭上，比如這裡的3號工作人員，他的在製品不斷堆積，他是整個價值流的瓶頸。到了第五天時，這個人最終崩潰了，無法繼續完成工作。

這是約束理論帶給我們的啟示，我們需要找到和解決瓶頸，一般分為如下步驟:

• 第一步，識別瓶頸。找到佇列最長那個人，剛才講到的視覺化、限制WIP都是找到瓶頸的關鍵方法。

• 第二步，考慮如何拓寬約束。找到能夠拓寬約束點的辦法，挖盡潛能。比如在瓶頸點人員很疲憊的時候有替代人員支援，或者通過自動化，人休息了但機器不停歇等。

• 第三步，協調整個組織配合上述決策。如果有了工作堆積，按剛才講的策略是暫緩開始、聚焦完成，上游不要再急於推過來新的工作，而是把已經堆積的工作逐步完成。

• 第四步，提升系統約束。比如在最薄弱的環節增加資源，從本質上拓寬約束。

• 第五步，如果這個約束解決，回到第一步，但不允許惰性導致系統約束。就是說當一個約束點解決，下一個約束點可能就暴露出來，要持續解決約束。

  

  
  上面是約束理論中解決約束的方法，我們再結合實際情況，看一下IT價值流中如何解決約束。在IT價值流中，約束一般按以下四個階段演進。

• 首先是環境的約束。比如測試和生產環境通常需要向另外一個團隊申請，可能數天數週才能搭建好。那麼解決這個約束的對策，就是按需、完全自動化、自服務的方式申請環境。

• 如果環境問題解決了，大多數情況下第二個約束會到程式碼的部署，經過很多手工、易錯的過程才能完成程式碼的部署。解決這個約束的對策，就是自動化部署，目標是實現部署過程的自服務化。

• 瓶頸點逐步轉移，環境問題、部署的問題解決之後，通常瓶頸會轉移到測試，測試有時候是由另外的質量控制部門去做，有可能花兩週時間去準備環境和資料，然後再花另外四周做手工迴歸，這是無法滿足快速交付要求的。解決這個約束的對策是自動化測試，讓測試速度跟上程式碼部署速度，並且能平行進行。後面會講到，通過持續整合、持續交付流水線，每次程式碼提交都會觸發一個流水線的例項，這個例項執行自動化測試的時候可以並行做下一個功能的程式碼開發，儘量讓測試的過程自動化，並且能夠跟開發過程並行。

• 測試瓶頸解決之後，可能約束點就轉移到了緊耦合的架構，程式碼的變更都需要工程師找到經理的審批，因為大家的程式碼是緊耦合的，一處變更可能會影響別人，所以需要整體控制。解決這個約束的對策是架構解耦，讓變更以獨立、自治的方式安全進行，從而提升開發效率。架構解耦、自組織團隊是DevOps裡非常關鍵的環節，雖然之前大家談得更多是怎麼實現自動化環境配置、自動化部署、自動化測試，實際上，解耦才是大型企業處理複雜問題的前置要素。

3.1.6 在價值流中排除浪費

在價值流中排除浪費。傳統的製造業裡有七種浪費，分別是傳輸浪費、動作浪費、過度生產浪費、過度加工浪費、等待浪費、庫存浪費和缺陷浪費，後來又增加了一個創造力浪費。

在價值流裡要提升效率，就要看到軟體交付過程中的浪費。這裡也列舉了八種:

• 第一是部分完成的工作，比如未評審的需求文件和變更單。

• 第二是額外的流程，比如下游不使用的文件或者不增值的審批流程。

• 第三是額外的功能，精益創業裡面有一句話，軟體開發過程中最大的浪費就是構建沒有人在乎的東西，也就是說範圍鍍金會增加不必要的複雜性、帶來浪費。

• 第四是任務切換，前面為什麼說要限制在製品，因為要儘量減少任務切換的浪費。

• 第五是等待浪費，包括等待工作所需要的資源等，這增加了週期時間。

• 第六是動作浪費，包括需要頻繁溝通的人不在一地辦公。之前我走訪過一些企業，有的組織啟動敏捷轉型的一個必要條件，就是團隊的成員必須要集中在一起辦公，最大化的消除異地溝通中的浪費。

• 第七是缺陷浪費，如錯誤、缺失、不清晰的資訊導致的缺陷。

• 第八是非標準的工作，比如手工操作、不可重建的環境等。在價值流中要識別和解決八種浪費，才能加快價值流的流動速度。

3.2、三步工作法的核心思路-Feedback

剛才把三步工作法的第一步 — 流動原則講完了，下面來看第二步 — 反饋原則。這裡有四個實踐：

• 第一是在出現問題時及時發現

• 第二是密集解決問題、構建新的知識

• 第三是將質量向源頭推進

• 第四是為下游工作進行優化。

先給大家一個背景的認知，我們工作在複雜系統之上。Cynefin框架描述了組織所處的環境。組織所處環境有五種型別，分別是簡單、繁雜、複雜、混沌、失序。

簡單是指，因果關係是清晰可見的。繁雜是指，因果關係明確，但是需要專家研究和解決。複雜是指，因果關係可以被回溯，但不可能提前預知，這是絕大多數企業所處的狀態，這裡有一個關鍵詞是Emergent，翻譯過來是浮現，即解決方案是慢慢浮現出來的，而不是一次性就明確的，所以需要不斷探索、不斷試錯、不斷迭代。

我們所處的環境就是複雜的環境，出現問題是不可避免的，我們要做的是在問題發現時，快速發現和解決問題。

3.2.1 及時發現，密集解決問題

左邊的圖指出，需要持續測試我們的設計和運營假設，要不斷做驗證，提升問題發現的速度，增加恢復能力。

要建立向前的反饋迴圈，比如原來採用瀑布模型，有可能花費一年的時間開發一個產品，到最後一個月測試才發現有重大問題，這種反饋是非常慢的。

我們建議的方式是快速迭代，持續整合、持續交付的方式。程式碼提交之後幾分鐘就能得到一個反饋，這次提交的程式碼如果存在錯誤，能快速發現、快速解決。

右邊的圖是密集解決問題，最典範的例子是安燈拉繩，豐田在生產汽車之前生產了豐田的織布機，豐田織布機裡一個非常有用的裝置就叫做安燈拉繩，也就是說發現問題的時候及時通報並解決問題。

在精益生產過程中都會有安燈拉繩的裝置，參觀汽車生產線時，可以看到有的車架上會有一個安燈拉繩裝置，出現問題時可以被觸發，立即發現問題而不是繞開問題。因為如果選擇繞開問題，修復成本會幾何上升，不斷提升的技術債，讓下游工作更難完成。

在DevOps實踐中，持續整合是很關鍵的一個部分。之前業界大師Jez Humble和Martin Fowier提出了一個經典的測試，驗證是不是在做持續整合。

有些人說我用Jenkins，所以我在做持續整合，實際上這並不充分。這個測試有三個問題。

• 第一，是不是每個開發人員每天都向共享的主幹提交程式碼；

• 第二，是不是每次提交都會觸發流水線自動化的構建和執行；

• 第三，如果構建失敗，是不是可以在10分鐘之內修復。

為什麼舉這個例子，因為剛才講了很多，有些聽起來貌似是生產製造領域的一些理念，而實際上這些理念同樣是持續整合裡最關鍵的原則。

• 比如第一個問題，每個開發人員每天至少向主幹提交一次程式碼，這對應小批量原則，把工作批量變小，不是積累一個禮拜的程式碼一次性提交，而是每人每天都儘量提交他的程式碼，通過減少批次，提升流動效率。

• 第二，每次程式碼提交觸發一個自動化構建和流水線執行，剛剛講自動化是提升效率、減少交接很關鍵的方法，如果每次程式碼提交都自動觸發流水線，我們可以做到一定程度上的測試和開發並行。

• 第三，如果構建失敗在10分鐘內修復，這符合安燈拉繩的原理，第一時間發現問題並解決問題，這樣修復成本才是最低的。剛才我講的這些原則或實踐，就是我們每天所做的技術工作中都應該參照和對映的。

3.2.2 保持將質量向源頭推進，併為下游優化

保持將質量向源頭推進，併為下游優化。這裡面一個很關鍵的點，審批流程的有效性會隨著決策遠離工作執行處而降低。我們傾向於工作由下游的人去稽核審批，但是如果我們下游的人根本不瞭解我們工作的情況，這種審批就是不增值和無效的。

有一些無效審批的例子，比如需要跨越另外一個團隊去執行手工的任務，需要遠離工作執行處、最繁忙的人進行審批，強迫審批人在缺少足夠資訊的情況下做決策，以及編寫大量的文件，但其中很多細節在寫完後會很快過期，這些都是無效的質量控制。

有效的質量控制的例子，比如通過Peer Review確認變更是否符合設計，就像谷歌的程式碼文化，他們要求進入程式碼庫經過非常嚴格的自動化測試和程式碼評審，另外自動化儘可能多的質量檢查，就像傳統由測試和資訊保安部門做的那樣，讓開發人員可以快速測試自己的程式碼，甚至自己部署生產環境。

圖中右上角列舉了一些tips，我們需要價值流中的每個人在他們控制的領域裡找到並解決問題，作為日常工作的一部分。質量和安全責任要在工作執行處得到保障。

精益裡面有一個實踐叫做JKK，就是每個工作單元100%的完成和保證自身質量，戴明博士提出的內建質量也是這樣含義，質量不是測試出來的，而是在整個過程中內建進去的，我們要將質量向源頭推進。

3.3、三步工作法的核心思路-Continual Learning And Experimentation

三步工作法最後一步是持續學習和實驗原則。這裡面提了四個實踐：

• 第一是開啟組織學習和安全文化

• 第二是讓日常工作的改進做到制度化

• 第三是將區域性發現轉為組織全域性改進

• 第四是在日常工作中注入恢復模式。

3.3.1、開啟組織學習和安全文化

開啟組織學習和安全文化，因為我們工作在複雜系統中，不可避免會經常出錯。出現錯誤時，很多公司處理的方法是：Name , Blame , Shame。出現錯誤時是一種責備和追責為主的文化。

這樣會導致組織內形成一種恐懼感，如果團隊成員都很恐懼，怕做錯事受到責備，就會選擇把小的問題隱藏掉，直到問題積累到一定程度最終災難性的爆發。

Westrum模型提出組織文化的三種型別，分別是病態型組織、官僚型組織和生機型組織。

• 病態型組織的特點是大量的恐懼和威脅，傾向於隱藏失敗；

• 官僚型組織的特點是嚴格的規則和流程，每個部門各掃門前雪；

• 生機型組織是積極尋找和共享資訊，責任共享，失敗引發反思。

在DevOps的範疇裡應該構建生機型的文化，引導一個免責的故障事後分析機制，讓學習過程變成良性的迴圈。

下面這段文字我覺得非常有啟發，消除責備就會消除恐懼，消除恐懼就會得到誠實，誠實才能形成預防措施。從Name , Blame , Shame轉變為免責文化，收穫的是能夠找到問題的根因。

有一個很好例子，今年1月31號晚上GitLab發生了非常重大的事故，某個運維人員在凌晨刪除了資料庫，大概有6小時的資料丟失，包括合併請求、評論等，而且是永久性丟失。有707位使用者、5037個專案受影響。

官方視訊直播了恢復過程，他們主要做的是問題根因分析，採用了5W（五個為什麼）的方法，分析問題並制定改進措施。但是官方也表態，造成問題的運維人員不會被解僱，而是被迫看一個很無聊的視訊作為處罰。

這個例子反映出DevOps提倡的是免責的文化，重點並不在追責，而是轉移到根因分析和對於恢復過程的改進，這是生機型組織的明顯特徵。

3.3.2、改進位制度化，區域性發現轉為全域性改進

改進位制度化，區域性發現轉為全域性改進。

舉兩個案例，Linkedin 2003年成立，當時核心業務執行在叫做Leo的Java單體應用上，多年發展後，2010年Leo外圍有100個系統，問題是核心的Leo系統經常當機，難以釋出新程式碼。

於是Linkedin做出一個決定，通過兩個月時間，完全不做新的功能開發，完全聚焦在非功能需求上，將之前積累近十年的技術債務一次性償還，相信這是一個非常艱難的決定。

這個案例給我們的啟示，比日常工作更重要的，是改進日常工作，我們要把改進融入到日常的工作中。

右圖是將區域性發現轉為全域性改進的案例，平安科技有一個“看板大巡遊”的活動，在組織級推動看板時，每個團隊會選一個人參加看板巡遊活動，由一個敏捷教練帶隊，像導遊一樣帶著大家到各個團隊看板處觀摩，評價每團隊的看板，相互學習。

最終巡遊完成後，他們集中討論哪個地方好，哪個地方可以借鑑，最後把學到的成果用於自己的改善。這就是很典型的例子，把區域性發現轉化為全域性改進，比如可以讓整個組織都能檢索到事故分析報告，可以共享程式碼，讓程式碼橫跨整個組織被所有人都能搜尋到。

百度前幾年工程能力建設的重要部分，就是建立了基於Git的程式碼託管平臺，除了可以更容易進行程式碼庫和分支管理之外，很重要的一點是程式碼的全域性搜尋，在許可權範圍內可以讓更多人都搜尋到所需的程式碼片段，促進組織的知識複用。

3.3.4、在日常工作中注入恢復模式

在日常工作中注入恢復模式。這裡也有一個例子，豐田的一個頂級供貨商有兩條生產線，但是在Slow Day的時候會把所有的製造放在一條生產線上，用來實驗增大壓力、擴充容量是否會導致失敗，增強反脆弱的能力。

在技術價值流裡也有這種模式，比如Game Day演習，模擬大範圍失敗，或者在生產環境注入大範圍失敗。

經典的例子是Netflix的Chaos Monkey工具，會在生產環境隨機殺程式，用來確保整個系統有強大的恢復能力。還有一個金句，“避免失敗的最好辦法是經常失敗”，Martin Fowler也提出過，“If it hurts，do it more often”，如果某個事情讓你感到痛苦，解決方案就是頻繁的做。

對敏捷，DevOps感興趣的同學可以加入我們們的社群，裡面有大佬分享相關技術，不怕你學不會，就怕你不來，交流群的：175317069。