1、 全局優化DevOps系統工作流目 錄 TOC o 1-3 h z u HYPERLINK l _Toc522795201 一、使工作可見 PAGEREF _Toc522795201 h 3 HYPERLINK l _Toc522795202 二、限制在制品數 PAGEREF _Toc522795202 h 5 HYPERLINK l _Toc522795203 三、減小批量大小 PAGEREF _Toc522795203 h 7 HYPERLINK l _Toc522795204 四、減少交接次數 PAGEREF _Toc522795204 h 11 HYPERLINK l _Toc5227

2、95205 五、持續識別和改善約束點 PAGEREF _Toc522795205 h 12 HYPERLINK l _Toc522795206 六、消除價值流中的困境和浪費 PAGEREF _Toc522795206 h 14 HYPERLINK l _Toc522795207 七、小結 PAGEREF _Toc522795207 h 16本文以谷歌、亞馬遜、Facebook等全球知名企業和組織的實際調查結果為依據，展示如何通過現代化的運維管理提升管理效率，為企業贏得更大市場、創造更多利潤。在技術價值流中，工作通常是從開發人員流向運維人員，也就是業務和客戶之間的所有職能部門。本文要描述的第一步

3、工作法，就是建立從開發到運維之間快速的、平滑的、能向客戶交付價值的工作流。要為這個全局目標進行優化，而非圍繞一系列局部目標，如功能開發的完成度、測試中問題的發現率和修正率、運維維護的可用性等。通過持續加強工作內容的可視化，減小每批次大小和等待間隔，內建質量以防止缺陷向下游傳遞，從而增強流動性。通過加速技術價值流的流動，可以縮短滿足內部客戶和外部客戶需求的前置時間，進一步提高工作質量，并使我們更加敏捷，能夠比競爭對手更為出色。我們的目標是在縮短代碼從變更到生產環境上線所需時間的同時，提高服務的質量和可靠性。實際上，我們可以在制造行業中找到價值流應用的相關線索，幫助我們將精益原則應用到技術價值流中

4、。一、使工作可見技術行業的工作內容是不可見的，這是其與制造業價值流相比的一個顯著差異。相對于工業產品的生產過程而言，在技術價值流中很難發現工作過程的阻塞點，例如，在哪里受阻了，在哪個環節產生了積壓。而在制造業的價值流中，工作在不同工作中心間的轉移通常是顯而易見并且緩慢的，因為必須真正地轉移庫存產品。另一方面，技術工作的流轉通過單擊一次鼠標就可以完成，譬如將工單重新指派給另一個團隊。由于點擊的操作太過容易，所以不同團隊可能會因為信息不完整而將工作“踢來踢去”，存在的問題也會被傳遞到下游工序，而這些問題完全是不易察覺的，直到無法按時向客戶交付產品，或者應用程序在生產環境中出了問題。為了能識別工作在

5、哪里流動、排隊或停滯，就需要將工作盡可能地可視化。可視化工作板是一種較好的工作方式，如在看板或Sprint計劃板上，使用紙質或電子卡片將各項工作展示出來。工作通常從左側發起（從待辦事項中拉取），然后從一個工作中心拉取到下一個工作中心（用列表示），最后到達工作板的最右側，而這一列也通常被標記為“完成”或“已上線”。通過這種方式，不僅能將工作內容可視化，還能有效地管理工作，加速其從左至右的流動。此外，還可以通過卡片從在看板上創建到移動至“完成”這一列，度量出工作的前置時間。理想情況下，看板應該覆蓋整個價值流；僅當工作到達看板最右側時，才能算是已完成（見圖1）。開發完成某個功能不能算是“已完成”，只

6、有應用程序在生產環境里成功地運行起來，并開始為客戶提供價值的時候，才能算是“已完成”。圖1橫跨需求、開發、測試、預生產和生產的看板示例來源：David J. Andersen和Dominica DeGrandis 2012年的工作坊培訓材料“ITOps的看板”通過將每個工作中心的所有工作都放進隊列中，并且可視化地展示出來，利益干系人更容易從全局目標出發，確定各項工作的優先級。這樣，每個工作中心都能采用單任務的處理方式，從優先級最高的任務開始，依次完成所有工作，以增加工作中心的吞吐量。二、限制在制品數制造業的日常工作通常是由定期（如每天、每周）生成的生產計劃決定的，根據客戶訂單、交貨日期、零件庫

