一天之内微软365宕机10小时、美国全国航班停飞：云依赖时代怎么写应急预案

11 月 12 日至 14 日，全球科技基础设施经历了一次罕见的连环考验。两起看似无关的故障，指向同一个问题：我们对少数几个系统的依赖，已经远超想象。

发生了什么

事件一：微软 365 大规模宕机。 当地时间 11 月 12 日，Microsoft 365 多项核心云服务发生大规模故障，中断持续超过 10 小时，影响 Outlook、Teams 等核心应用，日本政府部分业务一度受阻。

微软北京时间 14 日凌晨致歉，说明故障由一次网络容量升级中的问题引入，在近期一次网络变更后暴露，与网络攻击、人工智能无关，底层问题已解决。

事件二：美国全国航班停飞。 北京时间 11 月 14 日凌晨 4 时 46 分，芝加哥奥黑尔机场首先出现通信故障，11 分钟后扩展至全美。FAA 将局部停飞升级为全国性地面停飞，影响全美 22 个区域航路交通管制中心，约 8000 架次延误，3100 架飞机在空中。FBI 初步排除网络攻击。

欧洲航空安全组织随后通告，暂停成员国赴美航班起飞。

对普通技术团队的三点提醒

第一，”云”不是默认可靠。 头部云厂商的 SLA 通常写 99.9%，但那是年度平均值。一次 10 小时的故障，就足以吃掉全年的额度。关键业务必须假设”云会挂”。

第二，单一依赖是最大风险。 邮件、IM、文档、身份认证都绑在同一家云上时，一次故障就是全面停摆。至少把”身份认证”和”关键通信”拆到不同供应商。

第三，变更管理比灾备更现实。 微软这次明确说是”网络容量升级中的问题，在后续变更后暴露”。绝大多数线上事故源于变更，不是黑客。上线前的灰度、回滚预案、变更窗口，比买多少备份都管用。

一份最小应急清单

1. 列出你的单点依赖：哪些服务挂了，业务会在 1 小时内停摆？
2. 准备离线通道：云 IM 挂了，有没有备用通知方式（短信、电话树）？
3. 数据本地可读：关键文档是否有本地副本，能否在断网状态下打开？
4. 写清楚”谁来决定”：故障时谁有权限切换、谁对外沟通，提前定好，别现场吵。
5. 每季度演练一次：不演练的预案等于没有。

技术选型时可以追求先进，但应急预案必须假设最坏。这不是保守，这是清醒。