软件项目开发全流程 · 第 33 课 · 生命期结束：下线与归档

1、为什么要"体面地"送走一个系统

从第 1 课到现在，我们走完了一个软件的整条生命线：立项 → 需求 → 设计 → 开发 → 测试 → 交付 → 运维 → 维护。而每一条生命线都有终点。

终点的形式有很多：

• 被新系统取代（重构重写、架构升级）；
• 业务被砍掉（战略调整、产品合并）；
• 技术被淘汰（框架停止维护、平台关停）;
• 干脆是寿终正寝（完成了历史使命）。

很多团队的失败，不是失败在"上线"，而是失败在"下线"：

下线一个系统，比上线它更需要纪律。

因为下线意味着：停服务、搬数据、通知用户、保存历史、安置团队——每一步都关乎别人的利益和公司的合规。草率下线会带来用户投诉、数据丢失、法律风险，甚至是"死了但没死透"的僵尸系统。

本课讲的就是：如何体面地、安全地、合规地送走一个系统。

2、下线评估：什么时候该说再见

下线不是一个拍脑袋的决定。先做下线评估（Decommission Assessment），回答四个问题：

一个实用的工具：使用者盘点（User/Consumer Inventory）。

• 谁在调用这个 API？（查网关日志、审计日志）
• 哪些数据只存在这个系统里？
• 有没有对外承诺（合同、SLA）还没到期？

⚠️ 最常见的下线事故：漏了一个"隐藏调用方"。 你以为没人用了，关掉服务，结果某个内部报表、某个老 App 的定时任务还在调它。先测量，再决定。

下线的三种模式：

• 硬切换：某个时间点直接关停（适合内部、无外部依赖的系统）。
• 渐进式：逐步缩小范围，观察反应（适合用户多的系统）。
• 并行运行：新旧系统同时跑一段，确认无误再关旧（最安全，也最贵）。

3、数据迁移：把有价值的"搬家"

系统可以死，数据不能丢。下线时最关键的工程动作就是数据迁移（Data Migration）——把老系统的数据搬到新系统、归档库或冷存储。

数据迁移的黄金四步（这跟第 34 课的思路一致）：

1. 盘点（有什么数据、多大量、什么格式、被谁用）
2. 映射（旧字段 → 新字段，哪些丢弃、哪些合并、哪些转换）
3. 演练（在测试环境跑一遍，记录耗时与错误）
4. 迁移 + 校验（正式迁移后，逐条核对：数量、总金额、抽样一致性）

关键纪律：

• 绝不"边删边迁"：迁移完成并校验通过前，原数据必须原样保留。
• 可回滚：迁移前做好快照，发现不对能退回去。
• 有对账：迁移后做数据一致性校验（有多少条？关键字段对不对？），出具报告。
• 注意关联：数据库、文件存储、缓存、搜索索引可能都要迁，别漏。

数据迁移的经典事故：字段映射搞错（日期格式、编码），导致新系统数据"看起来对、其实全乱"。必须抽样人工核对。

4、数据销毁：合规的"抹掉"

数据不只是"搬走"，还有一部分必须彻底销毁（Data Destruction）——因为它涉及用户隐私或已过留存期限，留着本身就是合规风险（呼应第 32 课的"最小必要"与"可删除"）。

哪些要销毁：

• 用户明确要求删除的个人数据；
• 超过法定/约定留存期限的数据；
• 与业务无关、当年"顺手收集"的冗余数据。

怎么"真删干净"：

• 数据库：执行删除，并确认备份、副本、缓存、日志里也一并清理。
• 文件/对象存储：删除对象，注意版本控制/回收站里的副本。
• 物理介质：报废硬盘要做消磁或物理粉碎，不能只是"格式化"。
• 销毁记录：留一份销毁证明（谁、何时、销毁了哪些数据），以备审计。

⚠️ "删了数据库 = 数据没了"是错觉。备份里的副本、日志里的明文、缓存里的残留，都可能让"已删除"的数据复活。销毁要覆盖全链路。

5、用户沟通：通知、导出、缓冲期

