重新审视现代数据中心中的 CPU 静默数据损坏

《Communications of the ACM》：Revisiting CPU Silent Data Corruptions in Modern Datacenters

　　

摘要
源自 CPU 的静默数据损坏（SDCs）日益被视为现代数据中心可靠性方面的问题。与崩溃和异常不同，SDCs 静默地破坏数据完整性，通常在影响传播通过大规模数据中心之前仍未被察觉。尽管认知度不断提高，现有的针对 CPU SDCs 的策略仍然效率低下，部分原因是它们基于未能完全反映运营现实的假设。在本文中，我们从系统的、面向生产的角度重新审视 CPU SDCs。基于实际观察，我们考察了它们在真实环境中的存在，分析了损坏数据和 SDC 发生的模式，并重新评估了现有的针对 CPU SDCs 的策略。我们的发现揭示了传统假设与实际观察之间的差异，有助于解释为什么许多现有策略和模型仍然效率低下或与实际情况不符。基于这些见解，我们概述了促进现代数据中心服务可靠性的未来方向。

现代数据中心以极大的规模运行。大型云平台部署由数百万处理器组成的集群，每个处理器都集成了日益复杂的组件。随着规模和复杂性的增长，对处理器故障的暴露也在增加。虽然许多故障表现为崩溃或异常，但其他故障要难以识别得多。静默数据损坏（SDCs），也称为静默数据错误或静默错误 13，是指在没有立即、可观察和明确指示的情况下发生的数据完整性违规。由于其静默的特性，SDC 的发生与其检测之间存在不可忽视的延迟。这种延迟检测允许损坏的数据在应用程序中传播，可能触发级联故障甚至大规模服务灾难。13 检测难度和系统性风险相结合，使得 SDC 成为现代数据中心服务的关键关注点。

关键见解
■随着数据中心基础设施的规模化和多样化，可靠性挑战日益增长。除了 CPU 静默数据损坏（SDCs）外，在其他处理单元（例如 GPU、DPU 和 TPU）中出现的 SDCs 也正成为重要的关注点。
■实际观察表明，CPU SDCs 表现出与传统假设不同的模式，特别是在其普遍性、损坏数据和触发条件方面。
■没有单一针对 CPU SDCs 的策略能同时实现全覆盖、强有效性和低开销。因此，提高数据中心可靠性需要协调的、多层保护，而不是孤立的解决方案。

一些 SDC 源自 CPU 的异常行为；在此，我们将其称为 CPU SDC。历史上，CPU SDC 主要归因于外部来源，如辐射或环境噪声。2,31,34 在此假设下，人们认为 SDC 在数据中心中的发生率极低，并且在生产环境中很少被观察到，因此数据中心服务提供商对其关注有限。13
然而，来自现代数据中心的实际证据挑战了这些长期假设。最近的研究表明，确实存在根因是内部处理器故障而不是外部来源的 CPU SDC。具体来说，这些研究分为三大类：针对个别事件的深入案例研究，11,35 与提供生产环境事件数据的大规模工业合作伙伴的合作，20,38 以及通过硬件模拟生成合成事件。24,33 这些研究还挑战了传统的叙述：CPU SDC 的行为、表现模式和影响可能比之前认为的更复杂，这突显了明确了解由内部处理器故障引起的 SDC 与由外部来源触发的 SDC 之间差异的必要性。

在本文中，我们从生产数据中心的视角系统地重新审视 CPU SDC。我们特别关注在生产环境中观察到的 CPU SDC，其中处理器故障是根本原因，并将它们与传统假设下的 SDC（即以外部来源为根本原因的 CPU SDC）进行比较，以刻画当前故障模型和策略的不足。我们探索 CPU SDC 的存在，调查它们的模式，并评估现有的针对 CPU SDC 的策略。基于调查和分析的见解，我们提供了潜在的未来研究方向，以促进现代数据中心服务的可靠性。

