Facebook史上最严重宕机，全网宕机近七小时，到底是怎么回事?

Facebook史上最严重宕机，全网宕机近七小时，高管赴推特道歉。近7个小时时间，全都挂了Facebook全网宕机，连内网都废了。Twitter成为了最大赢家。对一家互联网巨头来说，这样的状况实在太尴尬。这已经是Facebook创办以来最严重的一次网络访问事故。直到下线近7个小时，美国西部时间下午三点左右，Facebook、Instagram等诸多产品才恢复正常访问。（目前只是美国地区恢复正常，全球其他国家和地区依然没有恢复。）

整个事件可以概况为：Facebook负责BGP变更的工程师，将包含Facebook权威（Authorized）域名服务器的网段185.89.218.0/23和129.134.30.0/23过滤掉了，从而造成的连锁反应。

以下是完整的整个事件的前因后果：

Facebook网络工程师，更新BGP路由配置时，将185.89.218.0/23和129.134.30.0/23这两条路由过滤掉了，这两条路由分别包含512个IP地址，一共1024个IP地址，其中：

185.89.218.0/23代表IP地址从185.89.218.0开始到185.89.219.255结尾的512个地址。

129.134.30.0/23代表IP地址从129.134.30.0开始到129.134.31.255结尾的512个地址。

意味着Internet上其他路由器将没有通往这1024个IP地址的路由，怎么办？

丢弃处理！

可是要命的是，这1024个IP地址恰恰包含Facebook公司权威DNS服务器的IP地址。这样就出大事了。要想透彻理解为何要出大事，首先要了解DNS是如何工作的？

当用户在浏览器里输入Facebook.com之后敲回车键，浏览器需要将facebook.com解析成IP地址之后才能建立TCP连接，然后TLS安全连接，然后是http交易。

通常用户的本地DNS服务器就是家庭网关IP、或者公司网关、或者公司DNS Server，比如192.168.1.1 、10.0.0.1、172.16.1.1之类的，也有的用户使用诸如1.1.1.1 、8.8.8.8、114.114.114.114的DNS服务器。但是这些这些DNS服务器，仅仅是域名解析的搬运工。当用户的解析Facebook.com请求到来时，它们先检查自己的缓存里是否有facebook.com与IP地址的条目，如果有，直接返回给用户。

如果没有，需要这些域名解析的搬运工比如1.1.1.1，去根域名服务器（一共13个虚拟IP地址）去查询，返回com域名服务器（一级）IP地址列表。

1.1.1.1这台不知疲倦的搬运工再联系com域名服务器（使用IP地址联系），com域名服务器给1.1.1.1 返回facebook.com域名服务器的IP地址列表。就是这么几台服务器才是最权威的数据源头，因为它们才真正知晓facebook内部服务器域名与IP地址的映射关系。

可是当1.1.1.1这台搬运工尝试联系facebook.com域名服务器的IP地址列表时，无法连接，因为Internet上没有facebook.com域名服务器的IP地址列表的路由表，Facebook域名服务器的IP地址为何从Internet全球路由表里消失了，因为Facebook网络工程师将它们（185.89.218.0/23和129.134.30.0/23）过滤出去了。

这样1.1.1.1就无法将Facebook.com域名解析返回给用户，用户就无法访问facebook的网站。

为何Facebook全球有30多亿用户，该次事件只影响到其中的8000多万的用户？

如上文所说，域名解析搬运工如1.1.1.1、8.8.8.8，如果成功解析facebook网站的域名，通常会缓存一段时间，这样当下一个用户访问facebook网站时，可以立马将结果返回给用户，这样可以省却不少的时间，同时刷新缓存定时器。

这就意味着，如果一台域名搬运工一直有用户在解析facebook域名，一直在刷新缓存定时器，那么这个缓存一直不会被删除，一直可以被直接返回给用户。所以，即使在互联网无法访问facebook权威域名服务器，但是依靠分布在全球各地的域名解析搬运工的缓存机制，依然有很多用户可以访问Facebook网站。毕竟Facebook其他服务器是可路由的、是可以到达的！

当然如果有的域名搬运工，缓存的内容由于没有域名解析的刷新，超时最后被删除。当域名搬运工试图联系facebook权威服务器时，就出现问题了。

Facebook负责变更BGP的工程师为何不在第一时间做回滚（Rollback）操作？

做变更的工程师通常都是远程VPN操作，而做路由变更操作是一种极度高风险的操作，因为一旦路由配置出错，工程师就无法再访问正在远程操作的路由器了。为了保险起见，为了不和路由器失去联系，工程师在commit变更代码时，会使用一个confirm选项，后面跟着一个数字，单位是分钟。比如

Commit confirm 2

这条代码的意思是，将当前的修改配置commit, 两分钟之后自动回滚到修改前的版本。在这两分钟内，工程师发现远程SSH软件与路由器的远程SSH连接依然没有断，那么就认为当前的修改没有问题，于是再次使用 commit命令确认当前修改，那么修改的配置就真正的生效了。

相反，如果工程师敲完命令立马自己的远程软件SSH断了，说明当前的修改让路由器与Internet失去了联系，路由出问题了。好在这种影响只会影响2分钟，2分钟之后自动回滚到修改前的版本，工程师依然可以再次联系到路由器，检查自己的配置哪里出了问题。

很显然，在这两分钟内facebook工程师没有尝试去Ping一下Facebook内部权威域名服务器。否则他们一定不会commit这次变更操作。

为了简化操作，工程师在等待confirm 的时间内，可以使用自动化的脚本，将公司内部最关键的服务器Ping一遍，其中包括域名服务器、域控制器、时间服务器等等，确保它们全部没有问题再commit配置版本。

源：车小胖谈网络