《DevOps實踐指南》第一部分

• 2019 年 12 月 10 日
• 筆記

《DevOps實踐指南》第一部分

第一部分　DevOps 介紹

• DevOps 的三步工作法：流動、回饋以及持續學習與實驗

簡史

• DevOps 基於精益、約束理論、豐田生產系統、柔性工程、學習型組織、安全文化、人員優化因素等知識體系，並參考了高信任管理文化、服務型領導、組織變動管理等方法論。把所有這些最可信的原則綜合地應用到 IT 價值流中，就產生出 DevOps 這樣的成果

精益運動

• 精益的兩個主要原則包括：堅信前置時間（把原材料轉換為成品所需的時間）是提升品質、客戶滿意度和員工幸福感的最佳度量指標之一；小批量任務的交付是縮短前置時間的一個關鍵因素
• 精益原則聚焦在如何通過系統性思考為客戶創造價值，系統性思考的範圍涉及建立持久目標，擁抱科學思維，創造流和拉動（而非推送）的協作模式，提倡從源頭保證品質，以謙遜為導向，尊重流程中的所有個體

敏捷宣言

• 在敏捷宣言中，一個重要的原則是「頻繁地交付可工作的軟體，交付周期可以是數星期也可以是數月，推薦更短的周期」，並強調使用小批量任務進行增量發布
• Mike 得出了結論：精益社區中大多數企業都沒有抓住精益的核心——改善套路（Kata）

第 1 章　敏捷、持續交付和三步法

1.1　製造業價值流

• 精益中的一個基本概念叫價值流
• 為「一個組織基於客戶的需求所執行的一系列有序的交付活動」，或者是「為了給客戶設計、生產和提供產品或服務所需從事的一系列活動，它包含了資訊流和物料流的雙重價值」

1.2　技術價值流

• 在DevOps中，我們通常將技術價值流定義為「把業務構想轉化為向客戶交付價值的、由技術驅動的服務所需要的流程」
• 不但要快速地交付，同時還要保證部署工作不會產生混亂和破壞，如中斷客戶服務、性能下降或者資訊安全不合規等問題

聚焦於部署前置時間

• 部署的前置時間是價值流的一個子集，也是本書討論的重點。價值流始於工程師1（包括開發、QA、IT運維和資訊安全人員）向版本控制系統中提交了一個變更，止於變更成功地在生產環境中運行，為客戶提供價值，並生成有效的回饋和監控資訊
• 目標是採用測試和運維與設計和開發同步的模式，從而產生更快的價值流和更高的品質。只有當工作任務是小批量的，並將品質內建到價值流的每個部分時，這種同步的模式才能實現
• 定義前置時間和處理時間
• 前置時間與處理時間（有時候也被稱為接觸時間或者任務時間）3是度量價值流性能的兩個常用指標
• 前置時間在工單創建後開始計時，到工作完成時結束；處理時間則從實際開始處理這個工作時才開始計時，它不包含這個工作在隊列中排隊等待的時間（見下圖）

• 常見的場景：為期數月的部署前置時間
• 測試和生產環境的前置時間很長，並且嚴重依賴於手動測試，或者需要各種審批流程，情況更是如此

• 部署前置時間一旦變長，那麼在價值流的每個階段，幾乎都需要「填坑」能手來補救。通常，
• 我們的目標：分鐘級別的部署前置時間
• 在DevOps的理想情況下，開發人員能快速、持續地獲得工作回饋，能快速和獨立地開發、集成和驗證程式碼，並能將程式碼部署到生產環境中（自己部署或者他人部署）
• 為了更容易地實現上述目標，還需要通過模組化、高內聚、低耦合的方式優化架構設計

關注返工指標——%C/A

• 技術價值流中的第三個關鍵指標是完成時間和精確的總花費時間的百分比（%C/A）。該指標反映了價值流中的每個步驟的輸出品質

1.3　三步工作法：DevOps的基礎原則

• 《鳳凰項目》把三步工作法作為基礎的原則，由此衍生出了DevOps行為和模式

