第三章 下线风险评估：给每个资产“算命”

数据资产下线，最怕什么？

怕的是你这边刚把表删了，那边老板的月报直接挂了。怕的是你自以为清理了垃圾，结果下游核心应用跑不出数据了。

所以，在动手之前，我们必须做一件事——风险评估。说白了，就是给每个待下线的资产“算一卦”，看看它到底牵动了多少人的神经。

3.1 评估的三个维度

我个人习惯把风险评估拆成三个维度来看。你想想看，一个数据资产的影响，无非就是“谁在用”、“怎么用”、“用了多久”。

• 影响范围： 下游有多少系统、报表、应用在依赖它？是内部用，还是对外给客户看？
• 影响深度： 下游是实时交易系统，还是离线跑批报表？是核心KPI，还是辅助分析？
• 影响时长： 如果这个资产突然消失，下游多久会出问题？是立刻报错，还是一个月后才暴露？

我在项目中遇到过一种情况：一个看似没人用的历史表，其实被一个季度报表的存储过程悄悄引用了。那个报表一年才跑一次，平时根本没人发现。所以，千万别信“感觉没人用”，得靠工具和流程说话。

3.2 风险等级矩阵

有了三个维度的打分，我们就可以把它们组合成一个矩阵。我习惯用 5x5 的矩阵，但为了实战方便，我简化成 3x3，更容易落地。

影响范围 \ 影响深度	低（辅助报表）	中（常规报表/应用）	高（核心交易/监管报送）
小（1-2个下游）	低风险	中风险	高风险
中（3-5个下游）	中风险	中风险	高风险
大（5个以上下游）	中风险	高风险	极高风险

3.3 评估流程：四步走

光有矩阵还不够，得有流程。我总结了一个四步走的评估流程，每一步都踩过坑，你直接拿去用。

1. 第一步：血缘分析

   用数据血缘工具，自动扫描出所有下游依赖。没有工具？那就手动查存储过程、ETL脚本、报表配置。这一步是基础，不能省。

2. 第二步：下游确认

   把血缘分析的结果，发给每个下游系统的负责人。让他们确认：“这个表/字段，你们还在用吗？如果下线了，你们能改吗？”

   我曾经遇到过，血缘分析显示有10个下游，结果确认下来，有3个系统已经废弃了，还有2个说“我们早就迁移了”。所以，一定要人工确认。

3. 第三步：影响评估

   根据下游确认的结果，对照风险矩阵，给每个资产打上风险等级。同时，记录下每个下游的“改造工作量”和“改造窗口期”。

4. 第四步：决策与预案

   高风险资产，需要业务部门签字确认。中风险资产，可以走标准下线流程。低风险资产，直接下线。

3.4 核心逻辑图：风险评估全景

下面这张图，把整个风险评估的逻辑串起来了。你可以把它贴在墙上，每次做评估时对照着看。

3.5 实战中的“坑”与“解”

评估流程看起来简单，但实战中总会遇到各种幺蛾子。我挑几个典型的说说。

• 坑一：血缘分析不准

  工具扫描出来的血缘，有时候会漏掉动态SQL或者跨库引用。我的解法是：工具扫描 + 人工抽查。对于核心资产，我甚至会要求开发人员手动梳理一遍。

• 坑二：下游不配合

  你发邮件问“这个表你们还用吗？”，对方可能一周都不回。我的做法是：设置截止日期，超时默认“在用”。同时，把风险等级提高一级，倒逼他们回复。

• 坑三：评估结果没人信

  你评估出来是低风险，但业务部门不认。怎么办？我的经验是：让业务部门参与评估。把矩阵和流程给他们看，让他们自己打分。这样出来的结果，他们才认。