Facebook 崩溃始末

TL;DR

Facebook 的路由配置出错导致服务器下线，让工程师不得不物理进入安全系数很高的服务器进行修复。

下面两篇博客分别从内部和外部视角对其进行了分析

Facebook 博客

原文：More details about the October 4 outage

在昨天的故障之后，我们的平台已经开始照常运行，我认为值得分享更多的细节，说明发生了什么，为什么，以及最重要的是，我们如何从中学习。

这次中断是由管理我们全球骨干网络容量的系统引发的。骨干网是 Facebook 建立的网络，将我们所有的计算设施连接在一起，它由数万英里的光纤电缆组成，横跨全球，连接我们所有的数据中心。

这些数据中心有不同的形式。有些是巨大的建筑物，容纳了数以百万计的机器，用于存储数据和运行沉重的计算负载，以保持我们的平台运行，其他的是较小的设施，将我们的骨干网络连接到更广泛的互联网和使用我们平台的人。

当你打开我们的一个应用程序并加载你的信息时，该应用程序对数据的请求从你的设备到最近的设施，然后直接通过我们的骨干网络与更大的数据中心进行通信。这就是你的应用程序所需要的信息被检索和处理的地方，并通过网络发送回你的手机。

所有这些计算设施之间的数据流量是由路由器管理的，它负责计算所有传入和传出数据的发送位置。在维护这一基础设施的大量日常工作中，我们的工程师经常需要将骨干网的一部分脱机维护：也许是修复一条光纤线路，增加更多的容量，或者更新路由器本身的软件。

这就是昨天故障的根源。在这些例行维护工作中，有一条命令被发出，目的是评估全球骨干网容量的可用性，这无意中关闭了我们骨干网的所有连接，并切断了 Facebook 全球数据中心的连接。我们的系统被设计为审计这样的命令，以防止这样的错误，但该审计工具的一个错误使其无法正确地停止该命令。

这一变化导致我们的数据中心和互联网之间的服务器连接完全断开。而这种连接的完全丧失造成了第二个问题，使事情变得更糟。

我们的小型设施执行的工作之一是响应 DNS 查询。DNS 是互联网的地址簿，使我们在浏览器中输入的简单网络名称能够被翻译成特定的服务器IP地址。这些翻译查询由我们的权威名称服务器回答，这些服务器（dns 服务器）本身也拥有一个对应的 IP 地址，而这些地址又通过另一个称为边界网关协议（BGP）的协议向互联网的其他部分公布。

为了确保可靠的运行，如果我们的 DNS 服务器自己不能与我们的数据中心对话，就会禁用这些 BGP 广播，因为这是网络连接不健康的表现。在最近的故障中，整个骨干网被从运行中移除，（刚刚提到的策略）使这些地方（dns 服务器）宣布自己不健康，并撤回这些 BGP 广播。最终的结果是，我们的DNS服务器变得遥不可及（不可路由），尽管它们仍在运行。这使得互联网的其他部分无法找到我们的服务器。

所有这些都发生得非常快。当我们的工程师努力弄清楚发生了什么以及为什么发生时，他们面临着两个巨大的障碍：

• 首先，由于他们的网络瘫痪，不可能通过我们的正常手段访问我们的数据中心；
• 其次，DNS的完全丧失破坏了我们通常用来调查和解决这种故障的许多内部工具。

我们的主要网络和带外管理网络访问被切断，所以我们只能派工程师到数据中心现场，让他们调试问题并重新启动系统。但这需要时间，因为这些设施的设计考虑到了高水平的物理和系统安全。它们很难进入，而且一旦你进入，硬件和路由器的设计是很难修改的，即使你有物理访问权。因此，我们需要额外的时间来激活所需的安全访问协议，让人们到现场并能够在服务器上工作。只有这样，我们才能确认问题，并使我们的主干网重新上线。

一旦我们的骨干网络连接在我们的数据中心区域内恢复，一切都会随之恢复。但问题还没有结束：我们知道，一下子恢复我们的服务可能会因为流量的激增而导致新一轮的崩溃。各个数据中心都报告说电力使用量下降了几十兆瓦，而突然扭转这种电力消耗的下降可能会使从电力系统处于危险之中。

幸运的是，由于我们已经进行了很长时间的 "风暴 "演习，我们对这一事件有充分的准备。在风暴演习中，我们通过关闭一个服务、数据中心或整个地区来模拟一个重大的系统故障，对所有涉及的基础设施和软件进行压力测试。从这些演习中获得的经验给了我们信心和经验，使事情重新上线并仔细管理不断增加的负载。最后，我们的服务很快就恢复了，没有再出现任何系统性的故障。虽然我们以前从未进行过模拟我们的全球骨干网被切断的风暴，但我们肯定会寻找方法来模拟这样的事件，并继续前进。

