第4章：下线流程设计——从申请、审批、通知到执行、验证的标准化流程

数据资产下线这件事，很多团队一开始都觉得「不就是删数据吗？」。嗯，我当年也这么想过。直到有一次，我把一个还在被实时报表引用的表给下线了，第二天早上业务方炸了锅……从那以后，我老老实实把流程拆成了五个阶段。

说白了，下线不是一次操作，而是一次有纪律的资产退役。你想想看，一个数据资产从出生到消亡，如果最后一步走得乱七八糟，前面所有的治理投入都可能白费。

4.1 五阶段流程总览

我个人习惯把下线流程拆成五个阶段，每个阶段都有明确的输入和输出。下面这张图是我在项目中反复调整后定下来的框架，你可以直接拿去用。

4.2 申请阶段：把「为什么下线」说清楚

申请是整个流程的起点，也是很多人最容易糊弄的一步。我曾经见过一个申请单，理由就写了四个字：「不再使用」。结果审批人追问了三天，最后发现是申请人的临时表，下游还有三个ETL任务在跑。

所以，我建议申请单至少包含以下内容：

字段	说明	示例
资产标识	表名/文件路径/API端点	ods_order_detail_2020
下线原因	必须选择预定义分类	数据冗余（已有ods_order_detail替代）
影响范围	已知的下游依赖清单	3个ETL任务、2张报表
数据保留策略	是否需要归档/备份	归档至冷存储，保留180天
期望下线时间	建议避开业务高峰期	2025-04-15 02:00

4.3 审批阶段：不是走过场，是真把关

审批环节最容易变成「秒批」或「秒拒」。我个人习惯设置三级审批，每一级关注的点不一样：

• 第一级：数据Owner审批——确认资产确实属于自己管辖范围，下线理由合理。这个环节我见过最离谱的，是A团队申请下线B团队的表，Owner直接打回。
• 第二级：数据治理委员会审批——评估下线对全局数据资产的影响，比如是否涉及合规要求、是否影响审计线索。这里要注意，如果资产涉及PII数据，必须额外标注。
• 第三级：技术负责人审批——确认下线操作方案可行，回滚预案完备。说白了，就是问一句：「万一出问题了，能不能快速恢复？」

4.4 通知阶段：让所有人都知道

通知不是发一封邮件就完事了。你想想看，如果某个下游系统没收到通知，第二天跑批失败，谁来背锅？

我建议的通知策略分三层：

1. 邮件通知——发送给所有已知的下游依赖方，包含下线时间、影响范围、迁移方案。邮件标题必须带【重要】标签，正文要有明确的「需回复确认」要求。
2. 即时通讯通知——在数据团队、运维团队、业务方的大群里同步消息。我个人习惯@所有人，并设置24小时内的确认回复截止时间。
3. 系统公告——在数据资产管理平台发布下线公告，所有访问该资产的用户都会看到弹窗提醒。

这里有个细节：通知发出后，必须收集确认回执。如果某个下游方在截止时间前没有回复，建议电话确认。别问我为什么知道——有一次我漏了一个下游，对方三天后才发现数据没了，那场面……

4.5 执行阶段：操作要规范，回滚要就绪

执行阶段是技术活，也是风险最高的环节。我个人的执行清单长这样：

# 下线执行检查清单
1. 确认审批已全部通过，通知回执已收齐
2. 备份数据（如果需要归档）
3. 断开上游写入（如果是表，先改为只读）
4. 观察24小时，确认无异常告警
5. 执行下线操作（删除/停服/归档）
6. 记录操作日志，包括操作人、时间、操作内容

另外，执行前一定要准备好回滚脚本。我见过太多团队觉得「不会出问题」，结果真出问题时手忙脚乱。回滚脚本要提前测试过，确保能在5分钟内恢复数据访问。

4.6 验证阶段：下线不是终点，确认才是

执行完下线操作，不代表流程结束了。验证阶段要做三件事：

• 功能验证：确认资产确实已不可访问。比如表被删了，查询应该报错；API下线了，调用应该返回404。
• 影响验证：检查下游系统是否正常运行。如果下游有告警，说明通知阶段有遗漏，需要立即回滚并重新通知。
• 归档验证：如果做了数据归档，确认归档文件完整可读。我习惯在归档后随机抽取几条记录做校验。

验证通过后，在数据资产管理平台更新资产状态为「已下线」，并记录下线完成时间。这样，整个流程才算真正闭环。

4.7 流程中的常见问题与应对

问题	原因	应对方案
审批超时	审批人遗忘或出差	设置48小时超时自动转审
通知遗漏	血缘分析不完整	结合自动化血缘工具扫描
执行失败	权限不足或依赖未解除	执行前做预检查脚本
验证不通过	下游仍有依赖	回滚并重新梳理依赖关系

嗯，以上就是下线流程设计的完整框架。你可能会觉得步骤有点多，但相信我——前期多花一天走流程，后期能省下一周救火的时间。数据治理这件事，慢就是快。