微软 Azure 的状态历史页上，9 月底连着挂出两份事后复盘。这两起都不算全球性大故障，但根因都很典型，值得拿来对照自己的架构。

第一起：瑞典中部的 AI 服务（跟踪号 7QL5-Z50）

2026 年 9 月 29 日 UTC 10:03 到 15:58，瑞典中部（Sweden Central）区域的 Azure OpenAI、Foundry Agent Service、Foundry Models 和 Cognitive Services 出现间歇性请求失败、延迟升高和 HTTP 5XX 错误。官方给出的根因：负责取元数据的后端服务遇到数据库超时，实例达到阈值后反复重启，健康容量随之下降。10:14 检测到失败率上升，11:29 定位到超时，15:22 扩容并提高资源上限，15:58 恢复。

这和我们在 9 月 3 日多个 AI 服务中断那篇里讲的是同一类风险：你的应用本身没出问题，但它依赖的模型接口在某一个区域里慢了、错了。

第二起：网关类服务，五个区域（跟踪号 7Q30-010）

9 月 30 日 UTC 20:30 到 10 月 1 日 UTC 02:15，ExpressRoute 网关、Azure Firewall、Application Gateway、WAF、VPN 网关和 Azure VMware Solution 在英国南部、法国中部、北欧、东南亚、英国西部出现连通性问题。其中「东南亚」就是 Azure 的新加坡区域。官方初步复盘的根因：区域网关管理上的一项近期变更，在一次不相关的操作系统维护进行时触发了过量负载，而服务因为依赖方的约束无法自动扩容。23:05 关联到操作系统维护并暂停，次日 01:36 恢复推进，02:15 确认缓解。

两件事放在一起看

  • 「机器活着」不等于「服务可达」。第二起事故里，大量虚拟机本身可能是好的，但前面的网关、防火墙、VPN 一断，用户照样连不上。监控只看主机存活是不够的，要从外部探测完整访问链路。
  • 变更和维护的叠加是老问题。单独看哪一个都没问题，撞在一起就出事。自己的服务器也一样：升级、重启、改配置尽量错开，并留出回退路径。
  • 把依赖画出来。我们在上半年宕机报告那篇里建议过先画依赖图：哪些请求要过哪家的哪一个区域，坏了能不能切。

对服务东南亚用户的业务

如果你的用户主要在东南亚，关键入口只放在单一厂商的单一区域，遇到这类事件就只能等。比较稳妥的做法是在另一家厂商、或另一个地区放一个能接管的入口，再配合 DNS 切换。选节点的思路见如何为业务选择低延迟的机房节点；我们的新加坡节点可以作为这类备用入口之一。