看板上有六十个指标，出事时还是没人看。这句话不是评价看板做得漂不漂亮，而是指指标集合本身从来没有被治理过：它只经历过"加"，没经历过"减"。加一个指标的成本是几行配置，删一个指标的阻力是一句"万一以后要看呢"。度量体系的治理要回答的不是"还该加什么"，而是四组决策问题——哪个指标真的进过决策、谁在它异常时真的会动作、它和谁重复、什么时候让它下线。
1. 只增不减的三个恶果
指标增长是自然规律而不是失误：新增几乎零阻力，删除却要有人承担"删错了"的责任。恶果按下面的顺序累积。
| 恶果 | 机制 | 典型表现 |
|---|---|---|
| 注意力稀释 | 面板越密，单条曲线越不显著 | 真异常淹没在几十条曲线里 |
| 矛盾指标 | 两个口径对同一事实结论相反 | 例会变成口径辩论会 |
| 维护成本 | 管道、文档、看板都要有人跟 | 一次口径变更要改五处,改漏一处长期错着 |
注意力稀释最隐蔽：它不产生报错，只产生"看了但没看出来"。撞到上限时第一反应通常是"再做个聚合看板"，于是进入第二轮稀释。
2. 裁指标的判据
裁剪不是审美判断，是三条可回答的判据。三条里命中任意一条不满足，就进入候选下线队列。
| 判据 | 提问方式 | 满足的表现 | 不满足的表现 |
|---|---|---|---|
| 被用于决策 | 上季度它改变过哪个决定 | 决策记录能引到它 | 只在看板上，不在决定里 |
| 异常时有人看 | 上次报警谁点开了 | 说得出人与动作 | 无人应答 |
| 与其他重复 | 它和谁讲同一件事 | 差值稳定且有解释 | 高度同步，取一即可 |
判据要靠证据而不是印象，先把引用事实数出来：
// 从看板、告警规则、决策文档里统计每个指标被引用几次
grep -rhoE "[a-z_]+_(rate|count|total|duration)" dashboards/ alerts/ docs/decisions/ \
| sort | uniq -c | sort -rn | head -50
─── 引用为 0 的是第一批候选；只被看板引用的进第二批
3. 三个层次的指标与越层的危害
指标按它回答的问题分三层。层次本身没有高下，越层才是问题：用过程指标回答价值问题，或用价值指标催过程动作，都会得到错误的因果。
| 层次 | 回答的问题 | 典型例子 | 越层的危害 |
|---|---|---|---|
| 用户价值 | 用户是否得到东西 | 下单成功率 | 用它催节奏 → 刷单、口径注水 |
| 系统行为 | 系统是否按预期工作 | 延迟分位、错误率 | 替代价值判断 → 全绿但没人用 |
| 过程效率 | 交付是否顺畅 | 变更前置时间 | 考核个人 → 行为被扭曲 |
判层的方法很直接：这个指标下降时，你希望谁去做什么。若答案不是"某个人去改某件事"，它多半只是参考数。
4. "虚荣指标"的识别特征
虚荣指标的定义不是"数字好看"，而是"它永远不会提示你该做什么"。三条识别特征通常同时出现。
| 特征 | 判断方式 | 反例（健康指标） |
|---|---|---|
| 只涨不跌 | 观察期内单调上升 | 有下降段且能追到原因 |
| 不可归因 | 变化对不上任何变更 | 能对上发布记录 |
| 改口径才好看 | 焦点从改善变成统计 | 口径由业务定义驱动 |
第三条最值得警惕：一旦讨论里出现"把口径改成……这样数就对了"，说明该指标约束的不再是系统，而是写报表的人。
能用查询回答的问题就别用争论回答：
// 虚荣指标探测：取一段观察窗，看是否存在下降段
// select time_bucket, value from metrics where key = 'KEY' order by time_bucket
// 判据：min/max > 0.9 且从未两连降 → 单调上升，候选虚荣指标
─── 只统计被引用过的指标，否则结果被废弃指标淹没
5. 因果关系推不出，只能对照
两条曲线同步变动说明的是相关。用"观察"推因果会稳定地出错，有两个机制会伪装成因果：共同上游（一次发布同时影响两条曲线）与选择偏差（只在出事窗口看数据）。
// 判断是否真的存在因果，至少要做一次结构对照，而不是看两条曲线
// 步骤示意（工具与查询语言按所用平台核对）
// 1) 分层对照：按渠道/版本/地域分组，看关系是否在每个分层里都成立
// 2) 时间错位：把 X 前移一个采样周期，看关系是否仍然成立（错位后仍成立多半是共因）
// 3) 分段对照：变更前后各取一段同长度窗口，比较斜率而不是绝对值
// 4) 反向验证：如果因果成立，抑制 X 应当带来 Y 的可观测变化
能做结构对照的场合，就别用"两个指标一起动"当论据——这条纪律把"我觉得"从指标讨论里摘出去。
6. 北极星指标的误用
单指标必然被优化，这是激励结构决定的，不是人的问题。北极星指标的作用是让团队对齐方向，一旦它被用于考核、被拆解到个人、被当作唯一验收标准，就会退化成一个可被绕过的目标。
| 误用方式 | 短期效果 | 长期后果 |
|---|---|---|
| 单指标考核 | 数字上升 | 分母被重写，体验不动 |
| 层层拆解 | 每人头上都有数 | 局部最优，协作成本升 |
| 替代护栏 | 决策快 | 看不见下行风险 |
稳妥的是"一个北极星 + 若干护栏"：北极星给方向，护栏给下限（错误率、投诉率、成本）。护栏被触碰时，北极星的增长不再构成推进理由。
7. 指标与告警的关系
告警不是"指标的一个视图"，而是一份值班契约：每条告警都在承诺"有人会为它动作"。所以它只该挂在可行动的指标上。
| 项 | 可告警 | 只该进看板 |
|---|---|---|
| 有明确处置动作 | 是 | 否 |
| 有明确责任人 | 是 | 可能没有 |
| 抖动噪音成本 | 可控（有 for 窗口） | 高 |
| 覆盖率/总量类 | 少用 | 常用 |
按这三列过一遍现有告警，不满足"有动作"的那些应当摘下告警通道。
// 只对"有人知道怎么做"的指标配 alert（字段名按所用监控系统核对）
alert: CheckoutSuccessRateDrop
expr: checkout_success_rate < SLO_THRESHOLD
for: 3m // for 至少要覆盖一个抖动周期，否则必然误报
annotations:
action: "先看支付渠道错误分布，再决定是否切换渠道或降级"
owner: "@checkout-oncall"
// 没有 action 字段的告警，等于把噪音分发给值班人
8. 维护成本与退役机制
维护成本分三块：数据管道（采集、存储、查询开销）、口径变更（文档与实现同步）、看板维护。三块都随指标数增长，收益却不然——这是裁剪的经济学依据。
// 退役四步：宣布 → 断引用 → 静默观察 → 删管道
// 1) 在看板与目录里标记 deprecated，写明计划下线日
// 2) 从告警规则与决策文档中摘掉引用（先摘引用，后停采集）
// 3) 保持采集，观察 STALE_PERIOD（如四到八周），记录是否有人问起
// 4) 静默期内无引用 → 删除看板项、告警规则与数据管道，并在目录留一行历史
// 例外：合规或审计要求的留存指标不走退役流程，改为单独归档
这个顺序很重要：反过来，退役当天会先炸出一批告警，讨论焦点就从"这个指标没用了"变成"告警系统出问题了"。
9. 所有权与决策记录
没有认领人的指标等于没有指标：异常时无人负责，争议时无人拍板。所有权最简形态是一个名字加一个复查周期。
| 项 | 最小要求 | 常见反模式 |
|---|---|---|
| 认领人 | 一个具体的人 | 认领人已离职 |
| 复查周期 | 每季看引用情况 | 加完没人再看 |
| 口径定义 | 可被复算的定义 | 靠口头共识 |
| 退役决定 | 有记录、有日期 | 只在聊天里说过 |
─── 指标决策记录：是否继续看 xxx
- 提出人 / 日期：
- 现状引用：看板 N 处、告警 M 条、决策文档 K 篇
- 判据命中：被用于决策（是/否，出处）；异常时会有人看（是/否，谁）；与 yy 重复（是/否）
- 决定：保留 / 降级为参考 / 下线（下线日）
- 复查时点：
10. 用什么证明治理起了作用
治理本身也要有观测量，否则退化成一次性清理。四个量足够。
| 度量 | 定义 | 期望的走向 |
|---|---|---|
| 在册指标数 | 状态为 active 的条数 | 增速放缓，出现净减少 |
| 被引用次数 | 告警与决策中的引用总数 | 引用集中到少数指标 |
| 矛盾指标对数 | 同事实双口径的对数 | 逐季下降或有仲裁 |
| 下线数 | 本季退役条数 | 大于零且不返工 |
别用"看板访问量"当成效：它高既可能是治理好，也可能是大家找不到东西。
11. 排错：治理推不动时的五种情形
治理失败很少因为判据不够多，多半因为判据被绕开。
| 现象 | 原因 | 处理 |
|---|---|---|
| 每个指标都有人说"要用" | 判据太软，用"以后可能" | 改成可举证：上季度引用出处 |
| 裁剪后报警变多 | 删的是观测层，留的是结论层 | 观测量按需可查，不常驻 |
| 合并后没人用 | 改了使用者的入口习惯 | 原入口保留做跳转 |
| 口径辩论反复 | 缺仲裁角色与记录 | 指定 owner，结论入目录 |
| 指标被加回 | 加入零门槛、无退役对照 | 一进一出配额 |
12. 边界：什么情况下不该上正式治理机制
治理机制的成本是会议、记录与流程。下列情形里它高过收益。
| 情形 | 判断依据 | 更合适的做法 |
|---|---|---|
| 团队极小 | 都知道哪些数在用 | 口头约定 + 一份目录 |
| 只有一条业务线 | 没有跨线口径冲突 | 一页核心指标 + 护栏 |
| 指标稳定三年 | 口径多年未变 | 年度复查点 |
| 系统即将重写 | 多数指标随架构消失 | 只盯迁移期对照指标 |
反过来，一旦出现跨团队口径争议、或同一事实有两个版本的数，就到了必须建正式机制的时候——争议本身就是触发信号。
13. 自测
- 一个指标"只涨不跌"且"不可归因"，你还需要看哪个特征才能判定它是虚荣指标？
- 两条曲线同步变动，除了因果，还有哪两个机制足以解释它？
- 为什么退役流程要求先断引用、后停采集？
- 北极星指标被用于考核后，最先退化的通常是它的哪一部分？
- 什么样的指标才配挂告警？请给出两个判断条件。
- 团队只有三个人、一条业务线时，度量治理的最小可用形态是什么？