Google Cloud 比利时磁盘丢失事件表明，本地性并非弹性

摘要

• 2015 年 8 月，欧洲西部 1-b 可用区（europe-west1-b）的 Google Compute Engine Standard Persistent Disk 在四次连续雷击影响当地电网后出现读取错误。Google 随后报告称，该可用区中极小部分已分配的 Persistent Disk 空间遭受了不可恢复的近期写入。
• 责任问题不在于百分比大小，而在于客户是否理解：即使是提供者托管冗余的可用区级 Persistent Disk，仍然位于物理故障域内，不能替代独立的快照、区域复制或应用级备份。
• Google 控制物理站点弹性、存储硬件敏感性、电源事件处理、Persistent Disk 持久性说明、状态报告以及备份指导的清晰度。客户控制工作负载架构、快照计划、恢复目标、复制选择，以及本地性要求是否与可恢复性混淆。
• 实际修复记录应区分已恢复服务、不可恢复数据、可用快照变通方案、硬件和软件更改、备份指导以及客户证据。在涉及数据丢失的云事件中，绿色状态页面不能作为完整的恢复证明。

极小百分比仍可能是严重故障

Google Cloud 比利时事件有时因永久丢失存储的百分比极小而被视为奇闻，这不是正确的第一视角。对于磁盘包含不可恢复近期写入的客户而言，百分比无关紧要。相关的问题是客户是否拥有可恢复的独立副本，应用能否容忍恢复点，以及供应商的持久性说明是否已在事件前充分说明剩余的物理站点风险。

Google 的公开Compute Engine 事件 #15056始于 2015 年 8 月 13 日，涉及欧洲西部 1-b 可用区的 Persistent Disk。状态页面最初报告该可用区中机器的读取错误，随后解释称不到 1%的磁盘受性能降级影响，接着不到 0.1%的磁盘部分块出现读取失败。事件记录还告知受影响客户从快照恢复是一种变通方案，同时创建新的 Persistent Disk 和从快照恢复不受影响。

媒体报道捕捉到后期的事件解释，包括 数据中心 Dynamics 的雷击和数据丢失报告以及 Silicon UK 的中断原因说明，记录了 Google 的声明：四次连续雷击导致本地电网短暂断电，影响了托管 GCE 实例磁盘容量的存储系统。Google 称几乎所有数据都已提交至稳定存储，但极少数情况下近期写入不可恢复，导致 Persistent Disk 永久数据丢失。广泛引用的数字是受影响的可用区中已分配 Persistent Disk 空间不到 0.000001%。

该记录既支持克制也支持严肃性。将事件描述为 Google Cloud 大规模数据破坏是错误的。受影响的服务是单一可用区中的 Standard Persistent Disk；据事后分析和当时报道，SSD Persistent Disk、快照和本地 SSD 均不在永久丢失范围内。同样，由于分母巨大而忽视事件也是错误的。数据持久性对于相关记录而言是二元事实。极小的不可恢复百分比对某人而言仍是永久丢失。

因此责任问题不是“为什么存在雷击？”雷击是外部危害。问题是谁控制了设计选择，使重复的电网电源事件影响到最近写入的磁盘状态；谁控制了持久性和备份指导的清晰度；以及谁控制了客户架构——该架构要么拥有独立的恢复点，要么没有。触发因素是物理的。根本责任问题是供应商管理的本地持久性与客户管理的可恢复性之间的边界。

本地性与持久性并非同一承诺

云本地性解决真实问题。客户可能出于对比利时或欧洲用户的延迟、采购原因、较低碳足迹或数据驻留承诺而选择欧洲西部 1。Google 当前的云位置页面和 Compute Engine区域和可用区文档解释资源位于区域和可用区，而可用区和区域是底层物理资源的逻辑抽象。这种抽象有用，因为客户无需管理建筑。但如果客户推断可用区资源已脱离物理故障域，则存在危险。

