返回档案库

案例库 · 软件与 IT · 技术决策 · 2026

一次维护 bug 把西美数据中心切出网络,Microsoft 365 瘫痪了五个小时

微软维护请求层里的一个 bug 把变更扩大到意图之外,移除了 IP 路由,切断了一个西美数据中心。

Microsoft · 2026-07-23

怎么回事

2026 年 7 月 23 日,美国东部时间上午 10 点 44 分到下午 3 点 41 分,Microsoft 365 以及一大部分 Azure 服务停机近五个小时(事故编号 MO1437424)。Teams、SharePoint Online、OneDrive、Admin Center、Power Automate、Copilot Chat 以及 Loop 的服务全部降级,Azure App Service、Application Gateway、Cosmos DB、AKS、ExpressRoute、Virtual WAN 等也一并故障。

根因是编码在自动化里的一项决策。一个软件层把人类维护请求转译成机器可读指令,而这次转换里的一个 bug 错误地把额外的网络设备标记为维护范围的一部分。结果是从比授权更多的设备上移除了 IP 路由,把一个西美数据中心从广域网上切了下来。

这次故障骗过了微软自己的安全门:这道检查评估的是那个有 bug 的转换输出,而不是工程师的原始意图,因此它校验了错误的范围并放行了。用户提交了 2,403 份 Downdetector 报告——是 29 次基线的 83 倍——至少 19 个下游 SaaS 服务跟着发生了级联停机,其中 16 个在微软宣布恢复后仍然开着。

这次事故给一个糟糕的季度收了尾:2026 年第一季度,Microsoft 365 交付了 99.526% 的运行时间,是 2013 年开始报告以来的最低水平。最说明问题的缺口不是那个 bug,而是那道安全检查——它核验的是机器产出的东西,而不是人想要的东西——一次没有任何检查清单抓到的自动化故障。

为什么会这样

  • 微软自动化了维护请求转译,而转换层里的一个 bug 悄悄扩大了变更范围
  • 安全门校验的是有 bug 的输出,而不是工程师的意图,所以错误的范围被当成正确的放行了
  • 从未经授权的设备上移除 IP 路由,把一个整个西美数据中心从广域网上切了下来
  • 近五小时的停机级联成 19 次下游服务停机,其中 16 次在微软修复后仍然开着
代价365 + Azure 停机五小时;19 个下游服务受影响代价高昂

教训

一道用某台机器的输出来校验同一台机器转译的安全门,等于给 bug 背书——自动化必须对照人类意图校验,而非对照它自己被扩大的范围。

资料来源

发现哪里写错了?告诉我们。

Comments · 0

    登录 后就能评论。

    类似的案例

    这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →