微软邮箱全球宕机：故障近十小时
内容提要
2026年11月13日凌晨，微软Exchange Online全球宕机并波及整个Microsoft 365生态，Outlook报错近13万条。故障源于网络配置变更导致安全连接进程过载、健康检查批量摘除节点，重连风暴压垮剩余服务器。微软多次判断反转后回滚配置，故障持续近十小时。文章指出，超大规模云的自动化容灾反而成为故障放大器，SLA赔付远不足以弥补真实损失。
延伸解读
自动化健康检查为何成为故障放大器
文章指出，健康检查本意是摘除个别异常节点，但在全局共因故障下，缺乏最大摘除比例熔断的探针会把成批变慢的节点逐一踢出服务池，造成容量断崖。剩余节点被重连风暴压垮，形成正反馈死锁。这提醒我们，自动化容灾机制在超大规模环境中可能反向放大故障，设计时需考虑全局异常时的保护策略。
Exchange 仍是 M365 生态的隐性单点
事故显示，Teams 消息和 SharePoint 文件读取大体可用，但依赖 Exchange 邮件、日历与联系人数据的 Graph API、Teams 日程、Copilot、Defender Safe Links 等上下游服务全部瘫痪。文章认为，这扯下了 SaaS“松耦合”的遮羞布，老牌 Exchange 依然是串起企业协同、安全审计乃至 AI Agent 的隐性单点，底层邮件连接层一抖，上层服务再强也瞬间失能。
SLA 赔付与真实业务损失不在一个量级
文章强调，Exchange Online 的 SLA 并非“宕机十小时就自动赔十小时损失”，而是按适用服务、受影响用户和统计周期计算可用率，最终能否获得账单抵扣还需按合同规则申请核定。即便拿到抵扣，也不过是订阅费用的一部分，与关键邮件收不到、业务流程中断造成的真实损失相差甚远。读者应认清云 SLA 的补偿边界，提前评估业务连续性风险。
超大规模云的结构性脆弱与自建权衡
作者对比传统 IDC 自托管，认为在自有小规模环境中几乎不会出现“一行网络配置变更引发安全连接进程与健康检查死循环雪崩”的离奇故障。超大规模公有云为维持全球多租户底座，叠加了复杂网络、自动化探针与安全网关，平时固若金汤，一旦某个齿轮卡死，自动化容灾便成为故障放大器。这提示读者在选择云服务时，需权衡便利性与继承巨头复杂度和风险性的代价。
Q&A
2026年11月13日微软邮箱宕机持续了多久？影响范围有多大？
故障从北京时间凌晨00:17开始，持续近十小时，截至上午10:01状态页仍显示“服务降级”。影响范围波及全球，Exchange Online及整个Microsoft 365生态均受影响，Downdetector上Outlook报错近13万条，美洲、欧洲与亚太地区企业用户全面受阻。
这次微软Exchange Online宕机的根本原因是什么？
直接原因是服务端负责建立安全连接的进程过载崩溃，叠加自动健康检查将大批节点摘除，导致剩余节点被重连风暴压垮。微软最终确认并回滚了一项与故障起点高度吻合的近期网络配置变更。
为什么微软的自动健康检查反而加剧了故障？
健康检查本意是摘除个别故障节点，但在全局共因故障下，缺乏最大摘除比例熔断机制，导致成批变慢的节点被踢出服务池，造成“容量悬崖”。剩余节点承受全球客户端重连风暴，几分钟内再次过载，形成正反馈死锁。
微软在排查过程中出现了哪些判断反复？
微软起初归咎于“多区域负载升高”，后承认高负载只是表象；先声称未发现近期变更，一小时后改口正在核查配置更新；尝试隔离重启节点一度局部回暖，但很快发现节点重新承接流量后再次失去响应，直到上午09:06才确认安全连接进程被压垮并回滚配置。
这次宕机对Microsoft 365生态和外部服务造成了哪些连锁影响？
Teams日程排会失效，Microsoft Graph API大面积超时，Copilot因读不到工作数据罢工，Defender Safe Links和Purview合规组件报错，部分Windows 365云桌面受影响。故障还导致OpenAI和Anthropic的M365企业连接器失灵，M365管理中心自身也无法加载。
微软Exchange Online的SLA赔付能弥补用户损失吗？
不能。SLA按适用服务、受影响用户和统计周期计算可用率，最终能否获得账单抵扣需按合同申请核定，即便获得也只是订阅费用的一部分，与关键邮件收不到、业务中断造成的真实损失不在一个数量级。
从这次微软宕机事件中可以看出超大规模云有哪些结构性风险？
超大规模云为维持全球多租户底座，叠加了上百层复杂软件定义网络、自动化健康探针和流量编排，一旦某个齿轮因配置变更卡死，自动化容灾机制反而成为“故障放大器”。租户被迫为巨型分布式怪兽的结构性脆弱买单，且生产面与管控面同生共死，管理后台也可能同时不可用。