数据主权和本地性关乎数据存储或处理的位置。可恢复性关乎失败后是否存在另一个可用副本。磁盘可以满足位置要求，但如果其唯一可恢复状态位于同一可用区和同一存储类中，则可能成为数据库的错误持久性架构。快照可以满足恢复，但可能有自己的位置选择。区域磁盘可以跨可用区提高可用性，但可能不满足每个恢复点目标。第二个供应商可以减少共同依赖，但可能增加运营复杂性和数据治理风险。这些是不同维度。

Google 当前的数据驻留条款和欧洲承诺材料说明客户数据在受支持服务中的驻留位置，但并不将每个本地资源变为独立备份。同样，Persistent Disk 产品页面描述持久化块存储，Compute EnginePersistent Disk 文档称 Persistent Disk 具有内置冗余以保护设备故障并通过维护事件保持数据可用性。这些是有意义的供应商承诺。但它们不保证每个可能的站点级危害都能在所有配置中使零近期写入不可恢复。

2015 年的事件暴露了解释性差距。客户可能将“持久”（persistent）理解为磁盘比虚拟机寿命长，这是正确的。另一些人可能理解为磁盘免于数据丢失，这不是安全推断。客户可能将“欧洲”或“比利时”视为主要合规决策而止步。事件表明位置不是恢复计划。同样有助于延迟和策略的本地放置，如果没有独立备份，则会集中物理风险。

因此，供应商语言应明确说明故障域。可用区级 Persistent Disk 在其设计内是持久的，但仍绑定到可用区。快照、区域磁盘、复制和应用备份改变故障模型。客户需要在事件前而非仅在状态页面告知从快照恢复后理解这一区别。最有价值的披露是存储选择到故障域、恢复点、恢复时间和客户职责的清晰映射。

物理触发因素应纳入云责任记录

云可以使物理基础设施从客户的日常工作中消失，但不能使物理危害消失。电源系统、电池、存储控制器、固件、机架、配电和电网事件仍然是服务的一部分。客户支付给供应商管理这些层，因为供应商具有更大的规模和专业知识。这使物理弹性成为供应商职责，而应用恢复架构部分由客户负责。

多家媒体报道的事件解释称，自动辅助系统迅速恢复供电，存储系统设计有电池备份，但一些近期写入的数据位于更易因长时间或重复电池放电而导致电源故障的系统上。这句话很重要，因为它区分了单次雷击和发现存储脆弱子集的重复物理压力。这也说明了为什么一些报道中使用的“旧磁盘”框架应谨慎对待：公开文章描述了硬件敏感性，但公开状态记录并未发布每个组件、年龄或内部工程决策。

Google 据称表示已对整个电气分配、计算硬件和控制 Persistent Disk 层的软件进行广泛审查，并正在升级存储硬件以降低对此类电源故障的敏感性。数据中心 Knowledge 的更新报告记录 Google 正在用更具电源弹性的硬件替换存储系统，且许多 Persistent Disk 存储已在较新硬件上。这些是响应措施。它们应理解为供应商对物理和存储栈的控制，而非客户架构行动。

供应商还控制事件状态。Cloud Status 页面提供了重复更新、影响百分比和快照变通方案指导。该记录远比沉默好。然而，它确实随着调查的进展从读取错误和性能降级转变为永久丢失。客户需要知道哪些磁盘存在读取错误，快照是否可用，是否可以创建新磁盘，哪些写入不可恢复，以及存储对新工作负载是否安全。在数据丢失事件中，影响分类不仅关乎服务可用性，还关乎可恢复状态。

状态页面在 Google 标记事件已解决时结束。对于从快照恢复的客户，恢复继续通过应用验证、数据对账和可能丢失的近期交易。这一区别至关重要。供应商服务恢复意味着存储服务正在运行。客户恢复意味着工作负载具有一致的数据集，企业能够说明缺失的时间间隔。这两个时间可能非常不同。

快照指导是共享责任具体化的地方

事件期间 Google 的状态更新告知受影响客户可以从快照恢复。该建议仅对拥有可用快照的客户有用。不存在的快照、太旧的快照、位置错误的快照、缺少应用一致性或从未测试过的快照不是恢复路径。因此，事件将一个常见的云术语“共享责任”转化为具体问题：谁在物理事件之前实际创建并验证了恢复点？

