40 小时里 Azure 出了两回事。我一开始也想写成"微软又崩了"，后来把两份官方时间线摊开看，发现它们连坏的地方都不一样——一个是 AI 服务的缓存被清了，一个是网关控制面被自己的更新压垮。硬凑成一篇，反而把最有用那点凑没了。

先说 9 月 29 日那次。

Sweden Central 区域，UTC 10:03 到 15:58，差不多 5 小时 55 分。Azure OpenAI Service、Foundry Agent Service、Foundry Models 这些 AI 服务间歇性请求失败，延迟升高，500 和 503 轮着来。

官方时间线里有一步特别值得记：09:38 在当地部署了一个内部服务，把它的缓存清掉了；10:00 后端流量开始陡增；10:03 客户开始受影响；10:17 监控才报警；10:28 工程师才介入。

从影响到有人看见，14 分钟；到有人动手，25 分钟。这 25 分钟不是空白，它实实在在算在故障时长里。我们平时算 SLA 只爱算"服务不可用多久"，很少算"我们多久才知道"。

第二次是 9 月 30 日 20:30 UTC 到 10 月 1 日 02:15 UTC，约 5 小时 45 分。这次不是某个 AI 服务，是网络那一层：ExpressRoute Gateway、Application Gateway、Azure Firewall、Azure Bastion、Virtual WAN、VPN Gateway 的管理操作间歇失败。一部分已经升级过的 ExpressRoute 网关拿不到控制面配置，直接临时断连；Azure VMware Solution 的客户也可能短时间失去到 SDDC 的网络。

影响面按官方区域列表是 30 余个区域。外面有文章写"18 个区域"，那个口径我没在官方找到依据，只当参考。

根因也不浪漫：一个平台触发的网关更新，在多个区域同时恢复推进，把区域网关控制面的请求量顶穿了，管理操作处理不过来。后面暂停更新、回滚，01:15 UTC 从第一个区域开始验证，02:15 UTC 全部完成。

这两次最像的地方，不是"都挂了"，而是"都是控制面出事"。数据面还在，但你想改个配置、扩个网关、拉个证书——改不了。很多公司自建平台也有这个病：平时都好好的，一出事发现连"进去改"的那条路都被自己堵死了。

微软给 9 月 30 日这次排了两场公开复盘直播（10 月 22 日 18:30–19:00 UTC、10 月 23 日 06:30–07:00 UTC）。愿意把时间线和根因摊开讲，这点还是值得学的——出事之后写一份"我们错在哪"，比写十份"服务已恢复"有用。

所以我现在看这类事故，会固定问三句：告警是几分钟后到的？谁在几分钟后动手的？控制面挂了我还能不能改配置？这三个问题，比一句"可用性 99.9x"更能说明一套系统到底扛不扛事。

平时机器多、平台多，靠人一台台登上去看状态本来就不现实，这也是我们用七亿批量远程管理工具做批量巡检的原因——但工具只能让你更快"看见"，看见之后那套"告警→研判→通报"的链，还得自己提前排。想按清单过一遍的，官网页的说明书可以对着比。

同类的云事故我写过两篇，可以连起来看：一个 DNS 缺陷，瘫了半个互联网 15 小时、AWS us-east-1 挂了 28 小时：这回不是 DNS，是空调。