灯灭系统亮：验证瞬时断电就绪状态

• 我们推出了“瞬时断电风暴”（Instantaneous PowerLoss Storm），这是 Meta 基础设施中一种全新的测试范式，旨在应对和缓解数据中心内的瞬时或零预警断电事件。
• 我们将分享：如何通过纵深防御策略在现有系统中构建容忍瞬时故障的就绪能力；实施过程中所做的权衡，以及我们如何验证这种就绪状态。

• * *

灾难防备绝非可有可无。飓风、野火、电力供应和网络中断，以及无数其他灾难场景，都对数据中心（DC）基础设施构成威胁。

当我们拥有数小时或更长的预警时间时，早期预警系统和久经考验的缓解策略已能有效发挥作用。随着数据中心规模的扩张，这些策略虽已日趋成熟，但基础设施规模和复杂性的不断增长，要求我们必须提升对瞬时断电等零预警灾难（即在毫无预警情况下发生的灾难）的防备水平，以将对整体集群可用性的影响降至最低。

“瞬时断电风暴”是 Meta 历史悠久的灾难就绪（DR）“Storm”计划中的一种新测试范式。它构成了应对和缓解由已知、新兴及未知风险引发的瞬时或零预警断电的最后一道防线和终极安全网。

我们如何通过纵深防御策略在现有系统中构建容忍瞬时故障的就绪能力

应对瞬时断电的能力必须从头开始构建到我们的数据中心技术栈中，涵盖机电设施、服务器机架、存储、计算资源以及核心 Twine 容器编排器。幸运的是，这些架构在设计之初就已将断电容错作为不可或缺的组成部分。

利用电池和断电信号警报器（PLS）在机架断电时持久化内存数据，便是其中一项关键能力。另一项能力则是为 Twine 服务提供强大的全区域异步信号机制，即以不可用事件（UE）的形式进行通知。（下文提到的“区域”是指多个数据中心建筑位于同一地理位置，并共享网络和电力连接的集合）。

尽管这些能力已在单个数据中心内的单一故障域中经过实战检验并得到加固，但我们发现在涉及整个区域的场景中仍存在显著漏洞。此外，对区域级场景进行测试，不仅要求我们应对规模（典型区域的大小通常是典型故障域的 50 到 60 倍）和副本放置方面的挑战，还需解决自主引导启动的问题。

引导启动（Bootstrapping） 是指启动一个已断电的区域，需要数百万个服务同时启动并自主完成相互发现。我们在下文中描述了引导启动过程中遇到的两个问题，这促使我们采取了_双重保险策略_，以覆盖所有可能的突发状况和意外情况。

其中一个尤为突出的问题——也是自早期就一直困扰我们的难题——是依赖关系，特别是令人畏惧的循环依赖，即“衔尾蛇”风险！我们的 Twine 编排器拥有一组控制平面服务——包括 Scheduler、Allocator、Broker、Zelos（协调器）等——若缺少这些服务，区域内任何其他服务都无法运行或启动。虽然在常规运行期间循环依赖的风险较低，但在引导启动整个区域时，其风险和影响要大得多。这是一个典型的“先有鸡还是先有蛋”的问题。

我们通过识别控制平面服务之间的关键启动依赖解决了这一问题，并在 CI/CD 流水线中通过 Belljar 测试_持续且频繁地_进行检测。这有助于在部署到生产环境之前发现并消除大部分（即便不是全部）依赖风险。鉴于基础设施的快速演进，作为双重保险方案，我们还必须具备打破任何可能意外出现的循环依赖的能力。专门构建的 Twine 恢复工具包提供了这种“快速启动”能力，用于恢复支撑 Twine 自身运行的关键服务。结合 Belljar 和 Twrko，我们已成功彻底消除了循环依赖这一隐患。

