摘要

  • 一条维护命令切断了骨干网连接，随后 DNS 路由被撤销。DNS 服务器仍在工作，但互联网已无法抵达。
  • 工程师需要先恢复访问，再谨慎重启服务。外部观测中的五个半小时，不能等同于所有用户的停机时长，更不是赶往机房的耗时。

用户打不开应用，工程师去修；可如果工程师也进不去呢？2021 年 10 月 4 日，Facebook 遇到的正是后一层麻烦。故障让 Facebook、Instagram 和 WhatsApp 难以访问，也破坏了公司用于排查和恢复的部分通道。

这不是“服务器全坏了”的故事。按照公司次日发布的工程说明，一些关键服务器始终在运行。问题是，无论用户还是修复人员，都需要一条仍然可用的路才能发挥它们的作用。

本来要查容量，结果切断了连接

起点是一次例行维护。工程说明称，一条原本用于评估全球骨干网可用容量的命令，意外断开了骨干链路，数据中心之间因此失去连接。用于阻止此类命令的审查工具又存在程序缺陷，没能拦住这次操作。

接着，DNS 服务器采取了预设动作。DNS 帮助设备把服务名称找到对应的地址；这些服务器无法再通过骨干网连到数据中心，于是撤销了自己的 BGP 路由公告。BGP 是网络之间交流“哪些目的地可以从这里抵达”的方式。公告撤回，通往 DNS 服务器的路线也就不再可用了。

因此，“还在运行”和“用户能够访问”是两回事。反复打开应用，并不能把已经撤销的路线重新找回来。DNS 服务器没有停工，不代表手机还能向它问到地址。

恢复连接之前，先恢复访问

公司称，常规网络访问和带外管理访问都不可用了。带外访问是为了在常规通道失效时管理设备而设置的另一条通道。与此同时，DNS 的丢失也影响了内部排障工具。两种问题同时发生，但工程说明没有证明“DNS 失效直接导致带外通道失效”，不能把它们写成一条已经证实的因果链。

工程师被派往现场恢复访问。物理安全和系统安全措施使进入现场、修改设备变得更困难，这是公司描述的恢复障碍。材料并没有提供一位工程师奔赴机房的完整故事，也没有把路上花费的时间单独测出来。

访问恢复、骨干网重新连接后，事情仍未结束。服务同时恢复可能带来骤增的流量和电力需求，公司因此谨慎安排重启。此前的故障演练在这一步派上了用场，但整个全球骨干网全部中断的情景，此前并未演练过。

外面看见的时间，不是里面每一步的时间

Cloudflare 的观测提供了另一只时钟。它在 UTC 时间 15:40 左右看到路由变动明显增加，15:58 注意到 Facebook DNS 前缀的路由撤回。其他 Facebook 前缀仍有路由，并非这家公司的所有网络地址都一起消失。

到了 21:00 左右，BGP 活动重新出现，21:17 达到一个峰值；21:28，全球连接和 DNS 解析看来已恢复。应用服务仍可能需要更多时间。

从 15:58 算到 21:28，是 330 分钟。这个数字能说明两个观测节点之间相隔多久，不能说明每个国家、每种应用、每位用户都经历了完全相同的停机时长。它更不是工程师到达机房的计时。前两个节点之间的 18 分钟，也不足以证明公司内部只有那么一小段发现故障的机会。

外部记录与公司的解释能够相互参照，却不能直接看见那条维护命令、审查工具的状态或内部报警过程。分清这一点，才能既使用独立观测，又不让它替无法观测的细节作证。

故障期间，应用和解析器不断重试，也给其他 DNS 服务增加了负担。不过，Cloudflare 称其 1.1.1.1 解析器的大多数查询仍在十毫秒内完成，只是最慢一部分查询的延迟上升。这场故障影响了 Facebook 以外的服务负载，并不等于整个互联网瘫痪。

回看这次事件，最值得注意的是恢复本身也会遇到故障：机器可能正常，路却断了；路接通了，服务又不能一拥而上。这两份当年的记录解释了 2021 年的困难，不能单凭它们判定 Meta Platforms 今天采用什么架构，或后来究竟落实了哪些改进。

2026 年 10 月 21 日更正：区分了管理访问中断与依赖 DNS 的工具失效，不再把外部观测时段等同于工程师路程或所有服务的停机时长，并删除了仅凭 2021 年资料推断当前架构的表述。