每一次这样的失败都是一个学习和改进的机会，我们可以从这一次学到很多东西。在每个问题之后，无论大小，我们都会做一个广泛的审查过程，以了解我们如何使我们的系统更有弹性。这个过程已经在进行了。

我们已经做了大量的工作来加固我们的系统（安全措施），以防止未经授权的访问，有趣的是，当我们试图从不是由恶意活动，而是由我们自己造成的错误引起的故障中恢复时，这种加固却减缓我们的速度。我相信这样的权衡是值得的：大大提高了日常的安全性，但是却在这样一个罕见的事件中恢复得很慢。从现在开始，我们的工作是加强我们的测试、演习和整体复原力，以确保像这样的事件尽可能少发生。

Cloudflare 博客

原文：Understanding How Facebook Disappeared from the Internet

"Facebook不可能瘫痪，对吗？"，我们想了一会儿。

今天（2021/10/05） 15:51 UTC，我们提了一个题为 "Facebook DNS查询返回SERVFAIL "的内部事件，因为我们担心我们的DNS解析器1.1.1.1有问题。 但当我们准备在我们的公共状态页面上发布时，我们意识到发生了其他更严重的事情。

社交媒体迅速爆发，报道了我们的工程师也迅速确认的情况。事实上，Facebook及其附属服务 WhatsApp 和 Instagram 都已瘫痪。他们的 DNS 服务器停止解析，他们的基础设施IP也无法访问。这就像有人一下子从他们的数据中心 "拔掉了电缆"，并将他们与互联网断开。

这本身并不是一个DNS问题，但DNS故障是我们看到的Facebook较大的故障的第一个症状。

这怎么可能呢？

Facebook的更新

Facebook 现在发表了一篇博文，介绍了内部发生的一些细节。在外部，我们看到了这篇文章中概述的 BGP 和 DNS 问题，但问题实际上始于一个影响整个内部骨干网的配置变化。这导致了 Facebook 和其他设施的消失，而 Facebook 内部的员工也很难再获得服务（主要是 dns 的原因）。

脸书又发表了一篇博文（上文的翻译），对发生的事情做了更详细的说明。你可以阅读那篇关于内部情况的文章，以及这篇关于外部情况的文章。

现在来看看我们从外部看到的情况。

认识 BGP

BGP 是边界网关协议的缩写。它是一种在互联网上的自治系统（AS）之间交换路由信息的机制。使互联网运转的大型路由器拥有庞大的、不断更新的可能路由列表，这些路由可以用来将每个网络数据包送到它们的最终目的地。没有BGP，互联网路由器就不知道该怎么做，互联网也就无法运行。

互联网实际上是一个网络的网络，它是由BGP捆绑在一起的。BGP允许一个网络（例如Facebook）向构成互联网的其他网络广播其存在。当我们写到 Facebook 没有广播它的存在时，ISP 和其他网络就找不到 Facebook 的网络，因此它就不可用。

各个网络都有一个ASN：一个自治系统号码。一个自治系统（AS）是一个具有统一的内部路由策略的单独网络。一个AS可以发起前缀（说他们控制着一组 IP 地址），以及过境前缀（说他们知道如何到达特定的 IP 地址组）。

Cloudflare 的 ASN 是AS13335。每个 ASN 都需要使用 BGP 向互联网宣布其前缀路由；否则，没有人会知道如何连接以及在哪里找到我们。

在这个简化图中，你可以看到互联网上的六个自治系统，以及一个数据包从起点到终点可能使用的两条路线。AS1→AS2→AS3 是最快的，AS1→AS6→AS5→AS4→AS3 是最慢的，但如果第一条失败，也可以使用。

在 15:58 UTC，我们注意到，Facebook 已经停止宣布他们的 DNS 前缀的路由。这意味着，至少，Facebook 的 DNS 服务器是不可用的。正因为如此，Cloudflare的1.1.1.1 DNS解析器无法再响应查询 facebook.com 的IP地址。

route-views>show ip bgp 185.89.218.0/23% Network not in tableroute-views>route-views>show ip bgp 129.134.30.0/23% Network not in tableroute-views>同时，其他的 Facebook IP 地址仍在路由中，但没有任何作用，因为没有DNS，Facebook 和相关服务实际上是不可用的。

