指标口径变更后「下游依赖」怎么快速盘点：metric registry 加血缘字段、自动扫描告警规则/面板/BI 视图、还是改口径前强制 PR review 贴引用清单？

【背景】 做了 8 年指标体系，最怕的不是"设计新指标"，而是"改老指标的口径"。上个月我们团队改了一个核心指标——"日活跃接口调用量"从"所有请求数"改为"去重独立接口调用数"（排除客户端重试和心跳探活）。改之前我以为影响面可控，结果：3 个团队的 SLO 基线全变了、2 条告警规则因口径变化开始误报、1 份对外 SLA 报告的数字"跳变"了 40%。最后靠挨个问 + grep 配置文件才把影响范围拼出来，耗时近一周。

【现象】 核心卡点：改口径前，我根本不知道这个指标被谁引用了。我们的指标"注册中心"（内部 metric registry）只记录了 owner、description、unit，没有"下游引用"字段。而实际的下游依赖分散在至少 5 个系统里：

1. Grafana 面板（JSON 存储，指标名是字符串）
2. 告警规则（YAML/JSON，有的用指标名、有的用 PromQL 表达式）
3. BI 报表（SQL 视图，口径硬编码在 SQL 里）
4. SLO/SLA 文档（Markdown/Confluence，指标名是自然语言描述）
5. 定时任务/数据管道（代码里直接引用指标 key）

【已尝试的三种方案及取舍】

• 方案 A：在 metric registry 加 downstream_dependencies 字段，让指标 owner 手动维护"谁引用了我"。→ 3 个月后字段就过期了，因为下游系统改配置不会回调 registry。维护成本 > 收益。
• 方案 B：写个扫描器，定期 grep 告警规则 YAML + Grafana 面板 JSON + BI SQL 视图，提取所有引用了目标指标的下游。→ 能做但覆盖率有限（SLO 文档和代码里的引用扫不到），且每次改口径前要手动跑一遍，容易忘。
• 方案 C：让所有下游系统统一用"指标 ID"而非"指标名"引用（类似 API 版本化）。→ 理想但改造成本极高，涉及 5 个系统、几十个团队，短期不现实。

【期望得到的答案形态】

1. 有没有人做过"指标血缘"（metric lineage）系统？怎么实现的？是手动维护还是自动扫描？扫描的覆盖率和维护成本大概什么量级？
2. 如果做自动扫描，PromQL 表达式和 SQL 视图里的指标引用怎么可靠提取（正则不够准确、AST 解析成本高）？有没有中间方案？
3. 有没有更轻量的做法——比如"改口径前必须走一次 PR review，review checklist 里有一项'请贴出所有引用该指标的下游系统 + 影响评估'"？这种"流程兜底"在什么规模下够用？
4. 指标口径变更的"影响面"有没有量化的评估方法（比如影响 N 个 SLO、M 条告警、K 份对外报告），而不是靠人肉盘点？

我倾向的方案是 B（自动扫描）+ 流程兜底（改口径前跑扫描器 + 人工确认 SLO/文档类引用），但卡在"扫描覆盖率"和"维护成本"上想听大家经验。