U7.10.3Long-frozen dashboards keep using metrics that are no longer valid设计
长期固化的仪表盘会继续沿用已失效的指标
别名: 指标腐化 · 仪表盘老化
概念解释
仪表盘创建时选定的指标反映当时的业务关注点，但业务会变：产品线调整、口径重新定义、数据源下线、KPI 更换。仪表盘本身不会自动知道这些变化——它忠实地渲染配置里写的指标定义，即使那个定义已经没有意义。长期运行后，仪表盘上的某些指标变成了"僵尸指标"：还在显示数字，但没有人能解释这些数字对应什么业务行为，或者它们的计算引用了已经不存在的字段。这些指标占据注意力却提供零信息，甚至因为数字看起来正常而掩盖了"其实这条数据管道已经断了"的事实。
机制
指标失效是渐进的且不可见的：上游字段改名后，依赖它的查询可能静默返回 null（图表显示为断线或空值）或返回缓存的旧值（数字还在动但已经不反映真实数据）。仪表盘的渲染层不区分"数据合法但业务含义已变"和"数据管道已断"——两种情况在屏幕上可能看起来一样。失效累积的原因是仪表盘的维护激励缺失：创建仪表盘的人有动力让它跑起来，但没有人有 KPI 去"让仪表盘保持正确"；仪表盘没有 owner 时失效更快，有 owner 但 owner 离开团队后同样进入无人维护状态。这与代码的技术债务类似，但更隐蔽：代码不编译时会立即报错，而仪表盘的失效不报错——它只是持续显示不再有意义的数据。
边界
并非所有"还在显示但没人看"的指标都失效了：低频但合规要求的指标（如监管报表里的数据）可能很少被查看但必须保留。失效的判定标准不是查看频率而是"数据与当前业务实体之间是否还有明确的映射"——如果一个指标的口径引用的产品线已经下线，它就是失效的，即使还有人出于习惯查看它。另一个边界是自动化的程度：有些系统的数据源有 schema 变更通知，可以让仪表盘在上游字段改名时自动标记受影响的指标，但这依赖上游系统的成熟度，不是所有场景都可用。
怎么落地
- 为每个仪表盘指定 owner，owner 变更时同步更新（离职交接清单的一部分）。
- 每季度跑一次指标审计：列出仪表盘上每个指标的口径定义、上游数据源、最近查看频率；口径引用已不存在的业务实体或最近 90 天零查看的指标列入待下线清单。
- 数据源 schema 变更时，自动检测受影响的仪表盘指标并通知 owner。
- 验证：从仪表盘上任选 5 个指标，让当前团队成员解释每个"衡量的是什么业务行为"；解释不清的指标即为候选失效项。