2021年10月4日15:40（UTC）前后，一条用于评估骨干网容量的维护命令执行出错，切断了Facebook全部数据中心之间的骨干连接；边缘DNS服务器健康检查失败后自动撤回BGP公告，Facebook、Instagram、WhatsApp从全球路由表中“整体消失”约六个多小时，波及约35亿月活用户，甚至逼得工程师带着工具物理进场抢修。本文以Meta官方复盘和Cloudflare的第三方技术分析为主轴，逐层拆解这条“自动化反噬自动化”的故障传导链，以及它留给所有网络运维人的教训。
干网络这行十多年，我见过各种姿势的断网：光缆被挖断、UPS起火、割接脚本写错一行、DDoS把会话表打满。但2021年10月4日这一次，属于另一种类型——网络没有坏，而是网络“消失”了。
Cloudflare的工程师当天在监控里看到了一生难忘的一幕，他们后来在技术分析文章《Understanding how Facebook disappeared from the Internet》（blog.cloudflare.com/october-2021-facebook-outage/）里写道：你有多少机会能看到Facebook把面向全世界的路由整体撤回？BGP还是那个BGP，协议没有Bug，全球运营商的路由器也都在正常工作——只是AS32934（Meta的自治域）主动把自己从互联网上“摘”了下去。
这不是运营商的网，却值得每一个通信运维人逐字精读。因为它演示了一种最危险的故障形态：每一步自动化都按设计运行，串联起来却是一场灾难。下面按官方复盘（Meta工程博客《More details about the October 4 outage》，engineering.fb.com/2021/10/05/networking-traffic/outage-details/）和Cloudflare的第三方测量，把这场事故完整过一遍。
先把时间线摆出来（均为UTC，北京时间+8）：
| 时间（UTC） | 事件 | 信息来源 |
|---|---|---|
| 10-04 约15:35 | 骨干网容量评估类维护命令执行出错，数据中心间骨干连接被切断 | Meta官方复盘 |
| 约15:39–15:40 | 全球各地观测到AS32934的BGP路由大规模撤回 | Cloudflare测量 |
| 15:40–16:00 | Facebook、Instagram、WhatsApp、Oculus全线不可达，域名解析失败 | 各方监测一致 |
| 16:00前后 | Meta内部确认重大故障；员工发现内部工具、门禁异常 | 官方复盘+当时报道 |
| 16:30前后 | 确认远程管理通道不可用，决定派工程师物理进入数据中心 | Meta官方复盘 |
| 约17:50 | 骨干网开始逐步恢复，部分流量回归 | Meta官方复盘 |
| 约21:00–22:00 | 主流服务陆续上线，Meta宣布全面恢复 | 官方复盘与公告 |
| 10-05 | Meta发布正式复盘博客，VP基础设施Santosh Janardhan署名 | Meta工程博客 |
三个细节值得注意。第一，故障是“瞬间全球生效”的——没有渐变、没有区域蔓延，因为BGP撤回是秒级扩散到全网的，这正是路由协议的设计目标被用在了错误的方向上。第二，Downdetector在半小时内涌入数以万计的用户投诉，各大社交平台上“Facebook挂了”本身成了热门话题——用户只能跑去竞品讨论竞品的宕机。第三，这不是Facebook第一次大规模瘫痪：2019年3月13日那次因服务器配置变更引发的级联故障持续了约14小时，是它历史上最长的一次；但2021年这次的特殊性在于根因的链条更长、更隐蔽，值得逐环拆解。
Meta官方复盘把根因写得非常坦率：当天，团队执行了一条用于评估全球骨干网容量可用性的维护命令。这条命令出了错——它的实际效果是把Facebook各数据中心之间的骨干网连接全部切断，等于把分布在全球的数据中心变成了彼此孤立的孤岛。
接下来的连锁反应，是本文最值得反复咀嚼的部分：
flowchart TD
A["运维执行骨干网容量评估命令"] --> B["命令出错，切断数据中心间全部骨干连接"]
B --> C["全球数据中心彼此失去互联"]
C --> D["边缘DNS服务器健康检查失败"]
D --> E["DNS服务器自动撤回自身的BGP公告"]
E --> F["AS32934从全球路由表中消失"]
F --> G["外部递归DNS无法到达Facebook权威服务器"]
G --> H["facebook.com等域名解析失败"]
H --> I["App与网站全线不可达"]
C --> J["内部管理网与带外通道同时失联"]
J --> K["无法远程修复，只能派工程师物理进场"]
注意这条链上的一个关键设计悖论：DNS服务器撤回自己的BGP公告，本意是故障时的正确行为——既然我不可达了，就不该继续吸引流量，免得用户把查询发进黑洞。这个健康检查+自动撤回机制在99.99%的场景里是优雅的自愈设计。但在这天，它成了“雪上加霜”的放大器：骨干断了，DNS服务器并没有坏，却按照设计逻辑把自己从网络上注销了。
我们做核心网的人对此应该有肌肉记忆：任何一个“故障时自动收敛”的机制，都要回答一个问题——当它的判断依据本身失效时，它收敛到的状态是安全还是致命？ 健康检查依赖带内探测，带内探测依赖网络可达性，而网络已经不可达——用故障链路上的信号去判断故障，得出的结论必然是“全面故障”，然后执行最激进的动作。
如果只是BGP撤回，理论上还有救：用户侧递归DNS里可能还有缓存，或者Facebook可以快速重新公告。但Cloudflare的分析揭示了一个更精巧的死亡螺旋——解析路径的自指结构。
Facebook没有把权威DNS托管给外部厂商，而是自建了遍布全球边缘PoP的权威DNS集群，这些服务器的IP地址通过自己的BGP对外公告。问题在于：
Cloudflare的测量数据直观地展示了用户侧行为：故障期间，其公共递归服务1.1.1.1收到的Facebook域名查询量从平日约125次/秒暴涨至峰值约33,700次/秒——接近270倍。全球数十亿终端在不断重试解析，而答案永远是SERVFAIL或超时。Cloudflare还观测到，故障期间全球流量出现了明显的再分配：Facebook系流量归零后，大量用户涌向其他平台。
这个死锁给所有自建DNS的机构提了醒——不只是互联网公司，运营商的DNS同样如此。我们很多省网的DNS解析链条也是“自己的域名由自己解析”，NS指向自家域名下的主机名。平时这叫自主可控，故障时它叫解析死锁：你的整个解析体系共享同一个故障域。解法说破不值钱但执行要下决心——关键的 glue 基础设施至少要让解析链条上存在一条不经过自身生产网公告路径的独立通道，哪怕是注册商侧的静态兜底记录。
故障定位并不算慢——Meta的团队很快明白骨干网断了、命令需要回退。真正的噩梦是：回退做不了。
官方复盘承认了两个次生困境：其一，远程运维通道（包括数据中心间的管理互联）依赖被切断的同一张骨干网，工程师手里所有“远程处置”的工具全部失效；其二，更荒诞的一幕出现了——数据中心的门禁系统跑在同一张网络上，员工刷卡进不了机房，办公室门打不开，会议室的投屏也黑着。内部协同工具同样瘫痪，据当时Bloomberg等媒体报道，工程师一度只能靠个人聊天工具互相联系。
最终Meta派工程师赶赴圣克拉拉数据中心，用近乎原始的方式——直连服务器控制台、手动操作——逐段恢复骨干连接。官方复盘的原话很诚实：这些手段“粗糙得像用螺丝刀修服务器”。17:50 UTC前后骨干网开始恢复，DNS服务器重新公告路由，约22:00 UTC服务全面上线，距离故障开始约六个多小时。
这一段对通信运维人的杀伤力最大，因为我们最清楚带外管理（OOB）四个字的分量。运营商网络里，核心网元普遍要求独立于承载网的网管通道，SON、短信猫、拨号备份，土办法年年在用，就是因为“生产网断网时你还得管得住设备”。Meta作为全球最顶尖的网络团队之一，不可能不懂OOB，它的教训在于规模：当你的管理平面、安全平面、办公平面全部长在同一张超大规模骨干上，任何“带外”都是自欺欺人。带外的本质不是多拉一根线，而是故障域的物理隔离——这根线所依赖的每一跳，都必须在主网故障时依然活着。
评估这次事故的影响，不能只看“刷新不出朋友圈”：
还有一个常被忽略的维度：故障期间Meta自己的安全与反滥用系统同样下线。官方复盘提到，这六个小时里平台对抗垃圾信息和恶意账号的能力也被削弱。断网从来不只是“服务不可用”，对平台方来说，它同时意味着防御短暂失明——这也是为什么重大断网事故往往伴随滥用行为的小高峰。
Meta复盘里给出的整改方向，可以归纳为一张对照表——我按运维视角补一列解读：
| 官方整改方向 | 具体动作 | 老兵解读 |
|---|---|---|
| 高危操作加固 | 对命令行维护工具增加物理隔离的审核机制 | “双人复核”要落到流程系统里，不能停留在班组公约 |
| 增加guardrails | 为骨干网相关命令增加测试与防护栏，防错误配置下发 | 等价于核心网的“指令白名单+影响面预演”，高危命令必须先在实验室过弹 |
| 故障域隔离 | 增强骨干网连接的故障隔离设计，避免单点操作波及全网 | 把“一根光纤都不剩”这种全断场景，从理论可能变成不可能 |
| DNS基础设施加固 | 边缘PoP与DNS网络增强冗余，解析路径去耦 | 针对本文第三节的解析死锁，给解析链条留独立生命线 |
| 恢复能力建设 | 加快重大故障的诊断与物理恢复流程 | “物理进场SOP”要提前写好：谁去、带什么、先进哪台设备 |
在官方清单之外，我把这场事故浓缩成六条教训，按优先级排给你：
复盘的尾声值得加上一段后续。据BGPStream等公开BGP监测平台记录与当时多家网络媒体的报道，2024年12月11日，AS32934又出了一次幺蛾子：Meta的自治域向全球宣告了一批RFC1918私网地址段（如10.10.10.0/24等大量保留前缀），持续数十分钟后撤回。由于私网地址本不该在公网路由，这次事件对普通用户影响有限，但它让全世界的网络工程师得以窥见Meta内部网络的拓扑一角，也说明即便是复盘过2021年大事故的团队，路由公告这类“一把梭”的操作依然存在出错的敞口。
这不是打脸，而是行业常态：网络安全的进步不是消灭事故，而是把同一次事故的复发概率和爆炸半径压小。2019年那次之后Meta没有改到位的地方，2021年付了学费；2021年之后的整改，到2024年依然有边缘在漏光。我们运营商的割接、升级、调参又何尝不是如此——每次复盘都说“举一反三”，真正值钱的是把教训固化成不能绕过的系统约束，而不是攒成一页没人再打开的PPT。
回到Cloudflare工程师那个感叹：你有多少机会看到Facebook从全世界消失？答案是：在一个把全部鸡蛋放进同一张超大规模网络、又让自动化替你守着鸡蛋的体系里，只需要一条维护命令。
这场事故最反直觉的地方在于：它不是能力不足造成的，恰恰是能力过剩造成的——自动化足够强，所以错误传播足够快；网络足够统一，所以故障域足够大。这对正走在自智网络、L4自动驾驶网络路上的通信行业，是一记及时的提醒：我们给网络装上越来越聪明的“自动收敛”，也必须同步给它装上“在什么情况下不许自动”的缰绳。
给网络自动化的每一把“删除键”配一把锁——这大概就是35亿用户换来的、最朴素的一条经验。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。