SRE CH27 - Reliable Product Launches at Scale

1. 1

2. Chapter 27
Reliable Product Launches at Scale
可靠地進行大規模發行
2
Authors: Rhandeev Singh, Sebastian Kirsch,
Vivek Rau (CH5)
P351 - P368, 17 (繁中版)

3. 3
https://www.linkedin.com/in/rhandeev-singh-378883/

4. 4
https://research.google.com/pubs/SebastianKirsch.html

5. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
5

6. 6

7. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
7

8. 上線協調工程師
● Google 軟體工程師
○ 有很豐富開發經驗，了解 產品
○ 對發行給幾百萬使用者的挑戰不了解，最小化故障的可能性、最大化 產品的效能指標
● 上線協調工程師 (LCE, Launch Coordination Engineers)
○ SRE 內部專職的顧問團隊
○ 軟體工程師 + 維運工程師組成
○ 負責指引建構符合 Google 標準的可靠、可擴展、穩定、效能的一流 產品
8

9. LCE 建立的發行流程與標準
● 審核新產品與內部服務，確保他們符合 Google 的可靠標準與實踐規範
● 發行過程中，負責多個團隊之間的協作與聯絡
● 追蹤發行所需任務進度
● 負責發行過程中所有技術相關的問題
● 整個發行過程中的守門員，決定否像發行是否安全
● 針對 Google 的實踐典範，和各項服務的整合來培訓開發者
9

10. 上線協調工程師的角色
● 組成：直接招聘的工程師 + 有經驗的 SRE
● 技術能力要求與 SRE 一樣
● 很強的溝通能力與領導能力
● 將分散的團隊聚合在一起，一起達成目標
● 處理衝突
● 提供建議與指導
10

11. 上線協調小組的優點
● 經驗廣泛
● 跨職能的角度
● 客觀性
11

12. 12

13. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
13

14. 14
建立發行流程 (Setting Up a Launch Process)
Google 用十年打造的發行流程：
● 輕盈 (Lightweight)
● 穩健 (Robust)
● 周全 (Thorough)
● 可擴展 (Scalable)
● 適應性 (Adaptable)

15. 有些需求相互衝突，例如同事滿足輕量級和完整性是很困難的。Google 透過以下手
段達到目的：
● 簡化
● 高度客製化
● 快速的共通模式
15
建立發行流程 (Setting Up a Launch Process)

16. 上線檢核表 (The Launch Checklist)
● 問題：是否需要一個新的域名？
● 問題：是否儲存持久化訊息？
● 問題：該服務是否有可能被某個使用者濫用？
16

17. 大型組織裡：
● 工程師不可能了解基礎設施
● 這些工程師，會經常重新發明輪子
● 消除重複勞動，使各服務之間的知識更容易傳遞
● 確保基礎設施有足夠的關注
推動融合和簡化 (Driving Convergence and Simplification)
17

18. Google 所有團隊都參與同一個通用的發行流程，上線檢核表成為推動通用基礎設施
融和的載體。
使用通用基礎設施的優點：
● 經過多年的最佳化、強化
● 已經消除容量、效能、擴展性的不確定性
推動融合和簡化 (Driving Convergence and Simplification)
18

19. 常見基礎設施的功能 (existing infrastructure as building blocks)
● 限速功能 (rate limiting)
● 使用者配額 (user quotas)
● 伺服器資料推送 (pushing new data to servers)
19

20. 發行未知的產品 (Launching the Unexpected)
● 建立全新的檢核表
● 需要相關領域的專家
● 檢核表應關注廣泛的主題：可靠性、故障模式和流程
20

21. 21

22. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
22

23. 擬定一份上線檢核表 (Developing a Launch Checklist)
● 可靠發行新服務、新產品的重要組成
● 檢核表隨時間不斷變長
● LCE 團隊週期性調整
● 檢核表具體事項，每家公司不一樣
● 跟公司內部的服務與基礎設施相關
23

24. 上線檢核表項目
1. 架構與依賴
2. 整合
3. 容量規劃
4. 故障模式
5. 用戶端行為
6. 流程與自動化
7. 開發流程
8. 外部依賴
9. 發行計畫
24

25. 1. 架構與依賴 (Architecture and Dependencies)
● 審查架構
● 確認是否正確使用通用基礎架構
● 確認負責人將基礎設施加入發行流程
● 在容量規劃中，確保依賴清單中的服務都有足夠容量
25

