1 of 44

讀書分享：The DevOps Handbook (2)

DevOps讀書會

2022-04-06 游上德

�

B L U E P L A N E T

2 of 44

大綱

讀書分享：The DevOps Handbook

  • 回顧
  • III. 第一步工作法：暢流的技術實踐
  • IIII. 第二步工作法：回饋的技術實踐
  • V. 第三步工作法：持續學習與實驗的具體實踐

2

2

B L U E P L A N E T

3 of 44

回顧

  1. 三步工作法
  2. 從何處開始

3

B L U E P L A N E T

4 of 44

「精實原則」與「前置時間」

  • DevOps是精實原則 (Lean Principle)應用到科技價值流的成果。
  • 為了縮短前置時間，需要減少批次規模、降低「在製品」(WIP)數量、避免重工等，同時要確保不會將殘次品傳遞到下游工作，並且持續從全局目標來優化整個工作系統。

4

B L U E P L A N E T

5 of 44

最小批次規模

  • 理論上最小的批量規模是「單件流」(single-piece flow)
  • 經典案例：發送十本廣告冊，投遞之前，每一本廣告冊都必須歷經四個步驟「折疊」、「塞入信封」、「彌封」、「蓋上戳印」。大批量策略是依序執行四個步驟；小批量策略是每次對一本廣告冊處理完四個步驟。

5

B L U E P L A N E T

6 of 44

三步工作法

  1. 暢流原則：�從開發平順過渡到營運
  2. 回饋原則：�持續不斷的回饋機制
  3. 持續學習與實驗原則：�互信的文化與主動實驗

6

B L U E P L A N E T

7 of 44

償還技術債

  • 比日常工作更重要的事情就是改善日常工作。
  • 為了有效管理技術債，要確保至少把20%的開發和營運週期投入到重新構建自動化工作、結構優化以及非功能性需求上。

7

B L U E P L A N E T

8 of 44

參考康威法則設計組織架構

康威法則：軟體的架構和軟體團隊的結構是一致的，如果讓四個團隊開發同一個編譯器，那麼編譯器最後會有四個執行階段。

組織型態：

  • 職能型：依專業劃分（成本優化）
  • 矩陣型：結合職能型與市場型，不推薦
  • 市場型：迅速回應客戶需求（速度優化）

​

8

B L U E P L A N E T

9 of 44

III. 第一步工作法：暢流的技術實踐

  • 為部署管線奠定基礎
  • 實現快速可靠的自動化測試
  • 實現並實踐持續整合和持續測試
  • 實現低風險發佈

9

B L U E P L A N E T

10 of 44

奠定部署管線的基礎

  • 佈建從開發到營運的快速暢流，必須確保任何人都能按需獲得類生產環境，讓開發者在最初階段就使用類生產環境。
  • 擴大解釋「完成」一詞的定義 - 「完成」的意思不只是實現了功能正確的程式碼，還包括在每個迭代週期結束時，已經在類生產環境中「整合且測試了」可運作和可交付的程式碼。
  • 將所有有型產物(artifact)納入版本控制系統，我們有了「唯一的事實來源」，而不是在文件裡或人的大腦中。

10

B L U E P L A N E T

11 of 44

持續整合(Continuous Integration)

  • 全面且可靠的自動化測試套件，驗證軟體是否處於可部署狀態
  • 一種在測試失敗時，可以「中止整條生產線」的文化
  • 開發人員的工作模式是在「主幹」上以「小批量」提交變更，而不是在生命週期很長的功能分枝上工作

11

B L U E P L A N E T

12 of 44

自動化測試

  • 讓測試從「階段性活動」逐漸轉變為「持續性活動」。
  • 應儘早在測試中發現錯誤，因此在執行耗時的測試（驗收測試、整合測試等）之前，首先執行速度更快的測試（單元測試）
  • 最快速的測試應該盡快發現越多錯誤。

12

B L U E P L A N E T

13 of 44

當部署管線失敗時拉下安燈索

  • 當佈建版本在部署管線中處於綠色狀態時，我們就能放心地將程式碼變更部署到生產環境中。
  • 當亮起紅燈時，所有人應停下手上的工作解決問題，要麼退回上一版本的程式碼。

13

B L U E P L A N E T

14 of 44

分支策略

  • 「提高個人生產力」：所有人都在自己的分支上工作
  • 「提高團隊生產力」：所有人都在同一個區域裡工作

作者說這是一個很有爭議的話題，但仍強調應該將「合併融入日常工作」，因為開發人員在自己的分支上獨自工作的時間越長，就越難將變更併入主幹，會進而導致惡性循環。