真实环境中的 CPU SDC
在本节中，我们调查 CPU SDC 在不同系统层中的存在，以回答为什么 CPU SDC 已成为现代数据中心中的重大问题这一问题。

CPU SDC 的根本原因。处理器故障是硬件组件和/或芯片设计中的缺陷和错误。许多类型的处理器故障都有潜力产生 CPU SDC。如图 1 所示，这些故障可以分为两类：器件故障和现场故障。器件故障发生在处理器使用之前，如设计错误和制造缺陷。36,39 现场故障发生在用户开始使用处理器之后，如晶体管弱化和磨损。30
图 1. CPU SDC 在不同系统层中存在情况的图示。
CPU SDC 的一个代表性根本原因是时序边际性，硬件缺陷阻止半导体电路在配置的时钟速率内达到稳态。6,10 存在时序边际性问题的处理器在充足电源下可以正常工作，并在低电压电源下间歇性地表现出错误结果。由于必须覆盖大量的边界情况，时序边际性的测试提出了重大挑战。

器件故障和现场故障在生产环境中都是不可避免的。首先，考虑到全面的高容量制造（HVM）测试相关的成本，与器件故障相关的缺陷和错误无法在生产芯片中完全消除。其次，在现代数据中心中，现场故障在处理器整个工作寿命期间发生，39 导致由现场故障引起的 CPU SDC 持续影响在线服务。14,20 此外，复杂性的增加和半导体光刻的进步进一步加剧了处理器的脆弱性和芯片测试的难度。这一趋势表明，CPU SDC 在未来可能会带来更大的挑战。

CPU SDC 的普遍性。测量能产生 SDC 的故障处理器的普遍性对于评估 CPU SDC 对数据中心服务的影响是必要的。几个数据中心报告了他们关于能产生 SDC 的故障处理器的测量结果：谷歌和 Meta 指出，与 SDC 相关的处理器故障故障率是每数千个处理器中发生几次。14,20 阿里云提供了更精确的数据，表明基于超过一百万个生产处理器的测量，这一故障率为 3.61?。38 这些报告表明，与在数据中心中通常观察到的其他类型的错误相比，CPU SDC 是相对罕见的事件。18 因此，在过去，CPU SDC 很少被检测到，主要是由于早年系统规模较小。然而，随着近年来的规模化趋势，CPU SDC 被更频繁地观察到。

作为对比，传统假设中的普遍性极低：由外部来源引起的 CPU SDC 预计在生产数据中心中大约 1000 年发生一次。31 错误发生率显著影响相关策略的设计，决定其实际适用性。由于其极其罕见的普遍性，由外部来源引起的 CPU SDC 受到的关注有限，并且在数据中心中经常被忽视。37 相比之下，由处理器故障引起的 CPU SDC 更普遍，并表现为数据中心服务中的一个普遍问题，特别是在大规模系统中。

跨处理器组件的普遍性。研究表明，CPU SDC 往往源自特定的处理器组件。7,8,26 这些组件确实可能更复杂，因此更脆弱。例如，在许多操作中，浮点运算被认为比整数运算更复杂，最近的研究证实与浮点运算相关的处理器组件确实更容易受到 CPU SDC 的影响。38 也有可能是一些组件倾向于产生具有明确信号的错误；因此，它们不易受到 SDC 的影响，正如最近研究所证实的那样。7

CPU SDC 的严重程度。在表 1 中，我们列出了 CPU SDC 影响现实世界服务的几个案例。由 CPU SDC 引起的服务故障表现出与软件错误引起的计算影响类似。然而，它们不同的根本原因需要不同的检测、诊断和处理策略。以下是几个代表性示例；其他示例表现出类似的行为：
•在案例 MT1 中，一个数学函数在集群中的故障处理器上产生错误结果。该函数用于在数据库应用程序中计算解压文件大小，错误结果导致数据丢失。
•在案例 ALI1 中，校验和计算受到影响。这种计算广泛用于端到端检查；错误结果导致故障处理器上的许多请求中止，导致服务质量低于保证。
•在案例 GGL1 中，一些处理器在执行新更新库中的特定指令时容易发生 CPU SDC。因此，当分析应用程序更新为使用最新库时，发生了一系列 SDC，导致对用户响应错误。

