美国东部时间11月12日，微软旗下Microsoft 365、Outlook、Teams（即时通讯）等多项服务持续中断多个小时，故障还波及OpenAI和Anthropic人工智能服务所使用的连接组件。 热搜里的“13万”，对应的是故障监测口径：据央视新闻数据，Outlook问题报告量一度达峰值138,058起，傍晚降至约34,490起——这是全球用户报障次数的峰值，不是微软公布的受影响用户总数，也不等于13万人的邮件永久丢失。 至于原因，微软当天的官方表态先把最容易误判的方向排除：故障原因是“多台服务器因负载过高意外离线，并非访问流量激增”。 换句话说，这次全球性瘫痪不是被用户“挤垮”的，而是微软自己的基础设施在处理内部负载时失了稳。CCTV国际时讯36氪梨视频
波及面：从邮箱登录到政府改用电话
受影响的远不止Outlook一个产品：此次故障波及Outlook、Exchange Online、Microsoft Teams、OneDrive、SharePoint、Microsoft 365 Copilot等多项核心产品，全球多个地区用户反馈无法正常访问服务。 国家层面的运转也被打断：日本数字大臣古川俊治13日表示，受微软办公软件大规模故障影响，日本政府的基础系统邮件无法正常收发，已通过电话等其他方式维持工作，各项业务未受影响。 澳大利亚间谍机构和联邦警察也于13日证实受到波及，澳内政部长称已启动一项协议，确保该国在服务恢复时获得优先处理。36氪央视新闻蓝鲸新闻
原因链条：健康检查失灵，负载像雪球越滚越大
把微软连续发布的多条状态更新拼起来，故障链条大致分三步。第一步是“自检失败”：微软表示部分基础设施出现异常高负载，进一步调查发现，问题并非整体流量突然增加，而是大量服务器意外变得不可用，导致剩余服务器承受更大负载压力；部分服务器未能通过自动运行的健康检查，因此被判定为不可用。 所谓健康检查，是负载均衡系统定期向服务器发测试请求、把没按时应答的节点自动移出服务池的机制。单台节点出故障时它是保险丝；大批节点同时“自检失败”时，它反而成了把流量压向幸存服务器的推手。36氪
第二步，幸存服务器继续恶化：微软进一步发现，部分服务器上负责建立安全连接的进程出现过载，导致服务器停止处理请求。 于是请求开始排队、客户端超时重试、更多节点因处理不过来而自检失败退出——这正是教科书式的级联故障：一台倒下，其余跟随。知乎
第三步，指向内部变更：微软同时表示，部分配置更新可能与此次故障有关。 工程师的排查也发现，一项近期网络配置变更与故障开始存在时间关联，微软已经开始尝试回退该配置。 需要说明，配置变更与故障目前只是“时间关联”，微软尚未给出最终定因。36氪知乎
为什么一个底层故障，拖垮了一排上层应用
Outlook、Teams、OneDrive、SharePoint、Copilot看起来是五个产品，实际共享同一套底座：用户邮箱背后运行的是Exchange Online，Teams的日历和会议安排要与其协同，Copilot也依赖访问邮件、日历等企业数据，微软11月13日更新的 MO1550821 事件通报已经确认了这种应用间依赖。 因此连接基础设施一旦失稳，上层功能便成排失效。知乎
恢复进度：有限恢复，全面恢复时间仍未承诺
截至美东时间12日18时，微软称已观察到有限恢复，用户正逐步重新连接。 口径上还要注意：Downdetector追踪到的微软各项服务问题报告峰值约20万份出现在纽约时间下午1点刚过，13万是Outlook单项、20万是全部服务合并，两个数字不能相加。 微软最新表态称，公司监测了为提升服务能力而部署的变更，确认变更未按预期生效，目前正寻找其他可行方案应对流量调配失衡问题。广元融媒36氪蓝鲸新闻
但恢复是有限度的：截至13日上午，有北京用户反馈Outlook和Copilot均无法使用，Teams还能发消息，却无法正常安排会议。 微软相关部门仍在全力修复，截至目前Microsoft 365服务可用性仍未得到明显恢复，且微软未公布明确的全面恢复时间。知乎知乎
微软执行副总裁查尔斯·拉曼纳（Charles Lamanna）13日在X平台就Outlook、Exchange Online等办公服务故障公开致歉，称团队正在努力解决问题，并持续通报最新修复状态。 经济层面的外溢也已出现：卡车和巴士制造商Workhorse Group因故障将原定于周四发布的财报推迟至下周一。摄氏度视频36氪
这次故障给依赖微软办公套件的团队提了个具体醒：报障曲线回落不等于邮件恢复送达，在微软给出全面恢复时间之前，重要沟通仍需保留电话、备用邮箱等替代通道；而“内部变更引发全球服务雪崩、却迟迟无法承诺恢复时点”这一过程本身，也让云服务对少数底座的集中依赖，成为一个值得持续观察的风险变量。