route-views>show ip bgp 129.134.30.0 BGP routing table entry for 129.134.0.0/17, version 1025798334Paths: (24 available, best #14, table default) Not advertised to any peer Refresh Epoch 2 3303 6453 32934 217.192.89.50 from 217.192.89.50 (138.187.128.158) Origin IGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402 path 7FE1408ED9C8 RPKI State not found rx pathid: 0, tx pathid: 0 Refresh Epoch 1route-views>我们跟踪我们在全球网络中看到的所有BGP更新和公告。在我们的规模下，我们收集的数据让我们看到了互联网是如何连接的，以及流量要从哪里流向地球上的各个地方。

BGP UPDATE 消息通知路由器你对前缀广播所做的任何改变。在检查我们的时间序列数据库时，我们可以清楚地看到从 Facebook 收到的更新数量。通常情况下，这个图表是相当安静的：Facebook 不会每分钟对其网络进行大量的更改。

但在UTC时间15:40左右，我们看到 Facebook 的路由变化达到了一个高峰。这就是麻烦开始的时候。

如果我们把这个观点按照路由的 announcements 和撤销 withdrawals 来划分，我们就能更好地了解发生了什么。路由被 withdrawals，Facebook 的 DNS 服务器下线。

随着这些 withdrawals，Facebook及其网站实际上已经与互联网断开了联系。

DNS 受到影响

作为这一事件的直接后果，世界各地的DNS解析器停止了对其域名的解析。

➜ ~ dig @1.1.1.1 facebook.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;facebook.com. IN A➜ ~ dig @1.1.1.1 whatsapp.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;whatsapp.com. IN A➜ ~ dig @8.8.8.8 facebook.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;facebook.com. IN A➜ ~ dig @8.8.8.8 whatsapp.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;whatsapp.com. IN A发生这种情况是因为DNS，像互联网上的许多其他系统一样，也有其路由机制。当有人在浏览器中键入https://facebook.com URL时，负责将域名翻译成实际IP地址进行连接的DNS解析器，首先检查它的缓存中是否有东西并使用它。如果没有，它就试图从域名服务器中获取答案，通常由拥有该域名的实体托管。

如果域名服务器无法到达，或者由于其他原因而无法响应，那么就会返回一个SERVFAIL，浏览器就会向用户发出一个错误。

由于Facebook停止通过BGP宣布他们的DNS前缀路由，我们和其他人的DNS解析器没有办法连接到他们的名字服务器。因此，1.1.1.1、8.8.8.8和其他主要的公共DNS解析器开始发出（和缓存）SERVFAIL响应。

但这还不是全部。现在，人类行为和应用逻辑开始发挥作用，导致另一个指数效应。一场额外的 DNS 流量的海啸随之而来。

发生这种情况的原因是

• 应用程序不接受一个错误的答案，并开始重试。
• 用户也不接受一个错误的答案，并开始重新加载页面，或杀死和重新启动他们的应用程序。

因此，现在，由于 Facebook 和他们的网站是如此之大，我们的DNS解析器在全球范围内处理比平时多30倍的查询，并可能对其他平台造成延迟和超时问题。

我们绝大部分的DNS请求都能在10毫秒内得到解决。同时，p95和p99百分位数的最小部分的响应时间增加了，可能是由于 TTL 过期不得不请求不存在的 Facebook 的 dns 服务器而导致的超时。10秒的DNS超时限制在工程师中是众所周知的。

影响到其他服务

人们寻找替代方案，想知道更多或讨论发生了什么。当 Facebook 变得无法访问时，我们开始看到对 Twitter、Signal 和其他消息和社交媒体平台的 DNS 查询增加。

我们还可以从 Facebook 受影响的 ASN 32934 的 WARP 流量中看到这种不可达性的另一个副作用。这张图显示了每个国家从15:45 UTC到16:45 UTC的流量与三小时前相比的变化。在世界各地，进出 Facebook 网络的 WARP 流量完全消失了。

互联网

今天的事件温和地提醒我们，互联网是一个非常复杂和相互依赖的系统，由数百万个系统和协议共同工作。信任、标准化和实体间的合作是使其为全球近50亿活跃用户工作的核心。

更新

在21:00 UTC左右，我们看到来自Facebook网络的BGP活动再次出现，并在21:17 UTC达到顶峰。

该图表显示了 "facebook.com "在Cloudflare 的 DNS解析器1.1.1.1上的可用性。它在15:50 UTC左右停止可用，并在21:20 UTC恢复。

毫无疑问，Facebook、WhatsApp和Instagram的服务将需要进一步的时间才能上线，但截至UTC时间21:28，Facebook似乎已经重新连接到全球互联网，DNS也重新工作。