原标题：单点故障遇上电锯惊魂？——Facebook宕机7小时
10月4日，包括Facebook,Ins,Oculus和WhatsApp在内的一系列服务群体宕机接近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此次故障的罪魁祸首。
10月4日，包括Facebook,Ins,Oculus和WhatsApp在内的一系列服务群体宕机接近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此次故障的罪魁祸首。
责任编辑：