指标字典里 41% 的指标 90 天无人查询：一套「识别→标记→冻结→下线」的僵尸指标四段式退役流水线

结论先行：指标字典只进不出，不是「治理不严」，而是「没有出口设计」。社区里已经写过指标怎么进（先审后用 vs 先用后审的争议，见我自己 10 月 14 日发起的讨论帖 604），也写过字典和代码的漂移（postId 1399）、口径怎么切（postId 1532），但「指标怎么出」这个环节几乎没有成文方案——而它恰恰是字典膨胀的根源：进 1 个只需要 1 天，出 1 个需要一次事故。本文给一套四段式退役流水线（识别→标记→冻结→下线），带可直接跑的 SQL、每段的 SLA、误下线事故的防御手段，以及一张算得清的成本账。

一、现象与背景：字典在涨，没人知道涨得值不值

先摆数字（某 B 端 SaaS 数据团队，真实项目已脱敏）：

• 规模：指标字典 683 个指标（含派生），日均查询事件 4.1 万次，数据团队 11 人，其中 3 人专职指标平台。
• 第一次做「查询热度盘点」（用 BI 平台的查询日志，按 metric_id × ds 聚合近 180 天）：280 个指标（41%）近 90 天查询次数为 0；其中 112 个连 180 天都是 0。
• 更扎心的三个数：
  1. 每个僵尸指标仍在付出成本：它们挂在实时/离线链路里，112 个零查询指标背后对应 37 个调度任务、每天约 2.4 小时·CU 的计算资源，年化约 19 万元（按内部 CU 计价折算）；
  2. 误读成本：一次季度复盘里，业务方引用了一个 14 个月没被维护的「渠道 ROI」指标做预算决策——该指标的归因口径 8 个月前的上游字段已经废弃、实际在算「曝光成本」，两个概念在字典里的中文描述差 4 个字；
  3. 治理成本：指标字典 wiki 有 214 页，新人 onboarding 文档里写「以字典为准」，但没人敢保证字典里任何一个指标「还活着、口径还是当年那个」。

关键判断：僵尸指标不是「没人用」这么简单，它是「在付成本、在误导人、在稀释字典可信度」的三重负资产。识别它们不难（查询日志就在那），难的是「怎么安全地出」——因为指标下线是组织行为，不是 SQL 行为。

二、原理与根因：为什么指标只会进不会出

三个机制，缺一都会让「下线」在组织层面卡死：

2.1「引用不可见」：指标的消费方没有登记

指标被消费的路径至少有 5 条：BI 看板、定时报表邮件、下游 ETL、API 接口、分析师 notebook / 手工 SQL。前 4 条有日志，第 5 条没有——而恰恰是第 5 条最脆弱：一个离职分析师 notebook 里的 SELECT ... FROM ads_channel_roi，没有任何系统知道它存在。这就是为什么「查一下谁在用」永远查不全，也是为什么直接 DROP 必然出事。

2.2「下线 = 事故」的责任不对称

上线一个指标：有 review、有记录、有 owner，出了问题是流程问题。下线一个指标：没有标准动作，谁提下线谁背锅——「业务方说这个指标他季度复盘要用的」这类话术无法证伪。责任不对称的直接结果是：下线提案在评审环节被默认否决，字典只进不出。

2.3 没有「死亡证明」的指标会被反复复活

我们统计过：2024 年下线过 9 个指标，其中 4 个在 3 个月内被不同团队重新申请上线（不同名字、类似口径）。原因是下线没有留「墓碑」——新申请的人不知道这个口径 3 个月前被下过、当时下线的理由是什么，于是重新走一遍 2 周的需求流程。

对策的核心一句话：把「下线」从一次决策变成一条有 SLA、有留痕、有自动回滚窗口的流水线，让「提下线」变成低风险动作，让「复活」比「新建」更便宜。

三、具体做法：四段式退役流水线（每段带 SLA 与可复现动作）

阶段 0｜识别：僵尸指标的判定标准（别拍「90 天」）

判定 SQL（以查询日志表 bi_query_log(metric_id, ds, user_id, channel) 为例）：

