Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SRE CH27 - Reliable Product Launches at Scale

1,087 views

Published on

SRE CH27 - Reliable Product Launches at Scale

Published in: Engineering
  • Be the first to comment

SRE CH27 - Reliable Product Launches at Scale

  1. 1. 1
  2. 2. Chapter 27 Reliable Product Launches at Scale 可靠地進行大規模發行 2 Authors: Rhandeev Singh, Sebastian Kirsch, Vivek Rau (CH5) P351 - P368, 17 (繁中版)
  3. 3. 3 https://www.linkedin.com/in/rhandeev-singh-378883/
  4. 4. 4 https://research.google.com/pubs/SebastianKirsch.html
  5. 5. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 5
  6. 6. 6
  7. 7. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 7
  8. 8. 上線協調工程師 ● Google 軟體工程師 ○ 有很豐富開發經驗,了解 產品 ○ 對發行給幾百萬使用者的挑戰不了解,最小化故障的可能性、最大化 產品的效能指標 ● 上線協調工程師 (LCE, Launch Coordination Engineers) ○ SRE 內部專職的顧問團隊 ○ 軟體工程師 + 維運工程師組成 ○ 負責指引建構符合 Google 標準的可靠、可擴展、穩定、效能的一流 產品 8
  9. 9. LCE 建立的發行流程與標準 ● 審核新產品與內部服務,確保他們符合 Google 的可靠標準與實踐規範 ● 發行過程中,負責多個團隊之間的協作與聯絡 ● 追蹤發行所需任務進度 ● 負責發行過程中所有技術相關的問題 ● 整個發行過程中的守門員,決定否像發行是否安全 ● 針對 Google 的實踐典範,和各項服務的整合來培訓開發者 9
  10. 10. 上線協調工程師的角色 ● 組成:直接招聘的工程師 + 有經驗的 SRE ● 技術能力要求與 SRE 一樣 ● 很強的溝通能力與領導能力 ● 將分散的團隊聚合在一起,一起達成目標 ● 處理衝突 ● 提供建議與指導 10
  11. 11. 上線協調小組的優點 ● 經驗廣泛 ● 跨職能的角度 ● 客觀性 11
  12. 12. 12
  13. 13. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 13
  14. 14. 14 建立發行流程 (Setting Up a Launch Process) Google 用十年打造的發行流程: ● 輕盈 (Lightweight) ● 穩健 (Robust) ● 周全 (Thorough) ● 可擴展 (Scalable) ● 適應性 (Adaptable)
  15. 15. 有些需求相互衝突,例如同事滿足輕量級和完整性是很困難的。Google 透過以下手 段達到目的: ● 簡化 ● 高度客製化 ● 快速的共通模式 15 建立發行流程 (Setting Up a Launch Process)
  16. 16. 上線檢核表 (The Launch Checklist) ● 問題:是否需要一個新的域名? ● 問題:是否儲存持久化訊息? ● 問題:該服務是否有可能被某個使用者濫用? 16
  17. 17. 大型組織裡: ● 工程師不可能了解基礎設施 ● 這些工程師,會經常重新發明輪子 ● 消除重複勞動,使各服務之間的知識更容易傳遞 ● 確保基礎設施有足夠的關注 推動融合和簡化 (Driving Convergence and Simplification) 17
  18. 18. Google 所有團隊都參與同一個通用的發行流程,上線檢核表成為推動通用基礎設施 融和的載體。 使用通用基礎設施的優點: ● 經過多年的最佳化、強化 ● 已經消除容量、效能、擴展性的不確定性 推動融合和簡化 (Driving Convergence and Simplification) 18
  19. 19. 常見基礎設施的功能 (existing infrastructure as building blocks) ● 限速功能 (rate limiting) ● 使用者配額 (user quotas) ● 伺服器資料推送 (pushing new data to servers) 19
  20. 20. 發行未知的產品 (Launching the Unexpected) ● 建立全新的檢核表 ● 需要相關領域的專家 ● 檢核表應關注廣泛的主題:可靠性、故障模式和流程 20
  21. 21. 21
  22. 22. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 22
  23. 23. 擬定一份上線檢核表 (Developing a Launch Checklist) ● 可靠發行新服務、新產品的重要組成 ● 檢核表隨時間不斷變長 ● LCE 團隊週期性調整 ● 檢核表具體事項,每家公司不一樣 ● 跟公司內部的服務與基礎設施相關 23
  24. 24. 上線檢核表項目 1. 架構與依賴 2. 整合 3. 容量規劃 4. 故障模式 5. 用戶端行為 6. 流程與自動化 7. 開發流程 8. 外部依賴 9. 發行計畫 24
  25. 25. 1. 架構與依賴 (Architecture and Dependencies) ● 審查架構 ● 確認是否正確使用通用基礎架構 ● 確認負責人將基礎設施加入發行流程 ● 在容量規劃中,確保依賴清單中的服務都有足夠容量 25
  26. 26. 架構與依賴 問題範例: ● 從使用者到前端,再到後端,請求流程的順序是什麼? ● 是否存在不同延遲要求的請留類型? 待辦事項: ● 將非使用者與使用者請求隔離 ● 確認預計的請求數量 ○ 單頁面的背後,會造成後端多個請求 26
  27. 27. 2. 整合 (Integration) ● 給新服務建立 DNS ● 設定 Load Balancing ● 設定監控系統 27
  28. 28. 3. 容量規劃 (Capacity Planning) ● 首次發行限制在單一區域或國家,有助於建立大規模發行的信心 ● 容量規劃和冗餘度、可用性有直接關係 ○ 需要三個點服務 100% 極端流量 ○ 需要維護四到五個部署點 ○ 資料中心和網路資源需要提前申請 ● 問題範例 ○ 發行是否與新聞、廣告、部落格文章有關? ○ 發行過程和之後預計的流量和增速是多少? ○ 是否已經取得需要的全部運算資源? 28
  29. 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. 30. 故障模式 (Failure Modes) 問題範例: ● 系統設計中是否包含單點故障源? ● 服務遇到相依系統不可用時,如何處理? 待辦事項: ● 為請求設定截止時間,防止因請求持續過長導致資源耗盡 (timeout) ● 加入負載丟棄功能,超載時可以丟棄新請求 (rate limiting) 30
  31. 31. 5. 用戶端行為 (Client Behavior) 問題範例: ● 該服務是否實作自動儲存、自動完成、心跳檢查功能? 待辦事項: ● 確保用戶端在請求失敗之後,以指數型增加重試延時 ● 確保在自動請求中時做隨機延遲抖動 31
  32. 32. Source: Error Retries and Exponential Backoff DyanmoDB Error Handling 32
  33. 33. 6. 流程與自動化 ● 自動化不可能完美 ● 每個服務需要有人工執行的流程: ○ 建構一個新版本 ○ 移轉服務到另一個資料中心 ○ 從備份復原資料 ● 自動化以外的流程,應該在發行前文件化 ● 確保工程師記住細節之前,就完成文件化 ● 流程文件化要做到每一個團隊成員都可以在緊急事件中處理問題 33
  34. 34. 6. 流程與自動化 問題範例: ● 維持服務執行是否需要某些手動執行流程? 待辦事項: ● 將所有手動執行的流程文件化 ● 將移轉到另一個資料中心的流程文件化 ● 將建構和發薪新版本的流程自動化 34
  35. 35. 7. 開發流程 (Development Process) ● Google 重度使用版本控制系統 ● 大部分的開發都在主幹 (mainline) 進行 ○ 發行版本是在分支進行 ○ 這種方式讓分支上修復每次發行的 Bug 更簡單 ● 存放組態檔 ● 待辦事項 ○ 將所有程式碼和組態檔放到版本控管系統 ○ 為每個發行建立新的分支 35
  36. 36. 8. 外部依賴 (External Dependencies) 發行依賴不受控的因素,確認其存在,並做好準備。 ● 依賴第三方的類別庫 ● 另一家公司提供的服務 ● 問題範例: ○ 這次發行依賴哪些第三方程式碼、資料、服務、或者事件? ○ 是否有任何合作夥伴依賴你的服務?發行時是否需要通知他們? ○ 當我們或者第三方供應者無法在指定日期完工時,會發生什麼事? 36
  37. 37. 9. 發行計畫 ● 市場部門需要在會議簡報中啟用某個功能,簡報之前要隱藏 ● 待辦事項: ○ 為該服務擬定發行計劃,將每個任務指派給特定的人 ○ 針對發行計劃每部分析危險性,並制定備用方案 37
  38. 38. 38
  39. 39. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 39
  40. 40. 可靠發行所需要的方法論 1. 灰度與階段性發行 2. 功能開關框架 3. 處理用戶濫用行為 4. 超載行為和負載測試 40
  41. 41. 1. 灰度和階段性發行 ● SysOps 最常講的就是:『永遠不要改變執行中的系統』 ● Google 的發行很少是『立即可用』 (push-button,在某個時間點之後立即可用) ○ 逐漸的發行產品和服務,降低風險 ○ 幾乎都是灰度進行 ● 灰度進行 ○ 先在某個 DC 的幾台機器上安裝,並且嚴密監控一段時間 ← 『金絲雀』 ○ 沒有異常,安裝在 DC 上所有機器,持續監控 ○ 安裝到全球所有 DC ● 金絲雀:Google 內部自動化的核心理念。 ○ Android APP 發行 ○ 流量限定 (rate-limited): 註冊邀請制 41
  42. 42. 2. 功能開關框架 ● 建立可控更新機制,允許在真實負載狀況下,觀察系統的整體行為 ● 驗證更改流程之後,能否提升使用者的感受 ● 新功能開放給 0-100% 的使用者 ● 上線發布後,不需要 LCE 參與 42
  43. 43. 2. 功能開關框架 - 需要滿足的要求 43 ● 同時發行多個變更,每個變更可針對不同服務器有作用 ● 灰度發行到一定的使用者比例 1% ~ 10% ● 將流量根據使用者、連線、對象,發送到不同服務器上 ● 新程式出現問題時,可以自動處理,不影響使用者 ● 發生嚴重 Bug 時,可以迅速單獨封鎖某個變更 ● 度量每個變更對使用者的體驗
  44. 44. 3. 處理用戶濫用行為 ● 故意或無意的自動請求,會造成驚群效應 (CH24, 25) ● 夜間更新:APP 晚上版本更新造成的大量請求 ● 週期性的程序 ○ 引入隨機性: Error Retries and Exponential Backoff ● 服務端控制客戶端的行為能力 ○ 下載組態檔: 啟用或禁用某些功能或參數,像是同步頻率 ○ 如果出問題,可以透過組態檔控制功能的開關 44
  45. 45. 4. 超載行為和負載測試 (Overload Behavior and Load Tests) ● 理想:CPU 用量和服務負載成線性關係 ● 實際: ○ 負載到某一個數量後,進入非線性轉折點 ○ 超載後服務進入鎖死狀態 ● 舉例: ○ 某個服務會記錄錯誤 Log,紀錄錯誤過程比處理後端成本還高 ○ 進入超載後,服務就入鎖死狀態 ○ JVM 的 GC thrashing (垃圾回收死亡螺旋) 45
  46. 46. 46
  47. 47. Agenda ● 上線協調工程師 ● 建立發行流程 ● 擬定一份上線檢核表 ● 可靠發行所需要的方法論 ● LCE 的發展 47
  48. 48. LCE 的發展 ● Google 組織快速成長,組成拆分小團隊,但是新手工程師容易重蹈覆轍 ● 為減少問題重複發生,上線工程ㄕ LCE 發行檢核表如下: ○ 什麼時候需要向法務部門諮詢 ○ 如何選擇域名 ○ 如何註冊域名及正確設定 DNS ○ 工程設計和正式部署常見的問題 ● 上述流程稱為『發行審查』,在新產品發行幾天或者幾週前的 SOP ● 檢核表隨時間越來越複雜,越來越長 ○ SRE 2004 年建立全值得 LCE Team,負責加速新產品審查速度 ○ 確保相關團隊能夠了解為了加速採用捷徑所帶來的風險 ○ 顧問程序標化,最後變成『正式作業審 查』 (Production Review) 48
  49. 49. LCE 檢核表的變遷 ● LCE 檢核表每個問題都很簡單,但背後緣由和對應答案很複雜 ● LCE 新員工需要六個月的培訓,用來充分了解檢核表的複雜度 ● 30% 是低風險發行:經過簡化程序、流量增長在 10% 以內的 ● 發行限制隨需求改變,例如 Google 併購 Youtube 之後,網路擴展變成是必要的 49
  50. 50. 附錄 E 50
  51. 51. LCE 沒有解決的問題 ● LCE 努力解決審查中的官僚主義 ● Google 2009 年內部小型專案發行難度很高 ● 大型專案更不用說,很多問題 LCE 都解不了 51
  52. 52. LCE 沒有解決的問題 - 擴展性的改變 ● 產品大幅超出早期的預測,且非常成功時 ● 需要進行設計變更、擴展性改變、結構改變、大量重構 ● 導致新功能無法正常發行 52
  53. 53. LCE 沒有解決的問題 - 不停增加維運壓力 ● 自動化通知太多 ● 部署流程太複雜 ● 手工維護工作增加 ● 團隊開發新功能時間越來越少 ● 不斷追蹤維運工作來源,以維持 SRE 50% 的上限 53
  54. 54. LCE 沒有解決的問題 - 基礎設施的改變 ● 開發團隊不斷修改基礎設施:叢集管理系統、儲存、監控、附載平衡、資料傳輸 ○ 不斷的修改設定檔、配置檔 ○ 重新建構可執行檔 ● 這些都超出 LCE 的範疇 54
  55. 55. 小結 ● LCE Team 是 Google 面對快速改變中,保障安全性的解決方案 ● 如果要將服務擴展到數億的使用者,快速更改並能確保可靠性,LCE 很有價值 55
  56. 56. 56

×