谷歌云 10 月 22 日在状态页发布了 europe-west2（伦敦）区域事故的初步报告：故障从太平洋时间 10 月 19 日 23:00（英国夏令时 10 月 20 日 07:00）持续到太平洋时间 10 月 20 日 05:10（英国夏令时 13:10），共 6 小时 10 分。我们的节点不在欧洲，但这份报告把一个常被忽略的问题讲得很清楚：同一个区域里的「多可用区」能扛住什么、扛不住什么。
经过：从电网中断到整个可用区断电
- 太平洋时间 22:53（英国夏令时 06:53），承载可用区 europe-west2-b 的机房遭遇电网中断，负载按设计切到 UPS 电池，同时启动现场的柴油发电机。
- 控制发电机的 PLC（可编程逻辑控制器）主、备两套都没能完成自动启动和切换，发电机始终没有接上负载。23:00 起 UPS 电池耗尽，这个可用区的物理服务器、网络交换设备和本地存储全部断电。
- 电网供电恢复后，现场工程师在 1 小时内接回了稳定的市电，之后重置并测试了发电机的自动控制器；谷歌逐步重启基础设施，分批把流量放回 b 区。
- 前 5 小时 29 分（到英国夏令时 12:29）大部分服务恢复；Compute Engine 的恢复拖得更久，12:46 才恢复创建新虚拟机，13:10 时超过 99% 的虚拟机恢复健康。
没断电的 a 区、c 区为什么也受影响
报告点名了两个原因。一是 b 区的工作负载集中涌向 a 区和 c 区，瞬间耗尽了剩余容量，出现排队、数据库故障切换变慢和间歇性的 500 / 503 错误；二是部分服务的控制面要跨可用区做同步校验，而校验依赖的组件恰好在已经断电的 b 区，于是 API 调用超时。报告点名受到意外影响的有 BigQuery、Looker、Compute Engine、GKE、区域级持久磁盘和 Cloud SQL。完全只放在 b 区的资源则直接无法访问。附带改进措施的最终报告还没有发布。
还有一个细节：事故当晚状态页最早的一条更新写的开始时间是太平洋时间 23:08，那其实是谷歌监控发出告警的时间；初步报告以 23:00 为开始。看云厂商的状态页时要有准备，最早的几条更新常常会被后来的报告修正。
对一台或几台 VPS 来说，能学到什么
- 备份放到另一个地区。放在同一机房、同一区域的备份，遇到整个机房断电时会和原数据一起无法访问。做法见 VPS 数据备份方案。
- 重要的业务在第二个地区准备一台机器，平时可以只是一台小规格的冷备，DNS 记录的 TTL 设短一些，出事时把解析切过去，参见 DNS 配置入门和如何为业务选择低延迟的机房节点。
- 把依赖关系画出来。这次 a 区、c 区出问题，是因为它们依赖的东西在 b 区。梳理自己业务依赖的方法见2026 上半年宕机的主线是「依赖风险」；9 月底 Azure 的两起事故见这篇复盘整理。
2026 年 11 月 7 日更新：谷歌云 11 月 4 日发布了最终事故报告：主体影响为 6 小时 8 分钟；发电机没启动，是因为机房检修期间只剩一路市电，而控制器的欠压检测接在另一路已断开的断路器上游，误以为那一路有电。详见后续报道。