2026 年 8 月 31 日晚间，Microsoft 365 开始出现大范围中断，在管理中心记录为 EX1464935，随后在 MO1465074 下扩大。影响并不限于电子邮件。Exchange Online 与 Teams、SharePoint Online 和 OneDrive for Business 一同宕机，Purview 和 Defender XDR 中的治理与安全工具也随之停摆。一家通过电子邮件联系客户、通过聊天进行内部协调、把文件存放在云端、通过仪表板监控安全的公司，在同一时刻失去了这四样东西。

Microsoft 将原因描述为 Exchange Online 基础设施中多个内部服务共用的核心身份验证配置出现问题，并采取了分阶段的缓解措施：先在部分基础设施样本上重新应用身份验证组件，然后再扩大范围。邮件流和搜索于 9 月 1 日恢复，对一小部分用户的有限影响一直持续到 9 月 2 日。完整的中断超过了一天，而余波持续了两天。

这不是一篇关于 Microsoft 的文章。每家大型服务商都会出现中断，我们此前也报道过其他人工智能服务的中断。这是一篇关于此次中断所暴露问题的文章，而这个问题比乍看之下更加危险。

你以为的六个系统，可能只是一个

请任何一位管理者列出他们的系统，你会得到一份清单：一个邮件系统、一个聊天系统、一个文件系统、一个安全系统。四个名字，四个图标，合同上通常也是四行。自然的假设是，一个宕机不会连带其他系统，因为它们是不同的东西。

但名字并不是系统的边界。真正的边界是这些服务在底层共享的东西：谁来验证你的身份，会话保存在哪里，数据经过哪个网络。当四个服务共享同一个身份验证层时，从风险角度看它们就是一个服务，无论它们在账单上看起来多么独立。

尴尬之处在于，这种共享在平时从不显现。恰恰相反，正是它为你带来了便捷的单点登录以及邮件与文件之间的顺畅集成。你每天都在购买这份便利，而每隔几年要在漫长的一天里为它付出代价。

这一点对一家中型沙特公司和一家全球企业同样适用。想一想，你有多少服务挂在同一个 Google 账户上，或者同一个 WhatsApp 号码上，或者同一家托管服务商上，或者同一位掌握所有密码的员工身上。每一个都是单点故障。区别在于，你的规模更小，也更容易修复。

用一小时梳理你的依赖关系

你不需要任何工具，也不需要顾问。你需要一张纸、一个小时和诚实的回答。在第一列写下公司一整天都离不开的每一项业务：接收订单、开具发票、回复客户、发放工资、交付服务。然后针对每一项问三个问题：

  • 这项业务依赖哪个外部服务？直接写下商业名称：这家邮件服务商、那个网店平台、那个支付网关、那家消息服务商。
  • 你用哪个账户或身份登录？惊喜通常就在这里出现。你会发现四个不同的服务通过同一个账户进入，或者三个服务绑定在同一个手机号码上接收验证码。
  • 如果它现在停止，一小时内的替代方案是什么？如果答案是没有，你就找到了一个真实而非理论上的单点故障。

完成之后，会有一两个条目在大多数行中重复出现。这些就是你的共享依赖。不要试图把它们全部消除，那既不现实也不经济。先挑出那一行会让收入停止的，优先处理它。

最容易预防的一类中断：到期日

并非所有中断都一样。有些源于你无法掌控的复杂性。另一些则源于写在某个无人查看之处的日期。第二类最容易预防，也最常重复发生，因为它只需要跟进。

以下这些到期日正在悄悄左右你的业务，每一项都应该放进同一个日历，并指定具名负责人：

  • 网站加密证书。证书过期后，你的网站不会变慢，而是向访客显示明确的安全警告，阻止他们进入。对销售的影响是立即且彻底的。
  • 域名注册。忘记续费域名会让网站和电子邮件一起瘫痪，因为电子邮件运行在同一个域名上。这是最糟糕的中断之一，因为它恰好切断了你本该用来解释情况的那个渠道。
  • 电子发票印章证书。天课、税务和海关总局（ZATCA）的电子发票详细技术指南规定，纳税人应在现有标识到期前为其发票生成单元续期加密印章标识，续期包括吊销旧标识并签发新标识。错过窗口期，你面对的就是开票问题，而不只是一条通知。
  • 系统之间的集成密钥。连接你的网店与库存系统、或连接你的系统与支付网关的访问令牌都有规定的有效期。它到期不会让任何一个系统停止，而是让两者之间的桥梁停止：订单继续涌入，同步却悄然中断。这正是那种很晚才被发现的故障。
  • 应用签名证书和绑定的银行卡。签名证书过期会让你无法向应用商店发布更新，订阅上的银行卡过期则会让服务本身停止。两者往往都在最糟糕的时刻到来。

操作规则很简单。任何有到期日的东西都需要三样：提前六十天的提醒、一位具名而非以部门代替的负责人，以及一位在负责人不在时知道如何续期的副手。三者缺一，你就又回到了依赖某个人记性的状态。

服务商宕机当天该怎么做

中断来临时，一家显得专业的企业与一家显得慌乱的企业之间的差别并不在于修复速度，因为修复本来就不在你手中。差别在于你事先准备好的三件事：

  • 一个位于宕机层之外的沟通渠道。如果你所有的内部协调都在同一个工具里，那么它一宕机你就无从协调。在一个真正不同的渠道上建一个备用群组，再加上一份保存在系统之外的联系人名单，就足够了。
  • 为关键业务明确规定的手动模式。没有系统时，你如何接单、记录付款并交付服务？今天就把它写在一页纸上，交给团队。写了这页纸的公司损失几个小时，没写的公司损失一整天。
  • 一条为客户准备好的消息。让客户生气的与其说是中断，不如说是沉默。一条简短的通知，说明哪些受到影响、临时解决办法是什么、下一次更新何时发布，就能把一次故障变成一个可控的局面。不要承诺你无法掌控的修复时间。

结束之后，只问一个问题，不多问：今天我们对自身依赖关系有了哪些以前不知道的认识？这个答案比任何报告都更有价值，而它通常只是一行字，值得做一处改动。

Origami 的观点

在我们的工作中，最让企业主吃惊的很少是中断本身，而是发现他们以为相互独立的系统竟然一起宕机了。一个建立在“我们有替代方案”这一信念上的决策，一旦发现所有替代方案都经过同一扇门，就会土崩瓦解。因此，我们在任何关于连续性的讨论中都先从梳理依赖关系入手，而不是先购买工具，因为你买的工具很可能就建立在同一层上，反而增加风险而不是降低风险。

我们还认为，对这样一次中断的正确回应并不是逃离云。正规服务商的云基础设施比大多数公司自行构建和运维的系统更可靠，一次罕见的中断并不会改变这一点。正确的回应是准确知道你的哪些业务会停止、哪些会继续，并且是经过深思熟虑做出的选择，而不是在糟糕的一天才发现。连续性不是一个可以买来的系统，而是在没有任何压力时你所做出的一系列小决定。

结论

共享身份验证层中的一个故障，让全球各地公司的六款产品停摆超过一天。教训不是更换服务商，而是弄清你的系统在表面之下究竟共享了什么。从一张能揭示依赖关系的三列表格开始，把所有到期日放进同一个日历并指定具名负责人，在需要之前写好手动模式那一页。这大约三个小时的工作挡在你与一整天的瘫痪之间，因此它是最便宜的连续性投资。

参考来源