北京时间11月13日，微软多项核心服务已经中断超过10个小时。微软给出的排查结论排除了两个最常见的猜测：这不是黑客攻击，也不是访问量把系统打爆。核心问题出在微软内部的容量调度环节：一批服务器没有通过自动健康检查被整体下线，剩余服务器被挤爆，而微软为提升容量部署的修复变更又没能按预期生效，故障因此不断延长。科技商业论蓝鲸新闻
宕机波及面：从北美邮件，到政府办公系统
这轮故障始于美国东部时间11月12日，Microsoft 365、Outlook、Teams、Copilot等面向企业和个人的核心办公应用持续中断，到13日中午仍没有完全恢复，也没有给出明确的全面恢复时间。第三方监测网站 Downdetector 上，Outlook 的问题报告量一度达138058起，微软方面明确表示，原因是"多台服务器因负载过高意外离线，并非访问流量激增"。故障最初被描述为集中在北美及中南美地区，随后微软改口称全球任何地区的用户都可能受影响。极客公园知乎哔哩哔哩
影响很快溢出办公场景。此次宕机波及OpenAI和Anthropic人工智能服务所使用的连接组件，日本、澳大利亚的政府系统也被拖入。日本内阁官房副长官尾崎正直确认，数字厅运营的政府共通信息基盘"GSS"出现故障，各府省厅只能靠电话、短信维持工作；澳大利亚政府则启动了相关协议，争取在恢复服务时获得优先处理。CCTV国际时讯蓝鲸新闻
第一环节：健康检查"下线"了大批服务器
要理解故障出在哪一环，先要看懂"健康检查"。大型云服务由成百上千台服务器共同接流量，系统会定期向每台服务器发送测试请求，超时未响应的就会被标记为异常、移出服务列表，这是保障高可用的标准机制。知乎
问题在于，这次是"相当数量的服务器"同时通不过检查。微软最初的通报是"多个地区的基础设施出现高负载"，后续调查排除了流量激增的可能：这些服务器未通过自动健康检查、被判定离线，压力全部转到剩下的机器上。被压垮的不只是容量：流量挤向剩余机器后，部分负责建立安全连接的进程出现过载，服务器干脆停止处理请求，刚恢复的机器一接流量又再次倒下。极客公园科技商业论
微软同时发现，一项近期网络配置变更与故障开始存在时间关联，并已着手回退该配置——这提示最初触发下线的，很可能是微软自己的变更而非外部冲击。知乎
第二环节：补救动作没生效，宕机被拖到10小时以上
故障之所以拖这么久，关键在于第二环：微软的补救没起作用。微软采取的缓解措施包括暂停所有部署与配置变更、将连接流量重新分配至其他基础设施、重启受影响服务器，并测试一种替代性的健康检查方案以加快恢复。但从结果看，这批"为提升服务能力而部署的变更"未按预期生效，微软称仍在寻找其他方案应对持续存在的流量调配失衡。截至发稿，微软尚未公布故障的根本原因，Outlook 仍有大量报障，企业用户得到的答复还是"全球故障，不确定恢复时间"。极客公园科技商业论观娱手记
对普通用户来说，这次宕机最值得记住的一点是：Outlook、Teams、Copilot、云文档押在同一套基础设施上，一台引擎熄火，一整个办公套件跟着停摆。而类似中断近期并非孤例，媒体已经在用"一月内两度宕机"来讨论微软云的可靠性标签。对企业IT而言，接下来的观察信号有两个：微软的正式事后复盘报告，以及它能否在下一次变更前证明自己容灾调度的真实水位。知乎