我们还在同一范围内遇到了一个“回旋镖”问题——关键信号的生成器反而受到了该信号的影响。原本用于协调服务关停与恢复的 UE，最终却把编排器控制平面服务自身也关停了，导致出现了一些无法被“回收”的孤儿服务（因为它们从未收到过 UE）。虽然这个问题本可以通过复杂的方案来解决，例如将一组预设服务从 UE 分发列表中排除，但我们决定采用一种更简单、更可持续的方法：允许控制平面服务直接“忽略”与电源相关 UE 关联的关停信号。

回旋镖效应：Service-Z 的关停间接影响了 Twine Scheduler 编排关停操作的能力。

在可靠性与增长速度之间取得平衡时所做出的权衡

虽然构建对瞬时断电的严密容错能力在技术上是可行的，但这可能会带来基础设施的机会成本，或导致系统过度工程化。后者甚至可能引入误报风险，进而影响正常运维。因此，我们需要做出一定的权衡，以在可靠性与工程效率之间找到最佳平衡点。

我们首先划定了必须避免的影响红线。存储和数据库系统的数据丢失、数据中心设施（机械/电气）的永久性损坏，或超出单个区域的持续性影响，都被我们明确列为不可妥协的基本要求。而短暂的服务错误、机架故障（在预定义阈值内），以及服务路由表或区域不可用检测中的有限数据滞后（这是异步系统中的经典难题）则被视为可容忍的风险。总体而言，只有那些无法通过事后补救措施解决，且无法在合理的平均响应时间（MTTR）内处理的问题，才会被归入不可容忍的影响范畴。

我们如何通过瞬时断电风暴演练验证准备情况，以及如何借此不断突破极限

通过对大型生产区域进行断电来验证上述预期和准备工作，伴随着巨大的风险，其中既有已知的未知因素，也有未知的未知因素。为了解决这种“要化解风险就必须先承担风险”的先有鸡还是先有蛋的难题，我们建立了一套渐进式方法：在启用新的/预生产区域时验证依赖关系等独立问题，同时在复刻生产环境的“影子”区域中运行测试。随后，我们得以在最新（因而规模最小）的生产区域中成功开展测试，并将爆炸半径控制在有限范围内。最终，我们对承载关键存储、AI 和数据仓库工作负载的大型生产区域执行了断电操作。在这一阶段，我们将这些风暴演练命名为瞬时断电风暴。

从宏观角度来看，风暴演练包括注入电源故障以导致整个区域立即断电，并在短暂的 MTTR 之后采取补救性的“排空”操作，将受影响区域与全局控制器/调度器隔离开来。我们还力求在测试前不采取任何预防性措施，以真实模拟意外断电场景。测试所选用的 MTTR 反映了真实事故场景中的典型 MTTR 水平。

每一次演练都帮助我们的基础设施和工程师团队朝着长期目标不断迭代训练，最终实现像处理子区域故障域失效一样无缝地应对整个区域的失效。

迈向未来的基石：慢即是稳，稳即是快

即便采取了所有预防措施，这一过程也并非一帆风顺，而是充满了学习和改进的机会。这不仅提升了我们的测试能力，还渗透到了整个基础设施体系中，推动了对现有系统的多项架构优化。

与此同时，我们的基础设施正在快速演进，以满足容量和 AI 的海量用例需求。只有奠定坚实的基础，才能实现快速发展。可靠性与速度是一枚硬币的两面，二者缺一不可。从瞬时故障中恢复区域的能力为我们奠定了坚实基础，使我们能够创新数据中心设计并加以验证，在快速部署容量的同时同步构建可靠性，并进一步拓展我们所能承受的风险边界。

此前的风暴演练主要验证了存储和数据库后端，现在我们正采用同样的渐进式策略，针对承载实时客户端流量的区域验证其对瞬时故障的抵御能力。（更多内容将在后续文章中介绍！）随着这一增长阶段新挑战的不断涌现，我们也在持续审视并调整各项权衡决策。