Google Cloud 倫敦區域事故分析：從備援供電失效到金融服務連鎖中斷

1. Google Cloud 倫敦區域事故

2026 年 10 月 20 日，Google Cloud 位於倫敦的 europe-west2 區域發生重大服務中斷。事故起因是單一可用區 europe-west2-b 的資料中心供電事件，但影響並未侷限於該區：其他可用區的運算資源、跨區控制系統（control plane）呼叫與工作佇列也受到連鎖衝擊。多項 Google Cloud 服務出現 API 逾時、錯誤率升高與處理延遲，仰賴雲端服務的金融及其他線上服務也受到波及。

依 Google Cloud 公布的初步事故報告，事件從英國夏令時間（BST）10 月 20 日 07:00 開始，到 13:10 大部分工作負載恢復，歷時約 6 小時 10 分鐘。Google 隨後仍需處理少數未完全恢復的工作負載，並於 15:03 公布事故結案。這個時間差提醒我們：平台大部分資源恢復、個別工作負載恢復，以及客戶端到端服務恢復，並不是同一件事。

本文依據 Google 公開的初步事故報告與公開報導，分析故障鏈、跨區關聯、復原策略，以及金融機構在雲端外包環境下應重新檢視的韌性責任。Google 尚未完成最終根因分析，故部分屬推論。

2. 事故時間線與影響範圍

Google 列出的受影響產品包括 Compute Engine、Google Kubernetes Engine、Cloud SQL、Cloud Storage、Persistent Disk、Pub/Sub、Memorystore 等。實際影響取決於客戶使用的產品、部署方式、跨區關聯與故障切換設計。

參考：Google Cloud 官方事故紀錄與初步報告。

3. 第一層故障：市電中斷後，備援供電未完全接手

3.1 原本應該發生的切換程序

資料中心的電力保護通常不是單一設備，而是由多個環節構成：市電供應、UPS 不斷電系統、緊急發電機、供電切換控制，以及連接至伺服器、網路與儲存設備的電力分配系統。

典型的設計，市電中斷時，UPS 先提供短時間的電力緩衝，讓發電機啟動並穩定輸出；之後，供電切換設備將負載轉移到備援電源。這個流程必須在 UPS 電池耗盡之前完成，否則即便發電機本身沒有故障，仍將斷電。

3.2 Google 初步報告指出了什麼？

電力中斷後，設施負載轉由 UPS 電池供應，現場緊急柴油發電機則應在啟動程序完成後接手。然而，負責自動化控制的可程式邏輯控制器（Programmable Logic Controller，PLC）未執行發電機的自動啟動與切換；而當時主要與備援的 PLC 竟同時失效。

當 UPS 電池儲備耗盡，europe-west2-b 的實體主機、網路交換設備及本地儲存陣列便失去電力而離線。這不是單純某台伺服器故障，而是整個可用區內多種基礎設施同時停頓。

3.3 備援設備在，不代表備援能力也在

如果主要 PLC 與備援 PLC 都無法完成啟動或切換操作，兩套系統是否真的具備足夠的故障獨立性？

兩套 PLC 不必然有相同缺陷，可能的調查方向包括共用控制邏輯、共同輸入訊號、共用電源或通訊路徑、切換程序的共同前提，以及測試是否涵蓋真實市電中斷情境。

這個問題對所有大型資料中心都適用。

4. 第二層故障：單一可用區失效，為何波及其他可用區？

4.1 可用區隔離，不等於所有關聯都已隔離

雲端架構常以多個可用區分散實體故障風險。當其中一區失效，負載平衡器、區域路由與應用程式應將流量導向其他可用區。因此，單一可用區的故障理應不會造成整個區域完全失去服務能力。

但「運算資源分散在不同可用區」與「服務的所有關聯都能跨區獨立運作」是兩回事。應用程式可能部署在多區，卻仍關聯共享中介服務、控制系統、目錄、後設資料服務、同步驗證程序或其他跨區元件。

4.2 跨區 RPC 逾時，讓控制系統也進入故障鏈

Google 的初步報告指出，區域服務控制系統對位於離線可用區的後端資料與目錄元件發出跨區遠端程序呼叫（Remote Procedure Call，RPC）時，發生逾時。這導致交易停滯、API 延遲升高，並使故障不再只是「某一區的伺服器無法使用」。

這類關聯尤其值得注意，因為控制系統負責管理、協調或驗證工作負載，而交易（資料）系統則負責實際執行客戶流量與運算。即使部分資料庫資源仍然存活，如果控制系統無法完成必要操作，客戶仍可能無法建立資源、完成交易或服務請求。

