summary
2025-01-08 22:31 UTC 起，Azure East US 2 区域因一次网络配置变更引发控制面故障，持续约 50 小时。Azure PubSub 服务（网络控制面在资源提供方与主机网络代理之间传递配置的中介，并充当配置缓存）在回收内部副本时误以并行方式执行，导致三个元数据分区失去仲裁、索引数据丢失，约 60% 的网络配置无法下发到主机代理，所有依赖该分区的服务管理操作（含虚拟机网络资源调配）失败。
timeline
22:31 UTC 配置回收操作以并行（应为串行）执行，分区失仲裁、索引丢失。22:55 UTC Databricks 集群启动失败开始。01:29 UTC 次日 SQL Database 新建连接报错。多家服务在 08-10 日陆续出现间歇性 500/超时。10 日 16:39 UTC 三个分区恢复，私有连接问题修复。11 日 04:30 UTC 微软宣布 East US 2 全部服务恢复。
root_cause
根因是网络控制平面的 Azure PubSub 服务在启用某特性时，对部分元数据分区执行内部副本回收（recycling）应以串行保证仲裁，却以并行执行，导致分区失去仲裁、索引数据丢失。失去索引后控制面无法向主机代理下发网络配置，造成 East US 2 虚拟机及相关网络资源调配全面失败。
amplifiers
① 控制面与数据面耦合：网络配置经由 PubSub 缓存下发，缓存失效即阻断所有服务管理操作。② 单可用区爆炸半径：虽仅一个 AZ 的配置问题，但依赖该分区索引的服务跨多可用区失败。③ 恢复慢：需重建索引并重新向代理下发配置，且部分服务依赖私有连接（Private Link），需逐层恢复。
mitigation
将流量从受影响可用区转移以缓解非 AZ 服务；修复私有连接问题；重建分区仲裁与索引；向主机代理重新下发网络配置。微软后续强化 PubSub 副本回收的串行化与仲裁保护，并为分区恢复增加自动化。
lessons
控制面变更必须串行化关键操作以保护仲裁；控制面缓存失效应不影响数据面既有连接；单 AZ 变更也可能因索引/缓存共享产生跨区域爆炸半径，需在变更前评估。
checklist
① 控制面元数据操作强制串行+仲裁校验。② 副本回收增加自动化仲裁检测。③ 变更前做单 AZ 爆炸半径评估。④ 私有连接依赖独立健康探测与快速回滚。