26. 架構與依賴
問題範例：
● 從使用者到前端，再到後端，請求流程的順序是什麼？
● 是否存在不同延遲要求的請留類型？
待辦事項：
● 將非使用者與使用者請求隔離
● 確認預計的請求數量
○ 單頁面的背後，會造成後端多個請求
26

27. 2. 整合 (Integration)
● 給新服務建立 DNS
● 設定 Load Balancing
● 設定監控系統
27

28. 3. 容量規劃 (Capacity Planning)
● 首次發行限制在單一區域或國家，有助於建立大規模發行的信心
● 容量規劃和冗餘度、可用性有直接關係
○ 需要三個點服務 100% 極端流量
○ 需要維護四到五個部署點
○ 資料中心和網路資源需要提前申請
● 問題範例
○ 發行是否與新聞、廣告、部落格文章有關？
○ 發行過程和之後預計的流量和增速是多少？
○ 是否已經取得需要的全部運算資源？
28

29. 4. 故障模式 (Failure Modes)
依照檢核表，檢查元件相依性，檢查以下：
● individual machine failures?
● Datacenter outages?
● Network failures?
● How do we deal with bad input data?
● Are we prepared for the possibility of a denial-of-service (DoS) attack?
● Can the service continue serving in degraded mode if one of its dependencies fails?
● How do we deal with unavailability of a dependency upon startup of the service? During runtime?
29

30. 故障模式 (Failure Modes)
問題範例：
● 系統設計中是否包含單點故障源？
● 服務遇到相依系統不可用時，如何處理？
待辦事項：
● 為請求設定截止時間，防止因請求持續過長導致資源耗盡 (timeout)
● 加入負載丟棄功能，超載時可以丟棄新請求 (rate limiting)
30

31. 5. 用戶端行為 (Client Behavior)
問題範例：
● 該服務是否實作自動儲存、自動完成、心跳檢查功能？
待辦事項：
● 確保用戶端在請求失敗之後，以指數型增加重試延時
● 確保在自動請求中時做隨機延遲抖動
31

32. Source: Error Retries and Exponential Backoff
DyanmoDB Error Handling
32

33. 6. 流程與自動化
● 自動化不可能完美
● 每個服務需要有人工執行的流程：
○ 建構一個新版本
○ 移轉服務到另一個資料中心
○ 從備份復原資料
● 自動化以外的流程，應該在發行前文件化
● 確保工程師記住細節之前，就完成文件化
● 流程文件化要做到每一個團隊成員都可以在緊急事件中處理問題
33

34. 6. 流程與自動化
問題範例：
● 維持服務執行是否需要某些手動執行流程？
待辦事項：
● 將所有手動執行的流程文件化
● 將移轉到另一個資料中心的流程文件化
● 將建構和發薪新版本的流程自動化
34

35. 7. 開發流程 (Development Process)
● Google 重度使用版本控制系統
● 大部分的開發都在主幹 (mainline) 進行
○ 發行版本是在分支進行
○ 這種方式讓分支上修復每次發行的 Bug 更簡單
● 存放組態檔
● 待辦事項
○ 將所有程式碼和組態檔放到版本控管系統
○ 為每個發行建立新的分支
35

36. 8. 外部依賴 (External Dependencies)
發行依賴不受控的因素，確認其存在，並做好準備。
● 依賴第三方的類別庫
● 另一家公司提供的服務
● 問題範例：
○ 這次發行依賴哪些第三方程式碼、資料、服務、或者事件？
○ 是否有任何合作夥伴依賴你的服務？發行時是否需要通知他們？
○ 當我們或者第三方供應者無法在指定日期完工時，會發生什麼事？
36

37. 9. 發行計畫
● 市場部門需要在會議簡報中啟用某個功能，簡報之前要隱藏
● 待辦事項：
○ 為該服務擬定發行計劃，將每個任務指派給特定的人
○ 針對發行計劃每部分析危險性，並制定備用方案
37

38. 38

39. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
39

40. 可靠發行所需要的方法論
1. 灰度與階段性發行
2. 功能開關框架
3. 處理用戶濫用行為
4. 超載行為和負載測試
40

41. 1. 灰度和階段性發行
● SysOps 最常講的就是：『永遠不要改變執行中的系統』
● Google 的發行很少是『立即可用』 (push-button，在某個時間點之後立即可用)
○ 逐漸的發行產品和服務，降低風險
○ 幾乎都是灰度進行
● 灰度進行
○ 先在某個 DC 的幾台機器上安裝，並且嚴密監控一段時間 ← 『金絲雀』
○ 沒有異常，安裝在 DC 上所有機器，持續監控
○ 安裝到全球所有 DC
● 金絲雀：Google 內部自動化的核心理念。
○ Android APP 發行
○ 流量限定 (rate-limited): 註冊邀請制
41

