据报道，Facebook该公司的主要业务于10月4日（星期一）发生严重中断。负责施工和维护其技术和应用的人员很难处理大规模停机。虽然停机Facebook公司不是什么新鲜事，但这次中断一定是公司历史上的停机。
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公司的大规模经营意味着需要额外关注代码审计工具（如未能阻止中断的工具）。