Outlook全球宕机超10小时：微软M365故障为何拖了这么久？

一次长达十余小时的服务中断，让全球许多企业又一次意识到自己对微软办公系统的依赖有多深。

从北京时间11月13日凌晨开始，微软旗下Microsoft 365（下称“M365”）爆发大规模服务故障，Outlook邮箱无法正常连接，Microsoft Teams、Copilot以及部分办公和安全管理功能也受到牵连。

据媒体报道，故障最严重时，美国故障监测网站Downdetector收到的Outlook异常报告超过13万次。电动卡车制造商Workhorse Group因为微软服务中断，把原定11月12日举行的季度业绩发布推迟到11月16日。OpenAI和Anthropic也报告了微软服务连接器异常。

微软披露的检修进展显示，问题症结逐渐指向后台基础设施：一些服务器意外不可用，原本由它们处理的请求被迫转给剩余设备，负载随之上升。与此同时，部分服务器恢复运行后很快又陷入异常。

服务器异常为何演变成系统性故障，微软又为何迟迟没能恢复？

故障最早出现在微软的Exchange Online服务上。

Exchange Online是M365的核心组件之一，企业邮件、日历和相关数据访问都靠它支撑，Outlook等应用也要通过它连接云端邮箱。

微软的服务健康公告显示，北京时间11月13日0时17分左右，Exchange Online开始出现连接异常，用户可能无法通过Outlook网页版、桌面客户端及其他接口访问邮箱。

微软随后排查发现，部分依赖Exchange Online的Teams日历、会议安排、Microsoft 365 Copilot、Microsoft Graph接口以及安全管理功能同样受到影响。不过微软也强调，不依赖Exchange Online的功能仍可正常运行。

起初，微软把问题归因于多个地区的基础设施负载过高，尝试重启服务器、重新分配流量。但后续调查表明，问题并非来自用户请求量的整体增长。微软确认，大量服务器未通过自动健康检查，意外退出服务，原本由它们处理的请求被转到其他服务器，剩余基础设施因此承受更高压力。

自动化机制也没能迅速化解危机，部分恢复运行的服务器在重新接收流量后再次失去响应。微软工程团队为此尝试限制部分请求、隔离受影响的基础设施，并用此前的软件配置重建服务器。

北京时间11月13日上午，微软进一步披露，受影响服务器中负责建立安全连接的进程出现过载，导致服务器停止处理请求。微软同时开始回滚一项与故障发生时间存在关联的网络配置变更，但尚未确认它是否为事故根本原因。

微软更新的故障处置进展显示，亚太地区部分受影响基础设施已完成恢复操作，相关流量正在逐步恢复，用户邮箱访问及积压邮件处理情况有所改善。不过部分用户仍可能遇到间歇性异常。微软表示，正在把恢复措施推广至其他受影响地区，同时增加基础设施容量，以提高服务稳定性。

安邦智库（成都）研究中心助理研究员刘祺在接受《每日经济新闻》记者采访时，把此次故障称为一种较为罕见的非线性连锁失效，带有“黑天鹅式”级联故障的特征。他认为，部分服务器突然退出服务后，异常沿着系统内部的依赖关系扩散，故障识别与处置的难度随之增加。

AI投资狂奔，微软的核心办公生意面临可靠性考验

眼下，微软正处在新一轮AI基础设施扩张之中。

微软2026财年年报披露，云业务收入为2144亿美元，比上一财年增长27%。年报中提到，AI基础设施投入不断加码、AI产品用量上升，这两件事都在挤压云业务的毛利率。2026财年，微软云业务毛利率下滑到66%。

工信部信息通信经济专家委员会委员盘和林在接受记者采访时表示，云厂商把更多算力资源向AI业务倾斜，AI需求也在占用部分原本用于系统冗余的预算，传统算力的新增投入相应减少。

盘和林表示，AI热潮正让云服务的稳定性面对新问题。算力需求涨得快、供给又跟不上，再加上AI训练带来高并发，算力资源调度因此更复杂。此外，针对AI算法的攻击、数据与信息安全风险、能源供应以及合规要求，也让云计算企业在基础设施管理上背负了更重的担子。

他还指出，问题可能进一步延伸到运维环节。随着AI逐步替代部分人工工作，企业在应急处置方面可能面临人力不足，日常系统维护和冗余灾备能力也可能受到影响。

与此同时，AI正不断嵌入微软原有的企业软件生态。Microsoft 365 Copilot把邮件、日历、文档与企业内部数据连接起来，越来越多的办公流程由不同云端服务协同完成。这种集成能提高企业工作效率，也意味着服务之间的依赖关系更加复杂。例如本次事故中，Copilot部分功能就无法访问邮件、日历和文件数据。

这些年，异常检测、日志分析、故障定位等运维环节已经用上了AI。可自动化系统跑起来，仍要依托底层网络、软件配置和服务组件。这些环节一旦自己出问题，要恢复还是得靠大量工程判断和验证。

刘祺的看法是，眼下对AI运维的能力不宜期待过高。原因在于，AI运维系统本身就架在相关基础设施上，底层服务器一失效，监测数据可能断流，AI对系统运行状态的感知也会被削弱。另外，按他的说法，当前AIOps（智能运维）更拿手的是认出已经出现过的故障模式，“主要价值是故障发生后加速排查定位，并不具备预测未知系统性崩溃的能力”。

刘祺还提到，这次故障里的未知异常缺少同类历史样本，AI很难识别出来；再加上现阶段的AI运维系统一般没有自主阻断故障扩散的权限，重大宕机也就难以从根源上避免。

这类事故其实不是头一回。今年10月，微软Azure云平台也出过服务故障，多个行业和生产力软件都受了影响。事故接连出现，大型云平台到底靠不靠得住，又一次被摆到台面上。

邮件、日历、文档、组织账号、权限管理，再加上安全合规体系，这些拼在一起，构成了M365那套复杂的办公基础设施；它的竞争优势，就建立在长期攒下的企业客户基础之上。对大企业来说，换供应商可不是买套新软件那么简单，大量历史数据、业务流程和员工使用习惯都得跟着搬。

刘祺的判断是，这次故障短期内不会对M365的订阅业务造成明显冲击。“M365主要依靠深度的生态绑定，因此护城河依然稳固，企业切换的迁移成本很高。”但他也提醒，Copilot等AI功能越集成越深，M365已经成了大量上层AI服务的底座，一旦出问题，波及的业务范围也在变大。往后重大宕机要是频繁发生，那些对业务连续性要求高的客户，可能会慢慢铺开多供应商方案，少依赖微软这一个平台。