• 第一步：實現開發到運維的工作快速地從左向右流動。為了最大程度地優化工作流，需要將工作可視化，減小每批次大小和等待間隔，通過加快技術價值流的流速，縮短滿足內部或者外部客戶需求所需的前置時間，尤其是縮短程式碼部署到生產環境所需的時間，可以有效地提高工作品質和產量，並使企業具有更強的外部競爭力
• 第二步：在從右向左的每個階段中，應用持續、快速的工作回饋機制。這樣不僅能創造出更安全的工作系統，還可以在災難性事故發生前就檢測到並解決它
• 第三步：建立具有創意和高可信度的企業文化，支援動態的、嚴格的、科學的實驗。通過主動地承擔風險，不但能從成功中學習，也能從失敗中學習

1.4　小結

• 價值流概念
• 重要量度指標——前置時間
• 三步工作法（支撐DevOps的原則）

第 2 章　第一步：流動原則

• 就是建立從開發到運維之間快速的、平滑的、能向客戶交付價值的工作流

2.1　使工作可見

• 技術行業的工作內容是不可見的，這是其與製造業價值流相比的一個顯著差異
• 由於點擊的操作太過容易，所以不同團隊可能會因為資訊不完整而將工作「踢來踢去」，存在的問題也會被傳遞到下游工序，而這些問題完全是不易察覺的，直到無法按時向客戶交付產品，或者應用程式在生產環境中出了問題
• 為了能識別工作在哪裡流動、排隊或停滯，就需要將工作儘可能地可視化。可視化工作板是一種較好的工作方式，如在看板或Sprint計劃板上，使用紙質或電子卡片將各項工作展示出來

• 通過將每個工作中心的所有工作都放進隊列中，並且可視化地展示出來，利益干係人更容易從全局目標出發，確定各項工作的優先順序

2.2　限制在制品數

• 但是技術工作者很容易被打斷，因為對所有人而言，這個中斷的後果似乎是不可見的，例如，將一個工程師同時分配到多個項目里，他不得不在多個任務、認知規則和目標之間來回切換，付出重新進入角色的成本
• 當使用看板管理工作時，可以限制多任務的出現，例如對看板的每一列或每個工作中心設置在制品數量的限制，並把卡片數量的上限標記在每一列上
• 例如，將測試工作的在制品數量上限設置為3。當測試隊列中已有3張卡片時，除非某張卡片完成了，或將3張中的一張退回到前一個隊列（左側的那一列），否則禁止添加新卡片
• Dominica DeGrandis是在DevOps中運用看板的專家之一，他指出：「控制隊列的長度（即在制品數）是一個非常強大的管理工具，因為這是影響前置時間的重要因素之一——
• 當限制在制品時，可能會發現居然沒什麼工作可乾的，因為要等待其他人。雖然進行一項新工作（即「干點什麼總比什麼都不幹強」）可能很誘人，但此時更好的做法是查明導致等待的原因，並協助解決那個等待的問題

2.3　減小批量大小

• 建立平滑而快速的工作流的另一個關鍵點，是通過小批量的模式完成工作
• 在精益中，一個重要的經驗是：為了縮短前置時間和提高交付物品質，應當持續不斷地追求小批量模式。理論上，最小的批量是單件流，也就是每次操作只執行一個單位產品的處理

• 這種大批量的發布會造成突發的、大量的在制品，導致所有下游工作中心4大規模的混亂，其結果是流動性變差，品質下降
• 在開發（或DevOps）流程中，批量大小是工作產品在不同階段間移動的單位數。對於軟體而言，最容易看到的是程式碼。當工程師簽入程式碼時，他們就批量地處理了一定數量的工作
• 在技術價值流中，單件流可以通過持續部署實現。其中，每一個提交到版本控制系統的變更都會集成、測試並部署到生產環境

2.4　減少交接次數

• 在技術價值流中，如果部署的前置時間以月作為周期單位，通常是因為要將版本控制系統中的程式碼部署到生產環境需要數百甚至數千個操作
• 當依賴不同價值流共享的資源（例如集中式操作）時，就會出現工作等待
• 即使在最好的情況下，有些資訊或者知識也不可避免地在交接過程中丟失
• 為了減少這類問題的出現，要麼努力減少交接次數，要麼用自動化方式執行大部分操作，要麼重新調整組織結構，讓團隊不必依賴其他人就可以獨立地為客戶提供價值

