摘要
2026 年 9 月 1 日，Google Cloud 可用区 us-central1-b 部分计算资源发生网络服务降级与实例隔离，持续时间 4 小时 11 分钟（07:41–11:52 PT）。根因为例行硬件维护（数据中心路由器扩容）期间流程错误，工程师在 13 分钟内依次拔掉相关路由设备的全部光纤连接（含冗余链路），导致该区域部分计算资源与外部网络失联。影响 GCE、GKE、Cloud Run、App Engine、Cloud SQL、BigQuery、VPC 等多款产品。谷歌已发布初步事故报告，最终报告待出。
时间线
2026-09-01 07:41 PT工程师在 us-central1-b 对数据中心路由器执行例行容量扩容维护，开始断开光纤
2026-09-01 07:41–07:54 PT13 分钟内依次拔掉相关路由设备的全部光纤连接（冗余链路亦未能幸免），警告未及传达到工程师
2026-09-01 07:41 PT自动网络丢失监控与主动探测立即发现异常，网络工程与事故响应团队介入
2026-09-01 期间工程团队将兼容工作负载流量自动疏散至区域内健康容量；现场技术人员定位并重新接回断开的光纤
2026-09-01 09:19 PT谷歌通报底层网络已恢复
2026-09-01 11:52 PTCloud Run / App Engine 等残余业务完全恢复，事件结束（总时长 4h11m）
根因
例行硬件维护（数据中心路由器扩容）期间，流程错误导致工程师在 13 分钟内依次拔掉相关路由设备的全部光纤连接。网络架构按设计可承受单设备/单光纤乃至多数双/三故障，且设备与光纤路径在物理上彼此分离、供电来源不同。但本次维护动作顺序断开了 100% 光纤路径，加之动作速度快、警告未能在全部连接断开前传达到工程师，致使 us-central1-b 部分计算容量与外部网络隔离，虚拟机无法被外部访问、亦无法连接区域外资源。
放大因素
- 冗余设计假设"单/双/三设备故障不影响客户流量"，但本次为流程性顺序全断，超出设计容错边界。
- 维护动作速度快（13 分钟内完成），警告机制未能在动作完成前实时触达执行人。
- 受影响区域承载着 GCE、GKE、Cloud Run、Cloud SQL、BigQuery、VPC 等多产品流量，网络隔离被放大为多产品级中断。
缓解措施
- 自动网络监控与主动探测在故障发生后立即发现异常。
- 工程团队将兼容业务流量自动转移/疏散至区域内健康容量。
- 现场硬件运维人员物理重新接回断开的光纤链路。
- 链路恢复、流量正常后，工程团队将流量切回，恢复相关资源服务。
- 谷歌发布 preliminary incident report，承诺 final report 含预防措施。
经验教训
- 物理维护流程需增加"断开前二次确认/断路器"机制，防止顺序全断冗余链路。
- 冗余链路在物理上须与维护动作强隔离，且警告须在动作完成前实时触达执行人。
- 维护窗口的自动化防护（如光纤断开速率限制、批量操作审批）应纳入变更管理。
- 跨产品依赖须在区域级故障时有更细粒度的故障隔离与快速疏散策略。
检查清单
- 维护流程是否对"全部光纤/电源路径断开"类动作设硬性二次确认
- 警告/拦截机制是否在物理动作完成前实时触达执行人
- 冗余链路是否物理隔离，避免单流程顺序全断
- 变更管理是否覆盖路由器扩容等硬件维护的批量操作审批
- 区域级网络隔离是否有自动流量疏散与快速恢复演练
- 是否对 preliminary report 的 final report 预防措施做跟踪闭环