摘要
2026-07-23，Microsoft Azure 美国西部（US West）云区域发生约 5 小时的网络连接中断。完全运行于该区域内部的服务未受影响，但所有进出该设施的流量中断，波及 Azure Kubernetes Service、Cosmos DB、Databricks、AI Search、API Management、Monitor、Virtual Desktop、Microsoft Graph、Sentinel、Power BI Embedded、VPN Gateway、ExpressRoute 等众多服务。微软事后发布初步事故复盘（PIR），根因为一次例行网络设备维护中，自动化系统错误扩大隔离范围、误删了未在初始评估中的一组 IP 路由。
时间线
14:44 UTC美西区域网络连接中断开始（太平洋时间 07:44），进出流量受影响
17:45 UTC开始回滚维护变更
18:26 UTC网络完成恢复、回到健康状态
19:41 UTC所有受影响服务全部恢复（持续约 4 小时 57 分）
维护执行中 - 请求转换系统出现 Bug，将额外设备误标为本次维护对象，从更多设备删除了 IP 路由
约 15:44 UTC - 工程师在事故发生后 1 小时内定位问题
根因
事故源于一次例行网络设备维护，需要隔离特定网络路径。正常流程下，维护请求会被转换为系统可读请求，并校验两条冗余路径中至少一条保持正常，维护前还需通过安全检查。但本次请求转换系统出现 Bug，错误地将额外设备标记为维护的一部分，导致一组 IP 路由从比预期更多的设备上被移除。这些路由位于 Azure 美西数据中心与广域网（WAN）之间，因此切断了进出该区域的网络流量。故障最初表现为 Azure 广域网大规模路由震荡。
放大因素
- 自动化越界：转换系统 Bug 使隔离范围超出人工评估，误删未纳入评估的路由。
- 冗余假设失效：虽确认至少一条冗余路径正常，但自动化实际波及了更多设备，破坏面超出预期。
- 影响面集中：被删路由处于数据中心与 WAN 之间，直接切断全部进出流量，而非局部服务。
缓解措施
- 17:45 UTC 起回滚维护变更，18:26 UTC 网络恢复，19:41 UTC 全服务恢复。
- 微软表示将对安全检查、自动化维护请求变更流程展开全面分析。
- 建议承载关键数据的企业采用多区域（multi-region）部署，降低单区域故障的整体影响。
经验教训
- 变更自动化必须有严格的爆炸半径（blast-radius）校验，转换系统 Bug 不应导致隔离范围越界。
- 冗余路径的"至少一条正常"假设需在自动化执行层被强制校验，而非仅停留在人工评估。
- 网络层路由删除属于高危操作，须有 dry-run 与可一键回滚的 runbook。
- 多区域部署是应对单区域网络中断的有效兜底，但不能替代变更安全。
检查清单
- 维护请求的自动化转换是否有范围校验与人工二次确认？
- 隔离操作的实际设备集合是否等于评估集合（防越界）？
- 冗余路径在自动化执行时是否被强制校验仍可用？
- 高危路由变更是否有 dry-run 与即时回滚预案？
- 关键业务是否具备跨区域故障转移能力？