summary
2014-11-18，微软为提升 Azure Storage 前端（特别是 Table 前端）性能而启用的一个配置开关，被错误地应用到了 Blob 前端。Blob 前端在收到该配置后陷入请求处理的无限循环（重试风暴），迅速耗尽计算资源，导致 Blob 存储的读写在全球多区域不可用或严重降级。
timeline
约 00:52 UTC 起 Blob 前端开始因错误配置进入无限循环，存储请求大量失败/超时；工程团队定位到配置开关误用，禁用该开关并逐步恢复；多数区域在数小时内恢复，少数区域耗时更长（官方 RCA 称全面恢复延至当日较晚时段）。
root_cause
配置开关被错误地从「仅 Table 前端」扩大应用到 Blob 前端；Blob 前端代码在该开关下会以不安全的方式递归/重试处理请求，形成自激循环。本质是配置推送缺乏按前端类型的隔离与护栏。
amplifiers
① 单点配置错误放大为全局：一个开关误用即拖垮 Blob 存储。② 未按 flighting/灰度增量发布：变更直接全量生效，无早期止损。③ 重试逻辑缺乏上限/熔断：循环自我维持而非快速失败。④ 恢复依赖人工定位与回滚，拖长 MTTR。
mitigation
禁用误用的配置开关，恢复 Blob 前端正常请求处理；后续为配置开关增加按服务类型的生效范围限制与灰度发布，并在推送前做影响评估。
lessons
全局配置开关必须限定生效范围并有护栏；高风险变更强制灰度（flighting）而非全量直推；重试/递归逻辑必须带次数上限与熔断，避免自我维持的循环。
checklist
① 配置开关按服务/前端类型隔离生效范围。② 全局变更走灰度发布与自动回滚。③ 重试逻辑加次数上限与熔断。④ 监控对「请求循环/重试风暴」类指标设告警。