2.3.1 Facebook 故障分析总结
Facebook 史诗级故障事件发生在 2021 年 10 月 4 日，故障绕过了所有的高可用设计，故障期间 Meta 公司旗下的 Facebook、Instagram、WhatsApp 等众多服务出现了长达接近 7 个小时宕机，影响范围之深以至于差点产生严重二次故障，搞崩整个互联网。
如此大规模服务的瘫痪不是 DNS 就是 BGP 出了问题。很不幸，这次是 2 个一起出了问题。
图 2-4 Facebook宕机
Facebook 官方在故障后续发布原因总结是：运维人员修改 BGP 路由规则时，误将 Facebook 的自治域 AS32934 [1]内的权威解析服务器的路由给删除了。这个操作的直接后果就是所有请求 Facebook 域名的解析请求都会丢弃在网络路由中，世界各地 DNS 解析器都无法再正常解析 Facebook 相关的域名。
1.故障现象
故障期间使用 dig 查询 Facebook 域名解析全部出现 SERVFAIL 错误，根据我们前面的结论，这是权威解析服务器出现了故障。那故障影响范围就大了，世界上所有的 DNS 解析器都不会再正常返回 Facebook 域名的解析结果。
➜ ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
因为 Facebook 用户太多了，用户无法正常登陆 APP 时会疯狂地发起重试。如图 2-5 所示，CloudFlare 的 DNS 解析器（1.1.1.1）请求瞬间增大了 30 倍，如果 1.1.1.1 宕机，恐怕整个互联网会出现相当一段时间不可用。
图 2-5 cloudflare 监控到 Facebook 故障时期的请求数
故障从美国东部标准时间上午 11 点 51 分开始，最终 6 个小时以后才恢复。
2.故障总结
这次故障实际上 BGP 和 DNS 一系列设计缺陷叠加，从而放大了故障影响：
- 运维人员发布了错误的 BGP 路由公告。
- 恰巧 Facebook 的权威解析服务器的 IP 包含在这部分路由中。
这就导致域名解析请求无法路由到 Facebook 内部网络中。由于 DNS 出现问题，运维人员很难再通过远程的方式修复，修复团队只能是紧急跑到数据中心修复（道听途说是打了飞的过去），这就是此次故障影响巨大的原因。
Facebook 这次故障带给我们以下几点关于 DNS 系统设计的思考：
- 部署形式考虑：可选择将 Authoritative nameserver 节点全部放在 SLB（Server Load Balancer，负载均衡）后方，或采用 OSPF Anycast 架构[2]等部署形式，从而提高 DNS 系统的可靠性。
- 部署位置考虑：可选择数据中心自建集群 + 公有云服务混合异构部署，利用云的分布式优势进一步增强 DNS 系统健壮性，同时提升 DNS 系统在遭受 DDoS 攻击时的抵御能力。
如图 2-6 所示，amazon.com 和 facebook.com 的权威域体系对比：amazon.com 的权威解析服务器分散在不同的 AS 内，所以它的抗风险能力肯要强于 Facebook。
图 2-6 amazon.com 与 facebook.com 域名结构对比
3.运维操作的警示
一些关键的运维操作具有很大风险，譬如更改 BGP 通告、修改路由、修改防火墙策略等。此类操作如果产生失误，有可能造成远程连接无法再使用，这个时候想远程修复就难了，只能接近物理机才能处理。
生产环境中存在很大风险性的操作，如果是修改建议确认两遍，如何是删除，那就确认三遍。除了祈祷手稳之外，正规的方式是引入类似二次提交的策略，譬如修改一个 iptables 规则，修改之后增加 10 分钟「观察期」。观察期结束后，系统自动恢复原来的配置，运维人员确认观察期内数据没有任何问题之后，再执行正式的操作。