为什么指标字典越做越乱？聊聊指标治理的「越治越乱」悖论

背景

做了十年算法，近两年重心放在数据分析和指标体系上。我见过一个很反直觉的现象：很多团队花大精力建了指标字典（metric dictionary / metric layer），上线时口径清晰、大家点赞，但半年后字典就成了"历史遗迹"——新业务上线没人往里加指标，老指标口径悄悄改了没人同步，最后看板上的数和字典里写的对不上，大家开始绕开字典直接用 SQL。

我习惯从现象倒推根因，觉得这个问题值得拿出来聊：指标治理为什么常常"越治越乱"？

几种常见做法（也都有坑）

1. 集中式指标平台：建一个统一的 metric service，所有指标走平台注册。优点是口径唯一，缺点是门槛高、接入慢，业务团队嫌麻烦就绕开了，字典变成"两套真相"。
2. 分散式 + 定期 review：各团队自己定义，季度 review 对齐。优点是灵活，缺点是 review 往往流于形式，口径漂移在两次 review 之间已经发生了。
3. 代码即字典：指标定义写进代码（如 dbt metric、LookML），靠 CI 保证一致性。优点是可执行、可验证，缺点是只覆盖了"进了代码"的指标，探索性分析里的临时指标没人管。

我的倾向

我倾向第三种方向，但加一个关键约束：指标要有"生命周期"，包括"废弃"。具体说：

• 每个指标有 owner、创建时间、最近引用时间、废弃日期；
• 超过 90 天没被任何看板/报表/实验引用的指标自动标记为"待废弃"；
• 废弃不是删除，是降权——从字典首页移除，但保留定义和口径说明供历史查询。

理由：指标字典乱的根本原因不是"没人管"，而是"只进不出"。人天然倾向于加指标（因为加指标容易、表达诉求快），不愿意删指标（因为删了怕别人要用）。没有退出机制的字典，本质是一个只追加的日志，不是字典。

想听大家聊聊

• 你们团队指标字典是怎么维护的？有没有"废弃"机制？
• 如果指标 owner 离职了，指标怎么办？有没有见过"孤儿指标"泛滥的情况？
• 你们觉得指标治理的瓶颈到底是"工具"还是"组织"？换句话说，如果给你一个完美的指标平台，口径还能对齐吗？
• 有没有"指标太多反而让决策更慢"的亲身经历？你们怎么处理的？