摘要
2021-10-04，Facebook 在例行维护中执行了一条 BGP 配置变更以评估骨干网容量，却意外撤回了数据中心向互联网通告的全部路由前缀。由于 DNS 服务器也依赖这张网络，DNS 解析随即失效，用户与工程师都无法访问 facebook.com，连远程排障通道也被切断。
# 自己把自家网络的「门牌」全摘了，连修门的路也堵死。
时间线
15:39BGP 变更撤回全部路由前缀，Facebook 从互联网「消失」
15:40+内部 DNS 因依赖同一网络不可解析，远程接入失效
数小时内工程师无法远程登录，恢复依赖物理进入数据中心
~21:00工程师在现场通过本地控制台恢复 BGP 通告
~22:00服务逐步恢复
根因
例行维护中，一条用于评估骨干网容量的审计 / 配置命令意外断开了 Facebook 家乡自治系统（AS32934）的全部 BGP 会话，撤回家乡向互联网通告的所有路由前缀——其中包括承载 facebook.com 等域名的 DNS 基础设施前缀。由于 DNS 服务器与权威解析服务依赖同一张网络，前缀被撤回后 DNS 完全不可达，工程师既无法远程登录、连排障工具也被切断，形成「排障通道自杀」。
- 审计 / 容量评估命令意外触发 BGP 会话断开，撤回家乡 AS 全部前缀（含 DNS 基础设施）。
- DNS 服务依赖 Facebook 自身网络，网络消失即排障通道消失，远程接入与带外管理（OOB）均不足。
- BGP 前缀撤回未排除关键基础设施前缀，缺独立逃生通道。
- 恢复被迫依赖工程师物理进入数据中心、通过本地控制台重新通告 BGP，耗时数小时。
放大因素
DNS 自依赖使故障雪崩；无有效带外管理，恢复被迫依赖人工到场、耗时数小时；全球规模放大影响面与舆论压力。
缓解措施
- 限制 BGP 前缀撤回范围，保留 DNS 等基础设施前缀。
- 建设独立带外管理网络，故障时不依赖被排障系统。
- 变更分级评审 + 自动回滚护栏。
经验教训
关键基础设施的前缀 / DNS 必须有「逃生通道」，绝不能让它依赖自身。任何会切断你排障路径的变更都是高危。
检查清单
- 确认故障窗内是否有 BGP / 网络配置变更
- 核对 DNS 是否依赖被排障网络
- 验证带外管理（OOB）是否可用
- 检查前缀撤回范围是否含关键基础设施
- 复盘变更审批与自动回滚