微软365宕机，Copilot也失灵

北京时间11月13日凌晨，Microsoft 365发生全球性大规模服务中断，Outlook、Exchange Online、Teams、OneDrive、SharePoint Online和Microsoft 365 Copilot等产品陆续出现连接失败、邮件延迟、文件无法访问和AI功能不可用的问题。

这次故障从美国东部时间11月12日13时25分左右开始，也就是北京时间11月13日2时25分左右。截至北京时间11月13日午后，事故已经持续超过10小时，微软仍未宣布全面恢复，部分修复措施甚至没有按照预期生效。微软将涉及多项服务的事故编号标记为MO1550821，Exchange Online相关事故编号为EX1550543。(ithome.com)

这不是一次普通的“邮箱打不开”，而是微软企业办公基础设施的一次连锁失效。邮件、日历、会议、文件、身份权限和AI助手虽然显示为不同产品，底层却共享Exchange Online、Microsoft Graph以及一系列连接和流量调度组件；当关键基础设施失去容量时，故障就会沿着依赖链迅速扩散。

Outlook报障接近13万，74个国家和地区出现异常

Outlook是此次事故最明显的故障入口，也是用户感知最强烈的服务。

根据故障监测平台Downdetector的数据，Outlook问题报告量在高峰期接近13万条，远高于正常水平。需要强调的是，Downdetector统计的是用户主动提交的报告数量，而不是实际受影响人数，因此13万并不代表只有13万名用户遭遇故障，实际覆盖的企业账户和终端数量可能高得多。(ithome.com)

用户遇到的症状并不完全一致。部分用户无法登录Outlook，部分用户可以打开邮箱却无法发送或接收邮件，还有用户发现搜索、附件、共享邮箱和日历功能失效。这种不一致通常意味着问题并非单一前端服务器完全离线，而是不同区域、租户或请求路径获得的剩余容量不同。

| 服务 | 主要异常 | 对企业工作的直接影响 | |---|---|---| | Exchange Online / Outlook | 无法登录、邮件收发延迟、邮箱加载失败 | 客户沟通、审批通知和外部邮件中断 | | Microsoft Teams | 部分消息、日历及会议功能异常 | 内部协作和会议安排受阻 | | OneDrive | 云端文件无法访问或同步 | 文档共享、版本同步和远程办公受阻 | | SharePoint Online | 页面或文件库访问失败 | 企业知识库及内部站点不可用 | | Microsoft 365 Copilot | 提示失败、上下文获取异常、应用内功能不可用 | AI总结、检索和自动化工作流中断 | | Defender XDR等管理服务 | 部分控制台或关联功能降级 | 安全运营和管理响应效率下降 |

日本政府成为此次故障影响公共部门的典型案例。日本数字厅运营的政府共通信息基盘GSS出现异常，多部门使用的Outlook邮件系统停止工作，政府人员不得不临时改用电话、短信和其他聊天工具维持联络。(ithome.com)

这件事的讽刺之处在于，企业部署统一云办公平台，本来是为了让员工不受地点和设备限制，但当统一平台本身发生故障时，集中化也会把多个原本相互独立的问题合并成一次全公司停摆。

微软确认不是流量暴增，而是服务器意外离线

微软给出的初步原因是部分服务器意外不可用，而不是突然增加的用户访问量。

微软最初观察到多个地区的基础设施处于高负载状态，但进一步排查发现，高负载只是结果，不是原因。相当数量的服务器因为未能通过自动健康检查而被判定为离线，剩余服务器需要接管更多连接和请求，最终出现容量不足和流量分配失衡。(ithome.com)

健康检查是云平台用来判断服务器能否继续承载请求的自动机制。它类似于数据中心里的“值班医生”：如果服务器连续无法正确响应探测请求，调度系统会把它从可用资源池中移除，避免用户继续连接到故障节点。

问题在于，当健康检查一次性移除太多服务器时，保护机制本身也可能放大故障。剩余服务器接收到更多流量后开始变慢，响应变慢又可能导致更多健康检查失败，于是形成“服务器下线—剩余容量承压—更多服务器异常”的连锁反应。