表 1. 部分生产 SDC 案例。请注意，在某些 CPU/GPU 混合服务中，供应商报告称他们面临 CPU 和 GPU SDC，但在其案例中没有严格区分来源。

| 案例 ID | 服务供应商 | 根本原因 | 服务应用 | 影响 |
| :--- | :--- | :--- | :--- | :--- |
| MT1 | 14 | Meta | CPU | 数据库 | 数据丢失 |
| MT2 | 12 | Meta | CPU | KV 存储 | 数据丢失 |
| ALI1 | 38 | 阿里云 | CPU | 存储系统 | 性能下降 |
| ALI2 | 38 | 阿里云 | CPU | 元数据管理 | 大量断言失败 |
| ALI3 | 40 | 阿里云 | CPU | 块存储 | 性能下降 |
| GGL1 | 20 | 谷歌 | CPU | 数据分析管道 | 错误结果 |
| GGL2 | 16 | 谷歌 | CPU/GPU | 大型语言模型 (LLM) | 影响训练 |
| DS1 | 1 | DeepSeek-AI | CPU/GPU | DL 框架 | 模型性能下降 |

从这些案例中，我们观察到，在评估 CPU SDC 的影响时，部署规模是一个关键因素，因为表 1 中列出的所有案例都是在大规模上部署的。例如，在案例 ALI1 中，受影响的服务部署在超过一百万个处理器上。

此外，我们观察到影响普遍存在于流行应用中，包括各种存储应用（例如案例 MT1 和 ALI1）和数据分析应用（例如案例 GGL1）。这一观察可归因于两个原因：首先，由于高性能要求和持续发展，这些应用程序利用一些复杂的处理器特性（例如向量单元）来提高性能。然而，这些复杂的处理器特性也可能脆弱，7 使得这些应用程序容易受到 CPU SDC 的影响。其次，这些应用程序通常需要大规模部署，这也导致它们容易受到 CPU SDC 的影响。

此外，我们观察到 CPU SDC 通常会破坏服务的基本功能，突显了 CPU SDC 的严重程度。例如，在案例 MT1 中，存储在数据库中的数据丢失。数据丢失违反了存储服务的基本保证，导致服务质量（QoS）违规。我们将 CPU SDC 破坏基本服务功能的条件分为两类。在第一类中，系统和应用程序都缺乏针对 CPU SDC 的有效检测策略，例如案例 MT1 和 GGL1。由于缺乏有效检测，错误结果在操作中传播，从而导致故障。到用户注意到问题的时候，影响可能超过了系统的故障恢复能力，正如案例 MT2 中报告的那样。在第二类中，系统或应用程序确实识别了 CPU SDC 的发生，例如案例 ALI1 和 ALI2。然而，由于对 CPU SDC 的理解有限，它们无法对这些错误做出适当的响应，导致在错误处理过程中浪费大量资源。例如，在案例 ALI1 中，受影响的应用程序将检测到的 SDC 的根本原因归咎于磁盘故障，而不是处理器故障。因此，故障处理器继续产生 CPU SDC，导致在错误处理上浪费大量资源。值得注意的是，在传统假设中很少出现第二种情况，其中的根本原因（例如噪声和辐射）通常被假设为瞬态的。2

CPU SDC 的模式
了解 CPU SDC 的模式对于开发更好的故障模型和策略至关重要。在本节中，我们介绍在生产环境中观察到的模式，将它们与传统假设下的模式进行比较，并调查其含义。

损坏数据的模式。CPU SDC 中的位翻转往往发生在特定位置。例如，在浮点数中，位翻转主要发生在小数部分。39 这种模式的一个架构原因在于时序边际性，它主要影响最低有效位。6 这种模式的另一个原因是不同位位置的硬件脆弱性变化。具体来说，与小数部分相关的计算逻辑比其他部分的逻辑更复杂，使其更容易受到位翻转的影响。此外，研究观察到，在数据缓存中，与最高有效位相比，最低有效位表现出更高的表现 CPU SDC 的可能性。33

