美国服务器业务遇上Outlook宕机两天：怎么分清是自己的问题还是云的问题

美国时间8月31日上午（北京时间当晚深夜），Outlook用户开始大量反映收不到邮件、登不上邮箱，Downdetector的报障量很快冲到了数万级。微软在管理中心挂出的事件编号是EX1464935，最初只把受影响服务列为Exchange Online。到9月2日，也就是事发48小时后，微软的说法是可用性已回到99%以上、多数用户不再受影响，但Exchange Online、OneDrive for Business、SharePoint Online等几项服务仍未完全恢复。

这件事有两个地方值得记下来。

第一个是事发初期的信息落差。用户已经登不上邮箱、报障曲线已经冲起来的时候，微软365的服务状态页面还显示一切正常，最先承认出事的是微软365状态账号在X上的一条帖子。也就是说，出事后的头一段时间，你按最“官方”的渠道去查，得到的答案是“没事”。

第二个是故障范围的演变。头几个小时，这看上去只是一次邮件故障。但微软后来查出问题在一个认证组件上，初步说法是一次配置错误导致认证组件没有按预期部署到部分基础设施。认证是公共底座，Exchange Online只是最先、最明显受影响的那一个。随后微软另开了事件MO1465074，把Teams、Microsoft Graph、OneDrive、SharePoint、管理中心、Copilot、Defender XDR等一串服务都列了进去。有人8月31日晚上判断“就是Outlook有点问题”，第二天早上发现自己接微软登录的业务模块也在报错，其实是同一件事。

对租美国服务器跑业务的团队来说，这种时刻要回答的问题只有一个，而且要快：现在这个异常，是我的问题，还是上游的问题。方向判断错了，半小时就浪费在重启自己好好的机器上；更麻烦的是，这半小时里你对客户什么都说不出来。下面是我们建议的判断顺序，不需要什么特别的工具，主要靠先后次序。

收到告警的第一分钟，先做的不是登服务器翻日志，而是切割影响面。看三样东西：服务器本身能不能SSH进去、负载有没有异常、对外的核心接口探测是否通过。如果这三样都正常，只是“发邮件”“微软账号登录”“调某个第三方API”这类具体功能不工作，那问题大概率在外部依赖上，而不在你的机器。反过来，如果多个互不相关的功能同时异常，而它们各自的外部依赖状态又都正常，才轮到怀疑自己的服务器和网络。这一步的价值在于，它把排查范围从“整台机器”缩到了“某一条依赖链”。

第二步是验证外部依赖的状态，这次事件正好说明了为什么不能只看官方状态页。状态页普遍更新滞后，大厂也倾向于内部确认之后再对外公示，等它变红，往往用户已经吵了一阵子了。更快的办法是交叉验证：Downdetector这类聚合平台看报障曲线有没有陡增，X和Reddit上搜服务名看有没有大面积同类反馈，官方状态账号（微软是@MSFT365Status）看有没有出现事件编号。三个来源里有两个指向“外部大面积异常”，就可以先按上游故障处理，不用等状态页表态。

第三步是多点探测，把“对方源站挂了”和“到对方的路断了”分开。从你的美国服务器上对目标做curl和mtr，再从另一个区域的节点（比如香港）做同样的事：两边都不通，多半是对方源站或其上游出了问题；美国通、香港不通，问题更可能在跨洋链路或对方的区域节点上，这时候该找的是线路，而不是对方的状态页。这一步是自己手里有服务器的团队相对于纯SaaS用户的天然优势：你有真实的探测位置，而不是只能刷新页面猜。手里同时有美国服务器和一个亚太节点（比如香港云服务器）的团队，两分钟就能做完这个判断；只有单点的，就得靠前两步。至于怎么把第二个节点纳入日常架构，这个栏目之前写过跨机房容灾与故障切换，这里不重复。

还有一件事，这次不少团队是事后才意识到的：告警通道不能和故障源绑在一起。很多监控系统的告警默认走邮件，而邮件走的就是Exchange。云挂了，通知你“云挂了”的那封邮件也一起挂了，值班的人是被客户群叫醒的，不是被监控叫醒的。更隐蔽的一层是，这次坏的是认证组件。如果你的监控平台、告警机器人或者值班系统本身用微软账号做单点登录，那在最需要它们的时候，你可能连登都登不进去。告警至少要有一条完全不依赖微软和谷歌生态的路径，Telegram机器人、短信、Webhook到你自己服务器上跑的一个小接收端都行，而且这条路径的登录凭据也要是独立的。监控具体该盯哪些指标不是本文的重点，栏目里的告警清单已经写过。

最后是对客户的交代。判断清楚是上游故障之后，第一时间在自己的状态页或客户群里说明三件事：故障源在哪家上游、我方基础设施是否正常、预计影响哪些功能。这次微软的恢复到发稿时已经过了两天还没收尾，期间多次说“多数用户已恢复”，但仍有一部分基础设施没回到健康状态。这意味着你不能只通报一次，得跟着上游的进展更新，直到你自己验证过受影响功能确实好了再宣布结束。客户其实不怕你的依赖出问题，过去几年AWS、Azure、Cloudflare都出过全球性事件，大家已经习惯了；客户怕的是你说不清楚，或者说了“已经恢复”之后又出问题。

大厂的故障你控制不了，这次的根因是微软自己的配置变更，你在自己机器上做任何操作都影响不了它的恢复速度。但“多快定位到是上游问题、多快把这件事说清楚”，完全在你自己手里，这比把服务器重启一遍有用得多。