数据完整性

一句话

这一章把问题反过来定义：数据完整性不是目的，数据可用性才是目的——用户不关心你存了几个副本、校验和对不对，只关心「我要用的时候，东西在不在、对不对」。而能毁掉它的失效模式有 24 种组合，没有任何单一手段挡得住，所以 Google 的答案是纵深防御的三道防线：软删除、备份与恢复、带外校验。全章最扎心的两句是：多副本不等于可恢复；没被验证过恢复的备份，等于没有备份。

Glossary · 术语表

坐标

SRE 全书第 26 章，属 Part III「实践」里的数据可靠性一组，紧接第 25 章「数据处理管线」——巧的是，管线正是批量毁数据的头号凶手之一。作者 Raymond Blum 与 Rhandeep Singh，长期负责 Gmail、Google 云端硬盘这类「丢一条都算事故」的系统。对应现实：任何长期持有用户数据的服务——邮箱、网盘、SaaS、支付账本、数据仓库。

这章要解决什么

可用性 SLO 大家都会定：99.9% 的请求成功。但有个尴尬的问题：请求成功了、返回的却是空的，算可用吗？一个刚把用户邮箱清空的系统，完全可以在监控面板上一路绿灯——延迟正常、错误率为零。可用性指标测的是「服务在不在」，不是「数据对不对」。

传统运维对这个问题的答复是「我们有备份」。这一章要拆穿的，正是这句话里的三个洞：备份可能从来没被验证过（GitLab 2017 年出事时，部署的 5 种备份 / 复制手段无一可用）；备份可能追不上损坏的速度（Google Music 2012 年误删的约 60 万 条音轨里，有约 16 万 条在被备份到之前就没了）；损坏可能根本没人发现，等发现时保留期内的每一代备份都已被坏数据覆盖。

而云时代把这三件事同时放大：更新速率高、持续交付天天改代码、服务之间层层调用、用户 24×7 不给你维护窗口、数据一存就是十几年。不解决的后果不是「慢一点」，而是用户的东西没了，并且永远回不来。

核心内容，讲透

换个定义：完整性是手段，可用性才是目的

教科书上的「数据完整性」是「数据在整个生命周期里保持准确与一致」。这个定义在工程上不好用——它没告诉你该做到什么程度、该花多少钱。这一章把标尺换成用户视角的数据可用性：服务能不能在用户需要的时候，把正确的数据交到他手里。这一换带来两个直接后果：

• 校验和全对、副本一个不少，但应用层读出来的是错的 → 依然算失败。完整性只是达成可用性的手段。
• 数据其实没丢、但恢复要三天 → 在用户眼里和丢了没区别。恢复时间是可用性的一部分。

所以 SLO 该写成「数据在任何时刻可被正确读取，且任一损坏事件在 X 小时内恢复」，而不是「我们每天做备份」。而且规模会把小概率变成日常：一个存了 100 亿 个对象的系统，就算每个对象一年只有百万分之一的概率静默损坏，一年也有约 1 万 个坏对象等着人处理。

为什么没有银弹：24 种失效组合

书里把「数据能怎么坏」拆成三个正交的轴：

• 根因（6 种）：用户误操作、运维失误、应用 bug、基础设施缺陷、硬件故障、站点灾难。
• 范围（2 种）：大面积（整个数据集）vs 局部（一个用户、一行记录）。
• 速率（2 种）：一次爆发（瞬间全毁，好处是你立刻就知道）vs 缓慢渗漏（一天漏一点，等发现时早已越过备份保留期）。

三轴相乘 = 6 × 2 × 2 = 24 种组合。关键洞察不在这个数字，而在于：任何一种防护都只覆盖其中几格。副本挡硬件与站点灾难，软删除挡误删，备份挡批量损坏——但备份挡不住缓慢渗漏：等你发现时，坏数据早已一代代覆盖进保留期内的所有备份。能挡这一格的只有早发现。所以答案必然是纵深防御，而不是「买个更好的备份方案」。

