摘要

  • Azure 表示，一项临时操作系统更新限制到期后，大量网关更新在短时间内恢复；此前部署的另一项变更也增加了配置操作的处理时间。
  • 叠加负载影响了多个区域的网络服务管理操作。部分 ExpressRoute 网关在配置和路由尚未完全恢复时便推进了冗余实例的更新。

云服务事故最容易被讲成一句话：一次更新导致了中断。Azure 对 9月30日至10月1日事件的复盘给出了更关键的交互关系。一项临时限制曾暂停一组网关的操作系统更新。限制到期后，大批更新在较短时间内继续执行。与此同时，一项先前部署的变更让共享区域网络控制面处理配置操作所需的时间变长。请求到达得更多，每个请求完成得也更慢。

这与“某次更新本身出错”不是同一种因果解释。微软描述的是重启与配置读取请求上升，遇上处理变慢的服务；已有的限流和负载保护没有充分保护关键处理。更新按区域滚动推进，因此各地受到影响的时间不同。Azure 列出的受影响服务包括 ExpressRoute Gateway、Application Gateway、Azure Firewall、Bastion、Virtual WAN 和 VPN Gateway，涉及美洲、欧洲、亚太、非洲和中东多个区域。公开复盘没有给出逐客户的受影响清单。

管理面故障也让部分连接中断

不少受影响操作属于管理功能。但部分 ExpressRoute 网关出现了更直接的后果：通往已连接本地网络的连接暂时丢失。Azure 称，更新期间重启的实例可能在配置和路由状态尚未恢复时就被标记为健康。更新随后推进到另一台冗余实例。如果两台都无法取回所需路由配置，连接就会中断。

在配置读取连续失败约30分钟后，受影响网关自动应用了本地保存的最近一次有效配置。这个约30分钟是微软所述的重试间隔，并不表示每位客户的中断都持续30分钟。整体事件始于9月30日20:30 UTC，最后一波影响在10月1日02:15 UTC得到缓解。Azure明确提醒，整体持续时间不代表每个客户或资源的实际受影响时长。

时间线也显示，单纯增加容量并不能解决问题。ExpressRoute 连接退化于20:43被监测到；更广泛的控制面问题于20:58出现。21:45暂停后续网关更新、调整流量都带来了短暂缓解；增加资源的尝试也未能稳定服务。到23:55，调查将配置处理时间上升与一项性能退化变更联系起来。回滚于10月1日01:15先在一个区域启动并验证，然后扩展到其他区域。回滚完成后，02:15客户影响结束。

维护窗口不等于队列恢复方案

Azure 网关文档说明，常规更新可能涉及软件补丁、网络组件升级和硬件退役。部分网络网关允许客户设置维护窗口，但窗口解决的是时间安排，不能证明暂停结束后延迟的更新将如何排空。微软复盘提出的后续措施包括：改进暂停更新的分批恢复方式、强化健康检查以确认配置和路由完全恢复后才更新另一台冗余实例、处理扩容限制，以及改善限流和负载卸除机制。这些是复盘中列出的措施与估计期限，不等于独立验证这些措施均已完成。

微软的安全部署指南建议逐步扩大变更范围、每阶段通过健康检查后再继续，并在发现问题时停止部署。本次事件提出了更具体的问题：“健康”指进程重新启动，还是意味着服务所需配置与路由已取回并验证？如果下一台实例仍依赖同一条尚未恢复的控制面路径，冗余并不能提供保护。

微软表示，客户无法避免或减轻这次特定服务事故的影响。客户仍可梳理各项工作负载依赖哪些网关，将自己的数据面观测与管理操作分开，并配置 Service Health 告警。这些做法能改善发现与响应，但不能把供应商的恢复计划变成客户可以控制的保证。

来源：Azure 事故复盘 7Q30-010；ExpressRoute 虚拟网络网关说明；客户控制的网关维护；安全部署实践。编辑框架仅参考：Heng Lu 笔记20。