微软采取了暂停部署与配置变更、释放内存、重新分配连接流量、重启受影响服务器，以及测试替代健康检查方案等措施。然而，服务器重启并不等于立即恢复业务：如果大量连接同时重新进入系统，刚恢复的节点可能再次过载。

这也是为什么微软一度观察到部分服务恢复，却又警告相关功能可能再次失去响应。恢复大型云服务更像是在高速公路事故后逐步开放车道，而不是简单按下一个重启按钮；如果一次放入全部积压流量，刚疏通的道路还会再次堵死。

修复“不如预期”，说明问题进入了容量恢复阶段

微软承认，先前部署的部分修复措施没有按照预期产生效果。

在持续数小时的处理中，微软尝试重启服务器并重新路由流量，但服务可用性并未出现与恢复容量相匹配的改善。微软随后转向其他方案，希望增加可承载流量的服务器数量，并解决持续存在的流量分配失衡。(ithome.com)

这种情况通常意味着技术团队已经找到主要故障域，却无法安全地一次性恢复全部容量。对于Exchange Online这样的全球性服务，系统不仅要处理实时请求，还要处理故障期间积压的邮件、同步任务、日历更新和后台索引操作。

积压任务会让恢复过程出现明显的“第二波压力”。即使服务器已经重新上线，数小时没有完成的邮件投递和文件同步也会同时重试，因此用户看到的往往不是从不可用瞬间变为完全正常，而是登录成功率、邮件投递速度和数据同步能力逐步恢复。

微软执行副总裁查尔斯·拉曼纳公开致歉，并表示目前没有迹象表明此次事故由恶意活动或网络攻击造成。这个判断很重要，因为它意味着此次事件更接近基础设施可靠性事故，而不是攻击者突破微软系统后导致的主动破坏。(ithome.com)

Copilot为什么也会被Exchange拖下水

Microsoft 365 Copilot是嵌入微软办公套件、能够调用组织邮件、文件、会议和日历上下文的企业AI助手。

Copilot并不只是一个独立聊天机器人。它的核心价值在于理解企业内部上下文，例如从Outlook邮件中总结客户需求、从Teams会议记录中提取任务，或者结合SharePoint与OneDrive文件生成报告。这些能力高度依赖Microsoft Graph以及邮件、日历和文件服务。

因此，基础模型仍然可以生成文字，并不代表Copilot能够正常工作。当Exchange Online或连接组件不可用时，Copilot可能无法取得用户要求的邮件、会议和文件上下文；没有这些数据，AI即使能够回答，也无法完成真正有用的企业任务。

| 产品或功能 | 本次事故中的主要依赖 | 影响边界 | |---|---|---| | Microsoft 365 Copilot | Exchange Online、Microsoft Graph、SharePoint、OneDrive | 应用内检索、总结和生成任务可能直接失败 | | ChatGPT的微软连接功能 | Microsoft 365连接与授权组件 | 新连接或调用相关工具可能失败，核心对话不一定受影响 | | Claude的Microsoft 365连接器 | 上游Microsoft 365服务 | 连接器出现错误，Claude核心模型服务不等于整体中断 |

OpenAI和Anthropic也报告了与微软服务连接相关的问题，但这不应被理解为GPT或Claude模型本身同时宕机。更准确的说法是：它们连接Microsoft 365数据的部分工具或连接器受到上游服务故障影响。(ithome.com)

这次事故说明，企业AI产品的可靠性不能只看模型推理接口。一个AI助手最终能否完成任务，取决于模型、身份认证、权限系统、数据连接器、企业搜索和业务应用等整条链路，其中任何一环不可用，都会让AI从“工作助手”退化成一个无法读取上下文的通用聊天框。

微软可能要付出多少费用抵扣

服务级别协议是云服务商对可用率作出的合同承诺，未达到承诺时，企业客户可以按规则申请费用抵扣。

