SRE CH27 - Reliable Product Launches at Scale (20180426)

Transcript

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
7. Agenda • 上線協調工程師 • 建立發行流程 • 擬定一份上線檢核表 • 可靠發行所需要的方法論 • LCE 的發展 7
8. 上線協調工程師 • Google 軟體工程師 ◦ 有很豐富開發經驗，了解 產品 ◦ 對發行給幾百萬使用者的挑戰不了解，最小化故障的可能性、最大化 產品的效能指標 • 上線協調工程師 (LCE, Launch Coordination Engineers) ◦ SRE 內部專職的顧問團隊 ◦ 軟體工程師 + 維運工程師組成 ◦ 負責指引建構符合 Google 標準的可靠、可擴展、穩定、效能的一流 產品 8
9. LCE 建立的發行流程與標準 • 審核新產品與內部服務，確保他們符合 Google 的可靠標準與實踐規範 • 發行過程中，負責多個團隊之間的協作與聯絡 • 追蹤發行所需任務進度 • 負責發行過程中所有技術相關的問題 • 整個發行過程中的守門員，決定否像發行是否安全 • 針對 Google 的實踐典範，和各項服務的整合來培訓開發者 9
10. 上線協調工程師的角色 • 組成：直接招聘的工程師 + 有經驗的 SRE • 技術能力要求與 SRE 一樣 • 很強的溝通能力與領導能力 • 將分散的團隊聚合在一起，一起達成目標 • 處理衝突 • 提供建議與指導 10
11. 上線協調小組的優點 • 經驗廣泛 • 跨職能的角度 • 客觀性 11
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
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
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
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