旧系统退役检查清单要回答的核心问题是“能否安全停用”。一份可直接用于评审和执行的清单，应同时覆盖三类内容：需要拍板的决策项、支撑决策的证据项，以及判断能否放行的退出条件。使用对象通常包括系统负责人、业务负责人、运维与安全、数据管理以及采购或合同归口；检查时点分布在退役决策评审、停用前准备、停用执行日和停用后观察期。本文只处理停用判定与放行，迁移切换窗口内的执行细节另行管理。退役过程中的检查项跟踪、证据留存与审批记录，可以借助ONES这类研发管理工具承接。
要点总览（TL;DR）
- 退役清单围绕“能否安全停用”组织，同时覆盖决策项、证据项和退出条件三类内容，使用对象包括系统负责人、业务负责人、运维与安全、数据管理及合同归口。
- 检查时点分四段：退役决策评审、停用前准备、停用执行日、停用后观察期，每个时点明确发起人和签字确认人。
- 六项决策必须有书面结论和决策人：停用范围与日期、数据处置、账号权限、集成接口、合同许可、回退窗口与回退决策人。
- 每项决策配可核验证据，如迁移核对单、访问日志、下游确认函、通知回执和结算凭证，证据写明留存位置与负责人。
- 阻断项未关闭不得停用；整体完成条件是全部阻断项关闭，非阻断项有遗留处理计划、责任人和完成时点。
谁在什么时点使用这份退役清单
退役清单需要先定人和时点，否则检查项容易停留在文档里无人推进。建议明确一名退役事项的总负责人（通常由系统负责人担任），由他发起各时点检查并汇总结论；业务负责人确认替代路径与用户影响；运维与安全负责账号、入口与访问控制；数据管理负责数据处置与核对；采购或合同归口负责合同结算与许可退订。
四个检查时点各有不同的输入和输出。退役决策评审会上，各角色对决策项给出结论并签字；停用前准备阶段，由系统负责人组织证据收集，业务与数据角色完成核对；停用执行日，运维执行账号回收与入口下线，系统负责人确认执行结果；停用后观察期内，业务负责人收集求助与异常上报，系统负责人做收尾判定并归档清单。
| 角色 | 决策评审 | 停用前准备 | 停用执行日 | 观察期 |
|---|---|---|---|---|
| 系统负责人 | 发起评审、汇总决策结论 | 组织证据收集、跟踪阻断项 | 确认执行结果 | 收尾判定、清单归档 |
| 业务负责人 | 确认停用范围与日期 | 确认活跃用户与替代路径 | — | 处理求助与业务异常 |
| 运维/安全 | 评估入口与账号处置方案 | 整理访问日志、依赖清单 | 回收账号、下线入口 | 监控异常访问 |
| 数据管理 | 确定数据处置方式 | 完成迁移核对与归档校验 | 确认只读或归档可访问 | — |
| 采购/合同归口 | 确认合同处置结论 | 准备结算或退订凭证 | — | — |
需要划清的边界是：本清单判断“能不能停”，不负责“新系统怎么切”。迁移切换的批次安排、回滚演练、数据同步频率等属于切换执行范畴，可在切换管理文档中单独维护，退役清单只引用其结论作为证据。
决策项：停用前必须拍板的六件事
决策项的特征是必须有明确结论和决策人，不能以“待定”“后续再看”通过评审。以下六项建议逐项形成书面结论，并写明截止时点。
| 决策项 | 可选结论 | 决策人 | 截止时点 |
|---|---|---|---|
| 是否停用、停用范围与停用日期 | 全量停用／分模块停用（列明模块）／暂不停用；确定具体日期 | 业务负责人与系统负责人共同确认 | 决策评审会结束前 |
| 历史数据处置方式 | 全量归档／迁移至新系统／只读保留／按合规要求销毁 | 数据管理负责人 | 停用前准备阶段开始前 |
| 账号与权限处置 | 全部停用／回收并保留审计账号／按名单保留只读账号 | 运维或安全负责人 | 停用执行日前 |
| 集成与接口处置 | 确认下游依赖清单，逐项解耦或切换至新接口 | 系统负责人与下游系统负责人 | 停用前准备阶段结束前 |
| 合同与许可处置 | 到期不续／提前退订／按合同结算 | 采购或合同归口 | 停用执行日前 |
| 回退窗口与回退决策人 | 设定窗口长度（如停用后若干工作日），指定唯一回退决策人 | 业务负责人指定 | 决策评审会结束前 |
分模块停用的情况要特别写明：哪些模块先停、哪些模块保留、保留模块的维护责任人和预计停用时间。回退窗口的长度取决于业务节奏与数据变更频率，窗口内应保持旧系统可恢复所需的最小环境，窗口到期后由回退决策人书面确认不再回退。
证据项：每项决策要拿什么来证明
证据项的作用是把口头确认变成可复核的材料。每类决策对应一组证据，证据应写明留存位置和负责人，评审时按清单逐项查验。
| 检查项 | 证据材料 | 留存位置 | 负责人 |
|---|---|---|---|
| 数据处置 | 导出记录、迁移前后条数对比、抽样核对单、归档位置与校验值 | 数据管理目录或项目文档库 | 数据管理负责人 |
| 实际使用情况 | 近一个周期的访问日志、活跃用户清单、活跃项目清单 | 运维日志系统 | 运维负责人 |
| 下游依赖 | 接口调用记录、下游系统确认函或解耦完成说明 | 系统集成文档 | 系统负责人 |
| 用户通知 | 通知回执、替代路径说明的签收记录、培训签到 | 业务部门存档 | 业务负责人 |
| 合同处置 | 合同到期日摘录、结算单或退订凭证 | 采购或财务存档 | 合同归口 |
证据的充分性按“能否支持结论”判断。例如访问日志要能说明检查周期内没有活跃业务操作，而不只是某一天无人登录；迁移核对单要包含条数比对和关键字段抽样，而不只是导出成功提示。通知证据要覆盖全部活跃用户名单，名单本身也应作为附件留存。
分阶段检查项与通过标准
把决策项和证据项按四个时点排成检查表，每项写成可判断的完成状态。以下为各阶段的检查重点与通过标准示例。
决策评审阶段
- 六项决策均有书面结论，通过标准：每项决策表中有结论、决策人和日期，无“待定”项。
- 停用范围与日期已明确，通过标准：范围描述到模块级，日期精确到日。
- 回退窗口与回退决策人已指定，通过标准：窗口长度有具体数值，决策人为具体人员。
停用前准备阶段
- 数据核对完成，通过标准：迁移前后条数一致或差异有说明，抽样核对单签字。
- 依赖解耦完成，通过标准：下游依赖清单中每项标注“已解耦”或“已切换”，并有对应确认记录。
- 通知覆盖全部活跃用户，通过标准：通知回执数量与活跃用户名单一致，缺口有补通知记录。
- 合同处置就绪，通过标准：结算或退订凭证已取得，或到期日早于停用日。
停用执行日
- 账号回收完成，通过标准：账号清单逐项标注停用或保留，保留项有审批记录。
- 入口下线完成，通过标准：登录入口、API 入口均不可访问，验证记录留存。
- 只读或归档可访问，通过标准：按数据处置结论完成验证，访问方式已告知相关方。
停用后观察期
- 无未处理求助，通过标准：观察期内登记的求助全部关闭或有明确处理计划。
- 无业务中断上报，通过标准：业务负责人书面确认观察期内无因停用导致的中断。
- 回退窗口到期确认，通过标准：回退决策人书面确认不再回退，旧系统恢复环境按计划释放。
阻断项与完成条件
阻断项是“未关闭即不得停用”的检查项，需要在清单中单独标记，并在停用执行日前逐项确认关闭证据和关闭人。常见阻断项包括：关键数据未完成核对或差异未说明；存在活跃下游依赖且未解耦；回退方案失效（如恢复环境已释放、备份不可用）；合同未结算或退订未完成；活跃用户未确认替代路径。
| 阻断项 | 关闭证据 | 关闭人 |
|---|---|---|
| 关键数据未核对 | 签字确认的核对单，差异项有处理结论 | 数据管理负责人 |
| 存在活跃下游依赖 | 下游系统确认函或解耦完成记录 | 系统负责人 |
| 回退方案失效 | 回退环境可用性验证记录 | 运维负责人 |
| 合同未结算 | 结算单或退订凭证 | 合同归口 |
| 活跃用户未确认替代路径 | 用户签收记录或补通知回执 | 业务负责人 |
整体完成条件分两层：全部阻断项关闭，且非阻断项即使未完成也已有明确的遗留处理计划、责任人和完成时点。停用执行日当天，由系统负责人对照阻断项清单做放行确认；观察期结束后，由系统负责人做收尾判定，确认回退窗口到期、求助清零、归档完成，并将清单、证据和审批记录一并归档，作为本次退役的可追溯记录。
用ONES承接退役过程的记录与交接
清单执行中的主要管理动作是跟踪、留证和审批。可以把每个检查项建成一个工作项，填写负责人、截止时点和当前状态，阻断项单独标记，评审时按状态筛选未关闭项。证据材料以附件或文档形式关联到对应检查项，避免材料散落在个人目录。决策评审与停用放行可以走评审流程，保留各角色的签字记录；观察期内出现的求助和异常同样以工作项登记，跟踪至关闭。这样退役结束后，检查项、证据、审批和问题处理形成一条可追溯的记录链，便于交接和后续审计。
常见问题
停用范围只涉及部分模块时，清单要怎么调整？
分模块停用需要在决策项中把范围描述到模块级，列明先停模块、保留模块和保留模块的维护责任人及预计停用时间。证据项相应收窄：访问日志和活跃用户清单按保留模块单独统计，确认保留模块仍有业务使用时，其账号、接口和合同处置结论单独记录。阻断项判定也按模块分别进行，先停模块的阻断项关闭即可放行该模块，保留模块继续按原清单跟踪。
回退窗口设多长比较合适，到期后还要做什么？
窗口长度取决于业务节奏和数据变更频率，没有统一数值，常见做法是覆盖一个完整的业务周期（如若干工作日），并在决策评审会上确定具体天数。窗口内应保持旧系统可恢复所需的最小环境，包括备份可用和恢复路径验证。窗口到期后由回退决策人书面确认不再回退，运维再按计划释放恢复环境，这一步的确认记录要归入退役档案。
观察期内又出现业务求助，是否要重新打开退役流程？
不必整体重开，但要区分问题性质。若求助属于使用习惯或替代路径不清晰，由业务负责人补充说明和培训即可关闭；若出现数据缺失、下游接口中断等影响业务的问题，应作为阻断项重新评估，必要时启动回退并在清单中记录处理过程。观察期收尾判定以求助全部关闭或有明确处理计划为前提，未关闭项要写明责任人和完成时点。
证据材料由谁保管，退役结束后留存多久？
证据按类别由对应负责人保管：数据类在数据管理目录，日志类在运维日志系统，合同类在采购或财务存档，通知类在业务部门。退役结束后，建议把清单、证据和审批记录集中归档到统一位置，形成一条可追溯的记录链。留存期限受行业合规和审计要求影响，各组织口径不同，需按自身规定确认，本文不给出统一期限。
决策评审会上有决策项暂时无法定论，能否先停用再补？
不建议。决策项要求每项有结论、决策人和日期，出现“待定”项时应暂缓放行，或将其明确列为阻断项并指定关闭时点。确实需要分步推进的，可以把该决策项关联的模块从本次停用范围中拆出，先停用已定论部分，未定论部分继续跟踪。这样停用执行日的放行确认才有依据，避免停用后因决策缺失返工。
