3毫秒的电压跌落，对于普通用电设备来说几乎可以忽略不计。

　　但2026年7月16日发生在荷兰Eemshaven的Google Cloud事故告诉我们：一次3ms的上游电网电压瞬态，最终却演变成了持续近15小时的云服务中断。

　　本次事故真正值得国内数据中心行业研究和警惕的是：为什么一个毫秒级外部扰动，能够连续穿透电力、备用电源、配电、冷却控制、冷却冗余、IT保护和人工恢复等多层防线？

　　本次事故原因

　　先说结论：

　　首先需要知道，3毫秒只是触发器，而不是15小时事故背后的真正原因。

　　真正原因远比想象中要复杂，深入挖掘会发现，本次事故是由外部电网扰动与数据中心自身多个问题叠加，形成电力与冷却两条事故线路，并最终共同作用于IT系统。　　

本次事故链路图

　　重点包括：

　　A/B两路市电存在共同上游

　　A侧DRUPS部件故障，备用电源未完整接管

　　实际IT负载部署与设计预期存在偏差

　　控制节点掉线，分配泵未自动重启

　　部分冷却冗余因已知施工不可用

　　可以看到，这些问题国内数据中心在运营中基本都存在，后面将带着疑问逐一解读。

　　本次项目背景

　　Google在荷兰运营着多个数据中心。本次事故发生在Google Cloud europe-west4-a环境，位于荷兰Eemshaven。

　　根据Google Cloud官方事故报告，受影响的包括GCVE、BMS和GCNV等多项业务，整体服务影响窗口达到14小时55分钟。

　　事故发生后，前期公开资料中有两个关键背景信息值得关注。

　　1. A/B双路市电上连同一变电站

　　公开资料显示，数据中心AB路两个连接均与TenneT的Robbenplaat 220kV变电站有关。从数据中心内部看，A/B是两条供电路径。但从更上游的电网来看，两条路径仍存在共同的上游依赖，可能只是两个不同的间隔。

　　也就是我们一直在说的“单节点”和“假双路”，这也是AB路同时受到电气扰动的原因。　　

双路供电示意图

　　2.施工导致冷却冗余降级

　　事故发生时，数据中心正在进行已知施工。Google明确表示，冷却系统的冗余备用源当时不可用，这也是冷却系统整体失效的一个重要原因。但目前公开信息不足以确认施工具体涉及哪一套冷却设备。

　　事故过程深度解读

　　前面已经介绍，本次事故实际上存在电气和冷却两条故障线路。初期由于电气问题导致部分机柜掉电，后期由于冷却问题导致IT设备保护性关机。作为从业人员，面对本次故障，一定有很多疑问？

　　问题1：上级电网发生了什么？

　　Google最终事故报告给出了一个关键表述：“An electrical fault occurred on the utility grid upstream of the data center”，即数据中心上游公用电网发生了一次电气故障。

　　准确的事故链条是：上游电网发生电气故障→ 出现约3ms电压瞬态 → 数据中心侧保护动作 → 备用电源开始接管。

　　至于电网究竟发生了什么具体故障，目前公开资料并不足以确认。因此不能进一步断言是雷击、短路、线路故障、变电站设备故障或其他具体原因。

　　问题2：双路供电为什么没有挡住事故？

　　公开资料显示，数据中心原有一条375MVA供电线路，又新增了一条375MVA供电线路作为备用，但均与TenneT的Robbenplaat 220kV变电站有关。

　　这种供电方式可以防御单路线路、单路设备或局部故障，但无法天然防御共同上游故障。Google官方报告明确指出，同一个上游电压瞬态同时影响了A、B两路市电。

　　所以，虽然真实存在双路供电，但双路只是两个路由，并不是上联两个完全独立的变电站、电网。国内早期数据中心很多都有类似的假双路情况。

　　问题3：备用电源有没有接管？

　　正常情况下，即使市电受到扰动，也应该通过DRUPS等备用电源系统承接过渡供电。

　　本次事故中，B侧DRUPS成功接管；A侧则由于电气部件故障，未能成功接管。

　　于是事故从“电网扰动”升级为“电网扰动+部分备用电源故障”，A侧必须寻找新的供电路径。

　　问题4：事故初期为什么部分机柜掉电？

　　A侧DRUPS接管失败后，有3排机柜受到影响，需要将供电从A路转移到B路。

