旧系统退役需要把仍在使用的入口、数据和依赖逐项交接清楚，再按阶段关闭。范围清单、六个推进阶段、角色分工和完成证据缺一不可，观察期内没有新的访问需求，才适合正式停服。退役清单与阶段任务可以在ONES工作项和文档中跟踪，具体能力以实际使用版本为准。
要点总览（TL;DR）
- 旧系统退役按“冻结新增—只读保留—数据归档—账号与集成下线—许可与资产处置—观察期关闭”六个阶段推进，每个阶段先确认输入、负责人和完成标志，再进入下一阶段。
- 退役前先做范围清单，覆盖系统本体、数据库与文件存储、定时任务、对外接口、账号与登录入口，并由业务、技术和合规相关方共同确认。
- 账号与集成下线按依赖顺序执行：先停同步任务与定时任务，再关接口与Webhook，最后关闭账号与单点登录，每项留下关闭时间和确认人。
- 退役结束以证据为准：新增数据为零、观察期内无新增访问需求、归档可读可检索、账号与集成关闭有确认记录、许可与资产处置完成、全部记录归档留存。
- 退役范围清单、阶段任务与关闭确认可在ONES工作项和文档中跟踪，阶段推进与证据归档在同一处衔接，具体能力以实际使用版本为准。
退役前先定范围：哪些系统、数据和入口要一起处理
退役范围决定后续所有关停动作的边界。只关闭应用服务器，却留下附件存储、定时任务或对外接口，旧系统往往会在某个下游报表或通知链路里继续运行。范围清单要覆盖系统本体及其周边资产，并由业务、技术和合规相关方共同确认。
清单建议至少包含以下字段：对象名称、对象类型、使用方、依赖方、退役类型、确认人。对象类型可按系统、模块、数据库、文件存储、定时任务、对外接口分类，逐类排查，避免遗漏。
| 盘点对象 | 要回答的问题 | 常见遗漏 |
|---|---|---|
| 系统与模块 | 哪些功能整体下线，哪些仅停止新增使用 | 后台管理入口、移动端页面 |
| 数据库与文件存储 | 哪些数据需要归档，附件存在哪里 | 历史附件、导出文件、临时目录 |
| 定时任务与同步任务 | 任务向哪些系统写入数据，停掉后谁受影响 | 夜间批处理、邮件推送任务 |
| 对外接口与Webhook | 哪些下游系统或报表在调用 | 第三方回调、监控探针 |
| 账号与登录入口 | 哪些账号、用户组、单点登录配置需要关闭 | 服务账号、共享账号 |
使用方与依赖方盘点要落到具体团队和系统。业务团队说明是否还有在用场景，下游系统负责人确认接口调用关系，报表与看板维护人确认数据来源。退役类型需要明确区分整体下线、部分功能下线、仅停止新增使用三种情况，不同类型对应的关停动作和保留范围不同。
范围清单完成后，通过评审或签字方式确认。确认内容至少包括退役对象、退役类型、保留的历史访问范围和计划时间。范围发生变更时重新确认，避免执行阶段临时扩大或缩小关停范围。
核心操作步骤：从冻结新增到正式关闭的六个阶段
退役按“冻结范围—只读保留—数据归档—账号与集成下线—许可与资产处置—观察期关闭”六个阶段推进。每个阶段先确认输入、负责人和完成标志，再进入下一阶段。前一阶段未完成就启动后一阶段，容易出现数据未归档、集成仍在写入的情况。
| 阶段 | 输入 | 主要动作 | 输出与完成标志 |
|---|---|---|---|
| 一、冻结新增 | 已确认的范围清单 | 停止新增数据与新建项目，在旧系统入口和常用沟通渠道公告替代系统入口 | 新增数据为零，公告已发出并被目标用户知悉 |
| 二、只读保留 | 冻结完成记录 | 旧系统转为查询状态，保留必要的历史访问 | 系统只能查询，写入入口已关闭 |
| 三、数据归档 | 归档范围与保留期限要求 | 确定归档范围、格式、保存位置与保留期限，执行导出并验证 | 归档文件可读可检索，抽样验证通过 |
| 四、账号与集成下线 | 集成清单与账号清单 | 先停同步任务与定时任务，再关接口与Webhook，最后关闭账号与单点登录 | 各入口关闭并有确认记录 |
| 五、许可与资产处置 | 合同、许可与资产台账 | 处理合同、许可、服务器与域名 | 处置完成，费用与资产状态更新 |
| 六、观察期与关闭 | 前五阶段完成记录 | 设定观察时长，记录并处理遗留访问需求，确认无新增访问后正式停服 | 观察期结束，关闭确认已归档 |
冻结阶段的关键是让用户知道去哪里继续工作。公告内容应写明替代系统入口、旧系统停止新增的时间、历史数据查询方式和联系人。只读阶段保留必要的查询能力，可以缓解用户突然失去历史数据的焦虑，也为归档验证留出时间。
归档阶段先确定归档范围，再选择格式和保存位置。归档结果要用抽样打开历史记录的方式验证可读性，确认附件、关联关系和关键字段都能正常查看。保留期限结合组织制度和合规要求确定，并在归档记录中写明。
集成下线按依赖顺序执行：先停同步任务与定时任务，再关接口与Webhook，最后关闭账号与单点登录。这个顺序可以避免残留任务反复写入或持续报错。每关闭一项，记录关闭时间和确认人。
观察期长度按系统影响面设定，影响面大的系统留出更长时间。观察期内记录每一次遗留访问需求，逐项判断是引导到替代系统还是补充归档，确认没有新的访问需求后再正式停服。
角色与交付物：谁签字、谁执行、谁验收
退役涉及多个角色，每个交付物都要有明确的提交人和验收人。责任不清时，关停动作容易停在“已经通知”这一步，缺少可核验的完成记录。
| 角色 | 交付物 | 验收人 |
|---|---|---|
| 系统负责人 | 退役范围清单、退役计划与时间表 | 业务代表与运维负责人 |
| 数据负责人 | 归档范围说明、归档结果、可读性验证记录 | 系统负责人与合规或信息安全角色 |
| 运维负责人 | 账号、集成、服务器与域名下线记录 | 系统负责人 |
| 业务代表 | 无在用场景确认、观察期反馈记录 | 系统负责人 |
| 合规或信息安全角色 | 保留期限与数据处置确认 | 系统负责人 |
系统负责人对整体节奏负责，维护范围清单和阶段计划，协调各角色按顺序交付。数据负责人对归档结果负责，确保归档范围覆盖范围清单中的数据对象，并完成抽样验证。运维负责人执行账号、集成、服务器与域名的下线动作，逐项留下确认记录。
业务代表确认没有仍在使用的业务场景，并在观察期内反馈遗留访问需求。合规或信息安全角色确认保留期限和数据处置方式符合组织要求。验收人检查交付物是否完整、证据是否可查，确认后才允许进入下一阶段。
退役范围清单、阶段任务与关闭确认可以在ONES工作项和文档中跟踪：范围清单作为文档沉淀，各阶段任务拆成工作项并指定负责人，关闭确认作为验收记录留存。这样阶段推进和证据归档在同一处衔接，便于后续审计和复盘。
示例：一个内部缺陷跟踪系统退役的推进过程
以下为演示情景，用于说明阶段衔接和判断点，不代表真实项目数据。某团队将内部缺陷跟踪系统替换为新平台，计划用数周完成退役。
范围清单列出：缺陷跟踪系统本体、附件存储、邮件通知服务、与代码库的关联接口，以及若干服务账号和单点登录配置。使用方包括研发团队、测试团队和两个依赖缺陷数据生成质量报表的下游看板。退役类型为整体下线，历史缺陷记录保留只读查询一段时间后归档。
冻结阶段在旧系统首页和团队沟通渠道发布公告，写明新平台入口、旧系统停止新增缺陷的时间、历史查询方式和联系人。冻结完成后新增缺陷数为零，新建项目入口关闭。只读阶段将系统切换为查询状态，用户仍可查看历史缺陷和附件。
归档阶段确定归档范围为缺陷记录、评论、附件和状态变更历史，导出后抽样打开若干历史记录，确认附件可下载、关联关系可查看。集成下线按顺序执行：先停与代码库的同步任务和邮件通知任务，再关闭对外接口，最后关闭服务账号和单点登录配置。每步记录关闭时间和确认人。
观察期内收到两次历史查询需求，均引导至归档数据查询方式处理。观察期结束后确认无新增访问需求，正式停服，并将公告、范围清单、归档记录和关闭确认统一归档。常见卡点包括：下游看板未提前通知导致报表中断、附件存储位置遗漏、共享账号无人认领，这些都需要在范围盘点阶段提前排查。
完成检查：退役可以宣布结束的判断标准
退役结束以证据为准，不以“系统已关闭”一句话作为结论。逐项检查以下内容，全部满足后再宣布退役完成。
| 检查项 | 完成标准 | 证据 | 负责人 |
|---|---|---|---|
| 新增数据 | 冻结后新增数据为零 | 冻结记录与系统状态截图或日志 | 系统负责人 |
| 只读访问 | 观察期内无新增访问需求 | 观察期访问与需求记录 | 业务代表 |
| 归档数据 | 可读、可检索，保存位置与保留期限有记录 | 归档清单与抽样验证记录 | 数据负责人 |
| 账号与集成 | 账号、接口、同步任务、单点登录全部关闭 | 逐项关闭确认记录 | 运维负责人 |
| 许可与资产 | 合同、许可、服务器与域名处置完成 | 处置记录与资产台账更新 | 运维负责人 |
| 记录留存 | 退役公告、范围清单、归档记录与关闭确认归档留存 | 归档目录与索引 | 系统负责人 |
检查时重点核对证据与检查项是否对应。归档数据不仅要有导出文件，还要有可读性验证记录；账号与集成关闭不仅要有操作记录，还要有确认人签字或系统状态证明。发现缺项时回到对应阶段补齐，再重新验收。
全部检查项通过后，发布退役完成通知，说明历史数据查询方式和后续联系人。退役记录归档留存，为后续系统审计、合规检查和同类项目复盘提供依据。
常见问题
旧系统冻结新增后，还有用户坚持要用旧入口，怎么处理？
冻结阶段的目标是停止新增数据与新建项目，历史查询能力在只读阶段仍然保留。遇到用户坚持使用旧入口，先确认其真实需求属于哪一类：如果是查历史记录，引导到只读查询或归档查询方式；如果是要继续录入新数据，说明替代系统入口和迁移安排，并记录该需求。
观察期内每一次遗留访问需求都逐项记录，判断是引导到替代系统还是补充归档。反复出现的需求说明公告或替代入口引导不到位，需要补充说明，而不是直接恢复旧系统写入。
观察期应该设多长，有没有统一标准？
观察期长度按系统影响面设定，影响面大的系统留出更长时间。资料没有给出统一数值，也不宜套用固定天数。判断依据可以包括：使用方数量、是否有下游报表或接口依赖、历史数据查询频率、替代系统的上手情况。
观察期内记录每一次遗留访问需求并逐项处理，确认没有新的访问需求后再正式停服。观察期长度和判断依据写进退役计划，便于后续复盘。
归档数据保存多久，到期后怎么处置？
保留期限结合组织制度和合规要求确定，并在归档记录中写明。不同数据对象可能有不同要求，缺陷记录、附件、状态变更历史的保留期限未必一致，归档范围说明里应逐类标注。
到期处置方式同样需要合规或信息安全角色确认，处置动作留下记录。保留期限和处置方式属于组织自定参数，本文不给出固定年限。
下游报表因为旧系统接口关闭而中断，退役前怎么预防？
预防动作放在范围盘点阶段：对外接口与Webhook逐项列出调用方，报表与看板维护人确认数据来源和调用关系。依赖方确认后，在冻结公告中同步告知接口关闭计划，给下游留出改造时间。
集成下线按顺序执行，先停同步任务与定时任务，再关接口与Webhook。关闭前再次通知调用方，关闭后记录关闭时间和确认人，出现中断时能快速定位是哪个接口导致。
退役完成后，相关记录要保留哪些、放在哪里？
退役公告、范围清单、归档记录与关闭确认需要归档留存，形成归档目录与索引，为后续系统审计、合规检查和同类项目复盘提供依据。检查时核对证据与检查项是否对应，例如归档数据不仅要有导出文件，还要有可读性验证记录。
记录可以统一存放在团队文档或工作项中，按系统名称和退役时间建立索引，方便后续检索。