42. 2. 功能開關框架
● 建立可控更新機制，允許在真實負載狀況下，觀察系統的整體行為
● 驗證更改流程之後，能否提升使用者的感受
● 新功能開放給 0-100% 的使用者
● 上線發布後，不需要 LCE 參與
42

43. 2. 功能開關框架 - 需要滿足的要求
43
● 同時發行多個變更，每個變更可針對不同服務器有作用
● 灰度發行到一定的使用者比例 1% ~ 10%
● 將流量根據使用者、連線、對象，發送到不同服務器上
● 新程式出現問題時，可以自動處理，不影響使用者
● 發生嚴重 Bug 時，可以迅速單獨封鎖某個變更
● 度量每個變更對使用者的體驗

44. 3. 處理用戶濫用行為
● 故意或無意的自動請求，會造成驚群效應 (CH24, 25)
● 夜間更新：APP 晚上版本更新造成的大量請求
● 週期性的程序
○ 引入隨機性: Error Retries and Exponential Backoff
● 服務端控制客戶端的行為能力
○ 下載組態檔: 啟用或禁用某些功能或參數，像是同步頻率
○ 如果出問題，可以透過組態檔控制功能的開關
44

45. 4. 超載行為和負載測試 (Overload Behavior and Load Tests)
● 理想：CPU 用量和服務負載成線性關係
● 實際：
○ 負載到某一個數量後，進入非線性轉折點
○ 超載後服務進入鎖死狀態
● 舉例：
○ 某個服務會記錄錯誤 Log，紀錄錯誤過程比處理後端成本還高
○ 進入超載後，服務就入鎖死狀態
○ JVM 的 GC thrashing (垃圾回收死亡螺旋)
45

46. 46

47. Agenda
● 上線協調工程師
● 建立發行流程
● 擬定一份上線檢核表
● 可靠發行所需要的方法論
● LCE 的發展
47

48. LCE 的發展
● Google 組織快速成長，組成拆分小團隊，但是新手工程師容易重蹈覆轍
● 為減少問題重複發生，上線工程ㄕ LCE 發行檢核表如下：
○ 什麼時候需要向法務部門諮詢
○ 如何選擇域名
○ 如何註冊域名及正確設定 DNS
○ 工程設計和正式部署常見的問題
● 上述流程稱為『發行審查』，在新產品發行幾天或者幾週前的 SOP
● 檢核表隨時間越來越複雜，越來越長
○ SRE 2004 年建立全值得 LCE Team，負責加速新產品審查速度
○ 確保相關團隊能夠了解為了加速採用捷徑所帶來的風險
○ 顧問程序標化，最後變成『正式作業審 查』 (Production Review)
48

49. LCE 檢核表的變遷
● LCE 檢核表每個問題都很簡單，但背後緣由和對應答案很複雜
● LCE 新員工需要六個月的培訓，用來充分了解檢核表的複雜度
● 30% 是低風險發行：經過簡化程序、流量增長在 10% 以內的
● 發行限制隨需求改變，例如 Google 併購 Youtube 之後，網路擴展變成是必要的
49

50. 附錄 E
50

51. LCE 沒有解決的問題
● LCE 努力解決審查中的官僚主義
● Google 2009 年內部小型專案發行難度很高
● 大型專案更不用說，很多問題 LCE 都解不了
51

52. LCE 沒有解決的問題 - 擴展性的改變
● 產品大幅超出早期的預測，且非常成功時
● 需要進行設計變更、擴展性改變、結構改變、大量重構
● 導致新功能無法正常發行
52

53. LCE 沒有解決的問題 - 不停增加維運壓力
● 自動化通知太多
● 部署流程太複雜
● 手工維護工作增加
● 團隊開發新功能時間越來越少
● 不斷追蹤維運工作來源，以維持 SRE 50% 的上限
53

54. LCE 沒有解決的問題 - 基礎設施的改變
● 開發團隊不斷修改基礎設施：叢集管理系統、儲存、監控、附載平衡、資料傳輸
○ 不斷的修改設定檔、配置檔
○ 重新建構可執行檔
● 這些都超出 LCE 的範疇
54

55. 小結
● LCE Team 是 Google 面對快速改變中，保障安全性的解決方案
● 如果要將服務擴展到數億的使用者，快速更改並能確保可靠性，LCE 很有價值
55

56. 56