技术做完了，还有一关最重要：人。

一个体面的下线，沟通节奏大致是：

1. 提前公告（越早越好，给足缓冲期，比如 3~6 个月）：说明为什么下线、什么时候关、替代方案是什么。
2. 提供数据导出：在关停前，让用户能把自己的数据带走（这是合规要求，也是善意）。
3. 多轮提醒：临近截止前，通过邮件、站内信、公告反复提醒（"倒计时"）。
4. 明确关停日与后果：说清楚关停后会发生什么、数据如何处理。
5. 保留一段"只读期"：关停写操作，但允许短期查询/导出，给用户最后一班车。
6. 正式关停后：给出最终说明，提供联系方式处理遗留问题。

💡 用户的痛点不是"你下线"，而是"你悄悄下线，还让我措手不及"。 尊重用户，就是提前、清晰、可操作地沟通。

6、归档：代码、文档、决策的保存

系统下线了，但知识和历史不该一起埋掉。归档（Archival）不只是"把代码扔进一个仓库"，而是一次有组织的保存。

要归档什么：

归档的原则：

• 可读：格式要通用（纯文本/Markdown 优于专有格式），别归档一个没人打得开的文件。
• 可找：有索引、有说明文档（README 讲清"这是什么、在哪、怎么用"）。
• 可追溯：注明归档时间、负责人、保留期限。
• 合规：归档前确认其中数据的留存是合法的（别把该销毁的数据也永久留着）。

7、团队交接：人的知识怎么留

最容易被忽略、却最值钱的资产，是团队成员脑子里的知识。

系统下线常常伴随人员流动（团队解散、转岗）。如果不做交接，知识就随人消失了。要做：

• 知识交接清单：列出系统的关键知识、外部联系人、历史坑点。
• 口述 + 文档化：让核心成员把"只可意会"的东西（为什么这么设计、哪些地方千万不能碰）写下来。
• 明确对接人：系统虽下线，但可能还有遗留问题；指定谁负责对外应答。
• 复盘与致谢：办一次下线复盘（呼应第 28 课），总结这个系统带来的经验，公开感谢参与者——这是团队文化的沉淀。

一句话：代码可以归档，经验必须交接。 一个团队的成长，正藏在这些"送走老系统"的复盘里。

8、常见误区

1. "关掉服务就完事了"：忽略数据迁移、用户通知、归档，会引发投诉、数据丢失和合规问题。
2. "数据先删了再说"：迁移校验未完成就删源数据，出问题无法回滚。
3. "用户不会在意"：不通知、不给导出，是对用户信任的最大伤害。
4. "归档就是打包代码"：没有文档、没有决策记录，归档等于一堆看不懂的废墟。
5. "团队散了，知识就散了"：不做交接，同样的坑下一个团队还会踩一遍。

9、动手实验 🎯

任务：为「Team Todo」写一份《系统下线方案》。

1. 下线评估：假设要把它替换为「Team Todo v2（新版）」，列一张评估表（业务/技术/替代/风险四维）。
2. 使用者盘点：列出所有可能依赖它的调用方（Web 前端、移动端、内部脚本、第三方集成），并说明如何验证"没人用了"。
3. 数据迁移方案：写出四步（盘点→映射→演练→迁移校验），并举 2 个需要"字段转换"的例子。
4. 数据销毁清单：列出哪些数据应销毁、哪些应归档，各自原因（合规 / 历史价值）。
5. 用户沟通计划：写一份"下线公告"草稿（含原因、时间、替代方案、导出方式、联系方式）。
6. 归档清单 + 交接清单：各列 5 项，说明归档什么、交接什么。
7. 复盘提纲：设计这场下线复盘要回答的 3 个问题（写进第 28 课的复盘模板）。

10、今天你带走的三句话

1. 下线比上线更考验纪律：先评估、先测量、先通知，再动手。
2. 数据可以搬、可以销毁，但都要"可校验、可回滚、可追溯"——迁移不删源，销毁留证明。
3. 系统的终点不是"关掉"，而是"知识被留下、用户被善待、团队被交代"——这才叫体面退役。