2.3.3 Facebook 故障分析与总结
Facebook 史诗级故障事件发生在 2021 年 10 月 4 日，故障绕过了所有的高可用设计，让 Facebook 公司旗下的 Facebook、Instagram、WhatsApp 等众多服务出现了长达接近 7 个小时宕机。这次故障的影响范围极广，差点导致严重的二次故障，险些搞崩整个互联网。
如此大规模服务的瘫痪不是 DNS 就是 BGP 出了问题。Facebook 很倒霉，这次故障是因为 DNS 和 BGP 一起出现了问题。
图 2-4 Facebook宕机
Facebook 官方后续发布的故障原因如下：
运维人员修改 BGP 路由规则时，误将 Facebook 的自治域 AS32934 [1]内的“权威域名服务器”的路由给删除了。
这个操作的直接后果是，所有 Facebook 域名的解析请求都会丢弃在网络中，世界各地“DNS 解析器”无法再正常解析 Facebook 相关的域名。
1.故障现象
故障期间使用 dig 命令查询 Facebook 域名解析记录，全部出现 SERVFAIL 错误。
➜ ~ 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。
因为 Facebook 用户太多了，用户无法正常登陆 APP 时会“疯狂”地发起重试。如图 2-5 所示，云服务商 Cloudflare 的 DNS 解析器（1.1.1.1）请求瞬间增大了 30 倍，如果 1.1.1.1 宕机，恐怕整个互联网都会受到影响。
图 2-5 Cloudflare 的域名解析服务器 1.1.1.1 在 Facebook 故障时请求瞬间增大 30 倍
这次故障还影响到 Facebook 内部，员工的工作邮箱无法打开、门禁系统也出现故障，Facebook 从外到内完全停摆。据 Facebook 员工回忆当天的情形：“ 今天大家都很尴尬，不知道发生了什么，也不知道该做什么，只好假装什么都没有发生”。
这次故障从美国东部标准时间上午 11 点 51 分开始，最终 6 个小时以后才恢复。
2.故障总结
这次故障实际上 Facebook BGP 路由系统和 DNS 系统一系列设计缺陷叠加，从而放大了故障影响：
- 运维人员发布了错误的 BGP 路由公告；
- 恰巧 Facebook 的权威域名服务器的 IP 包含在这部分路由中。
这就导致域名解析请求无法路由到 Facebook 内部网络中。
且因为是 DNS 出现问题，运维人员也受故障影响，很难再通过远程的方式修复，修复团队只能是紧急跑到数据中心修复（道听途说打了“飞的”过去）。
Facebook 这次故障带给我们以下关于 DNS 系统设计的思考：
- 部署形式考虑：可选择将“权威域名服务器”全部放在 SLB（Server Load Balancer，负载均衡）后方，或采用 OSPF Anycast 架构[2]等部署形式，从而提高 DNS 系统的可靠性。
- 部署位置考虑：可选择数据中心自建集群 + 公有云服务混合异构部署，利用云的分布式优势进一步增强 DNS 系统健壮性，同时提升 DNS 系统在遭受 DDoS 攻击时的抵御能力。
如图 2-6 所示，amazon.com 和 facebook.com 的权威域体系对比：amazon.com 的权威解析服务器有多套不同的地址，分散于不同的 TLD 域名服务器，所以它的抗风险能力肯要强于 Facebook。
图 2-6 amazon.com 与 facebook.com 域名系统对比
3.运维操作的警示
一些关键的运维操作具有很大风险。例如，更改 BGP 通告、修改路由、修改防火墙策略等，这类的操作如果产生失误，有可能造成远程连接无法再使用，这个时候想远程修复就难了，只能接近物理机才能处理。
这对我们的思考是，如果生产环境要进行很大风险性的操作，除了慎之又慎外，合理的方式应该使用一种二次确认的方式。例如，修改一个 iptables 规则，修改之后增加 10 分钟“观察期”。观察期结束后，系统自动恢复原来的配置，运维人员确认观察期内数据没有任何问题之后，再执行正式的操作。