2.5　持續識別和改善約束點

• 在任何價值流中，總是有一個流動方向、一個約束點，任何不針對此約束點而做的優化都是假象
• 優化約束點之後的工作中心5個關鍵步驟
  • 識別系統的約束點
  • 決定如何利用這個系統約束點
  • 基於上述決定，考慮全局工作
  • 改善系統的約束點
  • 如果約束點已經突破了，請回到第一步，但要杜絕慣性導致的系統約束
• 在DevOps的轉型過程中，如果希望前置時間從月或季度縮短為幾分鐘
  • 環境搭建：如果生產或測試環境的搭建總是需要數周或數月，則按需部署就無法實現。解決措施是按需建立完全自服務的環境，保證團隊在需要環境的時候，能通過自動化方式創建
  • 程式碼部署：如果程式碼的部署需要花數周或更長時間（譬如每次部署需要1300個手動、易出錯的操作，涉及多達300名工程師），那麼就無法按需部署。解決措施是儘可能自動化部署的過程，以便讓任何開發人員都可以按需自動化地部署
  • 測試的準備和執行：如果每次程式碼部署都需要兩周的時間來完成測試環境的準備和數據集的配置，手動執行所有的回歸測試還需要另外四周時間，那麼就無法實現按需部署。解決措施是實現自動化測試，這樣才能在安全、並行地執行部署的同時，使測試的速度能跟上程式碼開發的速度
  • 緊密耦合的架構：如果架構是緊密耦合的，那也無法實現按需部署，因為每次要做程式碼變更時，工程師都不得不從變更評審委員會裡獲得執行變更的許可。解決措施是創建鬆散耦合的架構，這樣開發人員才能安全、自主地進行變更，提高生產力
• 如果能突破以上的約束點，那麼接下來的約束有可能是開發部門或產品經理

2.6　消除價值流中的困境和浪費

• 浪費和困境的部分類型
  • 半成品：它指的是價值流里任何還沒有徹底完成的工作（例如，需求文檔或尚未審核的變更單）、處於隊列中的工作（如等待QA審核或伺服器管理員審核的工單）
  • 額外工序：在交付過程中執行的、並未給客戶增值的額外工作，可能包括那些在下游工作中心從沒使用過的文檔，或是對輸出結果做出的並不增值的評審或審批
  • 額外功能：在交付過程中構建的那些組織或客戶完全不需要的功能（如「鍍金」）
  • 任務切換：將人員分配到多個項目和價值流里後，他們需要進行上下文切換
  • 等待：由於資源的競爭而在工作之間產生了等待
  • 移動：資訊或數據在工作中心之間移動的工作量。例如，在一個需要頻繁溝通的項目里，團隊成員實際上不在一起辦公，無法坐在一起緊密協作，另外，工作交接也會產生移動的浪費，需要額外的溝通來澄清所有歧義的部分
  • 缺陷：由於資訊、材料或產品的錯誤、殘缺或模糊，而需要一定的工作量來確認
  • 非標準或手動操作：需要依賴其他人的非標準的或手動的工作，例如使用不能自動化反覆重建的伺服器、測試環境和配置
  • 填坑俠：為了實現組織的目標，不得不把有些人和團隊置於不太合理的處境（連夜給軟體版本提交了上百個工單）
• 我們的目標是將這些浪費和困境（任何需要填坑俠的場合）都可視化，並系統地進行改進，減輕或消除這些負擔，從而實現快速流動的目標

第 3 章　第二步：回饋原則

• 第一步工作法描述的原則，使得工作能夠在價值流中從左向右快速地流動。第二步工作法描述的原則，則使得在從右向左的每個階段中能夠快速、持續地獲得工作回饋

3.1　在複雜系統中安全地工作

