Google Cloud 10 月 22 日在狀態頁發布了 europe-west2（倫敦）區域事故的初步報告：故障從太平洋時間 10 月 19 日 23:00（英國夏令時 10 月 20 日 07:00）持續到太平洋時間 10 月 20 日 05:10（英國夏令時 13:10），共 6 小時 10 分。我們的節點不在歐洲，但這份報告把一個常被忽略的問題講得很清楚：同一個區域裡的「多可用區」能扛住什麼、扛不住什麼。
經過：從電網中斷到整個可用區斷電
- 太平洋時間 22:53（英國夏令時 06:53），承載可用區 europe-west2-b 的機房遭遇電網中斷，負載按設計切到 UPS 電池，同時啟動現場的柴油發電機。
- 控制發電機的 PLC（可程式邏輯控制器）主、備兩套都沒能完成自動啟動和切換，發電機始終沒有接上負載。23:00 起 UPS 電池耗盡，這個可用區的實體伺服器、網路交換設備和本機儲存全部斷電。
- 電網供電恢復後，現場工程師在 1 小時內接回了穩定的市電，之後重置並測試了發電機的自動控制器；谷歌逐步重啟基礎設施，分批把流量放回 b 區。
- 前 5 小時 29 分（到英國夏令時 12:29）大部分服務恢復；Compute Engine 的恢復拖得更久，12:46 才恢復建立新虛擬機器，13:10 時超過 99% 的虛擬機器恢復健康。
沒斷電的 a 區、c 區為什麼也受影響
報告點名了兩個原因。一是 b 區的工作負載集中湧向 a 區和 c 區，瞬間耗盡了剩餘容量，出現排隊、資料庫故障切換變慢和間歇性的 500 / 503 錯誤；二是部分服務的控制層要跨可用區做同步驗證，而驗證依賴的元件恰好在已經斷電的 b 區，於是 API 呼叫逾時。報告點名受到意外影響的有 BigQuery、Looker、Compute Engine、GKE、區域級持久磁碟和 Cloud SQL。完全只放在 b 區的資源則直接無法存取。附帶改進措施的最終報告還沒有發布。
還有一個細節：事故當晚狀態頁最早的一條更新寫的開始時間是太平洋時間 23:08，那其實是谷歌監控發出警示的時間；初步報告以 23:00 為開始。看雲端服務商的狀態頁時要有準備，最早的幾條更新常常會被後來的報告修正。
對一台或幾台 VPS 來說，能學到什麼
- 備份放到另一個地區。放在同一機房、同一區域的備份，遇到整個機房斷電時會和原資料一起無法存取。做法見 VPS 資料備份方案。
- 重要的業務在第二個地區準備一台機器，平時可以只是一台小規格的冷備，DNS 記錄的 TTL 設短一些，出事時把解析切過去，參見 DNS 設定入門和如何為業務選擇低延遲的機房節點。
- 把依賴關係畫出來。這次 a 區、c 區出問題，是因為它們依賴的東西在 b 區。梳理自己業務依賴的方法見2026 上半年當機的主線是「依賴風險」；9 月底 Azure 的兩起事故見這篇復盤整理。
2026 年 11 月 7 日更新：Google Cloud 11 月 4 日發布了最終事故報告：主體影響為 6 小時 8 分鐘；發電機沒啟動，是因為機房檢修期間只剩一路市電，而控制器的欠壓檢測接在另一路已斷開的斷路器上游，誤以為那一路有電。詳見後續報導。