作为对比，在传统假设下，每个位位置都有相等的翻转概率。15 实际观察与传统假设之间位翻转分布的差异具有重大含义，特别是关于损坏数据的值。

例如，对于浮点数，CPU SDC（静默数据损坏）会导致轻微的精度损失。根据阿里云的测量，97.5% 的双精度浮点数（float64）精度损失低于 0.01%（如图 2 所示）。谷歌的一项案例研究也报告称，其一种 CPU SDC 仅会导致 0.0000003% 的精度损失。35 某些计算方法，如雅可比方法，可以通过几次迭代容忍这些轻微的精度损失。15 相反，在传统假设下，CPU SDC 会导致显著的准确性下降，因为许多位翻转发生在指数部分。

图 2.float64 数据的相对精度损失。39 在实际观察中，多位翻转事件的发生率不容忽视。例如，在扩展双精度浮点数中，约 20% 的情况会发生双位翻转，约 8% 的情况甚至有更多的位翻转。38 这种普遍性与传统假设形成鲜明对比，在传统假设中，多位翻转事件相对罕见。31

损坏的数据相对于输入也表现出模式。首先，在某些 CPU SDC 中，某些输入前提条件，如值约束（例如最小值阈值）和位约束（例如特定位必须设置为 1），是触发 SDC 所必需的。其次，单个处理器故障通常会在不同输入中产生位于一致位置的位翻转。这些模式在传统假设中不存在，突显了需要完善现有的 CPU SDC 故障模型。

SDC 发生的模式。故障处理器即使在可能产生 SDC 的条件下，偶尔也可能表现正常。为了评估 CPU SDC 的可复现性，研究人员使用发生频率作为指标，量化为每分钟观察到的错误数量。我们观察到 SDC 发生中存在模式，这也区分了实际观察到的 CPU SDC 与传统假设中的 CPU SDC。

显著的发生方差。CPU SDC 的可复现性表现出显著的变异性，发生频率范围从每分钟低至 0.01 次到每分钟数百次不等。39 这可以归因于处理器故障的变化，例如老化程度。25 生产观察 20,38 表明，CPU SDC 可能与某些假设中使用的瞬态错误或永久错误不同。7,32 然而，由于在生产环境中观察到的发生频率存在显著方差，CPU SDC 面临着瞬态错误和永久错误的双重挑战：较不可复现的 CPU SDC 倾向于模仿瞬态错误，较差的可复现性使得识别根本原因成为挑战。高度可复现的 CPU SDC 倾向于模仿永久错误，在这种情况下，可能需要及时识别并隔离故障处理器，以防止不断出现新的 CPU SDC。

触发条件。除了处理器故障和工作负载外，CPU SDC 的发生还受到各种触发条件的影响。这些触发条件包括温度、湿度等环境因素，以及频率、电压等系统配置。20,36 温度是一个典型的触发条件，其影响可归因于偏置温度不稳定性（BTI）和热载流子注入（HCI）等硬件现象，两者都会导致电路的性能和可靠性随温度升高而恶化。图 3 显示了一个 CPU SDC 样本中发生频率随处理器温度的变化方差，从中我们观察到 CPU SDC 的发生需要最低温度阈值，并且发生频率随温度升高呈指数增长。

图 3.发生频率随温度的变化。38

针对 CPU SDC 的策略
在本节中，我们评估针对 CPU SDC 的策略，将它们分为七类，并结合实际观察到的模式分析其优势和局限性，表 2 提供了简要总结。我们还介绍了现有生产环境中使用的策略，强调了对策略改进进行进一步研究的必要性。

表 2. 现有的针对 CPU SDC 的策略。
类型 通用性 有效性 开销
测试 ? ? ?
控制 – ? ?
监控 ? ? ?
冗余 ? ? ?
编码 ? ? ?
预测 ? ? –
ABFT ? ? ?

