制品保留策略要解决的是“该留的留得住、该清的清得掉、每次处理有据可查”。落地路径分四步：先盘点需要纳入范围的制品，再按发布状态与业务影响分级并定下保留期限，把规则写进构建、发布与仓库管理动作，最后用检查清单定期验证。本文按这四步展开，并给出规则表、角色分工和一个版本的完整执行示例。
要点总览（TL;DR）
- 制品保留策略按四步落地：盘点制品范围、按发布状态与业务影响分级定规则、把规则写进构建与仓库动作、用检查清单定期验证。
- 盘点要覆盖构建产物、发布包、交付文档以及版本标识与来源信息，并区分可重建与不可重建制品，后者应给予更长保留期和更多副本。
- 分级规则表至少包含等级、判定条件、保留期、存储与副本、到期动作、审批人六列；低等级制品可自动清理，正式发布与客户交付制品采用到期提醒加人工复核。
- 策略负责人、构建发布负责人、仓库管理员、交付负责人与审计角色各有明确交付物，清理与延长保留都要留痕，例外审批单本身也是审计材料。
- 判断策略是否生效看三点：关键制品可取回且完整、过期制品按规则处理、每次保留或删除都有记录可查；出现新制品类型或合规要求变化时触发规则修订。
先盘点：哪些制品需要纳入保留范围
盘点的目的是把“制品”从模糊概念变成一份可核对的清单。范围通常包括四类对象：构建产物（编译生成的二进制、镜像、依赖包）、发布包（对外或对客户交付的安装包、补丁包）、交付文档（发布说明、部署手册、验收材料、合规证据）、以及把这些串起来的版本标识与来源信息（版本号、构建号、提交记录、构建时间、构建人）。版本标识本身不是制品，但缺少它，制品就无法被准确定位和取回，因此要作为每条记录的必备字段。
盘点时逐项记录以下字段，形成制品盘点表：
| 字段 | 填写要求 |
|---|---|
| 制品名称 | 与仓库或交付清单中的名称一致，避免别名 |
| 制品类型 | 构建产物 / 发布包 / 交付文档 / 其他 |
| 版本 | 版本号或构建号，能唯一定位 |
| 来源 | 来源构建任务或代码提交，便于重建与追溯 |
| 存放位置 | 仓库地址、目录或文档库路径 |
| 大小 | 用于评估存储成本与清理收益 |
| 关联发布 | 所属版本、发布批次或客户交付单 |
| 可重建性 | 可由源码与构建环境重新生成，或不可重建 |
盘点做法上，先按仓库和交付渠道各拉一次全量清单，再与发布记录比对，找出“有发布记录但找不到制品”和“有制品但说不清来源”的两类缺口。可重建制品与不可重建制品的区分要在盘点阶段就标注清楚：前者在源码、构建脚本和依赖版本都具备时可重新生成，保留压力较小；后者如手工制作的交付文档、外部提供的签名包、特定环境下的构建结果，一旦丢失难以复原，后续分级时应给予更长的保留期和更多副本。
分级与规则：保留期限怎么定
分级的依据是发布状态与业务影响，而不是制品体积或生成时间。一个常用的四级划分是：正式发布（面向生产环境或公开版本）、客户交付（按合同或验收要求提交给特定客户）、内部测试（测试与预发环境使用）、临时构建（开发过程中的中间产物）。等级越高，保留期越长、副本越多、审批越严。
下表可作为规则表的填写模板，具体期限需结合行业合规要求与企业实际确定，表中数值仅为示例口径：
| 等级 | 判定条件 | 保留期（示例） | 存储与副本 | 到期动作 | 审批人 |
|---|---|---|---|---|---|
| L1 正式发布 | 已发布至生产或对外公开 | 长期，不少于产品生命周期 | 主仓库加异地备份 | 到期前复核，默认延长 | 发布负责人 |
| L2 客户交付 | 按合同或验收单交付客户 | 按合同约定，无约定时不少于交付后若干年 | 主仓库加独立归档副本 | 到期复核后清理或延长 | 交付负责人与合规负责人 |
| L3 内部测试 | 仅用于测试、预发环境 | 覆盖当前与上一版本测试周期 | 主仓库单副本 | 自动清理，保留最近若干份 | 测试负责人 |
| L4 临时构建 | 开发中间产物，无发布关联 | 短期，如数天至数周 | 主仓库单副本 | 自动清理 | 构建发起人 |
两类制品需要特殊考虑。不可重建制品即使等级不高，也应至少保留到确认不再需要为止，并在规则表中单独标注；与合规、审计、客户争议相关的制品，保留期以外部要求为准，规则表中写明依据来源，避免凭经验设定。规则表还应留一列“例外说明”，记录个别制品被单独调整期限的理由，便于后续复核时解释差异。
把规则落到流程：标记、自动化清理与例外审批
规则只有进入流水线和仓库动作才会被执行。第一步是在制品生成时打标：构建任务根据发布渠道自动写入等级与保留期，例如进入正式发布流水线的制品标记为 L1，合并请求触发的临时构建标记为 L4。标记应随制品元数据一起存储，而不是记在某个人的表格里，这样清理任务才能按标记批量处理。
第二步是明确到期处理的分工。L3、L4 这类低等级制品适合自动清理，由定时任务扫描到期制品并执行删除，删除前输出待清理清单；L1、L2 采用到期提醒加人工复核，系统在到期前若干天通知责任人，责任人确认后执行清理或发起延长。自动清理与人工复核的边界要写进规则，避免高等级制品被自动任务误删。
第三步是例外审批。需要延长保留时，由制品责任人提交申请，写明制品标识、当前等级、申请延长的期限与理由，经规则表指定的审批人确认后更新标记，并在记录中保留原到期日与新到期日。例外记录本身也是审计材料，不能只改标记不留痕。
第四步是清理前的完整性校验与回滚准备。删除前核对制品是否仍被某个发布记录或交付单引用，校验文件大小与摘要是否与登记一致；对可能被重新需要的制品，先确认可从源码重建或已有归档副本，再执行删除。清理动作应支持按批次回退，至少在删除后保留一段观察期，发现误删时能够恢复。
在制品与发布、交付记录的关联管理上，ONES 覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，可支撑交付结果回溯；测试用例、缺陷、版本和发布过程也能关联到需求链路中。团队可以把制品的等级标记、到期复核任务和例外审批单作为工作项纳入同一套流程管理，让保留动作与发布记录保持对应。制品仓库层面的保留期限设置与自动清理需结合所选仓库工具实现。
角色与交付物：谁维护策略、谁执行清理
保留策略要长期运转，需要把“定规则”和“做动作”分开落实到人。策略负责人对规则表的正确性负责，构建发布负责人保证制品生成时标记准确，仓库管理员执行清理并核对清单，审计或质量角色抽查记录完整性。
| 角色 | 主要职责 | 交付物 | 复核节奏 |
|---|---|---|---|
| 策略负责人 | 制定与修订分级规则，裁定例外争议 | 规则表、修订记录 | 每季度或发布流程变更时 |
| 构建发布负责人 | 在流水线中写入等级与保留期标记 | 标记配置、构建记录 | 每次流水线变更时 |
| 仓库管理员 | 执行到期清理，核对待清理清单 | 清理记录、删除批次日志 | 每次清理后 |
| 交付负责人 | 确认客户交付制品的保留要求 | 交付清单、延长申请 | 每个交付批次 |
| 审计或质量角色 | 抽查制品可取回性与记录完整性 | 抽查报告、问题清单 | 每半年或审计前 |
交接点主要在两处：制品从构建环节进入仓库时，标记信息随制品一并移交；制品到期进入复核时，责任从仓库管理员转给制品责任人确认。定期复核建议与发布节奏对齐，每次大版本发布后检查一次规则表是否仍匹配当前制品类型，避免规则停留在旧流程上。
示例：一个版本的制品从发布到到期清理
以下为演示情景。某产品发布 3.2 版本，构建流水线生成安装包、镜像与发布说明文档。安装包与镜像进入正式发布渠道，按规则判定为 L1，流水线自动写入等级与保留期标记，并在发布记录中登记版本号、构建号与来源提交；发布说明文档随交付单提交给客户，判定为 L2，同时生成一份归档副本。测试阶段产生的若干临时构建标记为 L4，保留期设为两周。
保留期内，客户反馈安装问题，支持人员按版本号在仓库中检索到对应安装包，核对文件摘要与登记一致后提供给客户排查；审计人员抽查时，通过发布记录回溯到该版本的构建来源与关联需求，确认制品与记录能够对应。
两周后，L4 临时构建到期，定时任务输出待清理清单，仓库管理员核对无发布记录引用后执行删除，清理记录中登记批次、数量与执行时间。数月后 L2 交付文档到达约定保留期，系统提前通知交付负责人，负责人确认客户合同已履约完毕、无争议，提交清理申请并经合规负责人确认后删除归档副本；同一批次中另一客户的交付文档因合同约定保留期更长，提交延长申请，审批通过后更新标记并保留原到期日与新到期日。整个过程产生的记录包括：标记配置、发布记录、取用核对记录、清理批次日志、延长审批单。
完成检查：策略是否真正生效
判断策略是否有效，看三件事：关键制品在需要时能取到且完整，过期制品按规则被处理而非靠人记忆，每次保留或删除都有记录可查。以下清单可逐项核对：
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 关键制品可取回 | 随机抽取若干正式发布与客户交付制品，按版本号检索并下载 | 全部可定位，文件摘要与登记一致 |
| 来源可追溯 | 从制品反查构建记录与关联发布 | 能对应到具体构建与发布批次 |
| 过期制品已处理 | 比对到期清单与实际库存 | 无长期滞留的过期制品，无误删高等级制品 |
| 例外审批齐全 | 抽查延长保留的制品 | 每笔延长均有申请、审批人与新旧到期日 |
| 清理记录完整 | 核对清理批次日志与执行时间 | 每次删除可追溯到执行人与批次 |
| 规则与现状一致 | 对照当前制品类型与发布流程检查规则表 | 无规则未覆盖的新制品类型 |
出现以下情况时应触发规则修订：新增了规则表未覆盖的制品类型，发布流程调整导致标记写入位置变化，外部合规要求更新了保留期限，或者抽查中发现同一问题重复出现。修订后同步更新规则表版本与标记配置，并通知相关角色，确保执行动作与规则保持一致。
常见问题
可重建制品是否可以缩短保留期，甚至不保留？
可重建制品在源码、构建脚本和依赖版本都完整具备时，保留压力较小，可以设置较短的保留期。但“可重建”本身需要条件：构建环境、依赖版本和构建参数都要能复原，否则重建结果可能与原制品不一致。建议对可重建制品保留最近若干份，并确保重建所需信息随制品登记；对不可重建制品，如手工制作的交付文档、外部提供的签名包、特定环境下的构建结果，即使等级不高也应保留到确认不再需要为止。
自动清理误删了高等级制品，应该怎么处理？
先按清理批次日志定位删除范围，确认是否有归档副本或可从源码重建，尽快恢复。事后要检查两处：自动清理任务的扫描条件是否把高等级制品纳入范围，以及制品生成时的等级标记是否准确写入。规则上应明确自动清理只处理低等级制品，高等级制品走到期提醒加人工复核；删除动作支持按批次回退，并保留一段观察期。若同一问题重复出现，应触发规则修订并同步更新标记配置。
客户合同没有约定交付制品的保留期限，该怎么定？
合同无约定时，规则表应给出一个默认下限，例如交付后不少于若干年，具体年限结合行业合规要求与企业实际确定。同时记录判定依据，便于后续复核时解释。若客户后续提出争议或审计需求，可在到期复核时提交延长申请，写明制品标识、当前等级、延长理由与新到期日，经审批人确认后更新标记并保留原到期日。默认期限不宜凭经验随意设定，应写明来源。
制品保留策略多久复核一次比较合适？
建议与发布节奏对齐：每次大版本发布后检查一次规则表是否仍匹配当前制品类型，策略负责人每季度或发布流程变更时复核一次分级规则。审计或质量角色可每半年抽查一次制品可取回性与记录完整性。出现新增制品类型、发布流程调整、外部合规要求更新，或抽查中同一问题重复出现时，应随时触发修订，不必等到固定周期。
制品等级标记应该记在哪里，才能被清理任务用上？
标记应随制品元数据一起存储，由构建任务在制品生成时自动写入，例如进入正式发布流水线的制品标记为 L1，合并请求触发的临时构建标记为 L4。记在个人表格里的标记无法被定时任务批量读取，也难以在交接时保持准确。标记写入位置要与发布流程绑定，流水线调整时同步更新标记配置，避免规则与执行脱节。
