新系统上线前，延迟、错误率、成本——你只盯哪一个作为「北极星」？

背景

做了 15 年算法，从推荐系统到数据平台都带过。最近帮两个团队搭新系统的观测体系，发现一个很有意思的现象：大家的监控面板都很漂亮，但被问到「这个系统上线后，你每天早晨第一件事看哪个数字」时，答案惊人地不一致——

• 有人盯 P99 延迟，认为快慢是用户体验的命脉；
• 有人盯错误率 / 5xx 比例，认为稳定压倒一切；
• 有人盯成本（QPS × 单次调用成本），因为老板只看账单；
• 还有人盯「请求成功率」或「SLA 达标率」，试图用一个综合指标兜底。

常见分歧

1. Google 四信号（延迟、流量、错误、饱和度）是否过时？ 微服务时代，四信号分散在几十个服务里，「看四个」等于「没看」。
2. 综合指标是偷懒还是聚合？ 「SLA 达标率」把延迟和错误揉在一起，数字好看时掩盖了结构性问题；拆开看又容易顾此失彼。
3. 成本是不是伪指标？ 很多团队把「单次请求成本」当北极星，结果优化成了「少调下游」，而不是「调得更聪明」。
4. 新系统 vs 老系统的优先级完全不同。 新系统要「先跑起来」，老系统要「别出事」，同一套指标体系未必适用。

我的倾向

我比较坚定地认为：延迟（P99）应该是技术团队的北极星，理由有三：

• 它是用户感知最直接的信号，错误率是「有没有」，延迟是「好不好」；
• 错误率通常要么 0 要么 100%（二值化），延迟是连续分布，能更早暴露退化；
• 成本是结果指标，延迟是过程指标——盯住延迟，成本自然有约束（延迟高 → 资源多 → 成本高，因果链清晰）。

但我也承认，这个答案高度依赖场景：B 端批处理系统、AI 推理服务、实时风控……最优解可能完全不同。

想听大家聊聊

• 你当前负责的系统，早晨第一件事看哪个数字？为什么是它？
• 有没有过「北极星选错了」导致团队优化方向跑偏的经历？
• 如果你的系统同时服务 C 端用户和 B 端 API 调用方，你会怎么拆指标？

欢迎带具体场景来聊，越具体越好。