Google Cloud 大規模故障：網路癱瘓事件剖析
上週，有人將存在問題的程式碼部署到生產環境，導致網路大範圍癱瘓。Snapchat、Spotify 和 Discord 等服務都出現了問題，同時 Cloudflare 的 Workers KV 服務也受到影響，導致超過兩小時的錯誤率接近 100%，進而引發了骨牌效應，使得整個網路的網站和服務都無法正常運作。
罪魁禍首是 Google Cloud Platform，它將伺服器租給許多受歡迎的應用程式。他們對這次的失誤深感抱歉，但這也顯示出大型雲端服務提供商對於我們習以為常的網路基礎設施具有多大的影響力。在今天的影片中，我們將從軟體工程的角度來了解這次大規模故障的來龍去脈。
Google Cloud 如何導致網路癱瘓
2025 年 6 月 16 日，Google Cloud 不僅癱瘓了網路，也讓自己的服務受到影響。Gmail、Google 日曆、雲端硬碟和 Meet 等服務都無法使用。這種規模的故障可能會讓公司損失數百萬美元。
當你在大型雲端供應商租用伺服器時，他們會提供一份名為服務水準協議 (SLA) 的合約，通常保證每月 99.99% 或更高的正常運行時間。當情況變得如此糟糕時，雲端供應商就違反了這份合約，你可能有權獲得財務補償，也就是 SLA 抵免額，基本上是 Google 為自己糟糕的表現退款給這些公司。這可能會讓 Google 損失幾百萬美元，但這次故障對他們作為雲端供應商的聲譽造成了更大的損害。在市場佔有率方面，Google 多年來一直位居第三，落後於 Azure 和 AWS。而最近的這次事件對他們來說更是雪上加霜。
程式碼錯誤導致的災難
那麼，從程式設計的角度來看，這場災難是如何發生的呢？Sundar 最近表示，人工智慧現在編寫了 Google 超過 30% 的程式碼。因此，許多人立即將矛頭指向 Gemini。但我既不能確認也不能否認這又是一次 "vibe coding" 的失敗。更可能的是，這段程式碼是由人手編寫的，因為它控制著 Google Cloud 的一個極其重要的部分。
基本上，當客戶向 Google Cloud 發出 API 請求時，這些請求會被路由到一個 API 管理服務，該服務會驗證 API 請求是否經過授權。這個服務還包含一個資料儲存庫，用於讀取配額和策略資訊，這些資訊可以快速地在全球範圍內複製。該服務本身是區域性部署的。Google 目前在我們所居住的平面靜止地球上擁有 42 個區域的資料中心。
問題程式碼的觸發與蔓延
通常情況下，一切運作良好，但在 2025 年 5 月 29 日，新增了一個配額策略檢查，這本應是一個新功能，但卻變成了一個巨大的錯誤。這個功能的程式碼路徑從未真正執行過，因為它需要一個策略變更來觸發程式碼，但顯然在測試階段從未觸發過，所以看起來一切都很好。這聽起來很像去年的 CrowdStrike 災難。
在這種情況下，該程式碼路徑沒有適當的錯誤處理，這將導致一個空指針，進而導致二進位檔案崩潰。我上週剛在我的 C 語言影片中談到帶有空指針的錯誤程式碼，但在任何情況下，這個錯誤一直處於休眠狀態，直到 6 月 12 日，當時插入了一個策略變更，然後在幾秒鐘內在全球範圍內複製，這導致 API 管理二進位檔案進入崩潰迴圈，進而導致科技界的恐慌和混亂。
災難控制與解決
幸運的是，Google 開發人員確實安裝了一個紅色的緊急按鈕來回滾。但花了約 40 分鐘才開始回滾，並花了約 4 小時才完全恢復到正常狀態。這一天將永遠被銘記，但你可以藉由本影片的贊助商 PostHog，開始建立更好的產品。你可能知道 PostHog 是一個用於建立更好產品的一體化平台。你可能不知道的是，PostHog 剛剛推出了 Mac，再次改變了遊戲規則。Mac 是他們的人工智慧產品分析師和助手，直接存在於你的 Postog 應用程式中。它與你的資料深度連接，這讓你可以做各種很酷的事情，例如研究答案、用自然語言提出產品問題、生成資料視覺化、代表你在 Postog UI 中完成工作，以及回答關於文檔的問題。這與 PostHog 提供的所有其他功能相結合，例如分析、功能標誌、會話重播等等。
今天就透過下面的連結試試 PostHog 吧。這裡是 The Code Report。感謝你的收看，我們下一次再見。
{# 
{# 
{#