Google 当前的磁盘和实例数据保护选项指南围绕恢复时间目标、恢复点目标、用例和成本构建恢复。快照创建文档解释标准和存档快照。快照概述描述增量快照。计划快照指南推荐计划作为备份实践，快照最佳实践页面添加了实际约束和可靠性建议。当前文档比许多早期云时代假设更清晰。

应用一致性仍然是客户关注点。磁盘快照捕获块状态；数据库可能需要静默、刷新或协调备份操作以使恢复状态可用。Google 的Linux 应用一致性快照文档解释带客户刷新的快照计划。重要点不是 2015 年与现在的确切功能集，而是持久的控制原则：可恢复性需要与应用对齐的备份过程，而不仅仅是供应商存储承诺。

小型团队尤其暴露于这一差距。初创公司或市政项目可能选择单个云可用区以减少延迟和成本。它可能在 Persistent Disk 上运行数据库，依赖产品名称和供应商声誉作为备份设计的替代。它可能没有专门的存储工程师、经过测试的恢复流程或业务影响分析。2015 年事件表明文档和产品默认值为何重要：内部专业知识较少的客户需要存储选项和警告，使故障域边界显而易见。

供应商和客户职责应以操作语言表述。Google 应设计存储系统以承受预期的物理危害，发布清晰的故障域信息，提供快照和复制工具，保存事件证据，并识别受影响的资源。客户应选择恢复目标，安排备份，验证恢复，将快照或副本放置在相关故障域之外，并决定位置约束是否允许离开可用区或区域的副本。任何一方都无法完成对方的全部工作。

区域磁盘和复制改变故障模型，但恢复思维的必要性不变

Google 现在提供区域 Persistent Disk 和 Hyperdisk 高可用性选项。区域磁盘文档解释区域中可用区之间复制的磁盘以提高可用性，区域磁盘故障转移指南描述主可用区故障时的强制挂载。Google 关于用于高可用工作负载的区域 Persistent Disk的博客使可用性用例明确。

这些功能对许多工作负载而言是有意义的改进，但不消除架构判断。区域复制可以防止单个可用区的不可用性或存储错误。它可能无法防止复制后的应用级损坏、客户删除、凭证泄露、区域范围的控制问题或过于近而无用的恢复点。客户仍然需要备份以应对损坏、保留和回滚。复制磁盘是高可用性机制，不自动是完整的数据保护方案。

同样的谨慎适用于快照。快照可以独立于失败的磁盘并恢复至另一个可用区。它仍然可能太旧、应用不一致、无法被正确项目访问、使用恢复环境无法访问的密钥加密，或存储在与策略冲突的位置。Google 的磁盘加密文档提醒客户磁盘和快照可能涉及不同的密钥选择。备份策略必须包括访问、密钥、保留、位置和恢复测试，而不仅仅是快照条目的存在。

Compute Engine 的当前 SLA和历史的2015 年 SLA 版本显示了另一个区别。SLA 处理服务可用性和在定义条件下的信用。它们不是可恢复性或业务损失的完整声明。信用可以补偿部分服务费用，而客户仍需恢复数据、对账交易、通知用户或重建信任。状态页面告知受影响客户从快照恢复的事实表明操作恢复存在于 SLA 信用问题之外。

对于数据主权所有者，复制选择需要谨慎的策略工作。客户可能要求数据留在欧洲或比利时。这并不意味着所有副本必须位于一个可用区。根据服务条款、监管期望和风险偏好，可能允许快照位于欧洲多区域或其他欧洲区域。相反，严格的位置要求可能阻止某些跨区域备份，并需要更高的本地可用性设计。负责的行为是在数据丢失前明确此权衡。

客户恢复证据是事件的一部分

供应商事件报告通常以服务恢复结束。数据丢失事件需要第二份记录：客户恢复证据。哪些磁盘有读取错误？哪些写入不可恢复？哪些客户从快照恢复？哪些快照失败或太旧？哪些应用需要手动对账？哪些客户工作负载没有备份？向客户发送了哪些关于永久丢失和变通步骤的消息？部分证据是私有的，但类别在公共层面重要。

