Facebook公司在10月4日晚间发表了一份简短声明，主要是为了反驳在社交媒体上传播的阴谋论。随后在10月5日公布了导致业务宕机的更多细节。
该公司发表的一篇博客文章基本证实了人们已经知道的事情，正如Cloudflare所详述的那样：Facebook公司以某种方式设法阻断从外部互联网到运行Facebook、Instagram、WhatsApp和其他属性的服务器的途径，并进行了例行维护。
Facebook公司运营着庞大的网络设施，其中包括自己的数据中心以及分散在世界各地的名称为“存在点”的小型数据中心设施，用于收集入站流量，并通过Facebook公司的专用网络将这些数据引导至最终目的地。
服务器和网络设备由于各种原因容易出现故障，检查网络上是否有任何故障是工程人员日常工作的一部分。但在10月4日早上，例行检查以某种方式执行，并作为命令将Facebook的所有连接从其骨干网络撤回。
该公司在其发表的一篇帖子中表示，本应检测配置更改中潜在的灾难性错误的审计工具失效，因为该审计工具中的一个错误使其无法终止发布的命令。
Facebook公司运营的基础设施选择使问题更加复杂，而很久以前就其内部设施做出的决定使得从这个错误中恢复比其他公司要困难得多。
Facebook公司几乎完全依赖自己的基础设施和定制服务来满足其运营所需的几乎所有需求，相比之下，其他规模和资源相同的科技公司至少在部分使用第三方提供商提供的基础设施来满足需求。
这其中包括DNS服务器，它们运行在那些规模较小的接入点设施中。这些服务器告诉Facebook公司的数据中心对其内容的传入请求来自何处，并为请求“facebook.com”的浏览器提供一条通往该目的地的计算机的途径。
Facebook公司的DNS服务器的设计旨在告知对“facebook.com”的入站请求，如果它们检测到该路径有问题，则避开通往数据中心的特定路径，因为长时间的延迟都会导致糟糕的用户体验。在正常情况下，工作路径比故障路径多得多，而且很容易找到快速绕行的路径。
然而，当所有这些路径都消失时，那些以其他方式运行的DNS服务器不知道Facebook的服务器在哪里，迫使它们向手机和浏览器返回错误消息。
让事情变得更加困难的是，Facebook公司的内部通信和灾难恢复工具依赖于与容纳这些DNS服务器的设施的连接。
到目前为止所描述的一切都发生在10月4日早上大约两分钟的时间里。重要的是Facebook公司需要快速恢复这个网络规模的错误，而这种恢复比以往更加艰难。而不知什么原因，Facebook与其服务器的带外连接(当主要网络出现故障时的正常备份计划)也失败了。这意味着需要物理访问其数据中心设施才能解决问题。
虽然Facebook公司实际上并不需要修改其服务器框架来解决问题，但确保允许具有专业人员进入最近的数据中心并处理相关服务器故障所花费的时间比人们想像的要多。
每一次宕机都是一次学习的机会，即使对于像Facebook公司这样似乎不愿意从其他领域的错误中吸取教训的公司也是如此。以下是从这件事可以学到的三个经验和教训：
•做好最坏的打算。企业需要制定针对计算资源或网络连接完全丢失的应急计划，而不仅仅是数据中心或云计算区域发生故障。
•采用多个服务商的服务。虽然互联网整体瘫痪的可能性极小，但采用多个云计算服务提供商的云计算服务是值得的。
•检查优先事项。如果没有采用大量的自动化技术，就无法实施Facebook公司那样大规模的操作，这意味着代码审计工具(例如未能阻止此次中断的工具)需要额外关注。
版权声明：本文为企业网D1Net编译，转载需注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。
京公网安备 11010502049343号