10月4日，包括Facebook、Ins、WhatsApp 和 Oculus在内的一系列服务群体宕机接近7小时，以致于Facebook高管要到竞争对手的地盘——推特上去发布声明、通知，以及道歉。

故障解决后，各种细节陆续披露出来，其原因的离奇让广大的运维人员不由感叹：原来Facebook也会出这些不靠谱的低级错误啊。

单点故障

一条很简单的命令出错——这是Facebook方面披露的事故最初原因。根据Facebook工程和基础设施副总裁Santosh Janardhan在一篇博客中透露，运维工程师只是根据日常运维要求输入了一条命令，目的是评估Facebook全网容量的可用性，结果却是“无意中切断了我们骨干网络中的所有连接，有效地断开了 Facebook 全球数据中心的连接。”

Janardhan表示，系统中有一条审核程序可以防止出现类似的错误，但很不巧的是，当时这个审核系统也出现了问题，导致错误的命令被“正确无误”的执行了下去。

这条命令的执行结果也非常简单：通知Facebook的域名解析服务器（DNS）删除Facebook相关的IP段的路由记录。从全网评估变全网删除，从而导致了Facebook以及相关的域名无法访问，全体宕机。

不过这些并不是Facebook史无前例宕机的根本原因。根本原因在于， Facebook虽然准备了多台DNS作为备份，但它们都处在子网络185.89.218.0/23和129.134.30.0/23。凡是Facebook的解析都需要及经过这里，一旦故障，就会导致Facebook及相关服务的失联。

可以说，过于简单的DNS配置导致的单点故障才是Facebook此次故障的罪魁祸首。

电锯惊魂？

运维宇宙的上古时代流传这个传说：最高权限管理员是一把改锥。

在这次Facebook故障中，改锥没有露面，但是电锯露了一小脸。在铺天盖地的猜测中，《纽约时报》语出惊人：因为数据中心安全设施保护严密，加上系统故障导致门禁不可用，Facebook工程师最后靠一把电锯打开了大门……

虽然最后辟谣了，电锯并没有出场。但现场“物理维护”的艰难并不比远程维护容易半分。

Facebook表示，因为DNS故障导致无法通过外网进行远程操作，只好派工程师现场解决问题。但“这些设施的设计考虑到了高水平的物理和系统安全性。它们很难进入，一旦您进入内部，即使您可以物理访问它们，硬件和路由器的设计也很难修改。”

并且，工程师“需要额外的时间来激活让人们到现场并能够在服务器上工作所需的安全访问协议”。可见在宕机的7小时中，工程师为解决“物理问题”也花了不小的功夫。

而在技术圈还有另一个传闻：在一切解决后，工程师心急上电，结果导致DNS被瞬间流量冲垮，只好拔掉网线重新开机，才真正的恢复了服务。

至此，Facebook的惊魂7小时才算正式结束，而留给业界的思考和教训、经验却会长久的流传下去。

1、任何能引发单点故障的环节都需要有冗余系统，无论看起来是否重要。

2、当外网出现问题无法远程运维的时候，应该有可以进行访问的内网通道。

3、一个关于电锯的问题：数据中心的物理安全措施同样会受到系统故障的影响，应该如何避免安全变成“掣肘”呢？