Facebook史上最轻微无法出访，全站无法出访近七半小时，老总赴twitter致歉。近7个半小时天数，全被挂了Facebook全站无法出访，连内部网都废了。Twitter成为了最大输家。对一间网络巨擘而言，这种的情况真是太难堪。这已经是Facebook创立以来最轻微的一次网络出访交通事故。直至推向市场近7个半小时，英国东部天数上午四点以内，Facebook、Instagram等众多产品才恢复正常出访。（目前只是英国沿海地区恢复正常，全球其它国家和沿海地区仍然没恢复正常。）

整座该事件可以概述为：Facebook负责管理BGP更改的技师，将包涵Facebook权威性（Authorized）域名伺服器的VLAN185.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门牌号。这种就出事了。要想有条理认知为什么Gazeille事，具体而言要介绍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实用性版本。

源：车小胖谈网络