　　结果是：第1排和第2排转换成功，第3排发生过载保护断路器跳闸，导致两路电源同时丢失。

　　更准确的表述是：A侧故障后，原A侧负载需要由B侧承接；如果实际负载部署与设计预期存在偏差，B侧可能无法完整承接。

　　Google指出，相关原因与实际负载部署和预期部署不一致有关。这体现了“设计冗余”和“有效冗余”的区别。

　　举个例子：

　　正常部署：A路+B路<100%；

　　A路故障时：A路0%，B路<100%。

　　非正常部署：A路+B路>100%；

　　A路故障时：A路0%，B路>100%。

　　如果A路+B路实际负荷大于B路可承载负荷，那么故障转移本身，就可能成为第二次故障。这也是设计冗余和有效冗余的区别。

　　数据中心上架和运行过程中，电气运维专业不仅要关注基础设施情况，也要关注IT系统负载均衡情况。

　　问题5：事故为什么扩大了？

　　如果事故只停留在电力系统，影响可能没有这么严重。真正让事故进一步升级的，是冷却系统同时出现异常。

　　Google报告显示，在3ms电压瞬态发生期间，Chiller Controller掉线。这里需要注意：不是简单的冷机掉电，而是控制系统或者控制模块掉线。

　　冷机本身仍有电，但冷冻水分配泵没有重新启动，于是没有有效水流，冷却能力下降，数据大厅温度持续升高，最终超过44℃，服务器和网络设备开始陆续执行保护性关机，事故最终扩大化。

　　问题6：为什么没有第一时间手动启动泵？

　　事故发生后，最终通过人工将水泵从Auto切换到Hand模式，恢复水循环和冷却系统。16:24发生的事故，冷却系统直到21:05才完全恢复。

　　那么问题来了：既然人工切换可以恢复，为什么不是第一时间完成？

　　Google没有公开细节，是告警太多影响事故的判断，还是第3排断电运维人员都去抢通业务，还是安全联锁等原因，我们无法判断，还需进一步调查，但从Google整改计划的指向性似乎能看出一些端倪：

　　电力事件监控

　　冷却异常早期告警

　　热失控自动关机

　　重大事件人员可用性

　　应急手册

　　联合演练

　　这似乎说明：运维管理从发现、判断、应急到联动都存在一些问题，而不只是冷却控制系统的冗余与恢复机制需要重新审视。

　　问题7：为什么备用冷源没有起到作用？

　　正常情况下，即使主冷却系统出现问题，还应存在备用冷却能力。Google明确表示，因为设施正在进行已知施工，冷却系统的冗余备用源（并没有说明是哪一套）当时不可用。这意味着事故发生时冷却系统处于冗余降级状态。

　　目前公开资料不足以确认是2N降为N还是N+1降为N，也不足以确认施工具体涉及哪些具体设备。只有公开资料显示Google在Eemshaven的Oostpolder区域确实正在推进扩建项目。

　　这意味着，整个施工阶段数据中心的冷却系统都处于降级状态，这也是很多数据中心的常态，也是最容易被忽视的状态，包括：

　　设备维护

　　配电检修

　　UPS维修

　　蓄电池放电试验

　　冷机维护

　　控制系统升级

　　扩建施工

　　问题8：为什么冷却恢复后业务不能立即恢复？

　　这是很多非数据中心行业人士最容易误解的一点：基础设施恢复不等于业务恢复，业务恢复本质上是一个多系统、分阶段的恢复过程，需要经历电力恢复、冷却恢复、环境恢复、网络恢复、存储恢复、计算恢复和业务恢复等多个阶段。　　

数据中心业务恢复过程

　　即使是第3排发生的保护性跳闸，恢复时也需要多个环节的确认。必须先确认故障已经消失，否则强行合闸可能导致再次过流、再次跳闸，甚至设备损坏。

　　因此，一个毫秒级事件可以产生小时级恢复。触发时间很短，但恢复过程本身可能非常长。

　　事故根本原因

　　本次事故看似简单，但实际是一次非常复杂、多种因素造成的连锁事件，完整的事故链如下：　　

本次事故防线分层

　　真正的冗余，不是设计图纸和现场有多少套设备，而是在最坏的那个时刻，有多少真正可用。

　　这起事故真正值得记住的，不是3毫秒导致Google宕机15小时，而是一次毫秒级外部扰动如何通过多个系统的连续失效，最终演变成小时级业务中断。