制定制品保留策略，核心是回答四个问题：哪些制品必须留、每类留多久、到期后由谁按什么条件清理、例外如何审批。做法是先按制品对交付、回溯和合规的价值分级，再为每级确定保留期限与存储位置，把清理触发条件和责任人写进规程，最后用一次试运行校准容量与可回溯性。最终交付物是一张分级保留表和一份清理操作规程。
要点总览（TL;DR）
- 先按制品对交付、回溯、合规和可重建性的价值分为 L1 至 L4，再为每级确定保留期限、存储位置和责任人，形成一张分级保留表。
- 期限口径在按时间、按版本数、按事件中选一种，每个级别只保留一种口径，并写明起算时点，避免规则无法判断。
- 制定过程分五步：盘点制品与容量、定分级与期限、定清理触发与例外、定审批与执行责任、试运行校准。
- 清理需要审批和回退路径，例外保留单独申请、到期复评，清理记录与审批记录一并留存作为回溯证据。
- 策略完成后用检查清单逐项核对，并按固定周期复核例外分布和容量增长，据此调整期限与分级。
先定分级：哪些制品必须留、留多久
保留策略的起点是分级。制品数量增长快、类型差异大，如果对所有制品套用同一期限，要么占用大量存储，要么删掉仍需回溯的版本。分级的作用是把有限的存储和管理注意力放到高价值制品上，同时让低价值制品有明确的退出路径。
分级可以从两个方向同时切入：一是制品类型，二是价值维度。类型决定制品在研发流程中的位置，价值维度决定它被再次使用的可能性。
按制品类型划分
- 发布版本：对外交付或上线使用的正式版本，是回溯和合规的主要对象，通常需要长期保留。
- 候选版本：进入发布评审但未正式发布的版本，保留到发布结论确定后一段时间，用于比对和问题定位。
- 每日构建：持续集成产生的中间产物，价值集中在短期，用于快速定位引入问题的构建。
- 临时调试包：为排查特定问题临时构建的制品，生命周期最短，问题关闭后即可进入清理流程。
按价值维度判定
同一类型制品在不同场景下价值不同，需要用价值维度做二次判断。对外交付的制品需要覆盖客户支持和合同约定；问题回溯要求保留与已发布版本对应的构建；合规审计要求保留能证明交付内容与审批过程的证据；可重建性则影响期限长短——如果源码、构建脚本和依赖都能稳定重建同一制品，保留期限可以适当缩短，但重建本身也需要被验证过。
分级保留表框架
把判定结果落成一张表，字段固定、口径统一，后续清理规则直接引用这张表。
| 级别 | 典型制品 | 保留期限 | 存储位置 | 责任人 |
|---|---|---|---|---|
| L1 关键交付 | 正式发布版本、对外交付包 | 长期保留，按合同或合规要求设定 | 长期归档库 | 发布负责人 |
| L2 回溯支撑 | 候选版本、发布评审版本 | 发布结论确定后保留一段固定时间 | 常规制品库 | 构建负责人 |
| L3 短期使用 | 每日构建、集成产物 | 按天数或保留最近若干个版本 | 常规制品库 | 构建负责人 |
| L4 临时制品 | 调试包、验证包 | 关联问题关闭后清理 | 临时存储区 | 制品创建人 |
表中的期限区间需要结合团队发布节奏填写。发布频率高的团队，L2 的保留时长可以按版本数设定；发布频率低、单版本影响面大的团队，更适合按时间设定。判定规则要写清楚：一个制品同时满足多个级别时，取最高级别；级别调整必须留下记录。
制定保留策略的五个操作步骤
分级表确定后，策略还需要经过盘点、定口径、定触发条件、定责任和试运行五个步骤，才能从一张表变成可执行的规程。每一步都有明确的输入和产出，完成标志是产出物经过相关角色确认。
步骤一：盘点现有制品来源、数量与占用
输入是现有制品库、构建系统和发布记录。动作是列出制品来源系统、类型分布、总量与增长趋势，识别长期无人访问的制品。输出是一份制品清单和容量基线。完成标志是清单覆盖全部制品来源，容量数据与实际存储对得上。
步骤二：确定分级标准与期限口径
输入是制品清单和业务对回溯、合规的要求。动作是把每个制品类型映射到 L1 至 L4，并为每级选定期限口径：按时间、按版本数或按事件。三种口径各有适用条件，混用会让规则难以执行。
| 期限口径 | 适用条件 | 注意点 |
|---|---|---|
| 按时间 | 发布节奏稳定，合规要求以时间表述 | 需明确起算时点，如构建完成时间或发布时间 |
| 按版本数 | 发布频繁，关注最近若干版本的可用性 | 需定义版本排序规则，避免并列版本无法判断 |
| 按事件 | 制品与问题、合同或下线事件绑定 | 需明确事件关闭的判定人和判定标准 |
输出是分级保留表的正式版本。完成标志是每个制品类型都有唯一级别和唯一期限口径，不存在“视情况而定”这类无法执行的表述。
步骤三：定义清理触发条件与保留例外
输入是分级保留表和期限口径。动作是写明清理的触发方式：定期扫描到期制品、事件关闭后触发、容量达到阈值时触发。同时定义例外情形，例如涉及客户投诉、正在进行的审计、未关闭的严重缺陷对应版本，这些制品在例外解除前不进入清理队列。输出是清理触发规则和例外清单。完成标志是每条规则都能被系统或人工按固定周期判断。
步骤四：明确审批与执行责任
输入是清理规则和例外清单。动作是确定清理清单的生成人、审批人和执行人，约定审批时限和批量清理的节奏。输出是角色职责表和清理操作规程。完成标志是每个环节都有具名角色，不存在无人审批或无人执行的空档。
步骤五：试运行并校准期限与容量
输入是完整策略草案。动作是先在一个项目或一条产品线上试运行一个清理周期，观察清理量、误删风险和容量释放效果，收集回溯需求是否被满足的反馈。输出是试运行报告和策略修订版。完成标志是试运行期间没有出现需要回溯但已被清理的制品，容量释放达到预期，期限设置经相关角色确认。
角色分工与各环节交付物
保留策略涉及定规则、维护数据、执行清理和提出合规要求四类工作，角色不清会导致规则定了没人执行，或者执行了没人负责。下表把角色、职责和交付物对应起来，交接节点以交付物完成确认为准。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 研发负责人 | 确定分级标准与期限口径，批准例外规则 | 分级保留表、例外规则 | 策略评审通过后移交执行角色 |
| 构建/发布负责人 | 维护制品元数据与标签，保证级别可识别 | 制品清单、标签规范 | 每次发布或构建后更新元数据 |
| 运维或平台负责人 | 执行清理、监控容量、记录清理结果 | 清理记录、容量报告 | 每个清理周期结束后提交记录 |
| 质量与合规角色 | 提出审计保留要求，确认证据完整性 | 合规保留要求清单 | 策略制定阶段和审计前确认 |
例外保留需要单独路径：由制品使用方提出申请，说明保留原因和预计解除时间，研发负责人审批，运维角色在执行清理时排除该制品。例外到期后重新评估，未续期的自动回到正常清理流程。审批记录与清理记录一并留存，作为策略执行的证据。
在研发管理平台中承载这套流程时，可以把版本、发布记录和交付物登记为统一管理对象，让制品级别、责任人和状态随发布过程流转。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程关联到需求链路后，出现问题时可以定位影响范围。策略中的分级表、清理操作规程和例外审批记录，也可以作为交付物模板和流程节点沉淀为可复用资产，使规范落到实际项目中执行。制品存储层的自动清理和配额能力需结合具体平台配置确认，策略文本中应写明执行方式。
示例：一条发布制品的保留与清理流程
以下为演示情景，用于说明分级如何随版本状态变化，以及清理判定如何执行。
背景：某产品线计划发布 3.2 版本，从候选构建到正式发布，再到后续下线。制品在制品库中以构建号标识，附带版本号、构建时间、触发人和关联需求范围等元数据。
候选阶段
3.2 的首个候选版本构建完成后，标记为 L2，保留期限设为发布结论确定后 90 天，存放在常规制品库，责任人为构建负责人。后续每个候选版本同样进入 L2，并在元数据中记录对应的测试结论和缺陷修复范围。
正式发布阶段
发布评审通过后，被选中的候选版本升级为 L1，转入长期归档库，保留期限按合同和合规要求设定，责任人转为发布负责人。原候选版本记录保留，级别变更写入变更记录，说明升级时间和审批人。未选中的候选版本维持 L2，等待期限到期。
到期清理判定
清理周期启动时，系统或人工生成到期清单。L2 候选版本到期后进入待清理队列，执行前核对是否存在未关闭的严重缺陷、客户投诉或进行中的审计。存在例外情形的，走例外申请路径并暂停清理；无例外的，由运维角色执行清理并记录清理时间、制品标识、执行人和审批单号。
版本下线阶段
3.2 版本停止支持后，L1 制品是否继续保留取决于合同约定和合规要求。需要保留的转入更长期的归档位置，不再保留的按下线流程审批后清理。清理记录和审批记录留存，作为可回溯证据，确保日后能够说明某个制品在何时、依据什么规则被清理。
整个流程使用的字段包括：制品标识、版本号、级别、期限口径、起算时间、存储位置、责任人、例外状态、清理状态。状态从“在用”到“待清理”再到“已清理”或“例外保留”，每次状态变化都留下操作记录。
完成检查：策略是否可执行
策略文本完成后，用以下清单逐项核对。每一项都应能给出明确答案，无法回答的条目需要回到对应步骤补充。
- 分级覆盖：现有制品类型是否全部映射到某个级别，是否存在无级别制品。
- 期限口径唯一：每个级别是否只有一种期限口径，起算时点是否写明，是否存在无法判断到期时间的表述。
- 清理有审批与回退：清理清单是否经过审批，误删或需要恢复时是否有回退路径和责任人。
- 容量经过验证：是否完成至少一个周期的试运行，容量释放是否符合预期，期限设置是否据此调整。
- 审计与回溯满足：合规角色提出的保留要求是否已纳入分级表，清理记录是否足以支撑回溯说明。
- 责任与时点明确：每个环节是否有具名角色，清理周期、审批时限和例外复评时点是否写明。
清单全部通过后，策略可以进入正式执行。执行过程中建议按固定周期复核一次，重点看例外申请是否集中出现在某一类制品上、容量增长是否偏离试运行预期，据此调整期限或分级，而不是让策略停留在首次制定的版本上。
常见问题
制品保留期限按时间、按版本数还是按事件设定更合适？
三种口径各有适用条件，关键是同一级别只选一种。发布节奏稳定、合规要求以时间表述的团队适合按时间，但要写明起算时点是构建完成时间还是发布时间；发布频繁、更关注最近若干版本可用性的团队适合按版本数，需要先定义版本排序规则；制品与问题、合同或下线事件绑定的场景适合按事件，需要明确事件关闭的判定人和判定标准。混用多种口径会让到期判断变得模糊，清理清单也难以自动生成。
试运行应该跑多久，用什么标准判断策略可以正式执行？
试运行至少覆盖一个完整的清理周期，让到期清单生成、审批、执行和记录留存各环节都实际走一遍。判断标准有三条：试运行期间没有出现需要回溯却已被清理的制品；容量释放量接近预期，说明期限设置与存储增长匹配；例外申请的数量和分布可以解释，没有集中出现在某一类本应正常清理的制品上。三条都满足后，把试运行中的修订写入正式版本再执行。
例外保留申请过多时，应该调整策略还是继续逐条审批？
先看例外集中在哪类制品。如果例外反复出现在同一级别，通常说明该级别的期限或分级标准与实际回溯需求不匹配，应回到分级表调整期限口径或级别归属，而不是长期靠逐条审批维持。如果例外分散、由客户投诉或审计等外部事件触发，保留逐条审批更合适，但要写明预计解除时间和复评时点，避免例外无限期延续。无论哪种情况，例外申请和审批记录都应留存，作为下一轮策略复核的输入。
清理后发现某个制品仍需使用，如何补救？
补救依赖两件事：清理前的审批记录和清理时的制品标识记录。策略中应写明回退路径和责任人，明确从归档位置或备份恢复的操作方式与时限。如果制品可重建，用源码、构建脚本和依赖重新构建并核对结果；如果不可重建且未做备份，则需要在策略复核时把这类制品提升级别或延长保留期限。回退事件本身也应记录，作为期限设置是否合理的判断依据。
制品分级和清理记录在研发管理平台中如何承载？
可以把版本、发布记录和交付物登记为统一管理对象，让制品级别、责任人和状态随发布过程流转。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程关联到需求链路后，出现问题时可以定位影响范围。分级表、清理操作规程和例外审批记录可作为交付物模板和流程节点沉淀为可复用资产。制品存储层的自动清理和配额能力需结合具体平台配置确认，策略文本中应写明执行方式。
