本文由犀思云技术团队共创从网络层视角探讨企业双活架构的韧性设计。事故信息据谷歌云披露与公开报道整理。9 月 1 日谷歌云一名工程师在数据中心路由器扩容期间于 13 分钟内依次拔掉了相关设备的全部光纤连接。不是黑客不是地震也不是什么惊天 bug。就是一次计划内的维护他为 us-central1-b 可用区内承载部分计算资源的路由器扩容时把相关设备的光纤连接一条接一条全部断开连冗余链路也没能幸免。要命的是那个机房是有冗余的多路由、多电源按最高可用标准建的。可这些冗余被这一次操作一勺烩了个干净。受影响资源一度与外部网络失联事件历时约 4 小时 11 分钟才陆续恢复。谷歌在披露中表示相关告警未能在连接全部断开前传达到工程师。看到这儿你可能想大厂翻车看个热闹。但真正值得后背发凉的是下一句——你公司里那些写着双活多活的系统很可能正踩着同一个坑只是还没到爆的那天。先搞懂一件事冗余为什么会归零我们买冗余图的是个安心这条断了还有那条。可这份安心藏着一个前提——这几条路不会因为同一件事一起坏。一旦有个共同的原因能把它们一起端掉冗余就在你最需要的那一刻瞬间变成零。谷歌这次的共同原因就是那一次维护多条物理上各走各的光纤、互为冗余的路由设备落进了同一双手、同一个时间窗于是一起没了。你有几条路不重要。它们会不会被同一件事一勺烩才重要。##真正该数的不是路径是故障域换个更实在的说法别数你有几条线数你有几个会一起坏的圈子。这个圈子工程上有个名字叫故障域。把冗余落进不同的圈子它才算数。而能把两条独立的路偷偷拽进同一个圈子的共同原因通常藏在四个地方。物理上两条备份线可能走同一根光缆、同一个机房入口、同一路市电操作上它们可能在同一个维护窗口、被同一个人、同一段脚本同时动到再往上一次配置推送、一条策略、一个配额能让跨区域的冗余一起翻车——很多全球性的云故障根子就在这儿最外面你把命都押在同一朵云、同一个地域上那这朵云本身就是一个故障域。##最坑的是那些看不见的绑定上面这些还算好查。真正阴的是你以为选了两朵互不相干的云做双活结果它们背地里共用同一套 DNS、同一个身份认证、同一条证书链甚至同一段海缆、同一家 CDN。平时风平浪静各走各的。真出事那天你才发现两条腿早就绑在同一根绳上了。打个更接地气的比方。你给核心系统拉了主备两条专线合同上白纸黑字双活。可这两条线出你机房走的是同一个弱电井进城并在同一段管道里。哪天一台挖掘机下去两条一起断。你花了两条线的钱命始终是一条。##比多买一条线更重要的是这两件事看懂了故障域你会发现很多人容灾的思路整个反了一出事就想着再买一条线。可有两件事比线的数量重要得多。**第一变更本身。**就是最大的风险源。这次的导火索不是设备老化是一次正常维护。现实里一大半重大故障都出在计划内的变更、割接、升级里——一次操作、一段脚本几分钟就能波及一大片。所以真正的护栏是分批做、跨故障域不许同时动、动手前告警能拦住人、出事能一键回滚。这些比多堆一份设备管用得多。**第二恢复得可预测。**谷歌这次是靠人跑去把光纤重新插回来才恢复的。这意味着恢复要多久全看运气——人多久到、多久判断对。真正的韧性是系统自己发现故障、自己把流量切到还活着的那条路你还全程看得见。同样是四个小时“自动切换、几分钟收敛和等人来救”是两个物种。一张图表测测你到底在哪一级很多公司觉得自己早做了双活。真拿尺子一量往往才发现停在半路L0 单点坏了就停L1 有备份但是冷的出事得手工拉起L2 热备可跟主用挤在同一个故障域里这就是前面说的假冗余共因一来一起完L3 主备落在不同故障域能切L4 跨云自动切还定期演练。扎心的是大量团队自评在 L3、L4一测实际在 L2。这里还有一句最容易被跳过、也最要命的话——没被演练过的冗余是薛定谔的冗余你只有在真出故障、打开盖子那一刻才知道它到底活没活。连谷歌都栽了你确定你那套跑得通最后把这五个问题甩给你的供应商不用等下次别人交学费。现在就可以拿这五个问题去问你的网络、云供应商也问问自己。五个问题里只要有一个答不上来你那套冗余就还没真正生效。##说到底可靠性是设计出来的不是买来的当然多云、多路径不是免费的午餐。它买来可靠性和韧性也带来复杂度和成本。真要处处双活最后可能没人管得动反而更复杂。聪明的做法是分级命脉业务交易、生产、合规链路做到跨故障域、能自动切重要业务退一档一般业务单域够用。把有限的钱花在一旦停摆最要命的那几个系统上。可靠性从来不是买来的一句承诺它是你一层一层、按轻重亲手设计出来的退路。谷歌这四个小时替整个行业交了学费。这周轮到你把自己的账对一遍了。我们长期研究企业多云网络与企业网络的韧性。想排查自己系统里有没有藏着的共因单点欢迎在评论区分享你的双活实践我们一起探讨。事故信息依据谷歌云 2026 年 9 月 5 日披露的维护操作事故说明us-central1-b 可用区2026 年 9 月 1 日发生历时约 4 小时 11 分钟公开报道参考云头条·新浪财经转载。欢迎转发请注明出处。 谷歌云 4 小时故障启示：你的网络“双活”，可能只是一个更贵的单点
本文由犀思云技术团队共创从网络层视角探讨企业双活架构的韧性设计。事故信息据谷歌云披露与公开报道整理。9 月 1 日谷歌云一名工程师在数据中心路由器扩容期间于 13 分钟内依次拔掉了相关设备的全部光纤连接。不是黑客不是地震也不是什么惊天 bug。就是一次计划内的维护他为 us-central1-b 可用区内承载部分计算资源的路由器扩容时把相关设备的光纤连接一条接一条全部断开连冗余链路也没能幸免。要命的是那个机房是有冗余的多路由、多电源按最高可用标准建的。可这些冗余被这一次操作一勺烩了个干净。受影响资源一度与外部网络失联事件历时约 4 小时 11 分钟才陆续恢复。谷歌在披露中表示相关告警未能在连接全部断开前传达到工程师。看到这儿你可能想大厂翻车看个热闹。但真正值得后背发凉的是下一句——你公司里那些写着双活多活的系统很可能正踩着同一个坑只是还没到爆的那天。先搞懂一件事冗余为什么会归零我们买冗余图的是个安心这条断了还有那条。可这份安心藏着一个前提——这几条路不会因为同一件事一起坏。一旦有个共同的原因能把它们一起端掉冗余就在你最需要的那一刻瞬间变成零。谷歌这次的共同原因就是那一次维护多条物理上各走各的光纤、互为冗余的路由设备落进了同一双手、同一个时间窗于是一起没了。你有几条路不重要。它们会不会被同一件事一勺烩才重要。##真正该数的不是路径是故障域换个更实在的说法别数你有几条线数你有几个会一起坏的圈子。这个圈子工程上有个名字叫故障域。把冗余落进不同的圈子它才算数。而能把两条独立的路偷偷拽进同一个圈子的共同原因通常藏在四个地方。物理上两条备份线可能走同一根光缆、同一个机房入口、同一路市电操作上它们可能在同一个维护窗口、被同一个人、同一段脚本同时动到再往上一次配置推送、一条策略、一个配额能让跨区域的冗余一起翻车——很多全球性的云故障根子就在这儿最外面你把命都押在同一朵云、同一个地域上那这朵云本身就是一个故障域。##最坑的是那些看不见的绑定上面这些还算好查。真正阴的是你以为选了两朵互不相干的云做双活结果它们背地里共用同一套 DNS、同一个身份认证、同一条证书链甚至同一段海缆、同一家 CDN。平时风平浪静各走各的。真出事那天你才发现两条腿早就绑在同一根绳上了。打个更接地气的比方。你给核心系统拉了主备两条专线合同上白纸黑字双活。可这两条线出你机房走的是同一个弱电井进城并在同一段管道里。哪天一台挖掘机下去两条一起断。你花了两条线的钱命始终是一条。##比多买一条线更重要的是这两件事看懂了故障域你会发现很多人容灾的思路整个反了一出事就想着再买一条线。可有两件事比线的数量重要得多。**第一变更本身。**就是最大的风险源。这次的导火索不是设备老化是一次正常维护。现实里一大半重大故障都出在计划内的变更、割接、升级里——一次操作、一段脚本几分钟就能波及一大片。所以真正的护栏是分批做、跨故障域不许同时动、动手前告警能拦住人、出事能一键回滚。这些比多堆一份设备管用得多。**第二恢复得可预测。**谷歌这次是靠人跑去把光纤重新插回来才恢复的。这意味着恢复要多久全看运气——人多久到、多久判断对。真正的韧性是系统自己发现故障、自己把流量切到还活着的那条路你还全程看得见。同样是四个小时“自动切换、几分钟收敛和等人来救”是两个物种。一张图表测测你到底在哪一级很多公司觉得自己早做了双活。真拿尺子一量往往才发现停在半路L0 单点坏了就停L1 有备份但是冷的出事得手工拉起L2 热备可跟主用挤在同一个故障域里这就是前面说的假冗余共因一来一起完L3 主备落在不同故障域能切L4 跨云自动切还定期演练。扎心的是大量团队自评在 L3、L4一测实际在 L2。这里还有一句最容易被跳过、也最要命的话——没被演练过的冗余是薛定谔的冗余你只有在真出故障、打开盖子那一刻才知道它到底活没活。连谷歌都栽了你确定你那套跑得通最后把这五个问题甩给你的供应商不用等下次别人交学费。现在就可以拿这五个问题去问你的网络、云供应商也问问自己。五个问题里只要有一个答不上来你那套冗余就还没真正生效。##说到底可靠性是设计出来的不是买来的当然多云、多路径不是免费的午餐。它买来可靠性和韧性也带来复杂度和成本。真要处处双活最后可能没人管得动反而更复杂。聪明的做法是分级命脉业务交易、生产、合规链路做到跨故障域、能自动切重要业务退一档一般业务单域够用。把有限的钱花在一旦停摆最要命的那几个系统上。可靠性从来不是买来的一句承诺它是你一层一层、按轻重亲手设计出来的退路。谷歌这四个小时替整个行业交了学费。这周轮到你把自己的账对一遍了。我们长期研究企业多云网络与企业网络的韧性。想排查自己系统里有没有藏着的共因单点欢迎在评论区分享你的双活实践我们一起探讨。事故信息依据谷歌云 2026 年 9 月 5 日披露的维护操作事故说明us-central1-b 可用区2026 年 9 月 1 日发生历时约 4 小时 11 分钟公开报道参考云头条·新浪财经转载。欢迎转发请注明出处。