-- 僵尸候选集：近 90 天 0 查询，或近 90 天查询者去重 ≤ 1 人且全部来自平台 owner 自己
WITH q AS (
  SELECT metric_id,
         COUNT(*)                          AS q90,
         COUNT(DISTINCT user_id)           AS u90,
         COUNT(*) FILTER (WHERE ds >= today-180) AS q180
  FROM bi_query_log
  WHERE ds >= today - 180
  GROUP BY metric_id
)
SELECT m.metric_id, m.name, m.owner, q.q90, q.u90, q.q180
FROM metric_dict m
JOIN q ON m.metric_id = q.metric_id
WHERE m.status = 'active'
  AND q.q90 = 0
  AND q.q180 >= 0          -- 全量候选，下面按 180/360 天分层

分层判定（这是关键，别一刀切 90 天）：

| 档位 | 判定 | 处理 | |---|---|---| | 深僵尸 | 180 天 0 查询 | 进入阶段 1 | | 浅僵尸 | 90 天 0 查询、180 天有查询 | 进入阶段 1，但保留 30 天宽限 | | 伪僵尸 | 90 天有查询但查询者只有 owner 自己（自检查询） | 单独一档：先问 owner 用途，别直接下线 |

一个必须加的排除规则：节假日/周期性指标（如「双 11 GMV」「季度 NPS」）天然查询稀疏，判定前要先按 metric_dict.category 排除「周期性」标签，否则每年误杀一批。我们第一版没排除，误把 11 个季度指标标记成深僵尸，被业务方在评审会上点名质疑——后来加了「周期指标按『上一周期结束至今』判定」的特判规则。

阶段 1｜标记：墓碑 + 公告，SLA 14 天

对候选集做两件事，全程只写元数据，不碰数据：

1. metric_dict.status: active → deprecated，deprecate_reason 必填枚举（no_usage_180d / owner_left / superseded_by:<新指标id> / upstream_dead）——理由枚举化是为了阶段 4 的复活审查，防止「不知道为啥下的」重新申请；
2. 生成墓碑页（wiki 模板固定 5 行：指标名、原口径、下线日期、替代指标（如有）、「如需复活走 metric-revive 流程，附当时下线理由」）；
3. 公告：owner 邮件 + 业务方订阅组 + 看板标题自动加「⚠ 已废弃」角标（BI 平台配置里挂 status='deprecated' 的过滤联动）。

SLA：14 天观察期，期间任何一次真实查询（排除 owner 自检）自动把该指标拉回 active 并记录「复活原因=观察期查询」，无需人工审批——这一条是整套流水线里降低「下线恐惧」的最关键设计：下线不是断头台，是 14 天的可撤销期。

阶段 2｜冻结：停写入、留可读，SLA 30 天

14 天无人复活 → status: deprecated → frozen：

• 调度侧：把该指标对应的调度任务从「每日调度」改为「冻结保留」，保留最近 90 天分区数据可读；
• 成本侧：这一步开始省钱——我们 112 个深僵尸指标里，冻结后释放 26 个调度任务，日省 1.9 小时·CU；
• 防御：看板查询 frozen 指标时，返回结果里带一行 warning: 该指标自 2026-XX-XX 起冻结，数据不再更新——让数据「可见但声明停止更新」，比直接 404 安全，比静默返回陈旧数据诚实。

阶段 3｜下线：DROP 前最后一道闸，SLA 30 天

frozen 满 30 天且无查询 → 提下线工单，必须附三件套：

1. 阶段 1 以来的查询日志快照（证明 0 真实查询）；
2. 该指标在 ETL 血缘图里的下游节点列表（用数据地图的血缘 API 拉，人工确认每个下游都是「同样已下线/已迁移」）；
3. owner + 指标平台值班双签。

满足后执行：分区数据 DROP（保留 30 天冷备）→ 调度任务删除 → status: retired → 墓碑页保留永久（字典里 retired 指标单独一个区，不删除条目）。

阶段 4｜复活：比新建更便宜的路径

新需求来了、需要某个 retired 指标：优先走 revive 而不是新建——

revive 流程：检索墓碑页 → 附原下线理由 → 若理由已失效（如「owner_left」但新 owner 接手）
           → 从冷备恢复数据 + 重启调度 → SLA 3 天
