制品保留策略要回答三个问题：哪些制品必须留、每类留多久、到期后由谁清理并留下什么记录。本文给出一张可直接填写的保留分级表、从盘点到清理的四步操作流程、角色与交付物对照，以及一份可执行性核对清单，帮助团队把“先别删”变成有依据、可追溯的规则。
要点总览（TL;DR）
- 保留策略按制品类型与用途交叉分级，一般设三到四级，每级写明保留期限、存储位置和责任人，期限取合规要求、回溯窗口、成本上限中最严的一条。
- 落地按四步推进：盘点制品与存储占用、按分级表打标形成台账、设定时间与事件两类清理触发条件及审批路径、小范围试运行自动清理并保留审计记录。
- 策略制定、审批、发布登记、交付归档、清理执行与复核应分角色承担，执行清理与复核由不同人负责，操作留痕可追溯。
- 单个制品到期后先判断是否仍为生产运行版本或回退候选，再决定延长、归档或删除，判定结果与审批单编号一并写入台账。
- 季度复核存储占用与保留期限是否匹配，反复延长的条目作为下一版策略的修订输入。
先定分级：哪些制品必须留、留多久
保留策略的第一步是分级，分级的依据来自两个维度：制品类型和用途。制品类型决定它承载什么信息，用途决定它服务谁、被追溯的概率有多高。两个维度交叉，才能得出“必须留、留多久”的判断，单看类型容易一刀切，单看用途又容易漏掉合规要求。
常见制品类型包括构建产物（编译生成的中间包、镜像）、发布包（对外或对生产环境的正式版本）、交付文档（部署说明、验收材料、客户交付清单）、版本标识记录（版本号、发布记录、变更说明）。用途上区分生产发布、客户交付、内部验证、临时构建四类。生产发布与客户交付的制品通常需要覆盖问题回溯窗口和合同约定，内部验证制品保留到验证结论确认即可，临时构建原则上不进入长期保留范围。
保留期限的确定建议同时参考三条约束，取其中最严格的一条作为该级下限：合同或合规要求的最短留存期；问题回溯所需的版本覆盖窗口，例如需要能回退到最近若干个生产版本；存储成本可承受的上限。三条约束写进分级表，期限才有依据，而不是凭经验拍一个数字。
存储位置同样要写进分级表。长期保留的发布包和交付文档放在受控的归档位置，限制删除权限；内部验证制品放在常规存储区，按周期清理；临时构建放在临时区，设置较短的自动过期时间。存储位置与保留级别对应，清理时才能按区域批量处理，减少误删风险。
下表是分级表的空白结构，团队可直接填写。填写说明：级别按保留强度从高到低排列，一般设三到四级即可；典型示例列两到三个真实制品名称，便于执行人对照；保留期限写区间并注明起算点，例如“自发布日起 24 个月”；责任人写岗位而非个人姓名，避免人员变动后规则失效。
| 级别 | 制品类型 | 典型示例 | 保留期限 | 存储位置 | 责任人 |
|---|---|---|---|---|---|
| L1 长期保留 | 生产发布包、版本标识记录 | （填写：对外发布版本包、发布记录） | （填写：自发布日起 N 个月，不低于合规下限） | 受控归档区 | （填写岗位） |
| L2 交付保留 | 客户交付文档、交付版本包 | （填写：验收材料、部署说明） | （填写：自客户验收日起 N 个月） | 交付归档区 | （填写岗位） |
| L3 验证保留 | 内部验证构建产物 | （填写：测试环境验证包） | （填写：自验证结论确认起 N 周） | 常规存储区 | （填写岗位） |
| L4 临时 | 临时构建、调试产物 | （填写：本地调试包、临时镜像） | （填写：N 天自动过期） | 临时存储区 | （填写岗位） |
操作步骤：从盘点制品到落地清理规则
分级表是标准，落地还需要一条执行顺序。下面四步按“先看清存量、再打标、再定规则、最后自动化”推进，每步都给出输入、动作、输出和完成标志，便于判断这一步是否真的做完。
第一步：盘点现有制品与存储占用
输入是各存储区、制品库和交付目录的现有清单。动作是导出全部制品条目，记录名称、大小、创建时间、最近访问时间、关联项目，并按存储区汇总占用。输出是一份制品清单和一张存储占用汇总。完成标志是清单条目数与存储区实际对象数一致，且能按项目或存储区排序查看占用前若干名。
第二步：按分级表为存量制品打标
输入是第一步的制品清单和已确认的分级表。动作是逐条对照分级表判定级别，无法判定的标记为“待确认”并注明原因，例如关联项目已关闭、找不到发布记录。输出是一份带级别的制品台账，台账字段与分级表一致，另加“判定依据”和“待确认原因”两列。完成标志是清单中每条制品都有级别或明确的待确认标记，待确认条目数量可控并有负责人跟进。
第三步：设定清理触发条件与审批动作
输入是带级别的制品台账。动作是为每个级别设定触发条件，建议同时设置时间触发和事件触发：时间触发即到期，事件触发包括被新版本替代、项目关闭、客户验收完成。事件触发需要人工确认后再执行，避免新版本尚未稳定就清理旧版本。同时明确审批动作：谁发起清理、谁审批、审批通过后由谁执行。输出是一份清理规则说明，逐级写明触发条件、审批路径和执行角色。完成标志是每条规则都能对应到台账中的具体级别，且审批路径上每个角色都已确认接受该职责。
第四步：配置自动或半自动清理并保留审计记录
输入是清理规则说明和台账。动作是先在小范围试运行，例如只对 L4 临时制品开启自动过期，观察一个周期后核对清理结果与台账是否一致，再逐步扩展到 L3、L2。每次清理生成一条记录，包含清理时间、制品名称与版本、级别、触发条件、审批人、执行人、结果。输出是清理记录和试运行结论。完成标志是至少完成一轮完整清理周期，记录可追溯到审批单，且没有出现需要恢复但已被删除的制品。
这四步中，制品台账是贯穿始终的核心载体。台账与发布流程关联后，新发布的制品可以在发布环节直接登记级别，减少事后补录。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；把测试用例、缺陷、版本和发布过程关联到需求链路，也有助于在清理前确认某个版本是否仍被问题回溯引用。团队可以把制品台账作为发布流程中的一个交付物登记环节，把清理审批作为下线流程中的一个评审节点，让保留规则跟着发布与下线动作走，而不是另起一套台账。
角色与交付物：谁定策略、谁执行清理
保留策略失效最常见的原因是清理无人负责，或者制定者与执行者是同一人且缺少复核。角色分工的核心原则是：定策略的人不直接删，执行清理的人不单独决定删什么，审批与执行分离，操作留痕。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 研发负责人 / 配置管理员 | 制定并维护保留策略，确认分级标准与期限，组织季度复核 | 策略文档（含版本号、生效日期）、分级表 |
| 审批者（研发负责人或指定评审人） | 审批清理申请，确认触发条件成立、无未关闭的追溯需求 | 清理审批单 |
| 发布负责人 | 在发布环节登记制品级别与存储位置，确保发布包进入对应归档区 | 制品台账中的发布登记记录 |
| 交付经理 | 在客户交付完成后归档交付文档，标注合同约定的留存要求 | 交付归档记录、留存要求说明 |
| 清理执行人 | 按审批单执行删除或归档操作，生成清理记录 | 清理记录（含时间、制品、级别、审批人、结果） |
| 复核人 | 抽查清理记录与台账一致性，核对是否有误删或漏删 | 复核结论 |
小团队可以合并部分角色，例如研发负责人兼任审批者，但执行清理与复核仍建议由不同人承担。角色合并时在策略文档中写明，避免后续人员变动后职责悬空。策略文档本身也应有版本号和生效日期，变更走审批，旧版本保留备查。
示例：一个发布包的保留判定过程
以下为演示情景，用于说明判定方法，不代表真实项目数据。
某发布包基本信息：版本号 v3.2.0，发布时间为某年 6 月，关联项目状态为“已上线、客户已验收”，该版本为当前生产环境运行版本，且客户合同中约定交付版本相关材料留存不少于 24 个月。
按分级表判定：该制品属于生产发布包，同时服务客户交付，对应 L1 长期保留级别。判定依据有三条：它是当前生产版本，问题回溯时需要能取到；客户合同约定了 24 个月留存期；它同时是交付版本包，需满足交付保留要求。三条约束取最严者，保留期限定为自发布日起 24 个月，存储位置为受控归档区，责任人为发布负责人。
到期后的判断路径：到期时先检查该版本是否仍为生产环境运行版本或回退候选版本。若已被后续版本替代且超过回溯窗口，则由发布负责人发起归档或删除申请，提交审批者确认无未关闭的追溯需求，审批通过后由清理执行人操作，复核人抽查记录。若到期时该版本仍在生产运行，则延长保留并在台账中记录延长原因和新的到期时间。
记录方式：在制品台账中更新该条目的“级别、保留期限、到期时间、判定依据、最近一次复核时间”，清理或归档后在清理记录中新增一条，关联审批单编号。台账与清理记录通过版本号和审批单编号对应，形成从判定到执行的完整链条。
完成检查：策略是否可执行的核对项
策略写完不等于可执行。下面这份清单用于发布前自检和季度复核，逐项核对，任一项不通过就回到对应章节修订。
| 核对项 | 通过标准 | 核对方式 |
|---|---|---|
| 类别覆盖完整 | 每类制品都有明确级别和期限，无遗漏类别 | 用制品清单逐类对照分级表 |
| 期限有依据 | 每级期限注明来源：合规要求、回溯窗口或成本上限 | 抽查分级表填写说明 |
| 清理可追溯 | 每次清理有审批单和清理记录，能对应到台账条目 | 抽取若干条清理记录回溯审批单 |
| 审批与执行分离 | 执行清理的人不单独审批自己的清理申请 | 核对角色对照表与实际操作人 |
| 成本与期限平衡 | 有季度复核安排，复核结论作为期限调整输入 | 查看最近一次复核记录 |
| 文档受控 | 策略文档有版本号和生效日期，变更走审批 | 查看文档版本历史与变更审批 |
| 试运行验证 | 至少完成一轮清理周期，未出现需恢复但已删除的制品 | 查看试运行结论与清理记录 |
季度复核时重点看两件事：存储占用是否与保留期限匹配，是否存在长期未访问却仍按高级别保留的制品；清理记录中是否有反复延长的条目，反复延长往往说明期限设定与实际回溯需求不符，应作为下一版策略的修订输入。复核结论写入策略文档的变更记录，形成“制定—执行—复核—修订”的闭环。
常见问题
制品保留期限设多长合适，有没有通用数字？
没有适用于所有团队的固定数字，期限由三条约束共同决定：合同或合规要求的最短留存期、问题回溯所需的版本覆盖窗口、存储成本可承受的上限。三条约束取最严者作为该级下限，并在分级表中注明期限来源和起算点，例如“自发布日起 24 个月”。有客户合同约定留存期的，以合同为准；没有外部约束的，可按需回退的生产版本数量估算回溯窗口。
清理触发条件用时间还是事件更可靠？
建议两类同时设置。时间触发即到期，适合临时构建和内部验证制品，可以自动执行；事件触发包括被新版本替代、项目关闭、客户验收完成，这类条件需要人工确认后再执行，避免新版本尚未稳定就清理旧版本。事件触发的确认动作应写入审批单，与清理记录关联。
小团队人手少，角色可以合并吗？
可以合并部分角色，例如研发负责人兼任审批者、发布负责人兼任台账登记人。执行清理与复核仍建议由不同人承担，至少做到执行人不单独审批自己的清理申请。角色合并的情况写进策略文档，人员变动时重新确认职责，避免清理动作无人负责或缺少复核。
制品到期时仍在生产环境运行，该怎么处理？
到期判定先看制品当前状态：仍是生产运行版本或回退候选版本的，延长保留并在台账中记录延长原因和新的到期时间；已被后续版本替代且超出回溯窗口的，由责任人发起归档或删除申请，审批确认无未关闭的追溯需求后执行。反复延长的条目应在季度复核时分析，判断是期限设定偏短还是回溯需求发生了变化。
策略上线后怎么验证清理规则没有误删？
先在小范围试运行，例如只对临时制品开启自动过期，观察一个完整周期后核对清理结果与台账是否一致，再逐级扩展。每次清理生成记录，包含时间、制品名称与版本、级别、触发条件、审批人、执行人和结果，复核人抽查记录与台账的一致性。完成标志是至少跑完一轮清理周期，且没有出现需要恢复但已被删除的制品。
