一次例行骨干维护命令误删全部骨干连接，BGP 撤路由让仍在运行的 DNS 服务器从互联网上消失，Facebook 全球服务随之中断。 本文是公开报告的摘要与解读，事实以原始报告为准

本文是公开报告的摘要与解读，事实以原始报告为准。

事件概要

2021 年 10 月 4 日，Facebook（现 Meta）发生全球性中断。Meta 网络工程负责人 Santosh Janardhan 于 10 月 5 日发布《More details about the October 4 outage》：工程师在例行维护中执行了一条用于检查全球骨干容量的命令，命令却切断了骨干网的全部连接，使各地数据中心与互联网隔离。本应拦截这类误操作的审计工具因 bug 未能生效。

骨干断开后，事故进入第二层。Facebook 的小型站点负责应答 DNS 查询，其权威 DNS 服务器的 IP 地址通过 BGP 对外宣告。当这些站点无法连接数据中心时，它们把链路判定为不健康，撤回 BGP 宣告。DNS 服务器仍在运行，外部网络却已找不到它们，也就无法解析 Facebook 域名。

报告没有给出精确起止时刻、总时长、受影响用户数，也没有逐项列出产品。可确认的是故障是全球性的，平台、消息和内部工具都受影响；10 月 5 日发布报告时服务已恢复。报告明确说这不是恶意攻击，也没有证据表明用户数据遭到入侵。

时间线

报告只给出日期和相对顺序，没有钟点。下表保留这种粒度，不补造时间。

影响面

故障是全球性的。报告描述，Facebook 自建的骨干网由数万英里光纤组成，连接全球数据中心；大型数据中心可能容纳数百万台机器，小型站点负责把骨干网接到更广泛的互联网。骨干一断，这些设施之间以及它们与外部世界的连接同时受影响。

对外表现为用户无法访问 Facebook 平台和应用，消息等场景受影响。报告没有给出受影响用户数量、请求失败比例或精确服务清单，因此不应引用未经报告确认的“数十亿用户”之类数字。

对内，故障同时打掉了排障能力。常规网络和带外网络都不可用，DNS 故障又让许多内部工具无法使用，响应者只能前往数据中心，而门禁、系统加固和现场流程都需要额外时间。部分站点停机期间用电负荷下降“数十兆瓦”，给恢复带来电气设备和缓存风险。报告排除恶意攻击，并称未发现用户数据被入侵。

根因

直接触发点是一条维护命令。它的本意只是检查全球骨干还有多少可用容量，实际却切断了所有骨干连接。报告没有披露命令内容和审计工具 bug 的细节，只说明该工具原本应在危险操作生效前阻止它。

第二个关键因素是 DNS 与 BGP 的联动。DNS 服务器本身仍在运行，问题在于小型站点把“无法连接数据中心”判断为链路不健康，主动撤回 BGP 宣告。宣告消失后，外部解析器拿不到权威 DNS 地址，域名解析随之失败。这是保护机制在总故障下产生的级联效应，不是 DNS 软件崩溃。

更准确的因果链是：维护命令误删骨干，审计保护失效，站点健康判断触发 BGP 撤回，DNS 从互联网上不可达，依赖域名解析的服务和内部工具大面积失效。把它称作“BGP 故障”或“DNS 故障”都只覆盖一环；核心是骨干控制面被误操作击穿，再由路由和解析层放大。

处置与恢复

团队首先面对的不是改哪行配置，而是如何进入现场。常规网络和带外网络都不可用，工程师只能前往数据中心；物理门禁、系统访问审批和加固措施都需要时间。报告把这一点视为恢复变慢的主要原因之一，同时认为这些安全措施日常带来的收益值得付出这种代价。

进入现场并确认问题后，团队恢复了各区域骨干连接。报告称，骨干连通性恢复后，其余环境也随之恢复。服务没有一次性全部拉起，而是分阶段恢复，因为同时重启可能造成流量猛增和再次崩溃；部分站点用电负荷大幅下降，突然反向拉升也可能危及电气设备和缓存。既有的“风暴演练”提供了受控恢复经验，但报告承认，此前没有演练过“全球骨干完全丢失”。

报告列出的后续动作仍处于早期：广泛复盘，加强测试、演练和整体韧性，并研究如何模拟这类事件。报告没有给出已完成的修复项、负责人或截止时间，因此不能把“将加强演练”写成“已经修复”。

教训

第一，维护命令必须有与风险匹配的爆炸半径控制。检查容量听起来是只读操作，实际却可能改变全局连接；危险命令需要 dry-run、范围确认、二次审批和独立熔断，而不能依赖一个从未被验证的审计工具。

第二，保护机制本身要纳入故障演练。DNS 站点撤回 BGP 宣告，在单站点故障时可能是正确的自我保护；当所有站点同时失去后端时，它会把“局部不健康”升级为“全球不可解析”。设计时要检查健康判断、路由宣告和依赖关系是否会形成正反馈。

第三，带外访问必须真正独立。若带外网络、跳板机、DNS、凭据系统都依赖同一条骨干，事故时就等于没有带外通道。至少应保留一条不经过生产骨干的入口，并把离线 runbook、联系方式和应急凭据放在可独立取得的位置。

第四，恢复要管理“重新上电”的冲击。流量、缓存、电源和连接队列都可能在整个系统同时苏醒时过载；分阶段恢复、限流、预热和回退阈值应写进 runbook，而不是临场决定。

第五，演练和公开复盘都要覆盖最坏场景与事实边界。单机、单可用区演练很常见，全球骨干全断、控制面全灭却很少被真正走一遍；同时，报告没给出的数字不应为了叙事完整而补上。

对本站读者的检查清单

• 高风险维护命令是否有 dry-run、影响范围预览、二次确认和独立熔断？
• 审计/拦截工具是否有测试和故障演练？失效时是否有第二道防线？
• DNS 健康检查与 BGP 宣告策略是否画成依赖图，避免总故障时一起撤回？
• 是否存在不依赖生产骨干的带外管理通道与可离线取得的凭据？
• 是否演练过骨干全断、DNS 全不可达、监控同时失效的组合场景？
• 恢复 runbook 是否包含分阶段重启、限流、预热和电源冲击评估？
• 关键内部工具能否脱离用户流量的 DNS 与网络路径独立使用？

恢复手册与同类复盘

• 公开复盘索引 — 按根因查找同类事故，并跳到对应 Runbook。

相关命令

• dig：从外部验证权威 DNS、NS 与 A/AAAA 记录是否还能解析。
• traceroute：检查到目标网段的路由在何处中断。
• mtr：持续观察路径丢包与路由变化，区分骨干中断和单点拥塞。
• tcpdump：在边缘抓包，确认 DNS 查询是否有去无回。
• curl：分别用域名和 IP 请求，判断问题在解析还是连接。
• bgp：理解 BGP 宣告、路由选择与故障传播。
• network-mental-model：按层定位解析、路由、连接和应用故障。
• incident-response-playbook：按发现、止血、恢复、复盘组织处置。
• incident-command：明确事故指挥、沟通和升级路径。

参考链接

• Meta Engineering 详细复盘：More details about the October 4 outage
• Meta Engineering 初次更新：Update about the October 4th outage

读完自测

合上页面，先回答，再展开对照。

1. 为什么骨干断开后，仍在运行的 DNS 服务器会从互联网上“消失”？
2. 这次事故中，审计工具和 BGP 分别起了什么作用？
3. 恢复阶段为什么不能把所有服务一次性重启？