summary
2021-10-04 约 15:51 UTC 起，Facebook 旗下全部应用及内部系统全球中断约 6 小时。根因是工程团队在维护骨干网时运行了一条本应将一个数据中心从 BGP 网络中撤回的命令，却因评估该命令影响的审计工具存在 bug 未能拦截，误将整个骨干网（含所有数据中心互联）从网络中断开，导致所有数据中心失去互相连接能力，进而触发 DNS 服务器无法被外部路由到达，facebook.com 等域名解析失败。
timeline
15:51 UTC 执行配置命令，骨干网连接开始中断。随后 DNS 解析失败，公共互联网无法到达 Facebook 的 DNS 服务器。工程师因 VPN/内部工具也依赖该网络，初期难以远程登录排障。约 21:00 UTC 网络层恢复，DNS 逐步恢复，各应用陆续上线，全部恢复耗时约 6 小时。
root_cause
审计/验证工具未能正确评估维护命令的爆炸半径，命令执行后把整个骨干网（而不仅是目标数据中心）的 BGP 路由全部撤回；网络断开后 DNS 基础设施不可达，形成自我封锁。
amplifiers
① 命令影响评估工具缺陷，未能在事前标出该命令会断开全量骨干网。② 控制面与数据面强耦合：骨干网一断，DNS/管理通道随之失效，运维失去远程抓手。③ 恢复依赖物理接触：需人员在数据中心本地接入才能修正 BGP。
mitigation
工程师进入数据中心通过本地控制台修正 BGP 配置并逐步恢复互联；恢复 DNS 服务后各应用灰度上线。Meta 后续重构审计工具、为关键维护命令增加强制二次确认与影响模拟。
lessons
变更审计工具必须能真实模拟命令的全局影响；关键网络维护需带外管理通道（OOB）独立于生产网络；高危 BGP 操作强制分级审批与Dry-run。
checklist
① 审计工具对维护命令做全量影响模拟并阻断超范围操作。② 保留独立于生产网络的带外运维通道。③ BGP 撤回类操作强制二次确认+灰度。④ 定期演练物理本地恢复流程。