状态页面重复的影响百分比有用，因为它们避免了模糊的保证。不到 1%受影响、不到 0.1%存在读取失败、不到 0.000001%永久丢失描述了缩小的类别。它们不应合并为单一陈述。受影响磁盘、主动失败磁盘和不可恢复数据是不同的状态。处于每种状态的客户需要不同的操作。

客户还需要资源特定的通知。通用状态页面告知市场某处有问题，但不通知单个数据库操作员特定磁盘是否受影响。Google 最有能力识别受影响的资源、关联存储系统并提供账户级通知。客户最有能力检查应用一致性、从自有快照恢复，并决定哪些近期业务数据可能缺失。两种证据都是必要的。

这一划分对审计员尤其重要。审计员在此类事件后审查云工作负载时，不应仅询问供应商是否报告了小百分比。正确的问题是组织是否知道其恢复点目标，事件前是否存在快照，恢复测试是否通过，备份位置是否符合策略，应用所有者是否接受了残余损失，以及供应商的通知是否提供了足够细节以分类受影响资源。如果答案是否定的，失败不仅是供应商事件，也是架构治理缺口。

采购应提前提出相同问题。此磁盘占用的故障域是什么？存在哪些独立副本？谁拥有快照计划？如何测试恢复？最大可容忍的写入丢失间隔是多少？位置策略是否允许在其他地方进行副本？如果存储介质、电源或控制系统威胁数据持久性，供应商将提供什么通知？数据丢失事件期间的支持路径是什么？这些问题将“云持久性”从口号转化为风险决策。

采购不应将区域视为备份

比利时事件对采购特别有用，因为它暴露了一个常见捷径。买家询问数据将驻留何处。供应商回答区域或可用区。买家将该回答视为弹性。但位置回答和恢复回答是不同的合同问题。一个描述放置；另一个描述丢失、损坏或不可用后发生什么。确保数据本地性但未定义备份设计的合同只解决了一半问题。

强有力的采购记录会在选择存储前识别工作负载所需的恢复点和恢复时间。日志工作负载可能容忍一定延迟但不容忍静默丢失。交易数据库可能需要每几分钟的应用一致性备份。公共注册表可能需要不可变备份和经过测试的恢复。小型分析项目可能接受每日快照。存储产品、快照计划、副本位置、加密密钥设计和恢复练习应遵循任务需求，而非相反。

采购还应要求提供者通知模型。在存储事件期间，在客户能从应用错误诊断前，供应商可能知道磁盘在受影响群体中。合同或支持计划应指定如何识别受影响资源，如何告知客户是否建议恢复，如何报告永久丢失，如何保留日志，以及如何确定技术支持的优先级。通用的服务状态页面不足以应对数据丢失事件，因为客户的操作是资源特定的。

买家还应避免在主权和弹性之间做出虚假选择。对于许多欧洲工作负载，另一个欧洲区域的独立副本可能满足策略，同时降低单可用区风险。对于更严格的工作负载，可能需要国家内的区域复制或谨慎管理的备份位置。对于某些数据，额外副本的成本和复杂性可能不成比例。责任点并非每个工作负载需要相同的设计，而是权衡应由理解丢失写入后果的业务所有者记录和接受。

审计员应警惕清单式回答。“数据存储在欧洲”不回答是否能恢复。“Persistent Disk 是持久的”不回答应用是否能容忍近期写入丢失。“快照可用”不回答它们是否已配置、最新、完整和经过测试。“供应商有 SLA”不回答客户是否有可用副本。审计证据应包括恢复测试结果、备份年龄、备份位置、密钥访问以及谁接受了残余风险的记录。

小型团队需要使可恢复性可见的默认值

最可能误解边界的客户往往装备最差，无法从跨越边界中恢复。大型企业可能有存储团队、备份平台、审计委员会和桌面演练。小型团队可能有一名工程师、一个项目、一个区域和一个仪表板，由于虚拟机可以删除而不删除卷，磁盘看起来是持久的。他们的风险不是贬义上的无知，而是抽象工作得太好的正常后果。