4.3 自動故障切換是轉移壓力，而未消除壓力

當 europe-west2-b 的工作負載被導向其他可用區時，替代區域必須承接原有流量與新湧入的工作。結果，轉移的查詢執行、高可用性資料庫切換與運算工作負載，使其他可用區的運算時段及處理容量承受龐大壓力，而出現佇列增加、資料庫切換延遲，以及間歇性的 HTTP 500 和 503 錯誤。

這顯示高可用性架構的高成本核心：故障切換很不便宜，它會把原本分散的負載集中到剩餘資源上。如果剩餘容量不足、控制系統仍關聯故障區，或大量元件同時啟動重試與切換程序，則原本用來保護服務的自動化機制將反成壓力放大的來源。

5. 故障鏈：從電力事件到客戶可見的服務中斷

關切故障鏈，不只找出第一故障點何在，還要分析每一層如何把故障傳遞給下一層。實體電力問題本應由資料中心備援系統吸收；備援切換失敗後，雲端平台應將影響限制在單一可用區；跨區關聯與容量壓力卻讓部分影響越過原本的故障邊界。

對金融 IT 團隊而言，架構審查不能只問「服務是否部署在多個可用區」，還應追問：故障區完全消失時，控制系統能否繼續運作？資料庫切換是否會同時引發大量重連？剩餘區域是否有足夠容量承接尖峰負載？重試是否有上限與退避機制？

6. 復原不只重新開機：為什麼恢復程序也可能造成第二波風險

6.1 隔離、優先排序、恢復與逐步回流

Google 公布的復原措施包括：將流量導離離線區、調整排程與容量限制以降低資源競爭、在穩定市電恢復後重設並測試發電機自動化控制器、逐步重新啟動核心基礎設施，以及在確認系統健康與儲存完整性後，控制流量重新進入 europe-west2-b。

這個順序很重要。電力恢復並不代表所有主機、網路、儲存與分散式服務都已可立即接受完整流量。服務必須逐層確認狀態，並在適當的節奏下重新承接工作。

6.2 復原過程也可能引發資源競爭

在大規模中斷後，系統通常需要處理積壓工作、重建資料庫副本、恢復佇列消費者、重新連線客戶端，並讓流量逐步回到恢復中的資源。若所有元件同時重試或同時回流，恢復中的系統可能再次遭遇容量尖峰。

因此，成熟的復原策略不應只包含「故障時如何切走」，也要定義「故障解除後如何切回」。逐步回流、工作負載優先排序、重試退避、流量整形、資料完整性驗證與容量保護，都是復原設計的一部分。

6.3 99% 的 VM 健康，不代表 99% 的業務已恢復

Google 表示，截至 BST 13:10，超過 99% 的 Compute Engine VM 已處於健康狀態；事故結案通知則在 15:03 發布。這些數字本身有價值，但不能直接用來衡量客戶的實際業務狀態。

一台 VM 可以被標示為健康，應用程式卻仍可能缺少必要的資料庫連線、等待佇列工作、無法通過身分驗證，或因外部關聯逾時而無法完成交易。基礎設施健康指標與端到端業務指標，應該分開監控。

7. 金融服務的風險：雲端故障如何轉化為業務中斷

7.1 客戶看到的是交易失敗，不是可用區代碼

金融服務通常由多個元件共同完成：使用者登入、身分驗證、帳戶查詢、風險檢核、交易處理、外部支付介接、帳務入帳、清算及對帳。即使核心交易引擎仍在運作，只要其中一個必要元件無法回應，交易就可能無法完成。

因此，服務韌性除了 VM、容器、資料庫或雲端區域的健康狀態， 還要以完整的客戶與業務流程衡量。

7.2 交易失敗與交易結果不明，是兩種不同風險

對金融系統而言，逾時不一定代表交易沒有發生。若請求已送達下游系統，但回應在網路中遺失，客戶端可能只看到逾時，而交易實際上已經提交。若系統直接重試，可能產生重複扣款、重複指令或帳務不一致等風險。

因此，災難復原與故障切換設計應涵蓋冪等性（idempotency：指某個操作、函數或 API 不論執行一次還是執行多次，所產生的最終結果與系統狀態都完全相同）、交易狀態查詢、唯一請求識別碼、重試策略、補償交易與事後對帳。這些措施都能降低中斷期間的資料與帳務風險。

7.3 金融業的恢復目標必須對應業務影響

