摘要
2026 年 9 月 1 日，Google Cloud 美国中部 us-central1-b 区域的一个可用区发生部分服务中断，持续约 4 小时 11 分钟（07:41–11:52 PT）。官方服务健康报告披露根因为：例行硬件维护期间一名工程师程序错误，在 13 分钟内依次拔掉了该区所有路由设备的 100% 网络光纤路径，使物理层冗余被一次性全失效击穿，导致该区部分资源严重网络降级与资源隔离，峰值流量掉率达 100%、虚拟机不可达、丢包升高。本次无数据丢失。本事件归为人为类（human），严重度 p1。
时间线
2026-09-01 07:41 PT中断开始；例行硬件维护中，光纤拔除动作启动
2026-09-01 07:41–07:54 PT程序错误导致在 13 分钟内依次拔掉受影响路由设备的全部光纤路径，物理链路被 100% 断开
2026-09-01 中断期间该区虚拟机之间仍可互相通信，但外部用户无法访问，出现严重网络降级、资源隔离与丢包；流量掉率在峰值达 100%
2026-09-01 检测后Google 将流量从失联路由器迁走，区域内健康容量自动接管，缓解影响范围
2026-09-01 处置中技术人员定位到断开的光链路，物理重插光纤
2026-09-01 11:52 PT物理链路完全恢复，流量恢复正常，容量重新投入服务；全程无数据丢失
根因
Google Cloud 官方服务健康报告给出的根本原因：在例行硬件维护程序中，一名工程师在物理维护动作里「无意中断开了网络光纤」。具体为一处程序错误（procedural error），使物理维护动作在 13 分钟内按顺序拔掉了受影响设备上跨所有设备的 100% 光纤路径。动作速度过快，以致「错误操作」的告警在链路被完全断开前未能送达该工程师。
Google 的数据中心设计本具备跨多路由设备的冗余，且设备与光纤路径在物理上分离、接入不同电源，可抵御单设备 / 单光纤及大多数双 / 三重复合故障。但本次维护动作一次性移除了该区全部光纤路径，冗余设备因失去与外部网络连接的上联链路而无法补偿——物理层全失效击穿了所有冗余假设。
放大因素
- 维护程序缺少「禁止同时移除全部光纤路径」的硬约束与二次确认，单人在 13 分钟内即可击穿整区冗余。
- 拔出动作速度超过告警触达速度，缺乏「链路全部断开前」的熔断 / 拦截机制。
- 受影响区虚拟机的南北向流量（外部访问）完全中断，依赖单区部署的工作负载直接失联；东西向（区内 VM 互访）仍通，但用户无外部管理通道。
- 区域级冗余设计默认「故障分散在独立路径」，未覆盖「同一次人为动作移除全部路径」这一相关故障（common-mode）场景。
缓解措施
- Google 检测后先将流量从失联路由器迁走，由区域内其他健康容量承接可达流量，限制故障外溢。
- 技术人员定位断开的光链路并物理重插光纤，链路恢复后流量归一、容量回投。
- 官方表示将加强维护流程审核与人员培训，防止同类物理层误操作重演（据后续报道，新增强制同侪复核与链路状态突变自动告警等 safeguard）。
经验教训
- 物理层冗余不能假设「故障彼此独立」；变更管理须显式覆盖 common-mode 人为场景（一次动作移除全部路径）。
- 涉及物理线缆 / 上联链路的维护，必须设「禁止全断」硬门禁 + 同侪复核 + 链路状态突变即时告警，速度需慢于告警触达。
- 单可用区部署的关键负载在区级网络中断时即整体失联，跨区部署与带外管理通道（out-of-band）是客户侧必选项。
- SRE 的自动重路由能限制区域外溢，但无法保全「恰在受影响区」的工作负载——容灾责任在甲乙双方。
- 参考：Google Cloud 服务健康报告（us-central1-b，2026-09-01）；The Register 报道。
检查清单
- 物理线缆 / 上联链路维护是否有「禁止全断」硬门禁与同侪复核
- 链路状态突变是否有即时告警且触达速度快于人为动作速度
- 变更流程是否覆盖 common-mode 人为故障（一次动作移除全部路径）
- 关键负载是否跨可用区部署并保留带外管理通道
- 是否定期演练应用故障转移与数据库恢复（而非仅依赖云商区域冗余）
- 是否将云商事件报告与内部恢复目标（RTO/RPO）逐项比对复核