根据微软2026年4月版相关协议，Exchange Online月度可用率低于99.9%、99%和95%时，对应的费用抵扣比例分别为25%、50%和100%。(ithome.com)

| 月度可用率门槛 | 30天内对应停机时长 | 费用抵扣比例 | |---|---:|---:| | 低于99.9% | 超过43分12秒 | 25% | | 低于99% | 超过7小时12分钟 | 50% | | 低于95% | 超过36小时 | 100% |

如果假设某个企业的全部Exchange Online用户连续10小时完全不可用，那么该月理论可用率约为98.61%，已经低于99%的门槛，可能进入50%抵扣档位。如果连续11小时完全不可用，理论可用率则约为98.47%。

不过，企业不能简单拿全球故障持续时间乘以用户数量后直接要求赔偿。微软通常会根据具体租户、受影响用户比例、实际不可用分钟数和服务范围计算“用户分钟”，不同地区和企业最终认定的可用率可能不同。

直接向微软订购服务的企业可以在Microsoft 365管理中心提交申请，并提供MO1550821或EX1550543事故编号。企业最好同时保留报错截图、受影响账号数量、业务中断时间、邮件延迟记录和内部事故报告；通过合作伙伴采购的客户则需要联系对应供应商。(ithome.com)

个人用户获得补偿的可能性相对较低，因为企业版SLA费用抵扣不等于面向所有消费者的现金赔偿。抵扣通常只作用于未来账单，也不会覆盖企业因为邮件中断、交易延迟或员工停工产生的间接损失。

真正的问题是“云办公单点化”

这次事故暴露的是企业数字工作环境正在从多套软件变成一个高度耦合的平台。

很多企业表面上使用Outlook、Teams、OneDrive和Copilot四种产品，实际上依赖的是同一套身份、连接、数据和管理基础设施。统一平台确实降低了管理成本，但也把原本分散的故障风险集中到了少数关键服务上。

Copilot的加入进一步提高了这种集中度。过去Exchange故障主要意味着邮件中断；现在Exchange还是会议摘要、客户邮件分析、日程建议和智能搜索的数据来源，同一个故障会同时切断人工工作流和AI工作流。

企业因此需要把Microsoft 365视为关键基础设施，而不只是软件订阅。最低限度的业务连续性方案应该包括：

• 为紧急联系人保留不依赖Microsoft 365的电话、短信或独立通信渠道；
• 对关键文档保留受控的离线副本或跨平台备份，而不是只依赖OneDrive同步；
• 在事故发生时记录租户级影响和用户分钟，为SLA申请保存证据；
• 区分“模型不可用”和“连接器不可用”，避免误判AI供应商故障范围；
• 为审批、客户支持和安全告警准备不依赖单一邮件系统的备用流程；
• 定期演练身份、邮件和文件服务同时中断时的业务恢复方案。

微软最终大概率能够恢复这些服务，但“恢复了”并不意味着这次事故没有长期影响。对微软来说，最需要解释的不是某批服务器为什么离线，而是健康检查和容量保护机制为什么没能把事故限制在局部，以及为什么多轮修复没有按预期快速恢复服务。

对企业来说，这次故障则再次证明，AI办公的最大风险未必来自模型答错，而可能来自模型根本拿不到数据。当邮件、文件、会议和AI助手都建立在同一个云平台上时，所谓智能工作流的可靠性，最终仍然取决于最传统的服务器容量、流量调度和灾难恢复能力。

参考来源

• 微软 Outlook 等服务今日大范围故障，受影响企业可申请费用抵扣：介绍故障起始时间、事故编号、初步原因及企业SLA费用抵扣规则。
• 微软高管回应 Outlook 等服务中断：深感遗憾，正全力修复：整理微软高管回应、修复进度以及非恶意攻击的初步判断。
• 微软 365 大规模宕机超 10 小时，日本政府不得不改用电话维持工作：介绍全球影响范围、日本政府应急措施及服务器健康检查相关信息。