当云端倒下：Microsoft 365 故障，以及企业该带走什么

11月12日基辅时间18时17分，Microsoft 365 发生故障，截至本文发布仍在持续。邮箱、日历、Teams 和 SharePoint 都打不开。全球企业受到波及，其中也包括乌克兰的公司——在这里，大部分企业邮箱都跑在 Microsoft 365 上。

我们自己的邮箱也中招，于是动手查清究竟哪里坏了。以下是我们亲自核实的事实、微软的官方说法，以及最重要的一点：无论你用不用微软，作为企业主该从中带走什么。

究竟哪些功能不可用

面对「邮件打不开」，第一反应总是一样的：是我们自己的问题，是密码、是网络、是域名设置。所以我们先查自己这一侧，结果很清楚。

• 账号登录正常。 微软能识别用户并授予访问权限——也就是说，密码、权限和访问设置都与此无关。
• 拉取邮件返回服务器错误 ——代码 502。不是「没有权限」，不是「密码错误」，而是「服务器无法响应」。
• 日历同样失败 ——代码 503。可见问题不只在邮件，而在 Exchange Online 承载的一切。
• 域名的邮件记录（MX）没有变动 ，仍然指向微软。邮件发往该去的地方。

结论很简单：我们这一侧完好，不响应的是服务本身。任何心存疑虑的人都该做同样的检查——只需几分钟，就能消除一半疑问。

官方时间线

微软用两个编号跟踪这次故障： EX1550543 ——Exchange Online 邮箱的访问； MO1550821 ——所有依赖 Exchange 的部分。Teams 的另一起故障（TM1550488）已关闭。最初说的是美洲，后来措辞改为「可能影响任何地区的用户」。

以下时间为基辅时间。

• 11月12日 18:17。 用户无法打开邮箱。微软通报正在调查邮件访问问题。
• 20:19。 多个地区同时出现负载升高。
• 21:18。 补充说明：负载上升 并非 因为流量涌入。部分服务器突然不可用，其工作由其余服务器接管。
• 21:43。 发现受影响的服务器通不过自动健康检查——系统自己把它们摘出了服务。
• 21:57。 「未发现与故障开始相关的任何近期变更。」
• 11月13日 00:00。 「受影响服务器上的主进程出现过载，导致处理能力下降。」
• 夜间。 补充说明：过载的正是负责建立安全连接的那个进程。与此同时，微软开始 回滚一项近期的网络配置变更，其时间与故障开始相吻合。
• 06:11。 「我们确认：没有任何迹象表明这是恶意行为所致。」
• 13:04。 亚太地区恢复完成，流量逐步放行，工作向其他地区推进。

原因：至今未予说明

在发布这篇文章时，最诚实的说法是： 没有官方原因。微软的解释在一天之内几经变化——从「我们没看到任何近期变更」到「我们正在回滚一项与故障开始时间吻合的近期网络配置变更」。公司承诺在恢复完成后发布包含原因的完整复盘。

微软明确表态的只有一点： 这不是网络攻击。这一说法在相隔数小时内出现过两次。

这件事最耐人寻味的不是原因，而是修复为何拖了这么久。重新投入使用的服务器， 一旦放流量进去就又倒下。微软直言变更「未按预期生效」。接下来便是原地打转：停止所有更新和配置变更、重启、绕开健康检查、把部分服务器按旧配置重建、用虚拟机补充算力。真正有起色，是在给负责授权与请求路由的组件打了补丁之后。

邮件会怎么样

这是最让人揪心的问题，所以单列一节。

• 投递被延迟 ——微软在故障说明中直接承认了这一点。
• 邮件的等待窗口延长到 48 小时。 通常，服务器若在规定时间内无法投递，就会把邮件退回发件人并标注失败。窗口延长意味着邮件不会被退回，而是在队列里等着。
• 微软未通报数据丢失。 但要说得准确些：它也没有明确表示「没有任何丢失」。字面上说的是，被延迟的邮件会被保留。

实际的做法是：不要重复发送邮件。它们都在队列里，等服务放行，客户会收到重复件。做好迎接涌入的准备——一整天的量会一次到达。

企业现在该做什么

1. 先确认问题不在自己这边。 如果账号能登录、邮件却打不开，那就是服务方的问题。故障状态可在 Microsoft 365 管理中心的「服务运行状况」中查看，编号为 EX1550543 和 MO1550821。
2. 不要动设置。 别人家出故障时，危害最大的反倒是自己这边的「修复」尝试：改掉域名记录、重装邮件客户端、重置密码。等服务恢复，要收拾的就是自己造成的后果。
3. 启用备用通道。 故障期间把与客户的紧急事项转到即时通讯或电话上。给等回复的人一句话——「我们邮件出故障了，请发 Telegram」，总好过一片沉默。
4. 记录停工。 如果停摆让你损失了钱，请把时间和后果记下来。微软有服务水平方面的承诺；这次故障在你的具体情形下是否构成索赔依据，要问你的许可协议和购买许可的合作伙伴。

面向未来的四条结论

这种规模的故障并不常见，若据此得出「云不行」的结论并不正确：放在储藏室里的自有服务器倒得更勤，恢复得更慢。结论在别处。

1. 备用联络通道必须在故障之前就存在，而不是故障当中临时想出来。 如果与客户的全部沟通都走同一家服务商的邮箱，那么它一出故障，你就彻底停摆。Telegram 机器人、企业通讯工具、电话——只要是客户事先知道的都行。
2. 别把所有东西放进一个篮子。 邮件、文档、沟通、身份验证和防护都交给同一家，确实方便，直到它那边出事的那一天。那时一切同时停摆。这次正是如此：随邮件一起倒下的还有 Teams、SharePoint 和 Defender。
3. 赚钱的东西要掌握在自己手里。 网站、订单、目录、询盘——最好放在你能自己查看状态、调起备份、不必等别人报告就能回复客户的地方。
4. 学会分辨「我们这边」和「他们那边」。 本文开头那套简单检查，能省下数小时的慌乱，也能避免对设置做多余的改动。

我们自己是怎么安排的

我们用 Microsoft 365 处理邮件和文档——这次故障里，我们的邮箱同样打不开。但我们为客户做的东西一直在正常运转：基于 我们自有的 Smart CMS 系统的网站、聊天机器人、客户后台和电话系统，都跑在自己的服务器上，与邮件分开。没有一个客户网站因这次故障受影响。

这正是结论里说的风险分摊：办公工具交给可靠的外部服务商，而负责销售和接单的部分，放在我们自己能负责的地方。

关于信息来源

访问、邮件记录状态和响应代码的检查，都是我们自己做的。微软的时间线与引述，取自其在管理中心和服务状态页面的通告——经由行业观察者的转述并相互比对，因为这两个来源只对特定客户的管理员开放。对每一位企业主而言，第一手来源是自己的管理中心。

---

本文由 SmartGT团队撰写。如果你拿不准自己的业务对单一服务商的依赖有多深，也不确定在这样的日子里自己的网站会怎样——请联系我们： center@uvc.in.net 或 +38 073 949 61 79。我们一起看看，并坦率地告诉你哪些该分到不同的篮子里。