Facebook故障是一系列不幸的事件酿成的！
一条写得很糟糕的命令、一款有缺陷的审核工具、一个阻碍成功恢复网络的DNS系统以及严密的数据中心安全，所有这些因素导致了Facebook长达 7 个小时的重大故障。
Facebook 表示，周一故障的根本原因是例行维护工作出了岔子，结果导致其DNS服务器不可使用，不过最先崩溃的是Facebook 的整个骨干网络。
雪上加霜的是，由于DNS无法使用，Facebook的工程师们无法远程访问他们所需的设备以便网络恢复正常，因此他们不得不进入数据中心手动重启系统。
这么一来速度慢了下来，但进一步阻碍恢复工作的是，数据中心实施了必要的保护措施，确保任何人都很难篡改。Facebook负责工程和基础设施的副总裁Santosh Janardhan在公司博客上写道：“数据中心很难进入；一旦你进入到里面，就算可以实际碰得到硬件和路由器，它们也被设计成很难改动。”
这要花时间，但是一旦系统恢复过来，网络就恢复正常。
恢复在其网络上运行的面向客户的服务是另一个漫长的过程，因为一次性开启全部服务可能会导致另一轮崩溃。Janardhan写道：“个别数据中心报告电力使用量下降了数十兆瓦，突然扭转电力使用量出现这种下降的情形可能会使电气系统到缓存的一切都面临风险。”
Facebook总共宕机了7小时5分钟。
例行维护搞砸了
触发故障的操作是，Facebook当时正将骨干网络的一部分断网进行维护。Janardhan写道：“在开展其中一项例行维护工作过程中，执行了一个命令，旨在评估全球骨干网容量的可用性，这无意中断开了我们骨干网络中的所有连接，实际上断开了Facebook全球数据中心的连接。”
这不是预定的计划，Facebook甚至部署了一款工具来理清可能导致这种灾难性故障的命令，但没有奏效。据Janardhan声称：“我们的系统旨在审核此类命令，以防止出现此类错误，但该审核工具的一个错误使其无法正确终止命令。”
一旦发生了这种情况，DNS注定要完蛋。
DNS是单一故障点
据监测互联网流量和故障的思科ThousandEyes的产品营销主管Angelique Medina表示，自动响应骨干网崩溃的机制似乎是导致DNS瘫痪的原因。
DNS（即目录名称服务）响应有关如何将Web名称转换成IP地址的查询，而 Facebook托管运行自己的DNS名称服务器。Medina说：“他们有一套架构，根据服务器的可用性来扩展或缩减DNS服务。当服务器的可用性因网络故障而降至零时，他们停用其所有的DNS服务器。”
这种停用是通过Facebook的DNS名称服务器向互联网边界网关协议（BGP） 路由器发送消息来完成的，这些路由器存储用来抵达特定IP地址的路由方面的信息。这些路由通常被公告给路由器，让路由器了解如何适当地引导流量。
Facebook的DNS服务器发送的BGP消息禁用了公告给自己的路由，因而无法将流量解析成Facebook骨干网络上的任何对应内容。Janardhan写道：“最终结果是，即使我们的DNS服务器仍在运行，也访问不了。这么一来，互联网的其余部分无法找到我们的服务器。”
即使DNS服务器仍然可以通过互联网来访问，Facebook的客户也会因他们试图访问的网络崩溃而丢失服务。对Facebook来说不幸的是，它自己的工程师也无法访问DNS服务器，而他们的远程管理平台访问已宕机的骨干系统少不了DNS服务器。
Medina说：“他们不仅仅将DNS服务用于面向客户的网站，还将其用于自己的内部工具和系统。通过完全关闭DNS服务，他们的网络操作员或工程师无法访问他们所需的系统以便解决问题。”
她表示，一套更稳健的架构将拥有双DNS服务，那样一个DNS服务可以支援另一个。据Medina声称，比如说，亚马逊（其AWS提供DNS服务）为其DNS使用两项外部服务：Dyn和UltraDNS。
汲取的教训
网络最佳实践认为，这起事件暴露了Facebook 架构存在的一个缺点。她说：“为什么他们的DNS在这里实际上是单一故障点？”如果本身出现DNS故障，又没有后备DNS，就可能会出现长时间的故障，“所以我认为一大经验教训就是要有冗余DNS。”
另一个共识是Medina针对其他服务提供商故障的看法。“通常就这些故障而言，他们的网络中存在错综复杂的依赖关系，以至于一旦整体服务架构中的一个部分出现了一个小小的问题，随后会出现这样的级联效应。”
“许多公司在充分利用大量的内部服务，这么做可能会带来不可预见的后果。这种情况在技术人员当中更为常见，但我确实认为值得指出。”
相关阅读 ·
- Facebook 大瘫痪，彻底消失 6 个多小时：因 BGP 路由问题
