摘要
2026年7月15日晚（太平洋时间 16:39 起告警）/7月16日 UTC，谷歌云荷兰 europe-west4-a 可用区（位于 Eemshaven）因上游公共电网发生电气故障，干扰了数据中心内部配电装置与制冷设备，机房环境温度迅速升高。谷歌为避免硬件在高温下损坏，主动关闭主机、存储集群与网络交换机，造成 Google Cloud VMware Engine、Google Cloud NetApp Volumes、Bare Metal Solution 三项服务大面积中断，整体可用区中断接近 15 小时。谷歌于 7月22日发布初步事故报告。受影响最深的是 Bare Metal Solution（约 12 小时 57 分钟）。
时间线
2026-07-15 23:39 UTC谷歌监控收到温度异常与硬件不可达告警（太平洋时间 16:39 7/15）
2026-07-16 04:17 UTC谷歌状态页首次公告 europe-west4-a 温度告警（供电故障引发制冷失效）
2026-07-16 04:41 UTC升级为服务中断公告：供电故障→制冷失效，已主动关停工作负载以保护硬件
之后数小时与第三方设施方协作恢复主用供电与制冷，按网络架构→存储节点→计算集群顺序受控重启并健康校验
受影响时长NetApp Volumes 中断 8 小时 31 分、VMware Engine 中断 9 小时 24 分、Bare Metal Solution 中断约 12 小时 57 分
2026-07-22谷歌发布初步事故报告
整体可用区中断接近 15 小时
根因
上游公共电网（utility grid）发生电气故障（electrical fault），干扰了数据中心内部配电装置与制冷设备；冷却能力下降后机房环境温度迅速升高。谷歌为避免设备在高温环境下损坏，主动关闭主机、存储集群与网络交换机。这是第三方设施供电链路的外部故障，非谷歌自身软件或配置错误。受影响机房由第三方设施 provider 运营，确切设施位置谷歌未完全披露。
放大因素
- 谷歌采取「热保护主动关机」策略，虽保护硬件，但停机时长由物理环境恢复决定，无法快速回滚
- 受影响三项服务（VMware Engine / NetApp Volumes / Bare Metal Solution）均依赖同一机房供电与制冷，单点故障横向击穿
- 控制平面操作（新建存储池、存储卷、备份）也随机房失效而失败，恢复链路本身受阻
- 仅多区域部署客户可切备用站点，单区域关键负载无规避手段
缓解措施
- 与第三方设施 provider 协作恢复主用供电与制冷，使环境温度回到安全操作水平
- 现场与远程团队按「网络架构→存储节点→计算集群」受控顺序逐步启动并校验
- 运行自动化恢复 playbook 恢复底层网络交换机与路由，使存储与计算集群受控上线
- 公告中建议多区域部署客户将流量路由到备用站点
经验教训
- 即便头部云厂商，区域级供电/制冷仍是「单点」：多可用区冗余不覆盖设施层上游电网故障
- 热保护主动关机是正确的工程决策，但意味着恢复必须等环境稳定，停机时长由物理恢复节奏决定
- 控制平面与数据平面同机房强耦合，制冷失效时连「创建备份」都无法操作，放大恢复难度
- 单区域关键负载必须有多区域或多供应商兜底
检查清单
- 评估关键负载是否依赖单一可用区的设施层（供电/制冷）
- 确认热保护关机后的受控重启顺序与校验 playbook 已就绪
- 关键路径做多区域部署，可切备用站点
- 控制平面操作（备份/快照）避免与数据平面同机房强耦合