缓解 CPU SDC 的主动策略。主动策略在故障处理器表现出 SDC 之前执行。这些策略可以通过减少其发生来缓解与 CPU SDC 相关的问题，但对于已经表现出来的 CPU SDC 无效。

测试。通过测试处理器的功能来减少集群中故障处理器的发生率是实际可行的。已经开发了各种工具链来识别可能导致 SDC 问题的处理器故障。14,24,26,30,35 在典型的测试过程中，多个精心设计的测试用例在目标处理器上执行，通过比较执行结果与预期结果可以识别处理器故障。

测试策略的最新进展扩大了广泛 SDC 条件的覆盖范围。例如，近期的一项工作采用硬件模型在环方法来生成功能测试程序，显著增强了跨不同微架构和故障类型的 SDC 覆盖范围。24 然而，鉴于生产环境中处理器故障的不可避免性（参见"CPU SDC 的根本原因"），在生产环境中进行在线或定期测试变得必要。此类测试会与在线服务争夺计算资源。此外，全面识别所有 CPU SDC 需要长时间的测试和极端的环境条件。38 因此，进行全面的生产内测试会产生无法承受的开销。

控制。由于 CPU SDC 的表现需要特定的触发条件，将系统参数保持在触发阈值以下可以缓解 CPU SDC 问题。然而，控制机制需要与在线服务共同执行，可能会向在线服务引入性能波动。对于容易触发的 CPU SDC，此类控制的开销变得尤其无法承受。近期的一项工作建议，控制触发条件最好用作主动 SDC 测试的补充，特别是对于难以通过测试识别的 CPU SDC。38

监控。某些系统事件，如核心转储，可以作为 CPU SDC 的侧信道。14,39 这些事件可以被监控和评估，以低运维开销识别 SDC。然而，它们的检测性能有限，因为这些侧信道不是 SDC 发生的直接指标。因此，在实际部署中，这些监控策略也作为其他检测技术的补充。14

容忍 CPU SDC 的被动策略。被动策略旨在解决已经发生的 CPU SDC。这些策略允许系统检测此类错误并容忍其影响。

冗余。冗余策略在独立的硬件资源上执行相同的计算过程，比较两个冗余过程的结果以检测 SDC，或通过对更多冗余过程的结果投票来纠正错误结果。9,19,27 冗余策略可以应用于各种层级。例如，双核锁步（DCLS）实现了硬件冗余，9 而软件冗余可以应用于保护操作或重建损坏的数据。

冗余策略提供对 CPU SDC 的稳定检测和纠正。然而，这些策略的关键弱点是显著的开销：鉴于 CPU SDC 事件发生频率不高，冗余所需的过度资源消耗通常是不可持续的。

编码。数据完整性可以通过校验和或奇偶校验来确保，这些是从数据编码而来的。22,23,40 这些编码策略已广泛用于检测和/或纠正影响数据存储和传输的损坏。纠错码（ECC）可用于保护缓存和寄存器。22 端到端检查可以通过使用校验和算法（如循环冗余校验（CRC））来保护数据传输。纠删码（EC）通过使用奇偶校验块促进损坏数据的重建。23

编码策略最大的担忧是面对 CPU SDC 时的无效性。处理器中使用的 ECC 通常设计为容忍单个位翻转，22 但在实际观察中，多位翻转事件占据不可忽视的比例（参见"损坏数据的模式"）。其他编码策略通常依赖脆弱组件来加速 CRC 和 EC 等算法，23 导致策略可能无效。因此，编码策略可能会产生错误结果，如表 1 中的案例 ALI1。此外，编码策略在解决 CPU SDC 方面的通用性有限，因为它们不能用于保护处理器中的计算组件。

预测。预测策略 3,13 使用机器学习（ML）技术来预测预期结果的范围。当计算过程的实际结果超出此范围时，即可识别 SDC 的发生。这些 ML 技术利用了某些计算特性，如迭代高性能计算（HPC）应用的平滑性特征。

