介绍
今天，2022 年 6 月 21 日，Cloudflare 遭遇中断，影响了我们 19 个数据中心的流量。不幸的是，这 19 个地点处理了我们全球流量的很大一部分。此次中断是由一项长期运行项目中的一项变更引起的，该项目旨在提高我们最繁忙地点的恢复能力。这些位置的网络配置更改导致从 UTC 时间 06:27 开始的中断。世界标准时间 06:58 第一个数据中心重新上线，到世界标准时间 07:42，所有数据中心都在线并正常工作。
根据您在世界上的位置，您可能无法访问依赖 Cloudflare 的网站和服务。在其他地方，Cloudflare 继续正常运行。
我们对这次中断感到非常抱歉。这是我们的错误，而不是攻击或恶意活动的结果。
背景
在过去的 18 个月中，Cloudflare 一直在努力将我们所有最繁忙的地点转换为更灵活、更有弹性的架构。在此期间，我们已将 19 个数据中心转换为这种架构，内部称为 Multi-Colo PoP (MCP)：阿姆斯特丹、亚特兰大、阿什本、芝加哥、法兰克福、伦敦、洛杉矶、马德里、曼彻斯特、迈阿密、米兰、孟买、纽瓦克、大阪、圣保罗、圣何塞、新加坡、悉尼、东京。
这个新架构的一个关键部分，被设计成一个Clos 网络，是一个额外的路由层，它创建了一个网状连接。这种网格使我们能够轻松地禁用和启用数据中心内部网络的某些部分以进行维护或处理问题。该层由下图中的脊椎表示。
这种新架构为我们提供了显着的可靠性改进，并允许我们在这些位置运行维护而不会中断客户流量。由于这些位置也承载了很大比例的 Cloudflare 流量，因此这里的任何问题都会产生非常广泛的影响，不幸的是，这就是今天发生的情况。
事件时间表和影响
为了在 Internet 上可访问，像 Cloudflare 这样的网络使用称为BGP的协议。作为该协议的一部分，运营商定义了决定哪些前缀（相邻 IP 地址的集合）被通告给对等点（它们连接到的其他网络）或从对等点接受的策略。
这些策略具有单独的组件，这些组件会按顺序进行评估。最终结果是任何给定的前缀要么被公布，要么不公布。策略的更改可能意味着以前公布的前缀不再公布，称为“撤回”，并且这些 IP 地址将无法再在 Internet 上访问。
在对我们的前缀广告策略进行更改时，术语的重新排序导致我们撤回了前缀的一个关键子集。
由于此次撤出，Cloudflare 工程师在到达受影响的位置以恢复有问题的更改时遇到了更大的困难。我们有处理此类事件的备份程序，并使用它们来控制受影响的位置。
03:56 UTC：我们将更改部署到我们的第一个位置。我们的所有位置都不会受到更改的影响，因为它们使用的是我们的旧架构。
06:17：更改已部署到我们最繁忙的位置，但未部署到具有 MCP 架构的位置。
06:27：部署已到达启用 MCP 的位置，更改已部署到我们的脊椎。这是事件开始的时候，因为这迅速使这 19 个地点脱机。
06:32：宣布内部 Cloudflare 事件。
06:51：首先对路由器进行更改以验证根本原因。
06:58：找到并理解了根本原因。工作开始恢复有问题的变化。
07:42: 最后的还原已经完成。这被延迟了，因为网络工程师互相检查了彼此的更改，恢复了以前的恢复，导致问题偶尔再次出现。
08:00：事件结束。
这些数据中心的重要性可以从我们在全球处理的成功 HTTP 请求的数量中清楚地看出：
尽管这些位置仅占我们整个网络的 4%，但中断影响了总请求的 50%。在我们的出口带宽中也可以看到同样的情况：
错误的技术描述以及它是如何发生的
作为我们不断努力标准化基础设施配置的一部分，我们推出了一项更改，以标准化我们附加到我们宣传的前缀子集的 BGP 社区。具体来说，我们正在向我们的站点本地前缀添加信息社区。
这些前缀允许我们的金属相互通信，并连接到客户来源。作为 Cloudflare 变更程序的一部分，创建了变更请求票证，其中包括变更的试运行以及逐步推出程序。在它被允许出去之前，它还经过了多位工程师的同行评审。不幸的是，在这种情况下，步骤不够小，无法在错误触及我们所有的脊椎之前捕捉到错误。
更改在其中一台路由器上如下所示：
[edit policy-options policy-statement 4-COGENT-TRANSIT-OUT term ADV-SITELOCAL then]
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add TLL01;
+ community add EUROPE;
[edit policy-options policy-statement 4-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL then]
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add TLL01;
+ community add EUROPE;
[edit policy-options policy-statement 6-COGENT-TRANSIT-OUT term ADV-SITELOCAL then]
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add TLL01;
+ community add EUROPE;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL then]
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add TLL01;
+ community add EUROPE;
这是无害的，只是在这些前缀广告中添加了一些附加信息。刺的变化如下：
[edit policy-options policy-statement AGGREGATES-OUT]
term 6-DISABLED_PREFIXES { ... }
! term 6-ADV-TRAFFIC-PREDICTOR { ... }
! term 4-ADV-TRAFFIC-PREDICTOR { ... }
! term ADV-FREE { ... }
! term ADV-PRO { ... }
! term ADV-BIZ { ... }
! term ADV-ENT { ... }
! term ADV-DNS { ... }
! term REJECT-THE-REST { ... }
! term 4-ADV-SITE-LOCALS { ... }
! term 6-ADV-SITE-LOCALS { ... }
[edit policy-options policy-statement AGGREGATES-OUT term 4-ADV-SITE-LOCALS then]
community delete NO-EXPORT { ... }
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add AMS07;
+ community add EUROPE;
[edit policy-options policy-statement AGGREGATES-OUT term 6-ADV-SITE-LOCALS then]
community delete NO-EXPORT { ... }
+ community add STATIC-ROUTE;
+ community add SITE-LOCAL-ROUTE;
+ community add AMS07;
+ community add EUROPE;
乍一看这个差异可能会给人一种这种变化是相同的印象，但不幸的是，情况并非如此。如果我们专注于差异的一部分，可能会很清楚为什么：
! term REJECT-THE-REST { ... }
! term 4-ADV-SITE-LOCALS { ... }
! term 6-ADV-SITE-LOCALS { ... }
在这种差异格式中，术语前面的感叹号表示术语的重新排序。在这种情况下，多个术语向上移动，两个术语被添加到底部。具体来说，4-ADV-SITE-LOCALS 和 6-ADV-SITE-LOCALS 术语从顶部移到底部。这些术语现在落后于 REJECT-THE-REST 术语，从名称中可以清楚地看出，该术语是明确的拒绝：
term REJECT-THE-REST {
then reject;
}
由于该术语现在在站点本地术语之前，我们立即停止宣传我们的站点本地前缀，取消我们对所有受影响位置的直接访问，以及取消我们的服务器访问原始服务器的能力。
除了无法联系来源之外，这些站点本地前缀的删除还导致我们的内部负载平衡系统 Multimog（我们的Unimog 负载平衡器的一种变体）停止工作，因为它无法再在服务器之间转发请求我们的 MCP。这意味着我们在 MCP 中的较小计算集群接收到的流量与我们最大的集群相同，导致较小的计算集群过载。
补救措施和后续步骤
此事件影响广泛，我们非常重视可用性。我们已经确定了几个需要改进的领域，并将继续努力发现可能导致再次发生的任何其他差距。
以下是我们正在立即开展的工作：
流程：虽然 MCP 计划旨在提高可用性，但我们在更新这些数据中心的方式上存在程序上的差距，最终对 MCP 位置产生了更广泛的影响。虽然我们确实为此更改使用了交错程序，但交错政策直到最后一步才包括 MCP 数据中心。变更程序和自动化需要包括特定于 MCP 的测试和部署程序，以确保不会出现意外后果。
架构：不正确的路由器配置阻止了正确的路由被宣布，阻止了流量正确地流向我们的基础设施。最终，导致错误路由通告的策略声明将被重新设计，以防止无意的错误排序。
自动化：我们的自动化套件中有几个机会可以减轻此事件的部分或全部影响。首先，我们将专注于自动化改进，为网络配置的推出实施改进的交错策略，并提供自动化的“提交-确认”回滚。前者的增强会显着降低整体影响，后者会大大缩短事件期间的解决时间。
结论
尽管 Cloudflare 在我们的 MCP 设计上投入了大量资金以提高服务可用性，但这次非常痛苦的事件显然未能满足客户的期望。对于在中断期间对我们的客户和所有无法访问 Internet 资产的用户造成的干扰，我们深表歉意。我们已经开始着手进行上述更改，并将继续努力确保这种情况不会再次发生。
