10 月 26 日我們根據初步報告寫了Google Cloud 倫敦 europe-west2-b 可用區停電的事。11 月 4 日，Google Cloud 在狀態頁發布了最終事故報告，根因比初步報告具體得多。按最終報告，主體影響在 6 小時 8 分鐘內解決（初步報告寫的是 6 小時 10 分）。

根因：一次檢修加一處檢測點位置

  • 這個機房是 2N 市電架構：兩路獨立的市電饋線 A 和 B，後面是一組高壓發電機，由一套雙冗餘的可程式邏輯控制器（PLC）管理。UPS 電池大約能撐 5 分鐘，留給 PLC 檢測欠壓、啟動並同步柴油發電機、再轉移負載。
  • 10 月 14 日的季度發電機帶載測試發現了問題，為了維修 B 路，B 路的斷路器被斷開，機房臨時處於單路（1N）供電的檢修狀態，全部關鍵負載只靠 A 路。
  • 10 月 19 日 22:53（太平洋時間，即英國夏令時 20 日 06:53），A 路因為機房外電網的一處地下電纜故障斷電。PLC 的欠壓檢測接在兩路饋線斷路器的上游：B 路斷路器雖然斷開，上游卻仍然有電，執行同一套邏輯的主、備兩台 PLC 都讀到「有健康的市電」，於是沒有向發電機發出啟動命令。現場團隊嘗試透過 PLC 遠端轉移負載，也因為同一個讀數被系統攔下。
  • 團隊判斷 UPS 電量撐不到遠端操作理順，就把整個設施切到備用市電，但在切換過程中電池已經耗盡，機房斷電。

為什麼恢復要 6 個小時

  • 以下均為英國夏令時：07:00 開始受影響；07:54 備用市電接通，08:20 資料大廳恢復供電，08:40 叢集開始恢復，08:45 網路裝置重新上線。
  • 真正慢的是儲存：突然斷電讓大量儲存裝置非正常關機，08:50 起開始恢復，工程師刻意不去恢復那些會讓情況更糟的服務。裝置數量太多，這一步花了很長時間，直到 11:13 儲存才基本就緒，11:45 開始逐步放回流量。
  • 12:11 Google Cloud 服務和 API 全部可用（仍有部分 GCE 虛擬機器未恢復），12:29 平台級中斷結束，13:08 GCE 虛擬機器 99.5% 正常、可以新建，15:03 發出事件結束通知。
  • 斷電期間另外兩個可用區也受拖累：跨可用區呼叫打到離線的可用區逾時，故障轉移湧來的負載擠滿了其他可用區的計算資源，全區出現間歇性的 500 和 503 錯誤。

Google 的修正，和對自建伺服器的啟示

Google 列出的措施包括：PLC 已在 10 月 20 日和 26 日兩次重新設定並驗證，26 日完成了帶全部關鍵負載的發電機轉移測試；電力公司 10 月 26 日找到了電纜故障點，預計 11 月 13 日修好 A 路，11 月 17 日前把機房切回 A、B 兩路並再做一次發電機帶載測試；11 月 6 日前完成 PLC 程式碼的全面審查。對我們自己的伺服器，有三點值得記住：冗餘在檢修時會悄悄變成單點，一台在維護時另一台就是唯一的；監控要看真實狀態，而不是一個上游訊號；突然斷電之後最慢的往往是儲存恢復，所以資料要按備份方案留一份在別處。多區域部署的思路見一個節點不夠，節點怎麼選見如何選擇低延遲機房節點。