周三下午，数据平台开了一场降本会。
大屏上第一行写着：历史日志，3 年，412 TB。
财务同事问：“近半年有人查吗？”
平台工程师翻了翻访问记录。直接查询几乎为零。会议室里安静了几秒，接着安全说可能要留，审计说先别动，业务说以后也许有用。
于是这 412 TB 数据又获得了一次完整的生命延期。它没有被证明有用，也没有被证明该删，只是因为没有人愿意在删除单上写自己的名字。
这事很常见。
企业里的旧数据有一种奇特待遇：活着时没人看，谈到删除时突然亲友满堂。存储账单每月来一次，责任人却像候鸟，到了签字季就不见了。
可“没人查询”并不是删除理由，“也许有用”也不是保留策略。
在删之前，团队至少要问清 4 个问题。
文中的 412 TB、时间范围与试点周期用于说明方法，不对应某家真实公司的存储规模或制度要求。
第一个问题：真的没人用，还是你只看见了查询日志？
平台先查访问记录没有错。
错的是把“没有交互式查询”直接翻译成“没有任何用途”。
日志可能被下面这些东西使用：
- 每天跑一次、但不留下人工查询记录的下游任务；
- 只在安全事件、客诉或事故复盘时触发的低频调查；
- 从原始日志重放明细、修复宽表或重算指标的恢复流程；
- 导出后由别的系统、团队或供应商继续使用；
- 被审计、法务或合约要求保留，但平时不会打开。
一个数据集半年没人点开，可能确实已经睡着了。也可能它是一把灭火器，平时没人使用，着火时才有人想起墙角那只红罐子。
因此，使用盘点至少要看四类证据：
| 证据 | 要查什么 | 容易漏掉什么 |
|---|---|---|
| 访问记录 | 查询、读取、下载、扫描 | 服务账号与跨系统读取 |
| 任务依赖 | 调度任务、视图、模型、报表 | 临时脚本与失败后重跑 |
| 事件使用 | 安全调查、审计、客诉、事故 | 低频但高代价的场景 |
| 责任访谈 | 数据所有者与主要使用方确认 | “可能有用”但说不出用途 |
最后一项很重要。
不要群发一句“谁还在用这张表”，然后把没有回复当作默认同意。更稳妥的问法是：
过去 12 个月，哪一次任务或事件需要过它？如果明天取不到，哪个流程会失败，损失是什么？
问题一旦落到具体动作，“以后也许有用”就会变得清楚一些。
第二个问题：保留它，依据到底是什么？
很多团队说“审计要留”，再问留多久、留哪类、谁规定的，回答就开始变得柔软。
保留依据通常来自几类地方：
- 法律、监管与行业要求；
- 合同、客户承诺与争议处理；
- 安全、审计和事件调查需要；
- 业务重算、模型训练或产品能力；
- 内部风险偏好与历史惯例。
这些依据不能混成一句“统一保留 3 年”。
登录审计日志、应用调试日志、数据库慢查询、订单操作记录、匿名统计日志，敏感程度、用途和恢复价值都不同。把它们都留 3 年，往往不是谨慎，而是没有分类。
团队需要一张最小保留登记表：
| 字段 | 示例问题 |
|---|---|
| 数据类别 | 这是什么日志，含哪些敏感字段？ |
| 保留依据 | 哪条制度、合同、业务流程或风险判断要求保留？ |
| 起算事件 | 从生成、结案、合同终止还是账号注销开始算？ |
| 保留期限 | 当前期限是多少，谁批准的？ |
| 例外冻结 | 遇到调查、诉讼或事故时，谁能暂停删除？ |
| 复核日期 | 什么时候重新确认依据仍然有效？ |
这里不应该由数据工程师在网上搜一个数字，替公司决定所有日志的保留期限。
具体期限与删除义务受所在地区、行业、合同和数据类型影响。工程师应该做的是把技术对象、当前规则和缺失责任人列清楚，再让法务、安全、审计和业务所有者对自己的依据负责。
如果一项数据只剩“大家一直这么留”，就把它标成“依据待补”，不要悄悄把惯例改写成规定。
反过来，如果确有保留要求，也不等于必须一直放在最贵、最快的热存储里。保留和即时访问不是同一件事。
第三个问题：不能直接删时，能不能先降温、归档或缩小？
数据生命周期不只有“留”和“删”两个按钮。
更实际的路径通常是：
热存储 → 低频存储 → 归档 → 到期隔离 → 验证删除
云对象存储的生命周期规则也通常把动作分成迁移和过期：先转到更低成本的存储层，到了条件再删除。工具能执行规则，但不能替团队决定哪些对象适用、何时开始计时。
降温前要问三个更细的问题。
需要多快取回？
事故调查可能要求几分钟内拿到最近 30 天日志，却可以接受用几个小时恢复两年前的记录。
把不同时间段分层，比把所有日志都放在同一速度上合理。检索时限要写进规则，不要等事故发生才发现归档需要排队恢复。
需要保留原始明细，还是保留可验证的摘要？
有些场景必须保留原始记录；有些分析只需要按日聚合、样本或特定字段。能否脱敏、去重、压缩或只保留必要字段，要由用途和依据决定。
缩小数据不是随手裁列。先验证下游、调查和重放是否仍然成立。
还能不能重放？
不少团队保留原始日志，是为了上游修复后重算。
可三年前的解析代码、字典和依赖版本早已不存在，留下文件也未必真的能重放。此时“可以恢复”只是文件还在，不是能力还在。
归档试点要同时保留：
- 数据清单、分区与校验信息；
- 解析规则、Schema 和关键字典版本；
- 加密与访问权限说明；
- 恢复步骤、预计时间和负责人；
- 一次实际取回并读取的演练记录。
最便宜的归档如果永远取不回来，只是把问题搬到一个更冷的房间。
第四个问题：谁批准，怎么停，删完如何证明？
日志不敢删，很多时候不是技术做不到，而是责任设计得太模糊。
平台团队维护存储，不一定拥有数据；安全团队提出调查需要，不一定承担全部成本；业务说以后可能要用，也不一定能定义恢复时限。
每条保留规则至少要有三种角色：
- 数据所有者：确认业务用途和停止使用的条件；
- 规则批准者：确认保留依据、期限和例外；
- 执行与验证者：配置迁移、删除、监控和恢复测试。
一个人可以承担多个角色，但角色不能空着。
真正执行时，也不要第一天就对 3 年日志下全量过期规则。
可以先做一个可撤回的小试点：
- 选一个边界清楚的日志前缀或分区；
- 导出对象清单、大小、时间范围与校验值；
- 检查版本、复制、备份和法律冻结状态；
- 先迁移到隔离区或低频层，观察一个约定周期；
- 做一次恢复与读取验证；
- 由责任人确认后，再执行最终删除；
- 保存规则版本、执行结果、失败对象与事件通知。
“删完”也不是控制台显示一条成功消息。
在不同存储和版本配置下，删除标记、非当前版本、复制副本、备份和缓存可能各有自己的生命周期。需要核对规则实际作用的对象范围，以及哪些副本仍然存在。
对于承载敏感信息的介质和设备，最终处置还涉及清除方法是否让目标数据在预期攻击成本下不可恢复。NIST SP 800-88 Rev. 2 把这类工作称为介质清除，并强调要根据数据敏感性、介质和处置场景选择适用控制。
这不意味着每次删对象都要开一场硬盘销毁仪式。
它提醒我们：逻辑删除、生命周期过期、版本清理、加密密钥处置和物理介质清除不是一回事。团队要先说清自己正在解决哪一层问题。
不敢删的数据，往往缺的不是容量，而是一张责任表
把四个问题放在一起，会得到一张比“最近是否查询”更可靠的判断表：
| 问题 | 通过标准 | 不通过时的动作 |
|---|---|---|
| 真的没人用吗 | 查询、依赖、事件和责任访谈均无明确用途 | 补依赖扫描或联系责任人 |
| 为什么保留 | 有可引用依据、起算事件和复核日期 | 标成依据待补，暂停最终删除 |
| 能否降温或缩小 | 检索时限、归档内容和恢复路径已验证 | 先做分层与恢复演练 |
| 谁负责删除 | 所有者、批准者、执行者齐全，可暂停可追溯 | 不进入全量执行 |
这张表不会让所有人立刻同意删除。
它的价值是把“我有点担心”翻译成可以处理的缺口：缺一条依赖证据，缺一个期限依据，缺一次恢复演练，或者缺一个愿意签字的所有者。
担心有名字，工作才有下一步。
明天就能做的 3 个动作
动作一：挑一个前缀，做 12 个月使用证据盘点
不要从全仓开始。
选一类边界清楚的日志，收集查询、服务账号读取、任务依赖、事件工单和数据所有者确认。把“无查询”升级成“目前没有发现这四类使用证据”。
后一种说法更慢，却也更可信。
动作二：建立一张最小保留登记表
先填 6 列：数据类别、保留依据、起算事件、期限、例外冻结、责任人。
缺失项直接写“待确认”，不要用空白假装问题不存在。
动作三：做一次只降温、不删除的演练
把一个小分区迁到低频或归档层，记录迁移成本、取回时间、恢复步骤和读取结果。
如果取回失败，先修恢复路径；如果恢复成功，再讨论更大范围。一次真实演练，比十句“以后应该能找回来”有用。
旧日志并不会因为被保留得久，就自动变得重要。
它真正需要的，是一个能说明用途、期限、恢复方式和责任人的位置。该留的，留得明白；该删的，删得可证。仓库也就不用一直替组织保存犹豫。
我叫石头，在数据行业里摸爬滚打了十几年，见过不少数据不是因为有用而留下，只是因为没人敢签字。这里写的，就是这些教训——我觉得值得说出来的那部分。
参考资料：NIST SP 800-92 — Guide to Computer Security Log Management · NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization · Amazon S3 — Managing the lifecycle of objects
