神仙打鼓有時錯 - DevOps 模範生 Google Cloud 6/12 全球大當機事件

2025-06-22 11:03 AM

Google Cloud 在 2025/6/12 發生了一起全球性的服務中斷，超過 50 個線上服務停擺、影響超過 140 萬筆用戶，影響範圍遍及 Google 自家服務（如 Gmail、Drive、Maps、YouTube、Meet、Gemini 等），甚至 Spotify、Discord、Snapchat、Cloudflare 等第三方平台也跟著中槍倒地。

事件發生在美國太平洋時間 6 月 12 日早上 10:49，歷時八個小時才恢復正常。但因為發生時間在台灣的凌晨(01:49)，多數人還在睡夢之間，故在台灣較無感，討論不多，我是看 YouTuber 原子能的影片才知道。但向來以穩定可靠著稱，號稱 DevOps 界天花板的 Google，發生如此長時間的服務中斷，還是源自一些低級錯誤，多少引發技術圈的討論。
(原來特種部隊等級的神人工程團隊偶爾也會犯凡人的錯，這讓常犯低級錯誤的雜魚如我，罪惡感頓時輕了幾公克)

圖片來源

事件經過：(時間一律以美國太平洋時間為準)

事發前兩週，2025/5/29 Google Cloud 的 Service Control 團隊對限額策略程式進行了升級，在此時埋下地雷。新版程式碼漏掉一項重要的空值檢查，意思是未來新增的策略若包含空值，整個 Service Control 系統將會因 Null Pointer Exception 崩潰。
6/12 10:49 Google Cloud 某個分區在 Service Control 策略資料庫「新增了一條包含空值的策略」，由於 Service Control 系統是分散式資料庫架構，全球 42 個分區隨即都同步了這條策略，踩到上回所說的 Bug，下場是全球各區的 Service Control 一起因為 Null Pointer Exception 停擺。
Google 運維團隊在 10 分鐘內找出問題，花了十多分鐘寫好 Patch，再花了十多分鐘部署到全球，只花了 40 分鐘完成程式修補，但此次故障事件並未在此告一段落。
Service Control 故障期間累積一堆待處理任務，系統有自動重試機制，但由於未加入加入隨機延遲也沒有指數退避(重試失敗要等更久再試，例如隔 1、2、4、8、16... 秒重試)，導致龐大數量的重試請求一起湧入衝垮系統。規模較大的分區如 US Central One，連帶著整個分區陷入癱瘓。
運維團隊被迫手動設定限流，並將部分流量引導到其他分區，花了三個小時消化完大批堆積任務。
Cloudflare 的主力產品 Workers KV 分散式資料庫，底層高度依賴 Google Cloud，在 Google 出事後，Cloudflare 的身份驗證服務、設定資料跟著一起掛點，而 Cloudflare 是承載全球 Internet 20% 流量的主要服務商，影響範圍被迅速放大。

事後 Google 為此道歉，並承諾進行以下改善：

增設全球資料同步前的驗證與測試機制(本次的一大缺失便是未經實際場景驗證便一次部署到全球)
強化 API 管理平台的資料驗證機制，防止無效或損壞的資料自動同步到全球
提升系統對異常資料的容錯能力，並加強異常監控與警示，確保問題能在早期被攔截
針對事故期間資訊揭示延遲，會優化內部與對外溝通機制，確保客戶能即時掌握狀態

而 Cloudflare 歷經本次事件後，也承認高度依賴 Google Cloud 外部服務的架構是種錯誤，承諾未來會將 Key Value 核心儲存移回自家的 R2 物件儲存服務。

從旁觀學習者角度，試著找出 Google 在這次事件所犯的經典系統開發及營運錯誤：

缺少資料檢核及錯誤處理
爆炸起因於未針對欄位值是 null 的情況進行檢核，也缺少必要的例外處理(Exception Handling)，導致程式因為 Null Pointer 崩潰中止。
上線前的測試不完備
不確定這次的限額策略程式改版有做了多少測試，但測試案例肯定沒巳含爆炸點值是 null 的情況。
未採用分階段部署策略
大型分散式系統在上線或更新時，為降低風險、提高可用性及確保服務不中斷，多會採用分批、分階段部署，不會一次性全面更新。這方面有一些的部署策略：
- 分階段部署（Staged Rollout）：將新版本逐步推送給不同比例的用戶，如先推送給 1%、5%、10% 等，逐步增加比例，限制新版本問題的影響範圍，爭取時間監控、修正問題。
- 金絲雀部署（Canary Deployment）：讓少數用戶先體驗新版本，觀察運行狀況，沒有問題後再全面推送。
- 藍綠部署（Blue-Green Deployment）：同時維護兩個完全相同的生產環境（藍色為舊版，綠色為新版）。先在綠色環境測試新版本，確認穩定後，將流量切換到綠色環境，並隨時可切回舊版。
- 滾動部署（Rolling Deployment）：逐步將新版本部署到部分節點，同時保留舊版本，直到所有節點都更新完成。
- 功能切換（Feature Toggle/Flag）：程式碼中嵌入功能開關，可動態啟用或關閉新功能，讓新功能僅對特定用戶或群體開放，逐步擴大範圍。
未啟用隨機指數退避重試策略
Google 運維團隊只花了 40 分鐘就修復了問題，但故障期間累積的待處理任務，因為沒有使用 Randomized Exponential Backoff 重試策略，造成服務恢復後，所有重試請求瞬間一起湧入，大水沖倒龍王廟。
延伸閱讀：閒聊 - 系統異常已排除，網站卻繼續崩潰瘋狂 503？