预测策略表现出两个局限性。首先，CPU SDC 中观察到的精度损失相对较小（参见"损坏数据的模式"），使得预测狭窄的结果范围变得困难。28 此外，此类预测所依赖的计算特性在某些 HPC 场景下有限，例如自回归模型和线性/二次曲线拟合。13 因此，现有的预测策略应用有限。

基于算法的容错。基于算法的容错（ABFT）是稳定检测 CPU SDC 的有效策略。4,5,21 ABFT 策略的核心概念是引入与数据有一定关系的信息（例如线性依赖），并在对数据的计算过程中保持这些信息。当发生 SDC 时，ABFT 策略可以通过检查信息与结果数据之间的关系来检测错误。ABFT 策略产生的开销相对较低，但由于"非通用性"问题，ABFT 策略的实际使用受到限制：每个 ABFT 策略都是为特定算法设计的，例如常微分方程和蝶形排序，系统仍然需要其他受影响操作的额外策略。13

实践中使用的策略。在当前生产环境中，测试策略是上述方法中部署最广泛的。许多知名数据中心，如由谷歌、Meta 和阿里云运营的数据中心，都已部署针对 CPU SDC 的测试，规模涉及数百万处理器和多年的运营经验。14,35,38 这种偏好是由于数据中心服务中需要保护的应用多样性，特别是在平台即服务（PaaS）和基础设施即服务（IaaS）等场景中，应用多样且程序内部是不透明的。测试策略在此类场景中提供灵活且通用的保护。另一个优势在于加速诊断。当数据中心服务遇到 CPU SDC 时，软件工程师需要数周的调试和硬件工程师的合作才能将其与其他可能的原因（例如软件错误）区分开来。使用精心设计的测试工具链，可以实现 CPU SDC 的相对稳定复现并提供清晰的根因分析信息，显著缩短了此诊断过程。此外，测试策略也不需要代码修改，这显著降低了工程开销。

然而，测试策略并不总是能提供足够的检测准确性，特别是对于高可靠性要求的应用。38 在此类场景中，需要额外的被动策略来检测 CPU SDC。然而，现有策略仍在通用性、有效性和/或开销方面挣扎。编码、预测和 ABFT 策略仅保护某些应用中的部分操作，留下许多其他操作仍易受 CPU SDC 影响。例如，虽然存储应用广泛采用编码策略来保护数据路径完整性，但许多 CPU SDC 发生在数据路径之外，真实世界事件证明了这一点（见表 1）。因此，这些存储应用仍然容易受到未检测到的 CPU SDC 的影响。此外，冗余策略的高开销限制了其适用性。例如，HDFS 选择性地为部分纠删码操作部署冗余策略，留下许多其他操作仍未受保护。19

因此，在现代生产环境中仍有大量操作无法得到有效保护，表明当前的可靠性要求尚未达到。在当前数据中心服务中，用户报告的 CPU SDC 发生率与自动报告的 CPU SDC 发生率相当，甚至超过。20 这种差异表明需要增强针对 CPU SDC 的策略。

针对 CPU SDC 的未来方向
迫切需要进一步研究以促进现代数据中心服务的可靠性。在本节中，我们从多个角度提供了潜在的未来研究方向。

硬件设计。如前所述，电子结构复杂性的增加和光刻工艺复杂度的提升表明，CPU 在未来可能变得更加脆弱。因此，增强硬件可靠性对于减少 CPU 引起的错误发生率势在必行。我们建议硬件可靠性改进的研究应侧重于某些处理器特性而非整个处理器，例如对特定指令应用冗余以及优化特定处理器组件的运行条件。这些有针对性的策略可能证明既有效又高效，因为 CPU SDC 往往发生在特定组件中。另一方面，当前识别脆弱组件的方法仍然不足，这也需要未来的研究。