7、存等條件，確定執行哪些任務。但技術工作通常是動態的尤其是存在共享服務的情況下，團隊必須要同時滿足很多利益干系人的需求，這導致臨時安排控制了日常工作。緊急的工作可能會來自于各種渠道，譬如工單系統、宕機告警、電子郵件、電話、即時通信的消息或管理層決定的事件。生產中斷在制造業里很顯眼，且代價極高，當正進行中的工作戛然而止時，所有的半成品都將報廢，然后再啟動一批新作業。這種高昂的代價，讓人們不希望中斷頻繁發生。但是技術工作者很容易被打斷，因為對所有人而言，這個中斷的后果似乎是不可見的，即便它對生產效率的影響比制造業更甚。例如，將一個工程師同時分配到多個項目里，他不得不在多個任務、認知規則和目標之間來回

8、切換，付出重新進入角色的成本。研究表明，即便是完成簡單任務，如將各種幾何形狀分類，當同時執行多個任務時，效率也會顯著降低。從認知上看，技術價值流中的工作，顯然要比分類幾何形狀復雜得多，所以多任務會導致更長的處理時間。當使用看板管理工作時，可以限制多任務的出現，例如對看板的每一列或每個工作中心設置在制品數量的限制，并把卡片數量的上限標記在每一列上。例如，將測試工作的在制品數量上限設置為3。當測試隊列中已有3張卡片時，除非某張卡片完成了，或將3張中的一張退回到前一個隊列（左側的那一列），否則禁止添加新卡片。另外，在把一項工作用卡片的形式顯示在看板上之前，任何與之相關的工作都不能開展，這強調了任何工

9、作都必須可視化。Dominica DeGrandis是在DevOps中運用看板的專家之一，他指出：“控制隊列的長度（即在制品數）是一個非常強大的管理工具，因為這是影響前置時間的重要因素之一對于大多數的工作條目而言，在它們完成以前，其實并無法預測到底需要多長時間。”通過限制在制品數，還能更容易地發現工作中的阻礙。例如，當限制在制品時，可能會發現居然沒什么工作可干的，因為要等待其他人。大野耐一把限制在制品比喻為給水庫排水來識別出阻礙快速流動的所有問題。正如看板方法：科技企業漸進變革成功之道的作者David J. Anderson所說：“停止開始，開始結束。”雖然進行一項新工作（即“干點什么總比什么

10、都不干強”）可能很誘人，但此時更好的做法是查明導致等待的原因，并協助解決那個等待的問題。實際上，糟糕的多任務處理發生的原因，通常是同時給一個人分配多個項目，造成了很多優先級沖突問題。三、減小批量大小建立平滑而快速的工作流的另一個關鍵點，是通過小批量的模式完成工作。在精益革命以前，大批量（或規模）生產的方式在制造業司空見慣，在作業配置或作業之間的切換相當耗時且昂貴時尤其如此。例如，在生產大型汽車時，需要將巨大而沉重的模具放到金屬沖壓機上，這個過程可能需要好幾天時間。鑒于成本如此高昂，通常會用大批量作業，一次沖壓出盡可能多的車身板，從而減少模具的更換次數。然而，大批量導致在制品的暴漲，并在整個制造

11、工廠中產生流量級聯的變化。最后導致前置時間長、產品質量差的后果如果發現了一個車身板有問題，整個批次都必須報廢。在精益中，一個重要的經驗是：為了縮短前置時間和提高交付物質量，應當持續不斷地追求小批量模式。理論上，最小的批量是單件流，也就是每次操作只執行一個單位產品的處理。也稱為“1的批量大小”或“11流量”，該術語表示批量大小和在制品都限制為1。關于小批量和大批量之間的巨大差異，James P. Womack和Daniel T. Jones在精益思想 一書里，通過“模擬郵寄宣傳冊”的經典案例進行了說明。這個例子假設要郵寄出10本宣傳冊。郵寄之前，每本宣傳冊都必須經歷4個步驟：折疊，插入信封，給信

