GoogleSRE保障数据完整性的手段保障数据完整性的手段
就像我们假设Google 的底层系统经常出问题那样，SRE 同样假设任何一个数据保护机 制都可能在最不适合的时间出现问
题。在所依赖的软件系统不停改变的情况下保障大规 模数据的完整性，需要很多特定选择的、相互独立的手段来各自提供高
度保障。
24种数据完整性的事故组合
由于数据丢失类型很多（如上文所述），没有任何一种银弹可以同时保护所有事故类型， 我们需要分级进行。分级防护会引
入多个层级，随着层级增加，所保护的数据丢失场景 也更为罕见。图 26-2 显示了某个对象从软删除到彻底摧毁的过程，以及
对应的分级数据 恢复策略。
第一层是软删除（soft deletion）（或者是某些 API 提供的“懒删除”机制）。这种类型的 保护在实践中被证实是针对意外数据
删除的有效手段。第二层，是备份和对应的恢复机 制。第三层，也就是最后一层，更多信息参见本章后面“第三层 ：早期预
警”小节。在 这三层中，如果同时还有复制机制，那么在某些场景下对数据恢复是很有用的（但是数 据恢复计划不应该依赖于
复制机制）。
第一层 ：软删除
当更新速度很快，同时隐私很重要的时候，大规模数据丢失和损坏通常是由应用程序的 Bug 造成的。事实上，数据删除逻辑
的 Bug 非常常见，以至于快速复原一定时间内的删 除操作是针对永久性数据丢失的第一道防线。
任何一个保障用户隐私性的产品都必须允许用户删除全部或者一部分数据。这种产品不 可避免地要处理误删除场景。允许用
户恢复他们的数据（例如，使用回收站机制）可以 降低出现频率，但是不能彻底消除这种场景，尤其是当该服务允许第三方
插件删除数据 的时候。
软删除机制可以大幅度减少支持人员的压力。软删除意味着被删除的数据立刻被标记为 已删除，这样除了管理后台代码之外
其他代码不可见。管理后台这里可能包括了司法取 证场景、账号恢复、企业管理后台、用户支持，以及在线排错等。在用户
清除自己的应 用中的垃圾箱时应该采用软删除，同时提供某种支持工具允许有授权的管理员恢复误删 除的文件。Google 在使
用量最高的工具上都实现了这种机制，否则用户支持所带来的压 力是无法持续的。
我们可以将这种软删除策略继续延伸，直接提供给用户数据恢复机制。例如Gmail的垃圾箱允许用户恢复 30 天之内删除的信
息。
另外一个常见的数据误删除场景是由于账号被劫持造成的。在这个场景中，劫持用户账 号的人常常会先将用户原始数据删
除，再用这个账号来发送垃圾或者进行其他非法活动。 当我们将用户误删除和账号劫持两个场景结合起来，在应用程序层
内，或者其下某层实 现软删除机制的需求就非常明显了。
软删除还意味着一旦数据被标记为已删除，在某段时间以后会真的被删除。这个时间的 长度，尤其是在有很多短期数据的情
况下，取决于某个组织的政策和相关的法律条文、 可用的存储空间和存储成本，以及产品的价格和市场定位等。常见的软删
除时间是 15、 30、45 或者 60 天。在Google的经验中，大部分账号劫持和数据完整性问题都会在 60 天内汇报或者检测到。
因此，为软删除保存超过 60 天的需求可能没有那么强烈。
Google 同时发现最严重的数据删除案例经常是由于某个不熟悉现有代码的开发者实现新 的删除逻辑时造成的。尤其是在开发
某种离线批处理数据流水线的时候（例如，某个离 线的 MapReduce，或者 Hadoop 流水线）。于是，在设计接口的时候，最
好能够使得不熟 悉现有代码的开发者无法（或者非常困难）绕过软删除逻辑。一个有效方法是让云计算 API 提供内置的软删
除和恢复删除 API，同时确保启用这项功能。再好的盔甲也要穿上才能起作用。
面向直接用户的 Gmail 或者 Google Drive 的删除功能都采用了软删除策略，但是云计算 API 类型的服务怎么办呢？假设该项
服务已经提供了可编程的软删除和还原机制，同时 有比较合理的默认值，剩下的误删除场景就是由内部开发者或者是外部开
发者错误操作 造成的数据丢失了。
针对这种场景，有时候可能会再增加一层软删除机制，我们称之为“懒删除”机制。可 以将“懒删除”认为是某种幕后清理机制，
由存储系统控制（与此相比，软删除是由程 序或者服务直接控制的）。在懒删除场景下，由某个云计算应用程序删除的数据
马上对应 用程序不可用，但是由云计算服务提供商保留几周时间再彻底销毁。懒删除不一定在所 有的策略中都适用 ：在一个
资源评论