• 複雜系統的一個重要特徵是，無法將系統視為一個整體，去理解各個部分是如何組合在一起的
• 複雜系統的另一個特點：相同的事情做兩次，結果未必相同
• 採取以下4項措施讓複雜系統更安全地工作
  • 管理複雜的工作，從中識別出設計和操作的問題
  • 群策群力解決問題，從而快速地構建新知識
  • 在整個組織中，將區域性的新知識應用到全局範圍
  • 領導者要持續培養有以上才能的人

3.2　及時發現問題

• 在所有工作執行的過程中，建立快速的回饋和前饋迴路。這包括創建自動化的構建、集成和測試過程，以便儘早檢測出那些可能導致缺陷的程式碼變更
• 我們還要建立全方位的監控系統，監控服務組件在生產環境中的運行狀態，以便快速探測到服務的意外情況。監控系統還能幫助我們度量是否偏離了預期目標，並將監控結果輻射到整個價值流中，這樣就能看到我們的行為是如何影響系統里的其他部分的

3.3　群策群力，戰勝問題獲取新知

• 一旦問題出現了，我們還必須群策群力，發動所有相關的人員解決問題
• 群策群力的目的是遏制住問題，防止蔓延，然後定位和處理問題，避免複發
• 讓所有參與者都得到更深入的知識，理解如何管理系統，把無法規避的、早期的無知階段變成學習的過程
• 群策群力的原因如下：
  • 防止把問題帶入下游的處理環節，否則不但修復的成本和工作量會呈指數級增加，而且還會欠下技術債
  • 防止工作中心啟動新的工作，那樣可能會在系統中引入新的錯誤
  • 如果問題還沒有得到解決，那麼工作中心在下一次操作（如55秒後）中，可能還會遇到相同的問題，需要更高的修復成本
• 這種全民總動員的做法似乎違背了常規管理方法，因為局部問題擾亂了整體的運營。然而，全民總動員讓學習成為了可能
• PDCA環——計劃（Plan）、實施（Do）、檢查（Check）、改進（Act）
• 只有儘可能在早期階段，通過全民總動員的方式來解決小問題，才能把災難性事故消滅在萌芽狀態
• 為了在技術價值流中實施快速回饋，我們必須建立等同於安燈繩和全民響應的機制
• 觸發了安燈繩時，我們就聚集在一起解決問題，停止開展任何新工作，直到問題解決。4這給價值流中的每個人提供了快速回饋（特別是那個導致系統故障的人），讓我們能夠快速地隔離和定位問題，避免出現更複雜的狀況，導致問題的因果關係變得模糊

3.4　在源頭保障品質

• 品質控制無效的例子
  • 需要其他團隊幫忙完成一系列乏味、易出錯和手動執行的任務，這些任務本應該由需求方自己採用自動化方式完成
  • 需要那些遠離實際工作場所且公務繁忙的人批准，迫使他們在不了解工作情況和潛在影響的情況下做出決策，或者僅僅是例行公事式地蓋章批准
  • 編寫大量含有可疑細節，且在寫後不久就過時了的文檔
  • 將大量工作推給運維團隊和專家委員去審批和處理，然後等待回復
• 儘可能多用自動化方式執行通常由QA和資訊安全人員來進行的品質檢查。按需執行自動化測試，而無需開發人員向測試團隊請求或發起測試工作。這樣，開發人員能夠快速地測試自己的程式碼，甚至把程式碼的變更部署到生產環境中

3.5　為下游工作中心而優化

• 精益定義了我們必須為兩類客戶而設計：外部客戶（最有可能為我們提供的服務付費的人）和內部客戶（緊隨我們立即接收和處理工作的人）。根據精益原則，我們最重要的客戶是我們的下游

3.6　小結

• 建立快速的回饋機制，對於實現技術價值流中的高品質、可靠性和安全性至關重要。為此，要在問題發生時識別問題，群策群力解決問題並構建新的知識，在源頭控制品質，並且不斷地為下游工作中心做優化

第 4 章　第三步：持續學習與實驗原則

4.1　建立學習型組織和安全文化