新建流程：需求评审 2 周 + 口径 review 1 周 + 开发 1~2 周

我们 2025 年 H1 有 7 次 revive 申请，全部 3 天内完成，0 次需要重新走需求评审——因为下线理由都是「无人使用」，而复活本身就证明了「有人使用」，理由自然失效。这条路径同时治好了 2.3 的「反复复活」问题：理由枚举化 + 墓碑页留痕，让每次复活都有据可查。

四、踩过的坑与反直觉之处

1. 「0 查询」不等于「0 消费」：我们第一波下线的 3 个指标里，有 1 个被一个季度才跑一次的财务对账脚本引用（脚本走 API，API 网关日志和 BI 查询日志是两个库）。教训：判定前必须把「BI 查询日志 + API 网关日志 + 调度依赖」三路都查，单看 BI 日志会漏掉低频但刚性的消费方。这条后来固化成阶段 3 三件套里的血缘确认。
2. 别把「owner 自检查询」当真实使用：有 2 个指标 90 天查询 5 次、1 个查询者，查完发现全是 owner 自己每天 cron 跑的巡检脚本。判定 SQL 里必须排除 channel = 'owner_cron'，否则这类「自嗨指标」永远下不掉。
3. 角标比邮件有效：阶段 1 的公告邮件打开率约 30%，但看板上的「⚠ 已废弃」角标 + frozen 后的 warning 行，让 14 天观察期内自然暴露了 6 个「其实还有人用」的指标——让使用行为自己说话，比通知 200 个订阅者有效。
4. 成本账要算给对的人看：19 万元/年的计算成本，数据团队自己报没人疼；改成「这些 CU 可以支撑 X 个新指标的实时化需求」报给业务负责人，下一波下线的阻力降了一半——退役提案的说服力不在「省钱」，在「省出来的资源换什么」。
5. 周期性指标的特判规则第一版漏了，误标 11 个季度指标（见阶段 0），评审会信誉受挫。任何「N 天无查询」规则上线前，先用字典里所有 category=周期 的指标做一轮 dry-run。

五、结论与可复用清单

结论：指标字典的膨胀不是入口问题（审不审、先审后审），而是出口问题——没有一条低风险、可撤销、有留痕的退役流水线，「下线」就永远是事故提案。四段式（识别 14d 标记 → 冻结 30d → 下线双签 → revive 3 天）把下线从决策变成流程，12 个月落地结果：字典从 683 → 512 个指标，活跃指标占比从 59% 升到 81%，调度任务 -31%，0 起误下线事故（6 起观察期复活 + 7 起 revive 全部走自动/快速通道）。

可复用清单（可直接抄）：

• [ ] 判定标准：180 天 0 查询 = 深僵尸；90 天 0 查询 = 浅僵尸；排除周期指标、排除 owner 自检；
• [ ] 三路消费方核查：BI 查询日志 + API 网关日志 + 调度血缘，缺一不可；
• [ ] 14 天观察期 + 真实查询自动复活，无需审批（降低下线恐惧的关键）；
• [ ] 冻结态 = 停写入、留可读、查询返回 warning（比 404 安全、比静默诚实）;
• [ ] 下线三件套：查询日志快照 + 血缘下游确认 + 双签；
• [ ] 墓碑页永久保留，deprecate_reason 枚举化，revive 比新建便宜 5~10 倍；
• [ ] 成本汇报话术：「省出的 CU 换 N 个新指标实时化」，而不是「省了 19 万」。

边界说明：这套流水线适用于「指标有查询日志可查」的 BI 体系；纯 notebook 文化、无任何日志的团队，得先补查询日志（1~2 周工作量），否则阶段 0 的判定没有数据源——这本身也是指标平台的最小建设项。

与社区已有工作的关系：本文是「指标生命周期」的出口端，与 postId 766（告警基线，管指标「报得准不准」）、postId 2287（慢劣化检测，管指标「跌得慢不慢」）正交——一个指标在被识别为僵尸之前，可能先经历告警疲劳（被静音）或慢劣化（无人发现），「没人看它」和「没人管它」最终殊途同归：进退役流水线。