这是我们从未想过需要撰写的一篇博客文章：在 Cloudflare 的一个主要数据中心发生断电事故后不到五个月，同一数据中心又再次发生断电事故。这的确很糟糕，但如果您在想“为什么他们继续使用这个设施？”，我不会责怪您。其实我们也在思考同样的问题。但事情的重点是：虽然该数据中心可能没有多大变化，但是 Cloudflare 在这五个月的时间里经历了很多变化。因此，虽然五个月前的大型数据中心离线故障确实令人苦恼，但这次事故的负面影响却减轻了许多。
本文介绍了一个高可用性数据中心在五个月内第二次发生断电故障的情况。但更重要的是，本文阐述了 Cloudflare 团队如何努力确保即使某个关键数据中心发生断电故障，也不会对我们的客户产生任何影响。
2023 年 11 月 2 日，Cloudflare 位于俄勒冈州波特兰地区的一个关键数据中心设施遭遇长时间断电故障。事故的起因是由电网提供商的维护工作引起的一系列级联故障，设施出现接地故障将此次事故推向高潮，而一系列意外事故使该设施无法及时恢复上线，情况变得更加糟糕。
如需阅读所有隐秘的详细信息，请访问此处。
每当数据中心完全断电时都会令人苦恼，不过，这是我们本该预料到的情况。遗憾的是，尽管有这样的期望，我们却并没有对产品实施各种要求，以确保它们在发生重大故障的情况下可以继续运行。
我们绝不允许再次发生这种错误。
橙色警报
此次事故着实令人苦恼，以至于我们宣布了“橙色警报”。我们借鉴了 Google 的这种理念：当 Google 业务面临生死存亡的威胁时，据说他们会宣布“黄色警报”或“红色警报”。Cloudflare 徽标是橙色的，因此，我们稍微修改了一下命名方案。
我们对“橙色警报”的构想是：主导处理事故的人员（在这个示例中是 Cloudflare 技术运营高级副总裁 Jeremy Hartman）获得授权，可以要求团队中的工程师完成他认为具有最高优先级的项目。除非宣布“红色警报”，但实际上我们最终会在遭受黑客攻击时这样做，这种情况下，“红色警报”将具有更高优先级。如果您有兴趣了解更多相关信息，请访问此处。
在成功应对了最近的这次事故之后，Jeremy 迅速对需要完成的最重要工作进行了分类，以确保即使在某个主要数据中心设施再次发生灾难性故障的情况下，我们也能保持高可用性。然后，团队开始着手处理相关工作。
我们的表现如何？
我们没有想到如此广泛的现实测试来得如此之快，但宇宙的运行方式会受到神秘因素的影响。2024 年 3 月 26 日星期二，距离首次停电事故还不到 5 个月，同一设施再次遭遇大面积停电。我们将在下文讨论此次停电的起因，不过，最重要的是，这次事故为我们团队在“橙色警报”下所做的工作提供了一个完美的测试。那么，测试结果是怎样的呢？
首先，我们来回顾一下 Cloudflare 的波特兰数据中心具备哪些功能。正如 2023 年 11 月 2 日的这篇博客文章所述，Cloudflare 控制平面主要由面向客户提供的网站和 API 等各种服务的界面构成。此外，分析和日志记录管道之类的底层服务主要由这些设施提供。
就像 2023 年 11 月的那次事故一样，我们立即收到警报，提示 PDX01 数据中心断电了。但与 11 月事故不同的是，我们很快就确定 Cloudflare 数据中心再次遭遇断电，这让我们陷入了与 5 个月前完全相同的处境。根据 2 月份一次成功的内部切断测试，我们也知道 Cloudflare 系统应该会有哪些反应。我们花了几个月的时间做准备，更新了无数系统并激活了大量网络和服务器容量，最终通过一次测试证明我们的工作取得了预期的效果。这种情况下的正确做法是自动故障转移到冗余设施。
我们的控制平面由数百个内部服务组成，其预期用途是当波特兰的三个关键数据中心之一遭遇断电故障时，这些服务可以继续在其余两个设施中正常运行，并且我们会继续在波特兰运营 Cloudflare 主要数据中心。如果波特兰数据中心完全不可用，我们能够将故障转移到 Cloudflare 欧洲数据中心。不过，这是备用选项，也不是我们立即追求的目标。
2024 年 3 月 26 日世界标准时间 14:58，PDX01 发生断电故障，我们的系统开始做出反应。到世界标准时间 15:05，我们的 API 和仪表板在没有人工干预的情况下都维持正常运行。过去几个月以来，我们的主要工作重点是确保客户在遇到类似停电的情况下，仍然能够配置和运行其 Cloudflare 服务。有一些特定服务需要人为干预，因此，需要更长时间才能恢复，但主要接口机制可以照常运行。
更确切地说，在 2023 年 11 月 2 日的事故期间，以下服务的控制平面宕机时间至少为六个小时，其中一些服务的功能降级了几天。
API 和仪表板Zero TrustMagic TransitSSLSSL for SaaSWorkersKVWaiting Room负载平衡Zero Trust GatewayAccessPagesStreamImages
在 2024 年 3 月 26 日的事故中，上述所有服务在断电后的几分钟内均启动并运行，并且其中多项服务在故障转移期间完全没有受到任何影响。
数据平面负责处理 Cloudflare 客户通过我们位于全球 300 多个城市的数据中心传递的流量，它没有受到影响。
Cloudflare 分析平台让客户可以了解其网络流量，但分析平台受到了影响，直到当天晚些时候才完全恢复。这是预料中的行为，因为分析平台依赖于 PDX01 数据中心。就像恢复控制平面的工作一样，在 2023 年 11 月 2 日的事故发生后，我们立即开始构建新的分析容量。然而，由于工作量庞大，这需要更多时间才能完成。我们一直在努力尽快摆脱这种依赖性，并且预计在不久的将来会完成这项工作。
在验证了控制平面服务的功能之后，我们再次面临如何冷启动超大型数据中心的问题。2023 年 11 月，这项活动大约花费了 72 小时；但这一次，我们在大约 10 小时内完成了这项活动。为了在今后进一步缩短这项活动的用时，我们还有很多工作要做，并且我们将继续完善相关流程，以防未来发生类似的事故。
我们是如何实现这一切的？
如前文所述，去年 11 月的停电事故促使我们引入了“橙色警报”，它是指在发生重大事故或危机时，我们将大部分或全部工程资源用于解决最紧迫的问题的流程。在过去的五个月里，我们将所有非关键工程资源转移到专注于确保控制平面的高可靠性。
各工程部门的团队响应号召，齐心协力确保提高系统在应对未来类似故障时的韧性。虽然 2024 年 3 月 26 日的这次事故出乎意料，但是我们一直在为这种情况做准备。
最明显的区别是控制平面与 API 恢复服务的速度。在没有人为干预的情况下，PDX01 发生断电故障七分钟后，仍然能够登录并更改 Cloudflare 配置。这是因为我们努力将所有配置数据库迁移到高可用性 (HA) 拓扑，并预先配置了足够的容量来吸纳容量损失。20 多个不同数据库集群中的 100 多个数据库同时因受影响的设施而发生故障，但自动恢复了服务。这实际上是一年多辛苦工作的结晶，我们通过每周测试，确保证明我们有能力正确地进行故障转移。
另一个重大改进是我们更新了 Logpush 基础设施。2023 年 11 月，PDX01 数据中心发生断电故障，导致我们无法将日志记录推送给客户。在启动“橙色警报”期间，我们在波特兰投资了 Logpush 基础设施 HA 部署，并且在阿姆斯特丹另外创建了一个主动故障转移选项。Logpush 利用了我们大规模扩展的 Kubernetes 集群，该集群散布在我们波特兰的所有设施，为服务所有者提供一种无缝方式用于部署具备高可用性和高韧性的服务。事实上，在 2 月的失序演习中，我们发现了波特兰 HA 部署中的一个缺陷，但客户没有受到任何影响，因为阿姆斯特丹的 Logpush 基础设施成功接管了服务请求。在这次活动中，我们看到采取修复措施后发挥了其应有的作用，并且能够从波特兰地区推送日志。
我们对 Stream 和 Zero Trust 产品进行的一些其他改进，对客户运行几乎没有影响。Cloudflare Stream 产品使用了大量计算资源进行视频转码，能够无缝移交给位于阿姆斯特丹的设施以继续运行。团队接到了服务可用性的具体目标要求，并提供了实现这些目标的多种选项。Stream 就是一个很好的示例，它说明了服务虽然选择了不同的韧性架构，但是依然能够在此次停电事故期间流畅地交付服务。Zero Trust 在 2023 年 11 月的事故中也受到了影响，此后将其绝大部分功能转移到我们的数百个数据中心，这些数据中心在此次事故中保持无缝运行。从根本上来说，这是我们推动所有 Cloudflare 产品采用的策略。因为我们遍布全球 300 多个城市的数据中心足以尽可能地提供高可用性。
数据中心的供电出现了什么情况？
2024 年 3 月 26 日世界标准时间 14:58，PDX01 数据中心的 Cloudflare 物理基础设施经历了一次彻底断电故障，随后据报告，为 Cloudflare 所有机柜提供服务的由 Flexential 拥有和运营的四台交换机同时发生了故障。也就是说，整个环境中的主电源路径和冗余电源路径均停用。在 Flexential 调查故障问题期间，工程师重点关注了一组称为电路交换板 (CSB) 的设备。CSB 好比是一个配电板，由一个主输入断路器和一系列较小的输出断路器组成。Flexential 工程师报告，CSB 上游的基础设施（馈电、发电机、UPS 和 PDU/变压器）没有受到影响，继续正常运行。同样，CSB 下游的基础设施（例如远程电源面板和连接的开关设备）也没有受到影响；因此，这表明停电故障就出现在 CSB 本身。
对 Flexential CSB 故障根本原因的初步评估表明，四个 CSB 内的断路器协调设置错误是导致事故的影响因素之一。过于严格的自动断开设置，可能会导致过流保护过于敏感，并且可能会导致设备误跳闸。在这起事故中，根据报告，Flexential 在四个 CSB 内的断路器设置相对于下游配置的功率容量来说过低。其中一个或多个断路器跳闸后，可能会导致剩余的活跃 CSB 板出现级联故障，进而导致 Cloudflare 的机柜以及共享基础设施上的其他设备完全断电。在对事故进行分类的过程中，我们得知 Flexential 设施团队注意到了错误的跳闸设置，他们重置了 CSB 设置并将其调整到预期值，这让 Cloudflare 团队能够以分阶段的有序方式启动我们的服务器。我们不知道这些设置值是何时确立的。通常情况下，这些值的设置/调整是在数据中心调试流程和/或断路器协调研究时的一个环节，然后再安装客户的关键负载。
接下来？
我们的首要任务是完成分析平台的韧性计划。分析不仅仅是仪表板中精致的图表。当您想要查看攻击状态、防火墙阻止的活动，甚至是 Cloudflare Tunnel 的运行状态时，您需要分析。我们有证据表明，Cloudflare 采用的韧性模式可以发挥预期的作用，因此，这仍然是我们的主要关注点，并且我们会力争尽快取得进展。
有些服务仍然需要手动干预才能正常恢复，并且我们已经为每个服务收集了数据和操作项，以确保无需执行进一步手动操作。我们将继续使用切断测试，来证明所有这些变化和增强功能可以提供客户所期望的服务韧性。
我们将继续与 Flexential 合作开展后续活动，尽可能地增进我们对其运行和审核流程的了解。虽然这次事故只发生在单个设施，但是我们会将这次演习转变成一个流程，确保我们以类似的视角看待所有关键数据中心设施。
我们再次对客户造成的影响深表歉意，尤其是那些依赖 Analytics Engine 的客户，他/她们在此次事故中无法使用产品功能。我们过去四个月的工作取得了预期的结果，并且我们将继续认真专注于完成剩余的工作。