2021年10月4日Facebook史上最严重宕机复盘分析

1、相关新闻

据BBC等媒体报道,UTC时间2021年10月4日15时39分(即北京时间10月4日23时39分),社交网络Facebook及其子公司Messenger、Instagram和WhatsApp全球无法使用长达7个小时。

Facebook在其twitter中发表官方声明“Our engineering teams have learned that configuration changes on the backbone routers that coordinate network traffic between our data centers caused issues that interrupted this communication. This disruption to network traffic had a cascading effect on the way our data centers communicate, bringing our services to a halt” (翻译:调度数据中心之间流量的骨干网路由器配置变化造成了这次通讯中断。这种网络流量中断对数据中心的通信产生了连锁效应,最终导致我们服务宕机。)

可以看出官方的答复并没有很清楚地说明错误原因。因此我们复盘给出宕机事故的根本原因。

2、Downdetector监测到Facebook网络波动 图片1

图1 Downdetector监测到Facebook网络波动 Downdetector网站通过收集社交网络中的中断信息来推断断网,如图1所示。Downdetector在EDT时间的10月4日11时44分(即北京时间10月4日23时44分)检测到Facebook网络波动问题,具体原因没有说明。

3、Facebook和WhatsApp服务中断原因分析 Facebook的AS为AS32934,WhatsApp的AS为AS11917。

北京时间10月5日凌晨0时(UTC时间10月4日16时整)观察到Facebook(AS32934)出现网络波动,其Prefix数量和IP数量都有所减少。直到北京时间10月5日早上7时整,Prefix数量和IP数量恢复,如图2所示。其中,Prefix数量由10月4日23时30分的129个减少为10月5日0时的103个,Prefix数量减少了26个,共计5,888个IP。丢失IP块明细如下:

129.134.25.0/24、129.134.26.0/24、129.134.27.0/24、129.134.28.0/24、129.134.29.0/24、129.134.30.0/23、129.134.30.0/24、129.134.31.0/24、129.134.65.0/24、129.134.66.0/24、129.134.67.0/24、129.134.68.0/24、129.134.69.0/24、129.134.70.0/24、129.134.71.0/24、129.134.72.0/24、129.134.73.0/24、129.134.74.0/24、129.134.75.0/24、129.134.76.0/24、129.134.79.0/24、157.240.207.0/24、185.89.218.0/23、185.89.218.0/24、185.89.219.0/24、69.171.250.0/24

图片2

图2 网动仪捕获到Facebook(AS32934)有明显波动情况发生

Facebook有4个权威DNS服务器,分别是a.ns.facebook.com(129.134.30.12)、b.ns.facebook.com(129.134.31.12)、c.ns.facebook.com(185.89.218.12)和d.ns.facebook.com(185.89.219.12),4个DNS服务器IP都在丢失的IP块中。

因此,这次故障的原因是调度数据中心之间网络流量的骨干路由器配置更改导致边界网关协议撤销了Facebook自治域AS32934下包含Facebook域名服务器IP的IP地址块,抹去了Facebook需要的DNS路由信息,紧接着DNS服务器离线,用户无法解析Facebook和相关域名并访问服务。

同时,在北京时间10月5日凌晨0时开始也监控到了WhatsApp(AS11917)下所有Prefix、IP和路径的丢失,如图3所示。

图片3

图3 网动仪捕获到WhatsApp (AS11917)有明显波动情况发生

WhatsApp服务也无法访问的原因是:在2019年Facebook 合并旗下所有服务并实现集中化,使公司可以统一了解用户的互联网使用习惯。但是,这也使得本次单点故障影响了整个Facebook服务体系。

综上所述,埃文科技网动仪捕获到Facebook的AS32934和WhatsApp的AS11917的网络波动,波动时间也与新闻报道的Facebook断网时间吻合。服务中断原因是主干路由器上的配置更改导致边界网关协议(BGP) 撤销了托管Facebook域名服务器的IP地址前缀,进而引发的一系列服务异常。

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

MySQL部分从库上面因为大量的临时表tmp_table造成慢查询

背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_

手写Java HashMap源码

HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22

2020年前端实用代码段,为你的工作保驾护航

有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )

Twitter的分布式自增ID算法snowflake (Java版)

概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移