想下线一批冗余指标，怎么评估下游依赖与影响面才不踩雷？

【背景】 我做了 3 年技术文档，最近转做指标体系搭建，团队 12 人（2 数据 / 4 后端 / 4 产品 / 2 运营），核心指标 40+ 个，散在 3 张 BI 看板 + 1 个数据仓库 + 若干 SQL 脚本里。习惯「从现象倒推根因」，这次想先把「哪些指标其实没人用了」清理掉，再谈新建。

【现象（具体可复现）】 季度复盘时统计发现：40 多个指标里，有约 15 个近 3 个月在看板 / 周报 / 报表里一次都没被引用过——要么是历史遗留，要么是口径重复（比如「活跃」和「有效活跃」两个数，业务方其实只用其中一个）。我想把这批冗余指标标记废弃甚至下线。但卡点马上出现：我根本不知道这些指标还被谁消费——可能是某个没挂在主看板上的私有 SQL、某个运营的本地脚本、某个已经没人看但还在跑的定时报表，甚至某个下游数据产品的取数逻辑。一旦贸然下线，最坏情况是某个老板的周报突然报错，或者某个下游服务读不到字段直接挂掉，这种「静默依赖」是最难排查的。

【已尝试与结果】

1. 在 BI 看板配置里搜指标名——只能搜到看板层面的引用，搜不到「看板背后还接了哪些 SQL 脚本」；
2. 在数据仓库 grep 指标字段名——指标名和字段名不一致（中文指标 vs 英文字段），grep 命中率低，且搜不到 BI 引擎里动态生成的查询；
3. 直接问业务方「你还有在用吗」——大家都说「应该没人用了」，但两周后就有个人来问「为什么我的表里这个字段没了」。 三次尝试共同失败点：我只有「指标 → 口径」这条正向链路，没有「指标 → 谁在用」这条反向依赖图。

【期望得到的答案形态】 希望回答给出可落地的具体做法，而非「上数据治理平台」这类方向性建议。具体希望覆盖：

• 下游依赖怎么枚举：除了看板配置 + 代码 grep，还有没有更系统的方式（比如 DB 视图的依赖查询、BI 引擎的查询日志分析、指标血缘工具如 dbt 反向血缘）？各自前置成本多少；
• 废弃的灰度流程：是不是该走「标记废弃 → 公告 N 天 → 软下线（保留字段但打 deprecation 标记）→ 硬删除」四步？每步建议多久、怎么通知、怎么监控「是否真没人用了」；
• 怎么判定「真没人用」：是靠引用计数为 0，还是要结合查询日志的访问频次 + 最近访问时间？阈值怎么定；
• 有没有「指标下线 checklist」或 SOP 模板可以直接抄，最好包含风险分级（哪些指标下线属于高风险、需要谁审批）。 如果能附上你们团队的「指标废弃公告模板」或一段从 BI 查询日志里捞下游引用的 SQL，会非常有帮助。