2021年10月4日，脸书及其旗下软件经历了六个小时的中断，包括WhatsApp、Instagram和Oculus VR。鉴于此事件的严重性，我们认为不妨深入挖掘一下我们所依赖的一些互联网技术，以及有必要剖析一下发生的原因。从而帮助广大客户进行自我诊断，分析自身IT架构目前是否能够避免此类事件，或者我们应该如何尽量避免此类事件的发生，以便更好的引以为鉴。

为何宕机时间长

首先，我们来分析一下为什么会中断这么久，长达数小时？主要原因是事故不仅使全球用户的服务受到影响，更严重的是涉及到全系统使用的带外系统维护平台的主DNS也在过程中被切断了访问。无法远程登录自己数据中心内相关设备的结果是，只能去机房现场进行恢复。

引用来自事故报告：“Our primary and out-of-band network access was down,so we sent engineers onsite to the data centers to have them debug the issue and restart the systems.”

为何无法远程登录

那为什么无法远程登录呢？因为，除了BGP路由引起的骨干网故障以外，该服务提供商自己的权威DNS系统也“脱网”了。那权威DNS系统为什么会“脱网”呢？这是因为DNS系统主动注销了自己的服务IP地址。那这又是为什么呢？结合公开资料的描述，我们分析此事件中的权威DNS估计是采用了IP anycast方式部署，该机制中通常会采用路由健康注入（Route Health Injection）方式，基于服务可用性，并利用BGP或OSPF动态路由主动发布和注销服务IP地址的路由信息。因此，当故障发生时，由于权威DNS与内部骨干网到所有数据中心服务器之间的路由通信故障，导致触发了动态路由更新，主动注销了通过BGP公告的所有DNS服务IP地址，使该服务提供商的互联网服务完全断开。

DNS方案建设问题及建议

权威DNS作为互联网基础服务系统，是一个企业机构IT架构中非常重要的一个环节，无论是面向互联网的外网DNS，还是面向内部网络的内网DNS系统，我们在设计和建设时一定要考虑如何提升其高可用性和安全性！通过此次事件，作为IT架构的设计、决策和维护人员，我们需要思考以下几个关键问题：

问题1：您的DNS系统是否单机房或单个云服务商部署？

F5建议：DNS系统要多中心或混合云部署，不把鸡蛋放在一个篮子里

问题2：您的DNS系统是否内外网隔离和独立分域部署？

F5建议：内外网DNS系统一定要分开独立部署；同时业务面DNS与维护管理面DNS也一定要分开独立部署；以免相互影响

问题3：您的DNS系统前端是否有专门针对DNS协议的安全防护体系？

F5建议：DNS系统一定要专门设计和部署针对DNS协议的安全防护设备，例如F5的高级防火墙AFM模块（Advanced Firewall Manager）

问题4：您的DNS系统是否全部通过BGP或OSPF的路由健康注入方式进行自我主动发布和注销？

F5建议：DNS系统作为一个公司的对外提供服务的核心基础设施，应考虑对多个Name Server（后简称NS）地址采用组合的方式进行对外公告，除了动态发布的NS外，也考虑保留部分传统方式公告的NS IP地址（DNS注册机制允许在上级域名管理机构注册多个NS服务地址），避免此类事件发生时所有权威DNS，甚至带外管理的DNS都不能提供服务。

问题5：您的DNS系统如何处理当内部骨干网络出现部分或全部故障时对外部发起的域名解析请求的响应？

F5建议：采用WideIP智能解析算法优化DNS域名解析请求，为用户返回最佳路径的应用服务器IP地址，对不能正常提供服务的服务器进行筛选屏蔽。当DNS认为某一应用的所有服务器IP地址均处于无法工作的状态时，可以选择返回所有可能的服务器地址作为响应结果给Local DNS或客户端，允许客户端自行尝试连接目标服务，以规避由于权威DNS自身与内部骨干网之间的故障导致的错误判断。（F5的DNS分布式集群解决方案还可以通过集群间的交叉健康检查探测来进一步筛选您部署在多中心、混合云内的不同服务资源以及连接所有这些资源的多条线路间的健康情况，并通过智能解析算法提供最优解，最大限度避免由于基础设施的故障导致的整体服务故障）

问题6:您的DNS系统是否具有除路由与IP地址可用检测手段以外的业务系统健康检查能力？

F5建议：结合F5 DNS的分布式集群部署与LTM的丰富应用负载及应用级健康检查能力实现多级且独立的业务能力监控与判断纠错系统，实现真正的DNS智能化，与业务实时服务能力的深度判断。

如果以上几个问题，您都有了比较放心满意的答案，那就可以最大程度的避免此类事件的发生。让我们一起构建一个高可用、高可靠的IT架构系统吧！

事件故障详情参考资料：

1.https://engineering.fb.com/2021/10/04/networking-traffic/outage/

2.https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/

3.https://blog.cloudflare.com/october-2021-facebook-outage/