第一道防线：软删除

机制很朴素：删除请求不真删，只给记录打上「已删除」标记和时间戳，读路径自动过滤掉；到期后才真正清除。用户端看到的就是回收站与版本历史。

它凭什么排第一？因为它挡住的是频率最高的那一类事故：用户误删、账号被盗后被恶意清空、运维一次跑错的脚本。这类事故远比机房失火频繁，而它的恢复成本几乎为零——改一个标记位，秒级完成，比从备份里捞快好几个数量级。用「频率 × 恢复成本」算，这是投入产出比最高的一层。

两个工程细节：窗口长度是个真权衡——太短救不回人（用户往往过几天才发现删错了），太长既占存储、又和「彻底删除」的隐私诉求正面冲突，业界常见做法是数周量级（Gmail 回收站 30 天就是这个思路）；懒删除（lazy deletion）——真把数据从所有副本、缓存、索引和备份里抹干净，在大规模系统里可能要几周才收敛，这意味着「删除」天然是一个过程而非瞬间。

也要说清它挡不住什么：软删除对付的是「删除」，对付不了「改坏」——应用 bug 把字段算错、写进脏值，回收站里一条都不会有。

第二道防线：备份与恢复——「备份本身没有价值，恢复才有」

这是全章的重心，有三个反直觉的点。

（1）复制不是备份。原文的措辞很不客气：「复制与冗余不等于可恢复性」（Replication and redundancy are not recoverability）。自动同步多副本的数据库，恰恰保证了一次误删、一行被改坏会被推送到所有副本，而且通常在你反应过来之前就完成了。把量级摆出来就很清楚：同步复制的传播延迟是毫秒到秒级，而人类发现问题的时间是分钟到天级——这两个数量级之间的鸿沟，就是副本救不了你的全部原因。

（2）备份不是归档。书里给的判据只有一句：能不能被应用重新加载回去。原文说得很明确——「备份与归档最重要的区别是，备份能被装回应用，归档不能」。备份是为了「装回去继续跑」，所以格式、schema、依赖版本都得和当前系统对得上；归档是为了合规与审计长期封存，可能压根装不回去。把归档当备份，是事故复盘里的常客。

（3）备份策略从恢复需求倒推。别先问「多久备一次」，先问三件事：能容忍丢多少数据（RPO）→ 决定备份频率与要不要重放事务日志；能容忍多久恢复不了（RTO）→ 决定介质与位置；要挡住 24 格里的哪几格 → 决定隔离程度。同集群的快照挡不住「误删被同步过去」，所以必须另有离线、异构、异地的一份。Google 在这一层选了磁带——慢得离谱，但胜在物理上与线上系统断开，任何在线的错误操作都传不过去；2011 年 Gmail 那次正是靠它救回来的。

成本也要算诚实：全量备份最简单，但存储与耗时随数据量线性涨；增量 / 差分省空间，恢复却要按顺序一层层叠加，链条越长越容易断。真实系统通常是「周期性全量 + 期间增量 + 保留 N 代」，而保留几代由「你最晚可能多久才发现损坏」决定——绕一圈又回到缓慢渗漏那一格。

第三道防线：带外校验

前两道防线都是事后的：它们让你能把数据捞回来，前提是你知道数据坏了。第三道防线专门解决「知道」：跑一批独立于主服务的校验器（validator）持续对账——引用是否悬空（一条歌曲元数据指向的音频文件还在不在）、跨库的账是否平、副本之间是否一致、业务不变量是否成立。

它为什么必须存在：系统越快、越自动，把损坏传播完所需的时间就越短，而人类发现问题的时间并没有变快。校验器的价值，是把「发现延迟」从「等用户投诉」（天）压到「下一轮校验」（分钟到小时）——这直接决定了你还能不能在保留期内找到一份干净的备份。Google Music 那次就是反例：问题是靠工程师排查「某首歌放不出来」才顺藤摸瓜发现的，彼时已有约 16 万条音轨过了能被救回的窗口。