12、封封口，蓋戳。如果采用大批量策略（即“大規模生產”），我們會對每本宣傳冊按順序執行上述4個步驟。換句話說，首先要將10張紙全都折疊完，再將每張紙分別插入信封，然后給所有的信封封口，最后全部蓋章。另一種方式是小批量策略（即“單件流”），即對每本宣傳冊順序地執行所需的所有步驟，然后再開始處理下一本宣傳冊。換句話說，先折疊一張紙，將其插入信封，再給信封封口，之后蓋章；然后，取下一張紙，并重復以上過程。采用大批量和小批量策略之間的差異是巨大的（見圖2）。假設對所有10個信封都必須采取如上4個步驟，并且每一步操作需要10秒。如果使用每批5個的大批量策略處理，則完成第一個蓋戳的信封需要用310秒。譯者注：

13、這里是“51流量”，即批量大小為5，在制品為1。由于這里是單人模擬的場景，并且一雙手同時只能加工一個信封，所以在制品數量也只能為1。310秒 = (5 10 + 5 10) + (5 10 + 5 10) + (5 10 + 5 10) + 10。圖2模擬“信封游戲”（折疊、插入、封口、蓋章）來源：Stefan Luyten的文章“單件流：為什么大批量生產不是最有效的處理工作的方式”。參考鏈接：/stefanluyten/single-piece-flow-5d2c2bec845b#.9o7sn74ns更糟糕的是，假設我們在信封封口操作中發現第一步的折疊做錯了，在這種情況下，我們能發現錯誤的最

14、早時間是在200秒之后，那樣我們就不得不將這個批次的10個小冊子再重新折疊并裝回信封中。相比之下，使用小批量策略時，僅用40秒就完成了第一封蓋戳信的生產，比大批量策略快8倍。如果第一步出錯了，只需要返工一本小冊子。小批量生產的在制品更少，前置時間更短，錯誤檢測更快，返工量更少。對于技術價值流而言，大批量的副作用和制造業一樣。我們制訂了軟件發布的年度計劃，將一整年的開發成果一次性地都發布到生產環境中。這種大批量的發布會造成突發的、大量的在制品，導致所有下游工作中心（多指數據中心的運維部門）大規模的混亂，其結果是流動性變差，質量下降。這和我們闡述的經驗是類似的，即對生產環境的變更越大，問題的定位和

15、修復就越困難，修復時間也就越長。Eric Ries在“創業經驗教訓”（Startup Lessons Learned）這篇文章中說：“在開發（或DevOps）流程中，批量大小是工作產品在不同階段間移動的單位數。對于軟件而言，最容易看到的是代碼。當工程師簽入代碼時，他們就批量地處理了一定數量的工作。有許多控制批處理的方式，從持續部署要求的小批量，到相對傳統的基于分支的大型模塊開發，都是聚合多個開發人員幾周或幾個月所工作的代碼。”在技術價值流中，單件流可以通過持續部署實現。其中，每一個提交到版本控制系統的變更都會集成、測試并部署到生產環境。（本書強調的是端到端的價值流，只有在部署之后，把價值交付給

16、客戶了，一項工作才算完成，因此是持續部署。）四、減少交接次數在技術價值流中，如果部署的前置時間以月作為周期單位，通常是因為要將版本控制系統中的代碼部署到生產環境需要數百甚至數千個操作。實際上，代碼在價值流流轉的過程中，需要各個不同部門的協同才能完成相關任務，包括功能測試、集成測試、環境搭建、配置服務器、存儲管理、網絡、負載均衡設備和信息安全加固等。一項工作在團隊之間交接時，需要大量的溝通請求、委派、通知、協調，而且經常需要排優先級、調度、消除沖突、測試和驗證。這些工作可能還需要使用不同的工單系統或項目管理系統，編寫技術規范文檔，用會議、電子郵件或電話的形式進行溝通，可能還涉及文件共享服務器、F

17、TP服務器和Wiki頁面的使用。實際上，上述流程中的每個環節都有其潛在的隊列，當依賴不同價值流共享的資源（例如集中式操作）時，就會出現工作等待。這些請求的前置時間通常會很長，從而導致那些本應按期操作完的工作持續地延期。即使在最好的情況下，有些信息或者知識也不可避免地在交接過程中丟失。經歷了多次的交接后，問題的上下文和所支持的組織目標可能會完全丟失。例如，服務器管理員可能會收到一個關于創建用戶賬號的新工單，但是他并不知道是什么應用程序或服務會使用這個賬號，為什么需要新建賬號，其他的依賴關系是什么，或者這到底是不是一個重復勞動。為了減少這類問題的出現，要么努力減少交接次數，要么用自動化方式執行大部