例如，一些近期研究假设与 CPU 静默数据损坏 (SDC) 相关的组件脆弱性主要由芯片面积决定。33 然而，其他研究表明，即使是相对较小的组件（例如，浮点运算单元 FPU）也可能表现出显著的脆弱性，这可能是由于架构复杂性而非物理尺寸所致。7,39 另一个关键的研究方向涉及调查由与 CPU 在架构和制造上相似的硬件设备（如张量处理单元 TPU、图形处理单元 GPU 和数据处理单元 DPU）引起的 SDC。这些处理单元在现代数据中心中越来越普遍，其不断增长的部署规模表明它们也面临着 SDC 风险。例如，近期研究报告称，一个生产集群在大语言模型（LLM）训练期间经历了 GPU SDC，这促使了对 GPU 进行系统的 SDC 测试。29 鉴于与 CPU 的架构亲缘关系，这些处理单元引起的 SDC 可能表现出与 CPU SDC 相似的模式。但是，这些处理单元上的工作负载（如并行张量计算和高吞吐量数据处理）与 CPU 上的不同，这导致与 CPU 场景相比，SDC 的影响存在分歧。然而，这些处理单元引起的 SDC 的精确模式和影响仍未得到充分探索，需要进一步研究以表征故障模型并制定缓解策略。由于 SDC 的低发生率，这一研究方向具有挑战性。CPU SDC 的研究为这一挑战提供了启示：工业界在推进 SDC 研究方面发挥着重要作用，因为大规模部署产生了足够的真实世界 SDC 事件，这对学术研究至关重要。17 软件开发。如前所述，现有策略不足以解决 CPU SDC 问题。考虑到减少策略开销的重大挑战，我们建议利用策略的通用性作为一种权衡来实现这一目标。与传统假设（即服务中的任何操作都可能受到影响）不同，实际观察表明，只有广泛使用易受攻击处理器功能的操作才容易受到 CPU SDC 的影响。38 我们建议系统工程师部署测试策略以提供基本保护，并为那些既表现出对 CPU SDC 的敏感性又有高可靠性要求的操作部署特定保护。然后，可以将高开销策略选择性地应用于这些特定操作，而不是服务中的所有操作，从而降低总体开销。例如，近期研究探索了几种云应用针对 CPU SDC 的选择性冗余，并展示了具有成本效益的运行时性能。27 我们进一步建议，工程师和研究者应投入更多精力，为尚未被现有 ABFT 策略覆盖的敏感操作开发新型 ABFT 策略。数据中心维护。许多服务（如平台即服务 PaaS 和基础设施即服务 IaaS）缺乏上层软件应用的详细信息，导致它们在维护阶段缓解 CPU SDC。然而，现有的维护实践由于缺乏对触发条件的关注而仍然效率低下，经常导致服务中出现反直觉的事件，这需要大量的工程努力来解决。例如，在 Google 集群中，当处理器配置在较低频率状态时，一个 CPU SDC 案例表现出更高的发生频率，20 其中较低的电压供应成为触发条件。36 类似地，阿里云的一次事件表明，更新的测试工具链未能实现更好的检测，甚至降低了 CPU SDC 覆盖率，因为更新的工具链在较低的执行温度下运行，这降低了一些 CPU SDC 的可复现性。38 我们建议数据中心维护应监控和管理这些触发条件。例如，构建能够配置和控制测试过程中处理器温度的测试工具链将是有益的，并开发能够有效达到极端工作条件的测试用例。结论 在本文中，我们从系统化、部署驱动的视角重新审视了现代数据中心中的 CPU SDC，将实际观察与长期以来的假设进行对比。基于我们的调查，我们概述了几个旨在促进现代数据中心服务可靠性的未来研究方向。我们相信这项工作可以增进对 CPU SDC 的理解，从而促进制定更有效的策略来解决相关挑战。致谢 我们感谢所有审稿人富有洞察力的评论和有益的建议。这项工作得到了国家自然科学基金（批准号 62025203）的支持。王少步是清华大学（中国北京）的博士研究生。张广言（[e-mail]）是清华大学（中国北京）的副教授。