浙江网站设计 site,seo手机关键词网址,厚街做网站,海口企业做网站设计作者 | 马超 责编 | 张红月出品 | CSDN弱小从来不是生存的障碍#xff0c;傲慢才是。10月4日 FaceBook 发生了一次史诗级中断事故#xff0c;故障期间 FaceBook 所有旗下APP全面对外服务中断#xff0c;而且故障的时间长达7个小时之久。根据 Facebook 最新的声明来看傲慢才是。10月4日 FaceBook 发生了一次史诗级中断事故故障期间 FaceBook 所有旗下APP全面对外服务中断而且故障的时间长达7个小时之久。根据 Facebook 最新的声明来看故障的原因是由于工程师错误地发出了一条指令切断了 Facebook 的数据中心“在全球范围内的所有网络连接”。恰恰是这条简单的指令造成的影响却是史诗级别的本次宕机事故非常彻底甚至Facebook自己的内网也完全报废无法访问。笔者看到事件解决过程中不少运维方面的大牛都直接把故障的原因定位到了DNS和BGP方面。从Cloudflare的博客中也能看到问题的原因也确实出在了BGP指令方面不过我们要问的是为什么这样一条小小的指令会造成如此之大的影响。route-viewsshow ip bgp 185.89.218.0/23
% Network not in table
route-views上一次Facebook的全面中断事件还要追溯到7年的2014年6月当时Facebook在APP更新版本时出现了一些问题随后就有一些用户开始无法登陆Facebook不过Facebook方面很快就找到了问题所在并进行了修复并在半小时之内就让服务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-viewsshow ip bgp 129.134.30.0/23
% Network not in table
route-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的网络工程师对于自身的能力太过自信了以至于他们可能就没有认真分析过回退方案的可行性而故障发生之后才发现网络设备已经无法通过远程方式登陆了回退方案执行的前提已经崩溃。因此在发布任何版本之前都要根据其造成的最大负面影响制订预案假定自身不会出现低级失误的想法是绝对错误的。逃生通道是最后生命线必须严格保持独立从故障的时间上看远程登陆的逃生通道也一定是受到了影响从这里我们能吸取到的教训就是一定要在平时做好逃生通道的可用性验证并且要尽量保证逃生通道的独立性不能把逃生和日常运营的通道混为一谈。作者马超CSDN博客专家阿里云MVP、华为云MVP华为2020年技术社区开发者之星。往期推荐“5GAI”到底有啥用云原生时代底层性能如何调优Redis很厉害使用规范来啦985大学的高材生只会写代码片段丢人吗点分享点收藏点点赞点在看