• 三種類型的企業文化
• 病態型：病態型組織的特點是組織中存在大量恐懼和威脅。由於政治原因，個體為了保全自身利益，通常會隱瞞真相或者歪曲事實。在這種組織中，故障和事故經常被隱瞞
• 官僚型：官僚型組織的特點是規則和流程僵化，所有部門通常都「自掃門前雪」。在這種組織中，通過評判系統處理事故，結果往往恩威兼施
• 生機型：生機型組織的特點是積極探索和分享資訊，讓組織更好地履行使命。在這種組織中，整個價值流中所有的員工共同承擔責任，對事故進行積極反思，並進行真正的根因調查

• 在意外和故障發生時，關注如何重新設計系統，從而防止事故複發，而不是去追究人的問題
• 例如，可以在每次事故發生後進行不指責的回顧，對事故發生的原因和過程做出客觀解釋，並就優化系統的最佳措施達成一致

4.2　將日常工作的改進位度化

• 比日常工作更重要的，是對日常工作的持續改進
• 通過明確預留時間來改善日常工作，包括預留時間來償還技術債、修復缺陷、重構和優化程式碼和環境。可以在每個開發周期的間歇中預留一段時間，或者安排改善閃電戰（kaizen blitze）時段，讓工程師通過自組團隊的方式來解決他們感興趣的問題
• 對於技術價值流而言，讓工作系統更加安全也一樣有助於發現和解決潛在風險。例如，一開始我們可能只是對影響客戶服務的事故做不指責的事後調查，隨著時間的推移，我們將逐漸地識別其他潛在風險

4.3　把局部發現轉化為全局優化

• 一旦在局部範圍內取得了成果，就應當把它分享給組織里的其他人，讓更多的人從中獲益。我們的目標是把這些隱性知識（即很難通過文檔或溝通的方式傳遞的知識）轉換為顯性知識，從而幫助其他人吸取這些專業知識並在實踐中應用
• NR以恪守標準化流程而聞名於世，出現任何流程或操作偏差都要寫故障報告，以便積累經驗。不管故障訊號強弱，或者風險大小如何，都會基於這些經驗持續地更新流程和系統設計
• 這樣帶來的結果是：在任何一組新船員出海時，他們都能迅速地從集體長期積累的智慧中獲得成長
• 在技術價值流中，我們也應該通過類似的機制建立全局知識庫。例如，把所有事故報告轉化成可搜索的知識庫，讓有需要的團隊能更加方便地使用它去解決類似問題，同時建立起組織級的共享源程式碼庫，讓所有人可以方便地使用整個組織的程式碼、庫和配置。這些機制有助於把個人的專業知識轉化為服務更多成員的集體智慧

4.4　在日常工作中注入彈性模式

• 在技術價值流中，通過縮短部署的前置時間、提高測試覆蓋率、縮短測試執行時間，甚至在必要時解耦架構，都屬於在系統中引入類似張力的做法，也都能夠提高開發人員的生產效率及可靠性

4.5　領導層強化學習文化

• 領導者可以使用下列問題來幫助和輔導實驗者
  • 上一步做了什麼？發生了什麼？
  • 你從中學到了什麼？
  • 現狀如何？
  • 下一個目標條件是什麼？
  • 當前工作有什麼阻礙？
  • 下一步做什麼？
  • 期望的結果是什麼？
  • 什麼時候能進行複查？
• 領導者幫助一線工作者在日常工作中發現並解決問題，這種方式實際上就是豐田生產系統的核心，也是學習型組織、改善套路和高可靠性組織的核心

4.6　小結

• 三步工作法的第三步原則實現了學習型組織，實現了職能部門之間的高度信任和跨部門合作，接受了「複雜系統中總會發生故障」的事實，並鼓勵談論任何問題以建立一個安全的工作系統

4.7　第一部分總結

• 探討了DevOps組織轉型的三步工作法：流動原則、回饋原則和持續學習與實驗原則

書籍

• 《豐田套路：轉變我們對領導力與管理的認知》
• 《第五項修鍊：學習型組織的藝術與實踐》
• 《探索吧！深入理解探索式軟體測試》
• 《看板方法：科技企業漸進變革成功之道》
• 《精益思想》
• 《第五項修鍊：學習型組織的藝術與實踐》
• 《豐田套路》
• 《精益企業》
• 《走動管理》