10 月 20 日早上，伦敦的 europe-west2 出了一回事。我先看到的是银行 App 登不上——劳埃德、汇丰、Halifax、Revolut 都报了障；再往下翻，Rightmove、DPD、BT、Royal Mail、NHS England 也上了名单。等官方状态页发出来，根因就一句轻描淡写的话：一个可用区出了电源事件。

注意，是一个可用区，不是整个区域。europe-west2 底下有三个可用区，这次挂的是其中一个（west2-b）。06:08 UTC 起，这片负载开始报 elevated errors，网络间歇性抽风；官方给的时间线是 13:00 UTC 左右先把负载「初步」恢复，中间这段时间，客户连新建负载都费劲。

受影响的服务清单拉出来不短：BigQuery Data Transfer Service、Cloud Filestore、Cloud Run、App Engine、Cloud NetApp Volumes、GKE、Managed Service for Apache Kafka……Keele University 一位讲师算了算，说大约 38 项服务受影响。

他点出来的那个词我觉得最值得记——「依赖效应」：核心区一挂，依赖它的 API、数据库、鉴权、支付，还有你根本没直接开的第三方 SaaS，会一层层跟着倒。你以为你只用了某个小服务，其实它底下压着一整套你没看过、也没买过的依赖。

这里还有个容易被忽略的背景：2026 年 7 月起，英国已经把 Google Cloud、微软、AWS、Oracle 正式纳入金融业关键第三方供应商的直管，这次 FCA 也介入了。也就是说，一个云的可用区抖一下，牵动的早就不只是「某家公司的服务器」，而是半个国家的线上业务。

我回头想，这件事真正戳破的还是那句老话：上云不等于高可用。搬上去只是把机房换了个地方，故障还是会长——区别是你从「看得见的机柜」换成了「看不见的可用区」。有人把这句话说得很准：

resilience is not achieved by simply moving to the cloud. True resilience requires designing for regional failures through multi-region deployments, workload portability, and tested disaster recovery procedures.

（韧性不是把东西搬上云就有了，得靠多区域部署、负载可迁移、以及真跑过的容灾演练。）

所以看这类事故，我会固定问三句：出问题的是一个可用区还是整个区域？我的业务有没有跨区？那个「跨区」是真部署了，还是只写在 PPT 里？这三句比一句「可用性 99.9x」更能说明一套系统到底扛不扛事。

我做批量巡检的习惯也是这么来的——机器一多，靠人一台台登上去看状态本来就不现实，这也是我们用七亿批量远程管理工具做批量巡检的原因。但工具只负责让你更快「看见」，看见之后那套「告警→研判→通报→切换」的链，还是得自己提前排过一遍。想对照着过清单的，官网页的说明书可以摊开一起看。

同类的云事故之前写过两篇，可以连起来看：一个 DNS 缺陷，瘫了半个互联网 15 小时、AWS us-east-1 挂了 28 小时：这回不是 DNS，是空调。