云供应商可以通过默认值和警告降低此风险。当客户为数据库型工作负载创建单可用区磁盘时，界面可以询问备份计划、推荐快照策略、显示故障域，并警告需要快照才能独立恢复。文档可以将故障域表放在创建工作流附近，而非深藏在可靠性指南中。定价页面可以显示无备份的成本作为风险接受，而不仅仅是快照作为额外成本。

客户可以通过简单的例程降低风险。每个持久化数据存储应有指定所有者、恢复点目标、快照或备份计划、恢复测试日期、备份位置和密钥访问计划。第一次恢复测试应在生产上线前进行，而非在第一次事件期间。测试应恢复至单独环境，检查应用一致性，并确认团队可以认证、解密和重新连接工作负载。如果团队无法负担恢复设计，这应是有意识的业务决策。

2015 年事件是一个好的教学案例，因为损失并不惊人。没有全球性崩溃使教训不可避免。百分比极小。然而，一个拥有受影响磁盘且无近期快照的小团队仍可能面临永久丢失。弹性教育通常关注巨大灾难；此事件表明罕见的、狭窄的失败足以惩罚未经测试的备份假设。

同样的逻辑适用于企业构建的内部平台。公司平台团队可能向产品团队提供“批准的云模板”。这些模板不应仅创建可用区磁盘并将备份选择留给可能不理解存储层的应用所有者。平台应要求或强烈引导快照计划、复制选项、保留期限和恢复测试。公司内部的共享责任反映了与云提供商的共享责任。

数据丢失改变状态语言的道德分量

许多中断状态可以用错误率升高、性能降级或恢复来表述。数据丢失需要不同的词汇。客户需要知道数据是延迟、不可用、损坏、回滚、部分不可恢复还是永久丢失。这些类别产生不同的责任。延迟数据可能需要队列处理。不可用数据可能需要故障转移。损坏数据可能需要验证和回滚。永久丢失可能需要通知、对账、赔偿或法律审查。

Google 的状态页面谨慎地从读取错误、性能降级和快照变通方案前进。后续报道记录了极小存储比例的永久丢失。受影响人群的缩小是有用的，但公开的教训是，一旦知道，应明确命名永久丢失。过长时间使用可用性语言的状态页面可能使客户将数据丢失事件视为重试问题。过于宽泛地命名永久丢失的状态页面可能引起不必要的恐慌。因此，精确性不是装饰性的；它控制客户响应。

存储事件的良好状态语言应说明受影响的产品、可用区、时间范围、资源类别、症状、当前客户操作和证据状态。应分离有风险的资源、已知存在读取失败的资源以及确认有不可恢复数据的资源。应说明快照、新磁盘、区域磁盘或其他存储产品是否受影响。应说明供应商是否能直接识别受影响资源以及如何联系客户。应在供应商从服务修复转向数据对账时更新。

这种精确性也有助于客户向其利益相关者报告。数据保护官员、审计员、董事会或小企业主需要知道事件是否改变了机密性、完整性、可用性或可恢复性。2015 年事件对狭窄磁盘群体而言是可用性加可恢复性，而非未经授权访问的证据。将每个云事件视为泄露是错误的；将每个存储事件视为暂时可用性问题也是错误的。类别应符合事实。

本地化决策应包括退出方案

每个本地化决策应包括退出方案：如果此可用区、区域或本地存储选择失败，工作负载去哪里，什么数据跟随它？2015 年选择欧洲西部 1-b 的客户需要知道失败的磁盘是否能恢复至另一可用区，快照是否存在于失败系统之外，应用是否能挂载恢复的磁盘，以及 DNS、凭证和操作员能否恢复服务。尽管产品名称和功能已变化，这些问题仍然适用。

退出方案包括几个部分。第一是数据：存在什么副本，多旧，位于何处。第二是计算：什么环境可以运行恢复的数据。第三是身份和密钥：谁可以访问和解密。第四是网络和路由：用户如何到达恢复的服务。第五是验证：团队如何知道恢复的应用是正确的。第六是沟通：如何告知用户和利益相关者发生了什么以及可能缺失的数据间隔。

