作者：多云行者 联合 犀思云共创 事故数据引自 Google 官方事故报告与公开报道
摘要：谷歌云 us-central1 因一次维护误操作在 13 分钟内顺序断开全部光纤，宕机约四小时。本文从可用度模型出发，解释“有冗余为何还会全断”：共因失效让可用度被共因概率封顶；并系统梳理故障域四层共因、三平面隐藏耦合、爆炸半径设计、MTTR 自愈闭环、成熟度分级与接入/跨云层的工程落地。
先说一个反直觉的观察：这次值得架构师认真对待的，不是“谷歌也会翻车”，而是它翻车的方式，一个有多路由、多电源冗余的可用区，被一次操作在 13 分钟里清零。
2026 年 9 月 1 日，谷歌云 us-central1-b 在例行硬件维护中，因一次不合规操作顺序断开全部光纤路径，导致该可用区对外连通峰值丢包 100%，约四小时后随光纤重插、流量自动重路由恢复。谷歌把根因归为流程不合规与执行速度叠加，动作太快，纠错告警未能在完全断开前触达操作者。作为长期做网络与容灾的人，我把它当成一份难得的公开复盘样本，从故障域的角度完整拆一遍，并尽量落到可执行的工程结论。
技术复盘：相关性故障如何击穿独立冗余
数据中心按高可用设计，具备跨多路由设备、多电源的冗余，其可用度模型的数学前提是各路径失效相互独立。这次操作制造的，恰恰是一次教科书级的相关性故障：一个操作者、一套动作，把本应彼此独立的所有路径顺序清零，独立性一旦被共因打破，可用度就从“并联”塌缩为“串联”。
有一个值得反复强调的量化直觉：N 条冗余路径的系统可用度并非 1−(1−a)^N；一旦存在共因 c，可用度被 (1−P(c)) 这一项封顶，共因概率成为可用度的上界，与冗余度多高几乎无关。这条结论有一个直接的工程含义：容灾投入的正确方向，是把共因概率降下去，让物理、变更、控制、供应商彼此“去相关”，而不是无脑再加一条冗余。加冗余只在故障独立时才线性收益，撞上共因就一分钱也换不来。此外，护栏没能在“全部断开”这一不可逆状态达成前介入，说明护栏的响应速度也是韧性的组成部分，而不只是设备层的冗余度。
用一个最简模型说清楚这件事。设单条路径可用度为 a，N 条相互独立的冗余路径，系统不可用需要它们同时失效：
无共因： A_sys = 1 − (1 − a)^N // 随 N 增大迅速趋近 1
有共因 c：A_sys ≤ 1 − P(c) // 被共因概率封顶，与 N 几乎无关
所以真正决定上界的，不是你堆了几条冗余，而是 P(c)，那个能同时打掉所有路径的共同原因的发生概率。
图1｜可用度模型：共因概率 P(c) 成为系统可用度的天花板，堆冗余也无法突破
故障域分析：韧性的第一性问题
评估韧性的正确起点，不是“有几条冗余”，而是“这些冗余覆盖了几个相互独立的故障域”。故障域即“会因同一原因一起失效”的范围，其共因来源可归纳为四层：
- 物理载体：同缆、同管道、同机房入口、同电力分区。
- 变更操作：同维护窗口、同操作者、同一自动化脚本的爆炸半径，最常被排除在容灾模型之外，却是本次的直接根因。
- 控制平面：同一次配置、策略或配额推送可跨区域同时生效，是许多“全局性”故障的根因层，也是逻辑上最难隔离的一层。
- 区域 / 供应商：单地域、单云、单运营商本身即一个故障域。
任何一条备份路径，只要与主路径共享上述任一共因，在该共因触发时都会一起失效。
网络隐藏耦合：三个平面都要独立
与四层共因并列的，是依赖平面的隐藏耦合。数据平面两条路径独立，不代表控制平面与管理平面独立：跨可用区乃至跨云的部署，可能仍共享同一个身份认证体系、同一套 DNS、同一条证书信任链、同一个时间同步源，或同一个变更编排平台。真正的故障域隔离，要求在数据、控制、管理三个平面上分别核验独立性。与其事后复盘，不如把它做成一张核验表，逐平面对主备过一遍，下面这张表列出了每个平面“独立”的判据、最常被忽略的共享点，以及对应的隔离动作。
图2｜三平面独立性核验：数据 / 控制 / 管理平面各自的隐藏共享点与隔离动作
将维护变更纳入故障域：给事故半径设上限
这次事故最该被行业吸收的一点，是把“变更”正式纳入故障域建模，并把“爆炸半径”当成一个可量化的设计指标，一次变更最坏能同时影响几个单元，应该在设计时就有明确上限。对策不是要求操作者更小心，而是从架构上把这个上限压下来：单元化（cell-based）与分区隔离，把系统切成互不影响的小单元；变更按单元分批、灰度发布，跨故障域串行而非并行；关键路径设“不可同时操作”约束；在不可逆步骤前置告警与熔断；并保证可快速回滚。一句话，变更管理不是流程合规的附属品，而是可用度模型里的一个显式变量。
图3｜爆炸半径控制：单元化 + 灰度 + 跨域串行，把最坏影响面限定在一个单元
恢复的确定性：MTTR 不该靠“人重插光纤”
高可用由 MTBF 与 MTTR 共同决定，而 MTTR 的关键在于“可预测”。把 MTTR 拆开看，它是“检测 + 决策 + 切换 + 收敛”四段之和，四段里方差最大、最不可控的恰恰是“决策”，因为它最依赖人到场与判断。这次的恢复路径是人工重插光纤后流量自动重路由，重路由是自动的，触发恢复的动作却是人工的，于是恢复时间被“人”这一段拖到不可预测。要压低并收敛 MTTR，就得把这几段尽量交给系统：故障的自动检测（而非告警风暴后的人工确认）、到健康故障域的自动重路由（而非人工切换）、以及逐流逐路径的实时可视（让切换有依据、让定位以秒计）。可视化不是锦上添花，它直接决定了故障域切换的置信度与速度，看不见的网络，切换只能靠猜。
图4｜MTTR 自愈闭环：靠人恢复方差大，自动检测→重路由→可视才可预测
成熟度与验证：没演练过的冗余不算冗余
把上述要求落成一把成熟度尺子：
L0 单点 / L1 冷备：无冗余，或有备份但需人工拉起。
L2 同域热备：看似双活，实为假冗余，主备同处一个故障域。
L3 跨故障域主备：主备落在不同故障域，可切换。
L4 跨云自愈：跨云自动切换并定期演练验证。
多数团队自评在 L3–L4，实测常在 L2。而最容易被跳过的一环是验证：没有被演练过的冗余是“薛定谔的冗余”，只有在真出事那一刻才知道有没有生效。谷歌有世界级冗余设计尚被一次操作击穿，正说明设计不等于兑现，应以定期切换演练与故障注入（混沌工程）持续证明故障域的独立性与切换的确定性。
图5｜容灾成熟度 L0–L4 × 冗余形态 / 切换方式 / RTO / 演练验证
混合云组网工程落地：接入与跨云层的参考做法
云数据中心内部的可靠性交给云厂商；而企业到云、云到云、站点到站点这一段，可以按“每一层都摆两个相互独立的故障域”来设计，做到任一层出现单点失效都能自动切到另一域。分三层看（对应图 6）：
接入层：站点侧用双 CPE，两条上联分别走不同光缆、不同机房入口、接入不同的 POP（图中 POP-1 与 POP-2）。这样接入侧本身就是两个独立故障域，而不是“一根线的两个逻辑通道”——挖断一根光缆、一个机房入口停电，只影响其中一条。
骨干层：主备在 SDN/SRv6 骨干上做路径分集——path A 经 POP-1→POP-3、path B 经 POP-2→POP-4，两条路径全程不复用任何中间节点与链路。因此单个 POP 或单段骨干链路故障，只会打掉其中一条路径，另一条仍在。
云层：经 NNI 预连接多朵云，关键业务跨云部署，把“单云失效”从灾难降级为一次调度。
三层叠加，端到端就得到两条真正独立的故障域路径（图中 A 为主用、B 为备用/多活）：接入、骨干、云任意一层出现单点失效，都只影响一条路径，业务自动切到另一条，而不是“名义双活、一断全断”。再以 iFIT 随流检测提供端到端逐流可视，让切换有依据、定位以秒计。落地按业务分级投放——命脉链路做到 L3–L4 的跨域自动切换，一般业务单域即可，避免一刀切的成本浪费。
图6｜端到端两条独立故障域：接入（双CPE/不同光缆入口/不同POP）、骨干（SRv6 路径A、B 不复用节点）、云（多云 NNI）三层均不复用，任一层单点失效自动切换，iFIT 全程可视
五个需要自检的问题，厘清分工与边界
无论自建还是选供应商，有五个问题最能照出韧性的真实水平：
- 冗余落在几个相互独立的故障域？
- 一次变更最坏影响多大范围、有哪些护栏？
- 故障切换是自动还是人工、RTO / RPO 是多少？
- 多久做一次真实切换演练、有没有记录？
- 主备是否共享隐藏依赖（缆、云、DNS、IAM、证书）？
最后必须厘清分工，否则方案会落空。云数据中心与可用区内部的可靠性属于云厂商域内，这次机房光纤事故就在这个域内，接入侧的任何设计都无法、也不应承诺替其兜底。可被工程掌控的，是接入与跨云这一层：把主备做到物理路由与故障域独立、切换交给系统、状态全程可视，降低的是“接入单点”与“单云依赖”两类风险。看清这条边界，哪些交给云厂商、哪些自己扛，方案才长期可兑现。
延伸问题总结
- 这次谷歌云故障的根因是什么？
据 Google 官方事故报告，2026-09-01 us-central1 一次不合规维护操作在 13 分钟内顺序断开全部光纤路径，绕过了数据中心的多路由/多电源冗余，导致该可用区对外连通峰值丢包 100%，约四小时后恢复；根因为流程不合规与操作过快叠加。
- 有冗余为什么还会全断？
冗余的有效性以各路径故障相互独立为前提。当一个共因（同一次操作、同缆、同变更窗口、同控制面策略）能同时影响所有路径时，可用度从并联塌缩为串联，并被共因概率封顶，与冗余度无关。应评估的是故障域的独立性，而非路径数量。
- 什么是故障域？常见共因有哪些？
故障域指“会因同一原因一起失效”的范围。常见共因分四层：物理载体（同缆/同入口/同电力）、变更操作（同窗口/同操作者/同脚本）、控制平面（同配置/策略/配额推送）、区域与供应商（单地域/单云/单运营商）；此外还需核验数据、控制、管理三平面的隐藏依赖耦合（DNS/IAM/证书/时钟等）。
- 企业侧能做哪些工程化措施提升接入韧性？
让主备跨越共因：物理路由与 POP 分离、关键业务跨云部署、以 BGP full-mesh 与 SDN/SRv6 提供多路径与快速重路由、以随流检测实现秒级定位与自动切换；把变更管理（分批、灰度、跨域串行、告警前置、可回滚）纳入设计；并按业务分级投放、以演练持续验证。
- 网络 / NaaS 服务商能替云厂商的机房故障兜底吗？
答：不能。云数据中心与可用区内部可靠性属于云厂商域内。WAN / NaaS 层降低的是接入侧与跨云侧的单点风险，使业务在某朵云或某条链路失效时具备切换与重路由能力。
参考资料
· Google Cloud 官方事故报告与状态页（us-central1，2026-09-01，07:41–11:52 PT 口径）；The Register 等公开报道。
· Google《Site Reliability Engineering》：关于相关性故障（correlated failures）、爆炸半径与无指责复盘（postmortem）的工程实践。
· IETF RFC 9197（In-situ OAM / 随流检测）：逐流、逐路径的实时可视化能力参考。
