译者 | 钟会 白眉林 | 颤抖地月

公司出品 | CSDN（ID：CSDNnews）

力量强大从不是存活的心理障碍，高傲才是。10月4日FaceBook出现了一场叙事诗级受阻交通事故，机械故障前夕FaceBook母公司大部份APP全面性对内服务项目受阻，所以机械故障的时间长达7个半小时之久。依照Facebook新一代的新闻稿上看，机械故障的其原因是由于技师严重错误地收到了两条命令，阻断了Facebook的网络系统“在亚洲地区范围内的大部份数据传输”。

不可否认是那条单纯的命令，导致的负面影响看似叙事诗等级的，此次难以访问交通事故十分全盘，即使Facebook自己的内部网也全然拆解，封禁。本栏看见该事件化解操作过程中许多网络管理各方面的薄罗藓都间接把机械故障的其原因功能定位到了DNS和BGP各方面。

从Cloudflare的网志中也能看见，难题的其原因也的确出在了BGP命令各方面，但是我们要问的是为何这样两条小小命令会导致这般之大的负面影响。

route-views>show ip bgp 185.89.218.0/23% Network not in tableroute-views>

上一场Facebook的全面性受阻该事件更要回溯到7年的2014年6月彼时Facebook在APP预览版时出现了许多难题，随即就有许多使用者开始难以进占Facebook，但是Facebook各方面迅速就找出了Vizille并进行了复原，并在十分钟内瞧瞧服务项目100%恢复正常了恒定。

此次叙事诗级机械故障也不是脆弱的BGP协议第一场出现难题，就在2020年1月23日，大部份后缀为.net的域名也出现难以解析的情况，经DNS顶级根服务项目运营商ISC调查，发现.net域名缺失了关键的A记录和AAAA记录，大部份.net后缀的互联网地址从ISC的F根服务项目器全部消失了，接下来美国宇航局（NASA）运营的E根服务项目器也遇到了类似的难题。

那次机械故障中ISC功能定位难题的时间也迅速，在5分钟内就迅速将难题功能定位在他们与Cloudflare合作运营的节点上，后来Cloudflare迅速查明其原因是由于他们刚刚发布的变更代码所导致的难题。但最终难题的化解也花了近两个半小时的时间，因为撤回导致该难题的BGP通告，出乎意料的长。

通过对比我们可以看见，此次Facebook的机械故障无论是从负面影响程度，还是机械故障时间上讲都堪称是负面教材的典型，而历史一再告诉我们，只要能从历史经验中总结一点教训就能避免悲剧的出现，因此复盘此次叙事诗级的机械故障，对于我们来说肯定也会是大有裨益。

什么是BGP协议

BGP边界网关协议是EGP外部网关协议的一种， 顾名思义BGP处理外部网络区域的之间路由信息的协议，其主要功能是与其他网络自治区的BGP协议系统交换网络路由信息。我们看见EGP相对的IGP内部网关协议，拥有众多储如RIP、OSPF、IS-IS、IGRP、EIGRP的协议族实现不同。EGP家族当中几乎只有BGP这一根独苗是可用的,BGP几乎是唯一一个能够处理独立路由域间的多路连接的协议。

我们举个例子来说明一下这个BGP协议，比如互联网上有7个独立的网络自治区域AS (Autonomous System)，它们分别是AS1-AS7,这7个AS之间相互的物理连接情况用橙色线段表示如下：

那么如果AS1区域内的设备想要与AS7区域内的设备产生连接，那么具体的路由路径应该选择AS1-AS4-AS5-AS6-AS7的蓝色路径，还是选择AS1-AS2-AS35-AS6-AS7的红色路径就是BGP协议要化解的核心难题，其实BGP之类的路由协议从宏观层面上看都有点像旅游规划，也就是可以把难题转化为从AS1到AS7的道路中哪条道路最快。BGP协议通过一系列的报文，Internet发布其前缀路由信息，并维护一个有限状态机，并以此来完成路由策略的收敛，但如果发布了严重错误的通告信息，那么就没有人能够知道如何连接这个严重错误区域了。当然本文不是要介绍BGP协议，这里各位读者对于BGP的有关概念性有所认识就可以了。

该事件处理机械故障复盘

正如Facebook公告所说，交通事故的一开始，Facebook已经停他们DNS前缀路由的BGP通告也就是说Facebook的DNS封禁，也就是说两条严重错误的命令让Facebook整体下线了。

route-views>show ip bgp 129.134.30.0/23% Network not in tableroute-views>

在机械故障前夕通过dig、nslookup等命令解析Facebook的DNS域名全部返回SERVFAIL，所以正如我们上文介绍，如果发布了严重错误的BGP通告，那么没有人能够再从互联网上找出你，这和人工破坏了Facebook网络系统的连向互联网的光纤线路，从结果上看没有任何本质区别。

依照CloudFlare的网志显示，Facebook的机械故障差点把整个互联网搞崩，因为Facebook使用者太多了，使用者在难以恒定进占APP时会疯狂的发起重试，所以由于Facebook域名解析缓存已经在各级DNS服务项目器上全部失效了，这就给根DNS也就是1.1.1.1导致了巨大的压力。据说这使1.1.1.1的DNS解析查询的速度比平时高出30倍，所幸1.1.1.1顶住了压力，Facebook机械故障前夕绝大多数的DNS解析请求的返回速度都稳定在10毫秒左右，否则一旦根DNS也崩溃那么后果将不堪设想。

最终在7个半小时之后，Facebook终端重新向互联网通告了他们的路由，至此服务项目才最终恢复正常。

通过此次该事件我们能学到了什么

以Facebook那些薄罗藓人物的实力，从发现机械故障到功能定位机械故障其原因的时间不会超过1分钟，即使很有可能在刚刚执行完那条严重错误的BGP通告命令之后就发现难题了，但是机械故障依旧持续了长达7个半小时。再结合Facebook内部网全部受阻的细节，那么我们可以推出隐藏在这背后的重要结论，那就是相关的严重错误命令把Facebook的VPN通道也全部负面影响了，我们知道Facebook目前在疫情的负面影响下，美国区的员工还处在远程办公的状态，也就是说在严重错误命令生效之后，远程网络管理技师自身的VPN以及逃生通道也全部失效了，而网络系统现场值班的人员可能只会加电、重启等单纯操作，即使不排除现场人员连进占到核心网络设备的权限都没有，一切都得指望远程网络管理的人员到现场化解了。

假设自己不出现低级失误，才是最大的低级严重错误：从上述分析中我们可以看出，Facebook的网络技师对于自身的能力太过自信了，以至于他们可能就没有认真分析过回退方案的可行性，而机械故障出现之后才发现网络设备已经难以通过远程方式进占了，回退方案执行的前提已经崩溃。因此在发布任何版之前都要依照其导致的最大负面负面影响制订预案，假定自身不会出现低级失误的想法是绝对严重错误的。

逃生通道是最后生命线，必须严格保持独立：从机械故障的时间上看，远程进占的逃生通道也一定是受到了负面影响，从这里我们能吸取到的教训就是一定要在平时做好逃生通道的可用性验证，并且要尽量保证逃生通道的独立性，不能把逃生和日常运营的通道混为一谈。