More Related Content Similar to SRE CH27 - Reliable Product Launches at Scale (20) More from Rick Hwang (20) SRE CH27 - Reliable Product Launches at Scale 2. Chapter 27
Reliable Product Launches at Scale
可靠地進行大規模發行
2
Authors: Rhandeev Singh, Sebastian Kirsch,
Vivek Rau (CH5)
P351 - P368, 17 (繁中版)
8. 上線協調工程師
● Google 軟體工程師
○ 有很豐富開發經驗,了解 產品
○ 對發行給幾百萬使用者的挑戰不了解,最小化故障的可能性、最大化 產品的效能指標
● 上線協調工程師 (LCE, Launch Coordination Engineers)
○ SRE 內部專職的顧問團隊
○ 軟體工程師 + 維運工程師組成
○ 負責指引建構符合 Google 標準的可靠、可擴展、穩定、效能的一流 產品
8
9. LCE 建立的發行流程與標準
● 審核新產品與內部服務,確保他們符合 Google 的可靠標準與實踐規範
● 發行過程中,負責多個團隊之間的協作與聯絡
● 追蹤發行所需任務進度
● 負責發行過程中所有技術相關的問題
● 整個發行過程中的守門員,決定否像發行是否安全
● 針對 Google 的實踐典範,和各項服務的整合來培訓開發者
9
14. 14
建立發行流程 (Setting Up a Launch Process)
Google 用十年打造的發行流程:
● 輕盈 (Lightweight)
● 穩健 (Robust)
● 周全 (Thorough)
● 可擴展 (Scalable)
● 適應性 (Adaptable)
16. 上線檢核表 (The Launch Checklist)
● 問題:是否需要一個新的域名?
● 問題:是否儲存持久化訊息?
● 問題:該服務是否有可能被某個使用者濫用?
16
23. 擬定一份上線檢核表 (Developing a Launch Checklist)
● 可靠發行新服務、新產品的重要組成
● 檢核表隨時間不斷變長
● LCE 團隊週期性調整
● 檢核表具體事項,每家公司不一樣
● 跟公司內部的服務與基礎設施相關
23
25. 1. 架構與依賴 (Architecture and Dependencies)
● 審查架構
● 確認是否正確使用通用基礎架構
● 確認負責人將基礎設施加入發行流程
● 在容量規劃中,確保依賴清單中的服務都有足夠容量
25
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
33. 6. 流程與自動化
● 自動化不可能完美
● 每個服務需要有人工執行的流程:
○ 建構一個新版本
○ 移轉服務到另一個資料中心
○ 從備份復原資料
● 自動化以外的流程,應該在發行前文件化
● 確保工程師記住細節之前,就完成文件化
● 流程文件化要做到每一個團隊成員都可以在緊急事件中處理問題
33
35. 7. 開發流程 (Development Process)
● Google 重度使用版本控制系統
● 大部分的開發都在主幹 (mainline) 進行
○ 發行版本是在分支進行
○ 這種方式讓分支上修復每次發行的 Bug 更簡單
● 存放組態檔
● 待辦事項
○ 將所有程式碼和組態檔放到版本控管系統
○ 為每個發行建立新的分支
35
36. 8. 外部依賴 (External Dependencies)
發行依賴不受控的因素,確認其存在,並做好準備。
● 依賴第三方的類別庫
● 另一家公司提供的服務
● 問題範例:
○ 這次發行依賴哪些第三方程式碼、資料、服務、或者事件?
○ 是否有任何合作夥伴依賴你的服務?發行時是否需要通知他們?
○ 當我們或者第三方供應者無法在指定日期完工時,會發生什麼事?
36
41. 1. 灰度和階段性發行
● SysOps 最常講的就是:『永遠不要改變執行中的系統』
● Google 的發行很少是『立即可用』 (push-button,在某個時間點之後立即可用)
○ 逐漸的發行產品和服務,降低風險
○ 幾乎都是灰度進行
● 灰度進行
○ 先在某個 DC 的幾台機器上安裝,並且嚴密監控一段時間 ← 『金絲雀』
○ 沒有異常,安裝在 DC 上所有機器,持續監控
○ 安裝到全球所有 DC
● 金絲雀:Google 內部自動化的核心理念。
○ Android APP 發行
○ 流量限定 (rate-limited): 註冊邀請制
41
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
48. LCE 的發展
● Google 組織快速成長,組成拆分小團隊,但是新手工程師容易重蹈覆轍
● 為減少問題重複發生,上線工程ㄕ LCE 發行檢核表如下:
○ 什麼時候需要向法務部門諮詢
○ 如何選擇域名
○ 如何註冊域名及正確設定 DNS
○ 工程設計和正式部署常見的問題
● 上述流程稱為『發行審查』,在新產品發行幾天或者幾週前的 SOP
● 檢核表隨時間越來越複雜,越來越長
○ SRE 2004 年建立全值得 LCE Team,負責加速新產品審查速度
○ 確保相關團隊能夠了解為了加速採用捷徑所帶來的風險
○ 顧問程序標化,最後變成『正式作業審 查』 (Production Review)
48
49. LCE 檢核表的變遷
● LCE 檢核表每個問題都很簡單,但背後緣由和對應答案很複雜
● LCE 新員工需要六個月的培訓,用來充分了解檢核表的複雜度
● 30% 是低風險發行:經過簡化程序、流量增長在 10% 以內的
● 發行限制隨需求改變,例如 Google 併購 Youtube 之後,網路擴展變成是必要的
49
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