10 月 26 日我们根据初步报告写了谷歌云伦敦 europe-west2-b 可用区停电的事。11 月 4 日，谷歌云在状态页发布了最终事故报告，根因比初步报告具体得多。按最终报告，主体影响在 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 谷歌云服务和 API 全部可用（仍有部分 GCE 虚拟机未恢复），12:29 平台级中断结束，13:08 GCE 虚拟机 99.5% 正常、可以新建，15:03 发出事件结束通知。
- 断电期间另外两个可用区也受拖累：跨可用区调用打到离线的可用区超时，故障转移涌来的负载挤满了其他可用区的计算资源，全区出现间歇性的 500 和 503 错误。
谷歌的整改，和对自建服务器的启示
谷歌列出的措施包括：PLC 已在 10 月 20 日和 26 日两次重新配置并验证，26 日完成了带全部关键负载的发电机转移测试；电力公司 10 月 26 日找到了电缆故障点，预计 11 月 13 日修好 A 路，11 月 17 日前把机房切回 A、B 两路并再做一次发电机带载测试；11 月 6 日前完成 PLC 代码的全面审查。对我们自己的服务器，有三点值得记住：冗余在检修时会悄悄变成单点，一台在维护时另一台就是唯一的；监控要看真实状态，而不是一个上游信号；突然断电之后最慢的往往是存储恢复，所以数据要按备份方案留一份在别处。多地域部署的思路见一个节点不够，节点怎么选见如何选择低延迟机房节点。