Skip to content
微软 11·12 大规模故障之后:日本企业如何用多云设计让业务不停摆

微软 11·12 大规模故障之后:日本企业如何用多云设计让业务不停摆

图片由xAI Grok生成
15 分钟阅读
0
0 条评论
39 次浏览

2026 年 11 月 12 日,Microsoft 365 发生大规模故障,Outlook、Teams 中断约 10 小时,日本时间 13 日下午仍未稳定。本文先按公开报道还原事件,再说明 SLA 能赔什么、不能赔什么,最后给日本企业一套只给关键业务准备第二条路的多云持续运营方案。

导语

2026 年 11 月 12 日(美国东部时间),Microsoft 365 发生大规模故障,Outlook、Teams 等服务中断,问题主要出在 Exchange Online。据路透社报道,当天服务中断约 10 小时;到日本时间 13 日下午,微软仍在回滚配置、扩充容量,服务仍不稳定。日本时间 13 日周五清晨起,日本也出现了故障报告。

这不是今年第一次。我的结论很简单:没有不会停的云,但业务可以设计成「云停了,工作不至于停摆」。多云不是把所有系统都做两套,而是只给「停了就麻烦」的那几样东西,事先准备好第二条路:联络、邮件、数据、身份,以及 AI 连接。

本文的事实部分以截至日本时间 2026 年 11 月 13 日 15 时的公开报道为准。

一、发生了什么

时间(美国东部 / 日本)事件
11/12 12:54 / 11/13 02:54微软 365 状态账号在 X 上确认:美洲地区用户通过多种方式访问 Exchange Online 邮箱出现问题
13:00 前后 / 03:00 前后Downdetector 上 Outlook 故障报告达到峰值,约 138,058 件
14 时以后 / 04 时以后微软说明:负载升高不是流量增加造成的,而是一批服务器意外不可用,压力集中到了剩下的设备上;已暂停所有部署,正在转移流量、重启服务器
18:00 前后 / 08:00 前后部分服务器已恢复并保持稳定,但只是有限恢复;微软尽可能把流量转到备用路由,并简化其余服务器恢复上线的流程
20:18 / 10:18微软称,负责建立安全连接的进程过载,服务器停止处理请求;开始回滚一项与故障开始时间吻合的近期网络配置变更
21:30 / 11:30美国仍有超过 2.5 万件 Outlook 故障报告
22:17 / 12:17微软称这项变更的效果不如预期,正在另找办法增加容量;稍后又表示,没有迹象显示是恶意活动
11/13 00:04 / 14:04已调整的区域出现部分恢复,但无法持续;微软正在扩容虚拟机,以增加容量、降低负载

日本时间 13 日周五清晨起,日本、印度、澳大利亚等亚太地区也出现了故障报告。微软此前表示,随着容量恢复、客户端重新连接,用户会逐步恢复。

影响范围不只是邮件。依赖 Exchange Online 的场景,包括日历、会议安排,以及在启用了信息屏障(Information Barriers)的组织中新建 Teams 聊天,都可能失败;微软列出的可能受影响服务还包括 Copilot、SharePoint Online、Microsoft Defender、Planner 和 To Do。Downdetector 显示,故障报告在约一小时内就遍及 74 个国家和地区。受影响的除了企业,还有美国众议院的用户,以及澳大利亚的情报机构和联邦警察。

AI 服务也受到牵连。OpenAI 表示正在排查微软连接器的问题,新连接可能失败,部分工具无法正常工作;Anthropic 表示,上游供应商的问题影响了它的 Microsoft 365 连接器。报道中提到的影响,集中在这些 AI 服务与微软之间的连接上。

故障也直接影响了企业经营。美国电动卡车制造商 Workhorse 原定 11 月 12 日美东时间下午 4:30 召开第三季度业绩电话会,因为「全球微软故障造成的业务中断」,改到了 11 月 16 日。

类似的事今年已经发生过几次:1 月 22 日,Microsoft 365 和 Outlook 中断,主要影响北美;7 月 23 日,美国西部区域的网络故障波及 Azure 和多项 Microsoft 365 服务;8 月 31 日,Outlook 和 Exchange Online 故障;11 月 9 日,欧洲、中东和非洲的部分用户通过网页版 Outlook 访问邮箱失败,持续约 4.5 小时。再往前,2025 年 10 月 29 日 Azure Front Door 的配置变更导致全球故障,也波及了 Microsoft 365。

二、SLA 赔的是费用,不是时间

Microsoft 365 里 Exchange Online、Teams 等服务的 SLA 是月可用率 99.9%。可用率低于 99.9%、99%、95% 时,分别可以获得 25%、50%、100% 的服务抵扣(service credit),需要客户自己申请。按 99.9% 计算,一个月里约 43 分钟的停机仍在 SLA 范围之内。

