1. 事故概況：單一可用區故障，影響卻跨越區域
2026 年 10 月 20 日，Google Cloud 倫敦區域（europe-west2）發生重大服務中斷。事故起於單一可用區的供電問題，卻進一步牽動跨區服務關聯，影響多項雲端服務。
Google 的事故報告指出，英國夏令時間（BST）07:00 左右開始發生問題；至 13:10，超過 99% 的 Compute Engine 虛擬機器已恢復正常，事故於 15:03 宣告結束。這段時間的服務復原，並非單純重新啟動主機，而是涉及基礎設施、容量調度與上層服務逐步恢復。
| 時間（BST） | 事件 |
|---|---|
| 07:00 | 事故開始，供電問題影響倫敦區域內的部分基礎設施。 |
| 事故期間 | 多項雲端服務受到影響，部分工作負載無法正常執行或回應。 |
| 12:29 | Google 持續進行基礎設施復原與服務調整。 |
| 12:46 | 復原工作持續推進，服務逐步恢復。 |
| 13:10 | 超過 99% 的 Compute Engine 虛擬機器恢復正常。 |
| 15:03 | Google 宣告事故結束。 |
受影響服務包括 Compute Engine、Google Kubernetes Engine（GKE）、Cloud SQL、Cloud Storage、Persistent Disk、Pub/Sub 與 Memorystore。這也說明，雲端服務即使分布在不同可用區，仍可能因共用的控制流程、服務關聯或容量限制，受到單一故障點的連鎖影響。
2. 第一個故障點：備援供電在關鍵時刻沒有接手
事故的起點是供電異常。Google 的說明指出，市電中斷後，不斷電系統（UPS）先以電池維持供電；然而，備用發電機未能順利接手。自動切換程序因主要與備援可程式邏輯控制器（PLC）未能完成操作而失敗。當 UPS 電池耗盡，europe-west2-b 可用區內的實體主機、網路設備及本地儲存陸續離線。
這裡值得注意的，不只是發電機為何沒有啟動，而是備援機制為何未能在預定時刻發揮作用。
設備有備援，不代表功能就有備援。兩套控制器若仍受相同的操作流程、狀態條件或其他共同因素影響，表面上的雙重配置仍可能出現共同模式故障（common-mode failure）。這是值得檢視的工程問題，但不能僅憑現有資訊，就斷定本次事故的根因必然是某一種共同模式故障。
對金融機構而言，這類事故提醒我們：備援設計不能只確認「有第二套設備」，還必須驗證故障發生時，接手程序能否在限定時間內完成，並且不受原系統故障牽連。
3. 為何單一可用區故障，會演變成跨區連鎖中斷？
可用區隔離的目的，是將故障限制在局部範圍；但實際系統還包含控制平面、服務中介層、資料庫與工作負載之間的關聯。當某個可用區完全離線，其他區域即使仍有運作中的主機，也不代表整體服務能維持正常。
依據 Google 的事故說明，可用區故障後，區域控制平面與部分中繼資料、目錄類元件之間的跨區遠端程序呼叫（RPC）出現逾時。這類呼叫若持續失敗，便可能妨礙工作負載管理與服務操作。與此同時，工作負載重新調度、資料庫故障切換及查詢執行等需求，可能集中到其他可用區，使剩餘容量承受額外壓力。
當請求量超過可用資源，或必要操作因逾時而反覆重試，系統便可能形成連鎖效應：佇列堆積、資料庫切換延遲、服務回應時間拉長，最後出現 HTTP 500 或 503 等錯誤。
| 故障階段 | 可能的連鎖效應 |
|---|---|
| 可用區離線 | 原本在該區執行的主機、網路或儲存服務無法繼續運作。 |
| 跨區呼叫逾時 | 控制平面與相關服務無法順利取得必要資訊或完成操作。 |
| 工作負載重新調度 | 其他可用區承接額外需求，資源與資料庫負載上升。 |
| 重試與佇列堆積 | 失敗請求再次進入系統，增加延遲並進一步消耗資源。 |
| 上層服務異常 | 用戶端收到逾時或 500、503 等錯誤，業務流程中斷。 |
這是從事故現象與雲端架構推導出的故障傳播路徑，並非 Google 已逐項確認的完整因果鏈。真正值得關注的是：跨區部署不等於跨區獨立。只要服務仍有跨區呼叫、共同控制元件或容量上的牽連，局部故障就可能超出原本預期的邊界。
4. 復原與金融業務：VM 恢復，不代表交易恢復
復原工作並非只要恢復供電、重新啟動虛擬機器就算完成。Google 必須隔離故障可用區、調整工作負載排程與可用容量、恢復供電、重設並測試發電機控制器，再逐步啟動基礎設施。服務重新接收流量前，也需要確認主機健康狀態與儲存功能。
因此，基礎設施的健康狀態，不等於業務服務已經恢復。虛擬機器可能已能運作，但資料庫仍在故障切換、佇列仍未清空，或上層應用程式仍無法完成端到端流程。
金融系統尤其需要注意交易逾時的意義：逾時不一定代表交易失敗，也可能代表交易已經完成，但回覆未能送達。 如果應用程式將所有逾時都視為失敗並直接重送，就可能造成重複扣款、重複下單或帳務不一致。
建議檢視以下控制措施：
| 控制項目 | 應確認的能力 |
|---|---|
| 可用區隔離 | 單一可用區失效時，能否避免故障持續牽動其他區域。 |
| 故障切換容量 | 剩餘可用區是否有足夠資源承接必要工作負載，而不只是具備切換機制。 |
| 重試與佇列 | 是否有重試上限、退避策略、流量控制及佇列壅塞處理機制。 |
| 交易一致性 | 是否使用唯一請求識別碼、冪等處理、交易狀態查詢與事後對帳。 |
| 端到端監控 | 能否從使用者請求一路追蹤到資料庫、訊息佇列及最終業務結果。 |
| 復原與流量回流 | 服務重新接收流量前，是否確認資料一致性、佇列狀態及實際處理能力。 |
金融機構不應只測試「主機掛掉後能否切換」，還應演練「交易結果不明時如何處理」、「部分服務恢復但下游仍未就緒時如何限流」，以及「服務恢復後如何確認帳務完整」。這些才是從基礎設施可用性走向業務韌性的關鍵。
5. 架構韌性、金融監管與外包責任
這起事故帶出一個值得追問的問題：架構撐住了事故，還是工程師把事故救了回來？
架構圖呈現的是設計意圖；只有在故障發生時，或透過足夠逼真的故障演練，才能驗證隔離、故障切換與復原機制是否真的有效。多區部署、備援設備與服務等級協議（SLA）都很重要，但任何一項都不能單獨證明系統具有足夠的營運韌性。
事故發生後，歐洲金融監管機構向 Google Cloud 詢問相關情況。英國國會財政委員會也公布英格蘭銀行（Bank of England）及金融行為監理總署（FCA）的相關函件。這反映金融監理機關關注的，不只是雲端供應商是否達到服務承諾，也包括中斷如何影響金融機構，以及機構是否具備辨識、承受與復原的能力。
採用外部雲端服務，不代表金融機構可以將所有營運風險一併外包。供應商負責雲端平台的工程與維運；金融機構仍須掌握自身業務流程、資料一致性、復原優先順序與客戶影響，並確認供應商的復原能力符合自身的風險要求。
更重要的是，韌性評估應以業務服務為單位，而非只看單一元件是否正常。例如，客戶能否完成付款、交易結果能否被正確確認、帳務是否一致，以及服務恢復後能否安全地重新接收流量，都比單看虛擬機器的健康狀態更接近真正的營運目標。
高可用性是架構目標；營運韌性，必須由整個系統在故障時的實際表現來證明。
參考資料
- Google Cloud：Incident report
- Reuters，2026 年 10 月 21 日：European financial regulators query Google over cloud outage that hit banks
- UK Parliament, Treasury Committee：Google Cloud outage: Bank of England and FCA letter published
編輯說明：文中對 PLC 共同模式故障及跨區故障傳播的部分分析，屬於根據事故資訊與雲端架構所作的技術推論；不應視為 Google 已確認的全部根因。