14

B L U E P L A N E T

15 of 44

Google的主幹開發

  • 2010年每分鐘有二十多個程式碼變更被簽入主幹，每個月 codebase中50%的程式碼都會被修改
  • 2013年允許一萬三千名開發者在一條主幹上開發

​

15

B L U E P L A N E T

16 of 44

雙峰IT

  • 「記錄式系統」：須符合監管和合規性要求，較注重正確執行，變更速度通常較為緩慢。
  • 「互動式系統」：對回饋快速響應，透過試驗找出最能滿足客戶需求的方式。

本書觀點是拒絕採用雙峰IT，因為每一位客戶都應同時享受速度和品質。

16

B L U E P L A N E T

17 of 44

Facebook發佈速度

五年內 PHP程式碼的部署從「每週一次」提高到「每天三次」；行動裝置app應用從「每六週一次」提高到「每兩週一次」。

17

B L U E P L A N E T

18 of 44

自動化佈署

  • 「手動部署」令開發人員極其痛苦，所以他們傾向減少部署次數，容易導致惡性循環；批量部署的工作量增加，所導致的意外風險及修復難度也會隨之增加。
  • 「自動化部署」將發佈和部署融入日常工作，使組織能夠快速地向客戶交付價值。

18

B L U E P L A N E T

19 of 44

藍綠部署模式

19

B L U E P L A N E T

20 of 44

金絲雀發佈模式

20

實現「暗度發佈」：

可以讓1%的線上使用者對預計發佈的新功能做「隱形呼叫」(invisible call)，觀察新功能在此工作負載下的表現，再逐漸增加使用者呼叫頻率及數量。

B L U E P L A N E T

21 of 44

架構與發佈風險

  • 「緊密耦合架構」不僅會降低生產力，還會影響安全變更的能力。
  • 「寬鬆耦合架構」提高生產力和安全性，讓小型且高產的「雙批薩團隊」可以執行小的變更。

2002年 Amazon在試圖脫離單一程式碼資料庫的轉型過程中，利用了「兩個披薩原則」來維持小型的團隊規模 – 團隊所有成員的人數能用兩個批薩飽（通常為五至十人）

21

B L U E P L A N E T

22 of 44

架構原型

22

B L U E P L A N E T

23 of 44

使用「扼制模式」(Strangler Application)架構遷移

  • 適用於將單體應用或「緊密耦合」的部份功能遷移至「寬鬆耦合」架構的實踐上。
  • 以API封裝舊有功能，並在新的架構中實現新功能，僅在必要時調用舊系統。以此方式讓舊有系統逐漸萎縮至完全消失。
  • 所有服務都透過版本化API進行存取，也稱之為「版本化服務」或「不可變服務」。

​

​

23

B L U E P L A N E T

24 of 44

IIII. 第二步工作法：回饋的技術實踐

  • 建立能錨定和解決故障的遙測系統
  • 運用監測機制，預測故障，達成業務目標
  • 將使用者研究和回饋等工作融入產品團隊的日常工作
  • 為開發和營運提供回饋，讓他們能安全地部署應用
  • 用同儕評審和結對程式設計的方式刺激回饋，提升工作品質

24

B L U E P L A N E T

25 of 44

遙測(Telemetry)

「一個自動化的通信過程，先在遠端採集點上收集衡量資料，後傳輸給相應的接收端，作為監測之用」

25

B L U E P L A N E T

26 of 44

集中式監測架構

  • 將日誌檔案集中到事件路由器後，就可以計算事件數量並轉換成衡量指標，以進行統計動作。

26

B L U E P L A N E T

27 of 44

資訊輻射體 (information radiator)

  • 以圖表、圖示等放在公開展示的地讓所有的人都可以看到。
  • 以遙測指標作為解決問題的引導，而非針對故障進行「問責」。
  • 團隊對觀察者、對自己毫無隱藏，承認並直面問題。

27

B L U E P L A N E T

28 of 44

Netflix�的自動擴展能力

28

B L U E P L A N E T

29 of 44

利用遙測讓部署作業更安全

  • 當我們對生產環境的監測不全面，問題都是從使用者反映才得知。
  • 增加更多遙測機制，在使用者反映之前就檢測到問題。

29

B L U E P L A N E T

30 of 44

共同承擔營運責任

讓開發人員要意識到，就算每一項產品功能都標記為「完成」，也不代表業務目標已經實現：

    • 開發和營運共同承擔值班工作
    • 讓開發人員追蹤工作對下游的影響（使用者訪談及非功能層面的回饋）
    • 讓開發人員自行維運服務