本地性约束使退出方案更复杂，但不是可选的。如果数据必须留在比利时，设计可能需要多可用区本地弹性、更频繁的快照和更强的现场备份控制。如果数据可以留在欧洲，设计可能使用另一个欧洲区域或多区域快照存储。如果策略允许用于灾难恢复的全局备份，设计仍必须处理隐私、加密和访问控制。关键是要明确决定，而非允许默认磁盘放置悄悄地决定。

供应商可以通过用客户语言呈现故障域使这更容易。界面可以描述“在 VM 删除后存活”、“存活于可用区硬件故障类”、“通过区域复制在可用区中断后存活”和“通过快照支持时间点恢复”，而非仅产品名称。没有简短的短语能覆盖每个边缘，但清晰的故障域语言比宽泛的持久性形容词更难误读。

未知和谨慎的边界

公开记录未命名每个受影响客户、每个丢失写入、每个内部硬件型号或每个事后工程更改。它不证明特定客户的备份失败导致其损失。它不确立法律违约、疏忽认定、损害赔偿或合规违规。它也不证明所有当前 Google Cloud 存储产品具有相同的 2015 年风险。云基础设施和产品功能已大幅变化。

公开记录确实支持几个确定结论。事件影响了欧洲西部 1-b 的 Persistent Disk。客户经历了读取错误。Google 指导受影响客户从快照恢复。基于 Google 说明的当时报道描述了四次连续雷击、存储系统短暂断电、部分存储的硬件敏感性以及极小部分已分配 Persistent Disk 空间的永久丢失。Google 表示将审查栈并升级存储硬件。当前 Google 文档使快照、计划备份、区域磁盘和数据保护选择明确。

最重要的推断有支持但应标记为推断：更清晰的故障域披露和经过测试的独立备份降低了物理站点危害变为永久应用丢失的机会。这不同于说每个没有快照的客户都是疏忽的，或 Google 未能履行法律义务。这是一个实际的控制结论。供应商可以使边界可见并构建更有弹性的基础设施。客户可以选择不依赖单个本地磁盘的恢复设计。

事件也警告两种相反的错误。第一种是云宿命论：因为超大规模供应商曾丢失极少量数据，云存储不可信。第二种是云自满：因为百分比极小，无人需要独立备份。成熟的态度更苛刻也更有用。使用供应商持久性，但不要将其与恢复点混淆。使用本地性，但不要将其与弹性混淆。使用 SLA，但不要将信用与恢复状态混淆。

实际的证据测试足够简单，可以在采购结束前运行。买家应能指出实时磁盘、最新的独立恢复点、恢复目标、身份和密钥路径、负责恢复的人员以及最近的成功测试。供应商应能指出故障域、资源特定通知路径、事件状态类别以及面对永久丢失的客户支持路径。如果任何一方在罕见的存储事件之前无法回答这些问题，架构正依赖于隐藏在体面产品名称中的希望。

这就是为什么一个 2015 年的小事件仍然属于 2026 年的责任计划。它将抽象的共同责任模型转化为可见的操作合同。供应商的栈现在可能更强，客户有更多工具，但决策逻辑保持不变：本地性必须与可恢复副本配对，可恢复副本必须经过测试，经过测试的恢复必须由面对数据缺失用户的企业所有者理解。

该决策的最终所有者不应隐藏在基础设施简写中。它应是指定的服务所有者，理解丢失一小时、一天或一个交易间隔的成本。

该所有者还应有权为备份提供资金。

比利时磁盘丢失记录仍然有用，因为它足够小而可以研究，足够严肃而改变实践。它表明供应商管理的冗余可能在物理危害边缘失败，状态百分比必须按类别解读，快照仅在存在并干净恢复时才有用，以及本地性不是独立可恢复性的替代品。Google 控制数据中心和存储栈；客户控制其恢复架构；审计员和采购团队控制这两个责任是否在下一个罕见事件前被检查。负责任的结果是一个存储计划，能够说明数据驻留何处，可恢复副本位于何处，其新鲜度如何，谁能恢复它，以及当本地可用区不再能恢复时，什么证据将证明恢复完成。