**概述**：2021年10月4日15:39（UTC），Facebook、Messenger、Instagram、WhatsApp在全球范围内集体失联，持续六到七个小时，Downdetector收到超过1000万份故障报告，创当时历史纪录。事后复盘显示：引爆它的不是黑客、不是光缆被挖断，而是维护中发出的一条骨干网容量评估命令，加上一个审计工具的Bug，再叠加一套“DNS失联就自撤路由”的联动设计。本文以Cloudflare工程团队的路由侧复盘和Meta官方工程博客为主轴，按时间线拆解这次互联网史上最著名的断网事故，并给出通信运维视角的四条作业。 ## 目录 - 事发：15:39，全球一起“拔网线” - 一张时间线表，看懂六小时 - 根因：三层设计的完美风暴 - 恢复：为什么修了六个小时 - 影响面：这一跤摔掉多少钱 - 给通信人的四条作业 - 参考来源 ## 事发：15:39，全球一起“拔网线” 2021年10月4日，北京时间深夜、美国西海岸清晨、欧洲傍晚。全球用户陆续发现，Facebook打不开了，WhatsApp消息转圈发不出去，Instagram刷新一片白。这不是区域性劣化，而是全球同时熄灯。 Cloudflare的工程师是最早察觉异常的第三方之一。15:51 UTC，他们内部立项了一个事件工单，标题是“Facebook DNS解析返回SERVFAIL”——一开始还以为是自己家1.1.1.1递归解析器出了问题，准备去状态页发公告时才发现：不是我们的问题，是Facebook整个从互联网上“消失”了。Cloudflare的描述很形象：就好像有人把Facebook所有数据中心的网线同时拔了。 从协议层看，事情一目了然。15:39 UTC起，Facebook的自治域（AS32934）开始大规模撤回BGP路由公告，其中致命的一条：它把自家全部权威DNS服务器所在的IP前缀一并撤掉了。路由没了，全球任何一台递归DNS都连不上Facebook的权威服务器，`dig facebook.com`一律返回SERVFAIL。Cloudflare在文章里贴出了route-views的实测输出——`% Network not in table`，那两个前缀从全球路由表里被整个抹掉了。 用户端的表现则五花八门。App打不开、网页报DNS错误是基本盘；依赖"Log in with Facebook"登录的第三方网站跟着遭殃，一批没有其他登录方式的用户被彻底锁在门外。更讽刺的是Facebook内部：据《纽约时报》报道，员工连工牌刷门禁、订会议室都失灵了——这些内部系统同样依赖那套已经瘫痪的DNS和内网服务。工程师发不出外部邮件、连不上公司通讯录，Zoom和Google Docs的企业认证也挂了。修复事故的人，自己先被困在了事故里。 对通信工程师来说，这个场景一点都不陌生。一张网在凌晨时分因一次例行变更整体趴下、告警系统跟着失明、修复人员进不了“机房”——这一整套戏码，运营商核心网 decade 里演过不止一次。区别只在于：Facebook这张“网”的用户数，是普通运营商的十倍。 ## 一张时间线表，看懂六小时 把Cloudflare实测数据、Meta官方复盘和维基百科汇总的媒体报道对齐后，整场事故的关键节点如下（均为UTC时间）： | 时间（UTC，10月4日） | 事件 | |---|---| | 15:39 | 骨干网配置命令生效，Facebook开始大规模撤回BGP路由，含全部权威DNS前缀 | | 15:40 | Cloudflare观测到来自AS32934的路由变更消息达到峰值 | | 15:50 | 主要公共DNS缓存过期，facebook.com等域名在全球范围内解析失败 | | 15:51 | Cloudflare内部立项“Facebook DNS返回SERVFAIL”事件 | | 15:58 | Cloudflare确认Facebook已停止宣告其DNS前缀路由 | | 约21:00 | Facebook网络恢复BGP广播，路由更新流量重新出现 | | 21:17 | BGP更新达到峰值，各前缀陆续回归全球路由表 | | 21:20 | 1.1.1.1上facebook.com恢复解析 | | 21:28 | Cloudflare确认Facebook重新接入全球互联网，DNS恢复正常 | | 约21:50 | 受影响前缀的BGP路由全部恢复 | | 约22:05 | DNS服务整体恢复可用 | | 约22:50 | Facebook、Instagram、WhatsApp等应用层服务基本恢复 | 从15:39到22:50，整整七个小时，比一般运营商重大故障的MTR（平均修复时间）目标高了两个数量级。为什么修这么久？这恰恰是本次事故最值得复盘的部分，下面按“根因—恢复—影响”三层展开。 ## 根因：三层设计的完美风暴 Meta工程副总裁Santosh Janardhan在事发次日发布的官方博客，把根因讲得非常坦率。这不是单一故障，而是三层问题叠成的正反馈，每一层单独看都不致命，摞在一起就是全球大断网。 **第一层：一条命令加一个Bug（引爆点）。**Facebook用一张自建的全球骨干网把所有数据中心连成一体，日常维护中经常要把骨干网的一部分摘下来检修。事发时，工程师发出了一条本意是“评估全球骨干网容量可用性”的命令，这条命令却意外断开了骨干网的全部连接——相当于瞬间把所有数据中心之间的“光缆”全拔了。按流程，这类危险命令上线前应有审计工具把关，但那个审计工具自己存在Bug，没能拦住它。双保险，变成了零保险。 **第二层：“健康才广播”的反噬（放大器）。**Facebook的权威DNS服务器部署在独立于骨干网的网络上，本意是隔离风险。但它有一条联动设计：一旦DNS服务器发现自己连不上Facebook的数据中心，就判定“网络不健康”，主动撤掉自己的BGP路由公告——免得用户连上一个后端全断的DNS。这个设计的出发点无可指摘，但骨干网整体被拔掉后，全球每台Facebook DNS服务器都自检失败，于是**集体闭嘴**。结果是一种很别扭的状态：DNS服务器本身活得好好的，但全世界找不到去它们家的路。用电信的行话说，这是一次典型的fail-safe设计退化成了fail-dead——保护机制本身成了故障放大器。 **第三层：人机合力重试风暴（雪崩）。**解析失败后，真正的流量海啸才刚开始。Cloudflare的复盘记录了1.1.1.1上的实测曲线：一方面App“不接受错误作为答案”，拿到SERVFAIL就疯狂重试；另一方面终端用户也在人肉重试——刷新页面、杀掉App重新打开，有时同样疯狂。两股力量叠加，全球公共DNS承载的查询量达到平时的30倍，一些体量小的递归服务被拖慢，连带Gmail、TikTok、Snapchat的用户都感知到了卡顿——Google公共DNS自己也出现了明显减速。这与移动网络里的信令风暴是同一个物理模型：故障让终端重试，重试让故障加重。 三层级联画成图，是这样一条雪崩链： ```mermaid flowchart TD A["例行维护
评估骨干网容量"] --> B["命令误发
断开全部骨干连接"] B --> C["审计工具Bug
未拦截"] C --> D["全球数据中心
互相失联"] D --> E["DNS服务器
自检失败"] E --> F["自动撤掉
BGP路由广播"] F --> G["全球解析不到
Facebook域名"] G --> H["App与用户
疯狂重试"] H --> I["公共DNS查询量
暴涨30倍"] I --> J["殃及其他平台
普遍变慢卡顿"] ``` 需要说明的是：第一、二层的事发机理以Meta官方博客与Cloudflare复盘的交叉印证为准；第三层的“30倍查询量”是Cloudflare自家网络的实测数据，口径仅限1.1.1.1。 ## 恢复：为什么修了六个小时 根因清楚了，按理说把命令回滚就行。但Facebook的工程师很快发现，他们面对的是两只拦路虎。 **第一只虎：所有远程通道全断了。**数据中心之间的连接没了，主用管理通道自然不通；就连为这种场景准备的带外（out-of-band）管理网，也依赖那套已经瘫痪的基础设施。Cloudflare的外部视角证实了这一点：从15:40到21:00之间，Facebook网络上几乎没有任何路由层面的动静——不是没人修，是修复动作根本推不下去。远程全部失效后，Meta只能派工程师**人肉赶赴数据中心现场**操作服务器。 **第二只虎：连进门都难。**据维基百科汇总的媒体报道，恢复工作是在加州圣克拉拉的数据中心完成的。这些设施按高等级物理安防设计——本意是防攻击者，结果是“很难进去，进去了硬件和路由器也被设计得难以改动”。启用安全访问协议、获得现场操作权限，每一步都比平时慢。Meta官方博客坦承：这种日常安全加固在面对自家误操作时，确实拖慢了恢复速度；但官方同时认为这个权衡是值得的——安全性平时更重要。这话是否成立，读者可以自行判断。 **第三道坎：不敢一键全开。**骨干网恢复后，Facebook没有立刻把服务全部拉起。官方博客透露，故障期间个别数据中心的用电功率骤降了“数十兆瓦”的量级——这意味着服务器大规模停摆、缓存全空。如果瞬间恢复全部流量，电力系统、缓存层都可能被回弹的洪峰冲垮，引发第二轮崩溃。好在Meta常年在内部搞“storm”演练（模拟某个服务、数据中心甚至整个区域离线，压测全部基础设施），团队有分段恢复的成熟预案，最终各服务相对平稳地回血。但官方也承认：此前的演练从未模拟过“全球骨干网整体下线”这种场景，以后要补上。 给运维同行划一个重点：这次恢复的本质难点不是“找到根因”（协议层数据15:58就看清了），而是**失去了对基础设施的一切操作手段**。这一点对所有大型网络——包括电信网——都成立。 ## 影响面：这一跤摔掉多少钱 六个半小时的全球断网，账单远不止股价。下表汇总维基百科引用CNBC、Bloomberg、CNET、Fortune等媒体报道的数据（第三方统计口径，未经Meta官方确认的项均已标注来源属性）： | 维度 | 数据 | 来源属性 | |---|---|---| | 全球不可用时长 | 约6—7小时（15:39起） | Cloudflare与维基百科交叉印证 | | Downdetector故障报告 | 超过1000万份，当时历史最高 | 维基百科引用媒体报道 | | 广告收入损失 | 至少6000万美元 | Fortune与Snopes测算，媒体报道 | | 当日股价 | 下跌约5% | CNBC报道 | | 扎克伯格个人身家 | 数小时内缩水约60亿美元 | Bloomberg报道 | | 数据中心功率骤降 | 单中心数十兆瓦级 | Meta官方博客 | | 公共DNS查询量 | 上涨30倍 | Cloudflare 1.1.1.1实测 | | 波及平台 | Gmail、TikTok、Snapchat等变慢 | 维基百科引用媒体报道 | 账面之外还有两笔隐形成本。其一，第三方生态被殃及：所有用"Log in with Facebook"做登录的网站都被连坐，一批用户当天彻底无法访问自己的账号。其二，对发展中市场的冲击：大量用户依赖Facebook的Free Basics免费上网计划获取信息，断网直接影响了当地的通信、生意甚至人道救援协调——对这些人来说，Facebook不是“某个App”，而是他们接入互联网的全部。 作为对比，有意思的一个细节是：这场大断网发生在当时全球用户量最大的互联网平台身上，但它毕竟只是“一家公司消失”。同样的机理若发生在运营商骨干网或公共信令网上，波及的就是紧急呼叫——这也是为什么各国监管对电信重大故障的处罚和整改要求，比对互联网公司严格得多。 ## 给通信人的四条作业 以下是笔者基于十八年核心网与运维一线经验，对这次事故的解读，属观点性内容，供同行参考。 **第一，检验你的fail-safe是“降级”还是“消失”。**“健康才广播”的设计逻辑，电信网里随处可见：小区失联自动去激活、会话边界设备在后端不可达时拒绝注册、网元健康检查不过就踢出资源池。这些设计的共同隐患是：当“健康信号”本身因上游故障而不可信时，保护机制会引发雪崩式自关闭。设计评审时要多问一句——上游整体失联时，本单元是应该**降级服务**（保留最小能力、标记降级状态），还是**整体消失**？Facebook的答案是后者，代价是七小时。正确的姿势是前者：宁可带着降级标识继续干活，也不要把自己从全网路由表里抹掉。 **第二，重试必须带背压，全网层面要有过载控制。**30倍的DNS查询风暴与移动网络的信令风暴同源同型：日本KDDI 2022年、软银2018年的两次全国性大故障，走的都是“故障引发终端海量重注册/重试，重试压垮更多网元”的同一条路径。运营商侧的对策是一套组合拳：终端退避加随机抖动，网络侧网元过载时主动返回明确的重试指示而非静默丢弃，SIP/ Diameter这类信令协议启用过载控制机制，把“用户的不耐心”从正反馈掰成负反馈。互联网公司的DNS重试风暴和电信网的注册风暴，在数学上是同一个方程，值得放在同一张教材里讲。 **第三，带外通道要真的“外”。**这次事故里最扎眼的细节是：主用通道和带外通道一起失效。很多网络的“带外管理”其实经不起推敲——物理上同沟同槽、电力上同源同柜、人员上是同一批运维。检验标准只需一条：把生产网整体拔掉，你还能看到设备吗？如果答案是否，那不叫带外，叫第二把挂在一把钥匙上的锁。对核心网机房而言，独立的物理通道、独立的供电、独立权限的紧急进场流程，三样缺一不可。 **第四，变更闸门自己也要被审计，恢复动作要演练。**一条能拔掉全球骨干的命令，唯一的闸门是一个有Bug的审计工具——单点防护形同虚设。变更管理的关键不在“有审批”，而在审批链路上没有共同故障点：命令灰度执行、分域生效、随时可停，高危命令强制双人复核加自动回滚脚本。同样重要的是演练覆盖面：Meta的storm演练救了恢复阶段，但他们自己承认没练过“骨干整体下线”。运营商的黑天鹅演练清单里，应该主动加入“最核心的共享依赖整体失效”这一项——公共信令网、统一DNS、集中化网管，每一个都是候选场景。 最后说一句题外但重要的话：这次事故里，Facebook的损失是六千万美元广告费和一天股价；但如果同样的“一条命令”落在承载紧急呼叫的电信网上，代价的计量单位就不是钱。这就是为什么运营商的变更窗口、审批流程和演练密度，理应比互联网公司更苛刻——这一点，值得每一个正在“互联网化”的网络团队自省。 ## 参考来源 1. [Understanding How Facebook Disappeared from the Internet — Cloudflare Blog](https://blog.cloudflare.com/october-2021-facebook-outage/) — Cloudflare路由工程师Tom Strickx与Celso Martinho的“外部视角”复盘，BGP撤回时间线、DNS解析实测、30倍查询风暴曲线均出自此文，是本文的技术主轴之一 2. [More details about the October 4 outage — Meta Engineering](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/) — Facebook工程副总裁Santosh Janardhan事发次日的官方复盘，骨干网命令误发、审计工具Bug、DNS联动设计、现场恢复与storm演练细节均出自此文 3. [2021 Facebook outage — Wikipedia](https://en.wikipedia.org/wiki/2021_Facebook_outage) — 时间线与影响面数据的汇总条目，引用《纽约时报》、BBC、CNBC、Bloomberg等媒体报道，用于交叉验证与第三方影响数据 --- > 本文由「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 等场景全覆盖。