​

​

30

B L U E P L A N E T

31 of 44

Google的 SRE工作交接

  • 「網站可靠性工程師」(SRE, Site Reliability Engineer)，用一句話來定義，就是軟體開發工程師開始負責營運工作。
  • 開發人員將產品交接給 SRE會經過兩套安全檢查：交接就緒審核 (LRR)、上線就緒審核 (HRR)

​

​

31

B L U E P L A N E T

32 of 44

Google的「服務回傳機制」(Service handback mechanism)

32

B L U E P L A N E T

33 of 44

將「假設驅動開發」和「A/B測試」整合到日常工作

  • 如果不能頻繁地（每天或每週）進行實驗，日常工作的重點就只能放在功能開發而不是客戶成果上了。
  • Microsoft的 Ronny Kohavi指出「只有約三分之一的功能成功提升了關鍵指標」，如果不進行使用者研究，那麼我們構建的三分之二的功能對組織的價值很可能為零。

讓軟體部署與發佈變得快速和安全，所有生產環境變更，都變成了低風險活動。

33

B L U E P L A N E T

34 of 44

Code review取代變更審核

  • 變更審核需要更長的前置時間
  • 最了解問題的人，就是那些離問題最近的人

​

34

B L U E P L A N E T

35 of 44

將 code review融入日常生活中

請工程師來審查十行程式碼，他會找到十個問題，請他審查五百行程式碼，他會說看起來不錯。

​

35

B L U E P L A N E T

36 of 44

V. 第三步工作法：持續學習與實驗的具體實踐

  • 建立公正的文化，使人們有安全感。
  • 故意引入故障到生產環境，培養組織韌性。
  • 將局部發現的經驗，轉化成全局改善知識。
  • 預留專門的時間，展開組織層級的改善和學習活動。

36

B L U E P L A N E T

37 of 44

韌性型組織 (Resilient Organization)

  • 熟練地發現問題，解決問題，並在整個組織中提供解決方案以擴大經驗的效果。

37

B L U E P L A N E T

38 of 44

Netflix 穩定的系統

  • 寬鬆耦合的系統架構：保證發生故障的件不會波及整個系統。比如，當流量劇增導致 CPU使用率暴漲時，就不再向使用者顯示個人化電影推薦清單，只顯示已經緩存的靜態內，以減少運算量。
  • 「搗亂猴」(Chaos Monkey)：不斷隨機刪除生產環境伺服器，來模擬 AWS環境故障（！）。希望所有工程團隊習慣在故障常態發生的情況下工作，使系統發展出能自動恢復正常的能力。

38

B L U E P L A N E T

39 of 44

「不指責的事後分析」會議

  • 學習型文化的先決條件之一是對待事故的反應要「公正」。
  • 消除肇事者的觀念稱之為「壞蘋果理論」。然而這種作法是無效的，因為人為錯誤並不是問題的原因，人為錯誤其實是後果。
  • 明確禁止使用「原來應該」或「原本可以」等詞語，因為這些是「反事實」的陳述。

39

B L U E P L A N E T

40 of 44

將「局部」發現的經驗，�轉化成「全局」改善的知識

不指責的事後分析會議之後，應將所有的會議紀錄和相關文件，集中在一個方便整個組織所有人存取的公開位置。

40

B L U E P L A N E T

41 of 44

重新定義失敗，鼓勵評估風險

  • 高效能 DevOps組織會更頻繁地失敗和犯下錯誤，這不但是可以接受的，更是組織需要的。
  • 降低判定故障的閾值，尋找更弱的故障信號，開始關注那些接近於事故的事件。

41

B L U E P L A N E T

42 of 44

將「償還技術債」制度化

  • 改善閃電戰
  • 春季/秋季大掃除 (spring or fall cleanings)
  • 反轉佇列工單週 (ticket queue inversion week)
  • 駭客日 (hack days)
  • 黑客松 (hackathons)
  • 20%的創新時間 (20% innovation time)

42

B L U E P L A N E T

43 of 44

Summary - 我個人的劃重點

  • 縮短價值流的前置時間、最小批次規模、減少WIP，並將「測試」、「重構」、「部署」、「營運」、「code review」…等通通都要融入日常作業中。
  • 「系統」架構要寬鬆偶合（微服務），「組織」架構要寬鬆偶合（雙批薩團隊、市場型組織）。
  • 20%時間償還技術償，持續學習並優化日常工作，打造「韌性型組織」、「賦生型組織」。

43

B L U E P L A N E T

44 of 44

Thank you for listening

44

B L U E P L A N E T