【背景】
做了 5 年算法工程，前 3 年大部分时间其实在搭指标体系：从最初「有什么埋什么、看板铺满 200 个指标」，到后来被迫做减法。现在负责一个日活 300 万级的推荐服务，核心指标从最初 140+ 砍到了 12 个，告警只配了 5 条。砍的过程非常痛苦——每砍一个都有人问「万一后面要用呢」，但砍完之后 on-call 的响应时间反而从平均 40 分钟降到了 12 分钟。
我特别想听大家聊聊：你们团队的核心指标到底定了几个？怎么定的？
【常见分歧 / 几种做法】
我在不同团队见过三种典型路线，取舍差异很大：
路线 A：「全量埋点，按需取用」
- 做法：所有接口、所有分支、所有业务事件都打点，Prometheus / 自建 Metrics 里躺着 500+ 个 time series。
- 优点：排查问题时「数据都在」，不用重新加埋点上线。
- 代价：指标之间口径经常打架（同一个「成功率」在网关层、服务层、业务层各算一套）；新 on-call 同学面对 200 个指标不知道先看哪个；Prometheus 内存和查询延迟随 series 数线性涨。
路线 B：「北极星 + 护栏，5~10 个封顶」
- 做法：只保留 1 个北极星（比如 P99 延迟或业务转化率）+ 3~4 个护栏指标（错误率、资源饱和度、数据一致性），其余指标降级为「debug 专用」，不进看板。
- 优点：告警聚焦，on-call 认知负荷低，指标口径容易对齐。
- 代价：遇到「指标之外的异常」（比如某个特定租户的慢查询把整体 P99 拉高了 0.3ms 但不破阈值）时，缺乏细粒度数据兜底。
路线 C：「分层指标，按角色切视图」
- 做法：同一套底层数据，按 SRE（基础设施层）、业务（转化漏斗层）、算法（模型质量层）分三套视图，每套 10~15 个指标。
- 优点：各角色看到自己关心的维度，不会因为「看板太杂」而忽略关键信号。
- 代价：维护成本高，底层指标口径变更时三套视图要同步改；跨层关联分析（比如模型延迟涨了但业务指标没动）需要额外工具串联。
【我的倾向与理由】
我倾向 路线 B 的骨架 + 路线 C 的切法，具体是：
- 核心指标 ≤ 8 个，且必须满足「30 秒内能看懂、3 分钟内能定位到 owner」。超过这个数，on-call 的认知负荷就开始指数涨了。
- 每个核心指标必须绑定一条告警规则和一个 on-call 响应 SOP——没有 SOP 的指标等于没配。
- debug 指标单独维护，命名前缀统一（比如
debug_），不进主看板、不参与告警，但查询时随时可用。这样既保住了「全量数据」的排查能力，又不污染核心视图。 - 指标口径写入代码注释 + 团队 wiki，而不是只存在某个人的脑子里。我见过最糟的情况：同一个「请求成功率」，网关层是 HTTP 2xx / total，服务层是业务 code=0 / total，算法层是「模型输出非空 / total」——三个数对不上，排查时先花 1 小时对齐口径。
但我不确定的是：当团队规模从 5 人扩到 30 人时，「8 个核心指标」这个数该线性增长还是保持不动？ 这是我现在最纠结的。
【想听大家怎么选】
- 你们团队的核心指标定了几个？有没有一个明确的「准入标准」？
- 指标口径不一致的问题，你们是靠「指标字典」文档解决，还是靠「指标即代码」（比如 metric registry）解决？
- 从 5 人团队扩到 30 人，你们的指标体系是「加指标」还是「加视图」？
- 有没有过「砍指标砍错了、后来不得不加回来」的经历？
欢迎拍砖，尤其是路线 A 的拥趸——我想听听你们是怎么在 500 个指标里保持 on-call 不崩的。
0赞
0收藏
0楼层