抵扣的是当月相应服务的费用,补不回业务损失。推迟的业绩发布、没能及时回复的订单邮件、没开成的 Teams 会议,都不在 SLA 的计算里。

另一个现实是集中度。日本的政府云(ガバメントクラウド)认定了 AWS、Microsoft Azure、OCI、Google Cloud、さくらのクラウド 五家,但实际使用高度集中。据数字厅资料,截至 3 月 31 日,国家使用的信息系统约 85% 运行在 AWS 上;数字厅官员在 6 月的说明会上还表示,地方自治体约 80% 采用 AWS,并希望多家事业者相互竞争、保持平衡。供应商名单上有好几家,不等于业务真的有第二条路。

三、多云的正确用法:不是全部做两套

全部做两套,成本和运维负担都会翻倍,中小企业很难负担。更现实的做法,是先按「停了会怎样」给业务分级,只给分级高的业务准备第二条路。下表是我们建议的分级示例:

业务停 1 小时停 1 天建议的第二条路
员工之间、与客户的紧急联络困扰严重Microsoft 365 之外的联络渠道
收发邮件(订单、报价、客服)可以忍受严重邮件持续服务、主要客户的备用联系地址
文件与资料可以忍受困扰另一家云上的备份副本
管理员登录与权限出事时严重严重紧急访问账号
AI Agent 与业务自动化可以忍受困扰多条模型路径、能降级的工作流

四、六项技术对策

  1. 备用联络渠道。 事先准备不依赖 Microsoft 365 的联络方式:另一家厂商的聊天工具、电话或短信联络网,以及存放在 Microsoft 365 之外的紧急联络名单。告警和通知也一样,要走一条不依赖出故障平台的通道。
  2. 邮件的持续性。 把域名的 DNS(包括 MX 记录)放在自己能控制的 DNS 服务上,并了解 TTL 设置。利用邮件持续或归档服务,让收到的邮件同时投递一份到另一个系统,这样 Exchange Online 无法使用时,仍能查看和回复重要邮件。同时给主要客户和供应商准备一个备用联系地址。
  3. 身份的紧急出口。 微软建议创建两个或以上的紧急访问账号:只存在于云端、使用 onmicrosoft.com 域名、不做联合或同步;使用与日常管理员账号不同的认证方式,微软推荐 FIDO2 通行密钥或证书认证这类抗钓鱼方式;并监控这些账号的登录,一旦使用就通知其他管理员。它不能让员工在 Exchange 故障时收到邮件,但能保证认证或配置出问题时,管理员不会被锁在门外。
  4. 把数据副本放到另一家云。 把 Exchange、OneDrive、SharePoint 中的重要数据,定期备份到 AWS 或 Google Cloud 的日本国内区域,最好设成不可更改的副本。故障或误删时,关键资料仍然能读取。
  5. AI Agent 的冗余。 这次 OpenAI 和 Anthropic 的 Microsoft 连接器都受到影响。让 AI Agent 进入业务流程时,要假设上游一定会停:任务先进队列,失败时自动重试并通知负责人;Agent 用的知识库在 Microsoft 365 之外保留一份;模型调用准备不止一条路径,例如 Amazon Bedrock 的日本国内跨区域推理,它只把请求路由到东京和大阪两个区域。
  6. 监控、判断与演练。 同时看厂商的状态页、Downdetector 这类外部监测和自己的合成监控;事先写好切到第二条路的判断标准和操作手册,例如关键业务中断超过 30 分钟就启动;每年至少演练一到两次。这里的 30 分钟和演练频率是我们的建议,不是任何标准的要求。

五、从哪里开始:按投入从小到大

  • 本周: 把紧急联络名单和备用联络渠道放到 Microsoft 365 之外;确认紧急访问账号能正常登录;订阅微软的服务状态通知。
  • 本月: 给业务分级,定下每项业务能容忍的停机时间(RTO)和数据丢失范围(RPO);选定邮件持续和备份方案。
  • 本季度: 给 AI Agent 和自动化流程加上降级路径和多条模型路径;做一次切换演练。

结语

没有不会停的云。这次故障提醒日本企业,要问的不只是「哪家云最可靠」,还要问「它停的时候,我的业务还剩哪条路」。

把这条路提前修好,花的钱通常比一天停摆的损失少得多。从一张紧急联络名单开始,就已经比大多数企业准备得更充分。

ソラナリンク株式会社(SolanaLink Co., Ltd.)是一家位于东京的 IT 服务公司,提供云解决方案、Web 与移动开发、IT 运维和 AI Agent 落地。如果你的团队需要梳理业务分级、设计跨 AWS、Google Cloud 和 Microsoft 365 的持续运营方案,或者搭建能降级的 AI Agent 工作流,欢迎通过 info@solanalink.jp 联系我们。

参考资料

11 月 12 日的故障

此前的故障

SLA、政府云与身份

AI 与日本国内推理

评论

评论 (0)