Microsoft 365 于 8 月 31 日开始出现的故障，到 9 月 1 日仍未完全平息。邮件流转率先恢复，但 Exchange Online、SharePoint、OneDrive 和 Teams 的搜索功能长时间不稳定，Microsoft 365 Copilot 的部分响应也随之中断。微软给出的原因，是多项服务共用的一处认证配置出现问题。
一处认证配置牵动多项服务
事情从邮件开始。协调世界时 8 月 31 日 11 时 55 分左右，微软注意到有关 Exchange Online 的用户报告增多并展开调查。大约 40 分钟后，微软表示已经在受影响的请求中定位到一个共同的失败模式，与认证和协议连接有关。
然而在评估修复方案期间，影响范围越出了 Exchange Online。微软将当天 15 时 8 分记为这次大范围事件的正式开始时间，并把根本原因归结为「多项 Microsoft 365 服务共用的核心认证配置出现问题」。最初 Exchange Online 的故障编号为 EX1464935，随后被并入范围更广的 MO1465074，涵盖 SharePoint Online、OneDrive for Business、Teams、Microsoft Purview 以及 Microsoft Defender XDR。
从受损功能的清单可以看出波及面之广。Exchange Online 的连接与搜索失效；SharePoint Online 与 OneDrive for Business 的文件访问、同步、内容加载和搜索受阻；Teams 的搜索、日历和状态显示异常；Microsoft 365 Copilot 中需要读取 Microsoft 365 数据的提示词无法执行。在用户看来是彼此独立的应用，底层却依赖同一套认证机制。
邮件先行恢复，搜索拖到最后
恢复过程分阶段推进。当天 16 时 36 分前后，微软表示正在重新排查近期的变更，寻找安全恢复认证组件的方式，包括回滚某项更新的可能。约一小时后，微软称缓解措施的测试取得了积极结果；到 18 时 40 分左右，开始在部分目标基础设施上重新应用认证组件，并在确认效果后逐步扩大范围，同时分批重启受影响的部分。
各项服务的恢复速度并不一致。Exchange Online 的邮件连接在周一晚些时候已大范围恢复，但微软提醒部分组织仍需时间清空积压的邮件队列。确认邮件流转的恢复保持稳定后，微软把重心转向搜索功能。
搜索的修复跨到了第二天。在 9 月 1 日 2 时 39 分的更新中，微软仅表示在部分受影响环境中，与搜索相关的服务运行状况遥测出现渐进式改善，并未给出完全恢复的预计时间。此后微软通报邮件流转与搜索已经恢复。从最初的报告算起，这次事件耗时接近一整天。
Copilot 让「停摆的代价」变得更大
值得注意的一点，是 Microsoft 365 Copilot 出现在了受影响清单里。生成式 AI 助手看上去只要模型在运行就能使用，但面向企业内部的助手，只有能读取邮件、文件、会议和聊天记录才谈得上有用。数据层或认证层一旦中断，模型再健康也无从作答。
企业交给 AI 智能体的工作越多，这层依赖就越重。过去「邮件挂了」「文件打不开」的故障，今后会变成「替人干活的机制整个停了」。在设计冗余时，与其先关心模型的可用性，不如先确认认证和通往数据的路径是否已经成为单点故障。
值得提前准备的应对
用户端能做的事有限，但并非没有。在认证类故障中，已经登录的会话往往还能维持，需要重新认证的设备则最先失去访问权限。故障期间贸然退出登录或修改密码，可能导致在服务恢复前无法重新进入。
另一点是通信渠道的分散。当 Teams 与 Exchange Online 同时中断，公司内部的联络路径会一起消失。把故障时的第一联络渠道放在另一套系统上，至少能保住通报状况与下达指令的能力。微软管理中心的服务运行状况信息本身也可能依赖同一租户的认证，因此配合外部状态页面查看会更快。
总结
8 月 31 日开始的 Microsoft 365 故障，源于多项服务共用的认证配置出现问题，影响从 Exchange Online 扩散到 SharePoint、OneDrive、Teams 以及 Microsoft 365 Copilot。邮件流转当天基本恢复，搜索的修复则拖到了 9 月 1 日。这次事件再次说明，单一组件支撑的范围有多广，而 AI 助手如今正建立在它之上。
注：缩略图为 AI 生成的示意图。
