# BGP一撤，Meta瘫了6小时：2021年全球最大断网事故复盘 ## 概述 2021年10月4日15:40（UTC）前后，一条用于评估骨干网容量的维护命令执行出错，切断了Facebook全部数据中心之间的骨干连接；边缘DNS服务器健康检查失败后自动撤回BGP公告，Facebook、Instagram、WhatsApp从全球路由表中“整体消失”约六个多小时，波及约35亿月活用户，甚至逼得工程师带着工具物理进场抢修。本文以Meta官方复盘和Cloudflare的第三方技术分析为主轴，逐层拆解这条“自动化反噬自动化”的故障传导链，以及它留给所有网络运维人的教训。 ## 目录 - 一、灾难现场：六小时，全球路由表里没有Facebook - 二、根因拆解：一条维护命令如何推倒整张网 - 三、解析死锁：为什么连DNS都救不了它 - 四、最难的一步：门禁失灵与“螺丝刀式”抢修 - 五、影响面：35亿用户之外，还有谁被拖下水 - 六、官方整改清单与老兵的六条教训 - 七、三年后的回声：私网地址泄漏事件 - 结语：把“删除键”锁进保险柜 ## 引言 干网络这行十多年，我见过各种姿势的断网：光缆被挖断、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的第三方测量，把这场事故完整过一遍。 ## 一、灾难现场：六小时，全球路由表里没有Facebook 先把时间线摆出来（均为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各数据中心之间的骨干网连接**全部切断**，等于把分布在全球的数据中心变成了彼此孤立的孤岛。 接下来的连锁反应，是本文最值得反复咀嚼的部分： ```mermaid 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服务器并没有坏，却按照设计逻辑把自己从网络上注销了。 我们做核心网的人对此应该有肌肉记忆：**任何一个“故障时自动收敛”的机制，都要回答一个问题——当它的判断依据本身失效时，它收敛到的状态是安全还是致命？** 健康检查依赖带内探测，带内探测依赖网络可达性，而网络已经不可达——用故障链路上的信号去判断故障，得出的结论必然是“全面故障”，然后执行最激进的动作。 ## 三、解析死锁：为什么连DNS都救不了它 如果只是BGP撤回，理论上还有救：用户侧递归DNS里可能还有缓存，或者Facebook可以快速重新公告。但Cloudflare的分析揭示了一个更精巧的死亡螺旋——**解析路径的自指结构**。 Facebook没有把权威DNS托管给外部厂商，而是自建了遍布全球边缘PoP的权威DNS集群，这些服务器的IP地址通过自己的BGP对外公告。问题在于： 1. facebook.com等域名的权威NS记录，指向的是Facebook**自己的域名体系**（如*.facebook.com、*.fbcdn.net下的名字）； 2. 递归解析器要找到这些权威服务器的IP，必须先解析这些“ glue记录”所属的域名——而这些域名同样由Facebook自己的权威服务器负责； 3. 当AS32934整体从路由表消失，这个解析链条的**每一环**同时断裂，不存在任何外部兜底路径。 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，它的教训在于**规模**：当你的管理平面、安全平面、办公平面全部长在同一张超大规模骨干上，任何“带外”都是自欺欺人。带外的本质不是多拉一根线，而是**故障域的物理隔离**——这根线所依赖的每一跳，都必须在主网故障时依然活着。 ## 五、影响面：35亿用户之外，还有谁被拖下水 评估这次事故的影响，不能只看“刷新不出朋友圈”： - **用户规模**：当时Meta“家族”应用月活约35亿，Facebook、Instagram、WhatsApp、Messenger、Oculus全线受影响。其中WhatsApp在拉美、印度、非洲很多市场承担的是**基础通信设施**的角色——家人联系、小商铺接单、社区通知都走它。 - **经济影响**：大量跨境小商家依赖WhatsApp Business接单，中断期间交易停摆；广告主一侧，Meta当日股价收跌近5%，据彭博等当时估算，扎克伯格个人身家缩水数十亿美元。 - **流量再分配**：据当时Sandvine等流量监测机构的估计，全球互联网总流量因Facebook系服务下线一度下降约5%——一个公司“下线”能搬动全球五个百分点的流量，这个体量本身就是互联网集中度的注脚。与此同时TikTok、Twitter等平台出现流量激增。 - **次生怪象**：WhatsApp的群组邀请链接因服务器异常被外泄，大量陌生人涌入陌生群聊，一时间出现了“公开群”奇观；医院的预约系统、企业的客服热线（跑在WhatsApp上的）也受到波及。据当时用户与媒体反馈，这些次生影响甚至比App本身不可达更令人不安。 还有一个常被忽略的维度：**故障期间Meta自己的安全与反滥用系统同样下线**。官方复盘提到，这六个小时里平台对抗垃圾信息和恶意账号的能力也被削弱。断网从来不只是“服务不可用”，对平台方来说，它同时意味着防御短暂失明——这也是为什么重大断网事故往往伴随滥用行为的小高峰。 ## 六、官方整改清单与老兵的六条教训 Meta复盘里给出的整改方向，可以归纳为一张对照表——我按运维视角补一列解读： | 官方整改方向 | 具体动作 | 老兵解读 | |---|---|---| | 高危操作加固 | 对命令行维护工具增加物理隔离的审核机制 | “双人复核”要落到流程系统里，不能停留在班组公约 | | 增加guardrails | 为骨干网相关命令增加测试与防护栏，防错误配置下发 | 等价于核心网的“指令白名单+影响面预演”，高危命令必须先在实验室过弹 | | 故障域隔离 | 增强骨干网连接的故障隔离设计，避免单点操作波及全网 | 把“一根光纤都不剩”这种全断场景，从理论可能变成不可能 | | DNS基础设施加固 | 边缘PoP与DNS网络增强冗余，解析路径去耦 | 针对本文第三节的解析死锁，给解析链条留独立生命线 | | 恢复能力建设 | 加快重大故障的诊断与物理恢复流程 | “物理进场SOP”要提前写好：谁去、带什么、先进哪台设备 | 在官方清单之外，我把这场事故浓缩成六条教训，按优先级排给你： 1. **自动化是双刃剑，先审计“故障时的自动行为”**。健康检查触发BGP撤回这类机制，上线前要推演最坏触发条件。凡是“自动收敛”，必须回答“判断依据失效时收敛到哪”。 2. **画出你的解析依赖闭环**。把自家权威DNS的解析链条画到底，确认里面不存在“解析自己必须先经过自己”的环。存在环的，立刻补外部兜底。 3. **带外管理要 annual audit**。OOB通道每年至少做一次“主网全断”演练验证。没验证过的带外，等于没有带外。 4. **高危命令分级管控**。能影响全网拓扑的命令，必须走变更窗口、双人复核、灰度下发。容量评估类“只读”工具要按能“写”的权限管理——这次事故的命令名义上是评估，实际有写副作用。 5. **恢复演练包含物理路径**。门禁、照明、控制台访问，这些“不联网就没法干活”的环节要纳入演练。断网演练如果只测业务切换，不测“你能不能走进机房”，就是半场演练。 6. **重大故障预案要包含“平台自身防御降级”**。断网期间垃圾信息、诈骗、冒名行为会激增，恢复上线时要有灰度启用防御的步骤，而不是开着门裸奔。 ## 七、三年后的回声：私网地址泄漏事件 复盘的尾声值得加上一段后续。据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亿用户换来的、最朴素的一条经验。 ## 参考来源 1. [More details about the October 4 outage — Meta Engineering](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/) — Meta基础设施副总裁Santosh Janardhan署名的官方复盘，本文根因链条、恢复过程与整改方向的权威主轴 2. [Understanding how Facebook disappeared from the Internet — Cloudflare Blog](https://blog.cloudflare.com/october-2021-facebook-outage/) — Cloudflare工程师团队的第三方技术分析，BGP撤回观测、DNS查询量测量（峰值33,700 QPS）与解析死锁机制详解 3. [How To Complex: Facebook BGP Edition — Jan Schaumann (Stevens Institute)](https://www.cs.stevens.edu/~jschauma/810/facebook-bgp.html) — 网络安全教授制作的事件深度讲义与视频讲解，对BGP与DNS技术细节的逐帧拆解 4. [Facebook, Instagram, and WhatsApp are down — Hacker News](https://news.ycombinator.com/item?id=28774073) — 事故当天登顶Hacker News的实时讨论帖，数千条从业者与一手目击者的讨论 --- > 本文由「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 等场景全覆盖。