三条实践要点：必须带外——用独立的读路径与部署，别和被检查的系统共用同一套可能有 bug 的代码，否则 bug 会同时骗过服务和校验器；校验器自己也要被监控——一个悄悄停掉的校验器比没有校验器更危险，因为它给的是虚假的安全感；告警要可定位——只报「有 N 条对不上」没用，要能指出是哪些记录、从哪个版本开始的。

让恢复真的可用：演练，而不是相信

最容易被跳过的一步：没被演练过的恢复流程，默认它是坏的。SRE 把「恢复」当成需要持续测试的产品功能——定期做端到端演练（Google 的 DiRT 灾难恢复演练就是这个思路），验收标准是「数据被真正加载回应用、业务校验通过」，不是「备份任务返回成功」。这一章把它收束到 SRE 的几条通用原则上：保持初学者心态（别假设，去查）、信任但要验证、「指望它没事」不是策略（hope is not a strategy），以及纵深防御本身。

关键权衡与选型

表 1 · 三道防线：各挡什么、多快、代价多少

表 2 · 复制 / 备份 / 归档：三件最常被混为一谈的事

表 3 · 备份介质与位置怎么选（按恢复需求倒推）

算一笔恢复的账：RTO 常常不是「策略问题」而是「物理问题」。要从异地把 100 TB 拉回来，就算跑满 10 Gbps，理论上也要约 22 小时——如果你的 RTO 写着「4 小时」，那就不是加钱买存储能解决的，得改架构（分片并行恢复、就近副本、优先恢复热数据）。没算过这笔账的 RTO，都是许愿。

为什么重要 / 落到真实系统

这一章之所以是数据类系统的必读，是因为它把一句人人会说的空话——「我们有备份」——变成了可被审计的具体清单：软删除窗口多少天？上一次完整恢复演练在什么时候、耗时多久？校验器覆盖了哪些不变量、它自己上次跑成功是什么时候？这套问法早已渗进行业：对象存储的版本控制与对象锁本质就是「软删除 + 不可篡改的备份」，数据仓库的 time travel 是软删除的另一种形态，数据可观测性工具做的就是第三道防线的商业化，而「恢复演练」成了金融与云厂商的合规硬指标。放到架构评审和面试里，它给你三句能一击戳破的话：多可用区不等于备份、备份成功率不等于恢复成功率、校验器没被监控等于没有校验器。

易错点与争议

• 把复制、RAID、多可用区当备份：本章要反复敲打的第一号误解。它们防的是硬件与站点，对误删和写坏不但无效，还会加速扩散。
• 只监控「备份成功率」，不监控「恢复成功率」：备份任务返回成功，不代表那份数据装得回去。GitLab 的教训正是「静默失败 + 通知也没发出来」。
• 演练只恢复一个小库：真实恢复的瓶颈往往是带宽和顺序依赖，小库测不出来；演练要按真实数据量估时。
• 校验器悄悄停了，或以为校验器能替代备份：前者给的是虚假安全感，后者搞错了分工——校验只压缩发现延迟，一个字节也救不回来。
• 软删除与「被遗忘权」的真实张力：软删除让删除变成持续数周的过程，而隐私法规要的是可证明的彻底删除。没有完美解，只能把窗口与懒删除的收敛时间明确写进设计和隐私说明。原书写于 2016 年、GDPR 尚未生效，这里的时代局限最明显。
• 2016 年的威胁模型里没有勒索软件：今天攻击者的标准动作就是先删你的备份、再加密你的数据。本章之后最重要的补充是不可变性——对象锁 / WORM 备份桶，加上独立于生产权限体系的备份账号。「离线磁带」的思路是对的，今天的等价物换成了「不可变 + 权限隔离」。
• 「24 种组合」不必当教条：它的价值是提醒你逐格自查覆盖率，不是一套精确分类学。

要点