2.3.3 Facebook 故障分析总结
这一节我们了解 Facebook 的故障的原因以及给我们的警示。
Facebook 此次故障发生在 2021 年 10 月 4 日,故障绕过了所有的高可用设计,故障期间 facebook、instagram、whatsapp 等众多服务出现了长达接近 7 个小时宕机,影响范围之深以至于差点产生严重二次故障,搞崩整个互联网。如此大规模服务的瘫痪不是 DNS 就是 BGP 出了问题,非常巧,这次是两个一起出了问题。

图2-5 Facebook宕机
Facebook 官方在故障后续发布原因总结是:运维人员修改 BGP 路由规则时,误将 Facebook 的 AS32934(Autonomous System,自治域)内的权威解析服务器的路由给删除了。这个操作的直接后果就是所有请求 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-6 所示,CloudFlare 的 DNS 解析器(1.1.1.1)请求瞬间增大了 30 倍,如果 1.1.1.1 宕机,恐怕整个互联网会出现相当一段时间不可用。

图2-6 cloudflare 监控到 Facebook 故障时期的请求数
故障从美国东部标准时间上午 11 点 51 分开始,最终六个小时以后才恢复。
2.运维操作的警示
一些关键的运维操作具有很大风险,例如更改 BGP 通告、修改路由、修改防火墙策略等。此类的操作如果产生失误,有可能造成远程连接无法再使用,这个时候想远程修复就难了,只能接近物理机才能处理。
对于这种在生产环境中很大风险性的操作,可以引用一种个二次提交的策略。例如,修改一个 iptables 规则,修改之后引入 10 分钟观察期
,观察期结束后,系统自动恢复原来的配置,运维人员确认观察期内数据没有任何问题之后,再执行正式的操作。
3.故障总结
这次故障实际上 BGP 和 DNS 一系列设计缺陷叠加,从而放大了故障影响:
- 运维人员发布了错误的 BGP 路由公告。
- 恰巧 Facebook 的权威解析服务器的 IP 包含在这部分路由中。
这就导致域名解析请求无法路由到 Facebook 内部网络中。由于 DNS 出现问题,运维人员很难再通过远程的方式修复,只能是修复团队紧急跑到数据中心修复,这就是此次故障范围、时长影响巨大的原因。
Facebook 这次故障带给我们以下几点关于 DNS 服务的思考:
- 部署形式考虑:可选择将 DNS 服务器节点全部放在 SLB(Server Load Balancer,负载均衡)后方,或采用 OSPF Anycast 架构等部署形式,从而提高 DNS 系统的可靠性。
- 部署位置考虑:可选择数据中心自建集群 + 公有云服务混合异构部署,利用云的分布式优势进一步增强 DNS 系统健壮性,同时提升 DNS 系统在遭受 DDoS 攻击时的抵御能力。
如图 2-7 所示,亚马逊 amazon.com 和 facebook.com 的权威域体系对比,amazon.com 的权威解析服务器分散在不同的 AS 内,所以它的抗风险能力肯要强于 Facebook。


图2-7 amazon.com 与 facebook.com 域名结构对比