Google Cloud 倫敦區域停電事後報告

10 月 20 日（台灣時間下午兩點左右），Google Cloud 倫敦區域 europe-west2 的 b 可用區整個斷電，影響一路延伸到同區域的其他可用區。Google 在 10 月 27 日於狀態頁公布完整的事後報告，寫得相當坦白。

我們多數人不會在倫敦跑服務，但這份報告講的是每個雲端架構都會遇到的問題：備援在真正需要的時候，不一定會動。

一、事情怎麼發生的

這個機房原本是 2N 供電，也就是兩路市電各自能扛全部負載，後面還有柴油發電機和 5 分鐘的 UPS 電池。

1. 10 月 14 日例行的季度發電機負載測試發現問題，機房把 B 路市電斷開維修，暫時只剩 A 路一條（1N）。
2. 10 月 19 日 22:53（美西時間），機房外的地下電纜故障，A 路斷電。
3. 發電機控制器（PLC）判斷要不要啟動發電機時，量的是 B 路斷路器上游的電壓。B 路雖然已經斷開，上游仍有電，PLC 就以為「市電正常」，沒有啟動發電機。
4. UPS 撐到電池耗盡，23:00 起整個可用區斷電。現場人員最後手動切到備用市電，才恢復供電。

斷電後不到一小時，備用市電就接上了，但服務沒有馬上回來。大量儲存設備是非正常關機，必須先完成修復，Google 選擇不急著開放流量以免狀況更糟。從開始到多數工作負載恢復，總共 6 小時 8 分。

二、最值得看的：其他可用區為什麼也受傷

照理說，一個可用區掛掉，另外兩個（a、c）應該頂住。報告直接寫了兩個原因：

• 需求瞬間湧入：大量工作負載同時容錯移轉到 a、c，把運算容量吃滿，造成排隊、資料庫容錯移轉延遲，以及間歇性的 500／503 錯誤。報告也承認，部分容錯移轉因為容量不足而失敗。
• 控制平面跨可用區相依：區域層級的服務會去呼叫位在 b 區的中繼資料元件，結果逾時。這段期間，有些客戶無法建立、更新或刪除區域資源。

Google 也說得很清楚：單一可用區的資源（VM、非 HA 的 Cloud SQL、zonal GKE 叢集等）在可用區故障時無法使用，是「設計如此」；需要容錯的話，客戶要自己規劃跨可用區的復原機制。

三、你現在可以檢查的事

如果你用 GCP，先找出哪些資源其實只活在一個可用區：

# Cloud SQL：availabilityType 為 ZONAL 代表沒有跨可用區 HA
gcloud sql instances list \
  --format="table(name,region,gceZone,settings.availabilityType)"

# GKE：location 是 zone（例如 asia-east1-b）就是 zonal 叢集
gcloud container clusters list --format="table(name,location)"

# VM 分布在哪些可用區
gcloud compute instances list --format="table(name,zone.basename(),status)"

其他雲也一樣，重點是這張清單：

• 列出每個服務的資料庫、快取、運算各在哪些可用區
• 區分「真的需要跨可用區」和「可以接受停幾小時」的服務，寫下來
• 容錯計畫不要依賴事故當下建立新資源；控制平面可能正忙、容量可能被搶光
• 確認備份在另一個區域也有一份，並實際演練還原
• 進行維護（升級資料庫、換節點）時，留意自己是不是暫時降到「只剩一份」
• 訂閱雲端廠商狀態頁的 RSS／通知，並有自己的外部監測

四、我的看法

這次的根本原因很「機房」，但教訓很軟體：一個在維護狀態下才會觸發的設定錯誤，平常的測試完全測不到。 Google 自己的改善項目也包括在其他類似架構的機房凍結計畫性維護，以及在 11 月 15 日前檢查全球同類 PLC 設定。

對中小團隊來說，不必追求全面多區域。但至少要知道哪些服務是單點、出事時要停多久、誰來決定切換。把這些寫成一頁文件，比多買一個可用區更實際。

如果你想檢視現有架構的單點與復原計畫，可以預約 30 分鐘初談。