案例库 · 软件与 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 次在微软修复后仍然开着
教训
一道用某台机器的输出来校验同一台机器转译的安全门,等于给 bug 背书——自动化必须对照人类意图校验,而非对照它自己被扩大的范围。
资料来源
- Microsoft 365 outage: Azure maintenance bug wiped IP routes, taking Teams down for hours — TechTimes
- Microsoft 365 outage affects Teams, SharePoint and other services — BleepingComputer
发现哪里写错了?告诉我们。
类似的案例
这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →

Comments · 0
登录 后就能评论。