復原時間目標（RTO）與復原點目標（RPO）不只是災難復原文件中的數字，還必須涵蓋：哪些服務必須優先恢復？哪些交易可以延後處理？哪些操作在狀態不明時必須暫停？恢復後如何確認交易完整性？誰有權決定重新開放服務？

此處技術團隊與業務團隊的緊密合作便極其重要：若只知道如何恢復伺服器，卻沒有明確的業務優先順序與交易核對程序，基礎設施即使恢復，業務仍可能長時間處於不確定狀態。

8. 金融 IT 團隊應檢查的控制項目

9. 備援設計究竟保護了什麼？

9.1 主要與備援 PLC 都失效的風險

Google 初步報告提到主要與備援 PLC 都未能啟動必要的自動化操作。這不代表兩套設備都具有相同缺陷，但它提出了一個不能迴避的問題：兩套控制器是否在關鍵故障情境下真正獨立？

工程調查應檢查控制邏輯、供電、感測輸入、通訊、切換條件與測試覆蓋率是否存在共同關聯。若兩套備援設備共享某個關鍵前提，那麼硬體數量增加，不一定會帶來同等幅度的風險降低。

這原則也適用於雲端軟體：兩個服務副本如果共用同一個控制系統、憑證服務、設定來源或資料庫，就不能只因為它們位於不同可用區，便認定故障風險已完全分離。

9.2 跨區 RPC 逾時：多區部署不代表多區獨立

Google 的初步報告指出，區域控制系統對故障區內的後端資料與目錄元件發出 RPC 時遇到逾時。這表示，即使某些工作負載位於其他可用區，仍可能因為必要的跨區關聯而受到影響。

因此，架構審查應區分兩種能力：一是工作負載可以在多區執行；二是當其中一區完全失效時，服務仍能在不關聯故障區的情況下完成必要操作。前者是部署分布，後者才更接近故障隔離能力。

如果系統在正常狀態下依靠同步跨區呼叫，設計團隊就應明確評估逾時、重試、降級、快取、隔離及控制系統不可用時的行為。否則便未曾真正切斷故障傳播路徑。

9.3 容量規劃不能只以正常運作為基準

當一個可用區失效，其他可用區必須承接額外負載；同時，資料庫切換、工作重試與積壓任務也可能提高資源需求。

如果一套系統只在所有可用區都正常時，才能維持足夠容量，那麼它的高可用性承諾究竟有多強？真正的容量測試應模擬故障時的流量重分配與恢復過程，而不只對正常流量壓力測試。

9.4 技術面的恢復（VM 健康率）vs. 客戶服務面的恢復

基礎設施指標容易量化，業務結果則複雜得多。VM 啟動、API 回應、資料庫連線恢復，都只是服務鏈上的局部條件。客戶真正關心的是登入是否成功、交易是否完成、資料是否一致，以及服務是否能持續提供。

因此，事故報告除了列出主機與服務的恢復比例，也應盡可能讓客戶理解：哪些業務功能仍受影響、哪些工作負載需要額外處理、是否存在交易核對或資料完整性風險，以及服務何時才真正回到可接受的業務狀態。

9.5 復原不僅把開關打開，尚需控制第二波風險

Google 採取隔離故障區、調整排程、恢復供電、逐步重新啟動基礎設施，以及在確認健康狀態與儲存完整性後逐步回流的方式復原。這個程序說明，復原本身也是一項需要設計與控制的工程。

如果所有工作負載同時重試、所有資料庫副本同時重建、所有客戶流量同時回流，恢復中的系統可能再次遭遇容量不足。復原程序必須考慮優先順序、節流、重試退避、資料驗證與流量回流節奏，而不單是「故障排除後重新啟動」。

10. 監管與外包責任：系統放上雲端，並不能把責任交出去

10.1 雲端服務已是金融監理的關注對象

這次事故引起英國與歐洲金融監管機構關注。公開報導指出，歐洲銀行管理局（EBA）已向 Google Cloud 詢問事故資訊及其對金融機構的影響；英國國會財政委員會也要求英格蘭銀行與金融行為監理總署（FCA）說明事故規模、金融服務影響與相關應對。

這不是單純的供應商客服問題。當多家金融機構關聯相同的雲端服務商或區域基礎設施時，單一供應商事故可能同時影響多家機構，形成集中度風險。監理關注的焦點，除了單一機構的復原能力，也包括金融體系對少數關鍵第三方服務商的共同關聯。

10.2 SLA 不等於營運韌性

服務水準協議（SLA）可以定義可用性承諾、服務抵免與部分補救措施，但它不會自動替金融機構設計好故障切換、交易一致性、客戶溝通、替代作業或監理通報流程。

即使供應商事後提供服務抵免，也不能直接抵銷金融機構在事故期間可能面臨的客戶損失、營運中斷、監理責任與聲譽風險。合約上的可用性承諾與機構自身的營運韌性，是兩個不同層次的問題。

10.3 外包的是技術執行，不是全部責任

金融機構可以將基礎設施、平台管理或部分營運工作交由雲端供應商處理，但仍需掌握自身的業務風險、服務關聯、復原目標與客戶責任。機構必須能回答：關鍵服務關聯哪些供應商？故障時可以採取哪些替代措施？誰有權決定降級、暫停或恢復服務？事故後如何證明交易完整性？

如果機構只把供應商 SLA 當作韌性保證，卻沒有驗證自己的端到端服務能否承受供應商故障，那麼它外包出去的可能不只是技術工作，還包括自己尚未真正理解的風險。

11. 架構撐住了事故，還是工程師把事故救了回來？

這次事件值得追問的，不是雲端是否會發生故障——任何複雜系統都可能故障——而是故障發生後，系統原本設計的隔離與自動復原機制，究竟發揮了多少作用，又有哪些部分必須仰賴工程師介入才得以恢復。

Google 公布的復原措施包括人工隔離故障區、調整排程與容量限制、恢復供電、逐步重啟服務，以及控制流量重新進入故障區。這些措施本身並不表示架構設計失敗；大規模分散式系統本來就可能需要人工介入。但它們提醒我們，評估韌性不能只看架構圖上有多少可用區、多少副本與多少自動化功能。

真正需要驗證的是：系統能否在預期的故障條件下，自動把影響限制在可接受範圍內？哪些決策仍需人工判斷？工程師介入前，業務服務會中斷多久？如果事故發生在另一個時區、另一個服務組合，或同時伴隨第二項故障，原本的復原程序還能否成立？

可以用一句話概括這個問題：架構圖描述的是設計意圖，事故演練與真實事件才揭示實際能力。這不是對單一供應商的指控，而是對所有宣稱具備高可用性與自動故障切換能力的系統提出的合理要求。

12. 韌性的最小單位，是端到端業務服務

雲端監控通常以區域、可用區、VM、容器、資料庫、API 或佇列為觀察單位。這些指標對工程診斷非常重要，但金融機構不能只停留在這個層次。

一筆金融交易可能依序經過使用者驗證、風險檢核、帳戶服務、交易處理、外部支付介接、帳務入帳與對帳。這條鏈上任何必要元件失效，都可能讓客戶無法完成交易。

因此，業務韌性的驗收標準應該是端到端的：客戶能否完成關鍵操作？系統能否正確處理逾時與重試？交易結果是否可確認？資料是否一致？恢復後是否能完成對帳？如果主要供應商或區域長時間不可用，機構能否在承諾的時間內維持最低必要服務？

雲端架構審查不只要問「是否多區部署」，應進一步還要問：跨區關聯是否已盤點？剩餘容量是否經故障情境驗證？控制是否可能成為共同故障點？切換與切回是否都經過演練？業務團隊是否知道何時應停止重試、暫停交易或啟動替代程序？

多區部署不能只是提高正常狀態下的可用性。

13. 結語：雲端架構圖並非韌性證明

Google Cloud 倫敦區域事故從資料中心供電事件開始，最終演變為多項雲端服務的連鎖中斷。它說明，分散式架構中的故障並不一定會停留在最初發生的地點；故障隔離、關聯管理、容量規劃與復原控制，彼此息息相關。

對金融機構而言，結論顯然不是「不要使用雲端」，而是不應將採用大型雲端供應商、多區部署或簽訂 SLA，當成韌性已經完成的證明。真正的韌性必須經過故障情境測試、端到端監控、復原演練與業務驗證。

14. 參考資料

1. Google Cloud Service Health：europe-west2 事故與初步根因報告
2. Associated Press：Google Cloud outage hits UK banks
3. Reuters：Revolut says some services back online after outage
4. UK Parliament Treasury Committee：Google Cloud outage and regulatory correspondence

編輯說明：本文依公開資訊撰寫。第 9 至第 12 節的評論屬於技術分析及風險推論，不代表 Google 已確認相應設計缺陷。後續仍應關注 Google 最終事故報告及相關監管機構正式文件。