18、分操作，要么重新調整組織結構，讓團隊不必依賴其他人就可以獨立地為客戶提供價值。因此，要通過減少隊列中的等待時間以及非增值工作的時間來增加流動性。五、持續識別和改善約束點為了縮短前置時間、提高吞吐量，我們需要不斷地識別系統中的約束點，提高工作產能。Goldratt博士在Beyond the Goal一書中提到：“在任何價值流中，總是有一個流動方向、一個約束點，任何不針對此約束點而做的優化都是假象。”如果我們優化約束點之前的那個工作中心，那么工作必將在這個約束點上更快地積壓起來。反之，如果優化約束點之后的工作中心，那么它還會處于饑餓狀態，等待約束點處工作的結束。對于這種現象，Goldratt博士給

19、出了解決方案，定義了如下“5個關鍵步驟”：識別系統的約束點；決定如何利用這個系統約束點；基于上述決定，考慮全局工作；改善系統的約束點；如果約束點已經突破了，請回到第一步，但要杜絕慣性導致的系統約束。在DevOps的轉型過程中，如果希望前置時間從月或季度縮短為幾分鐘，那么一般需要依次優化下面的約束點：環境搭建：如果生產或測試環境的搭建總是需要數周或數月，則按需部署就無法實現。解決措施是按需建立完全自服務的環境，保證團隊在需要環境的時候，能通過自動化方式創建。代碼部署：如果代碼的部署需要花數周或更長時間（譬如每次部署需要1300個手動、易出錯的操作，涉及多達300名工程師），那么就無法按需部署。解

20、決措施是盡可能自動化部署的過程，以便讓任何開發人員都可以按需自動化地部署。測試的準備和執行：如果每次代碼部署都需要兩周的時間來完成測試環境的準備和數據集的配置，手動執行所有的回歸測試還需要另外四周時間，那么就無法實現按需部署。解決措施是實現自動化測試，這樣才能在安全、并行地執行部署的同時，使測試的速度能跟上代碼開發的速度。緊密耦合的架構：如果架構是緊密耦合的，那也無法實現按需部署，因為每次要做代碼變更時，工程師都不得不從變更評審委員會里獲得執行變更的許可。解決措施是創建松散耦合的架構，這樣開發人員才能安全、自主地進行變更，提高生產力。如果能突破以上的約束點，那么接下來的約束有可能是開發部門或產

21、品經理。因為我們的目標是讓小型開發團隊可以獨立、快速、可靠地開發、測試和部署，并持續為客戶創造價值，所以這些環節應該是約束點集中的所在。對于高績效者來說，不管工程師是處于開發、QA、運維還是信息安全崗位，他們的目標都是盡量提高生產力。當約束點出現在開發階段時，我們將僅受限于有多少創意精良的業務假設，以及能否開發出必要的代碼來用真實客戶來測試這些假設。以上所述的約束點在DevOps轉型中是相當普遍的在價值流中識別約束點的技術，諸如如何使用值流映射和度量的方法，以后會詳細描述。六、消除價值流中的困境和浪費豐田生產系統的先驅之一新鄉重夫認為，浪費是業務興盛的最大威脅精益中對浪費的常用定義是“使用了超

22、出客戶需求和他們愿意支付范圍的任何材料或資源的行為”。他定義了制造業里7種主要的浪費類型：庫存、過量生產、過度加工、運輸、等待、移動和缺陷。現代化的精益理念解釋道：“消除浪費”會有點貶義和不近人情的意味，我們的目標其實是想通過持續的學習來破除日常工作中的困境，從而更好地實現組織的目標。在本書的后續內容里，“浪費”一詞意味著這個更具現代感的定義，因為它更符合DevOps所期望的理想境界。Mary和Tom Poppendieck在Implementing Lean Software Development: From Concept to Cash一書中描述道：浪費和困境是軟件開發過程中導致交付延遲的主要因素。下面是該書中描述的關于浪費和困境的部分類型：半成品：它指的是價值流里任何還沒有徹底完成的工作（例如，需求文檔或尚未審核的變更單）、處于隊列中的工作（如等待QA審核或服務器管理員審核的工單）。部分完成的工作會逐漸地過期，隨著時間的推移最終失去了價值。額外工序：在交付過程中執行的、并未給客戶增值的額外工作，可能包括那些在下游工作中心從沒使用過的文檔，或是對輸出結果做出的并不增值的評審或審批。額外工序不僅增加了處理的工作量，還增加了前置時間