前面有一段时间，我专门在补监控这块。面板做了，指标埋了，告警也配了，交付时看着挺完整。真等线上出问题，尴尬很快就出来了：这些东西很多时候没人用，或者到了最该用的时候，也帮不上太多忙。

这事挺打脸。明明花了不少精力补系统能力，现场排查时大家还是先去翻日志、查数据、找人问情况。面板不是完全没用，但离“出了事先打开它”还差得远。

因为很多时候，图确实不少。

• 接口有成功率
• MQ 有堆积
• 线程池有活跃线程数
• 数据库有 RT
• 缓存有命中率

看上去系统像是被照得很亮，真到线上出问题，团队第一反应却还是翻日志、查数据、问业务、看群消息，最后再靠经验猜哪里最可疑。

回头复盘时，尴尬的地方就出来了：系统里并不缺指标，缺的是能在现场帮上忙的指标。

它们没法及时告诉你业务是不是已经受损，也很难在故障刚冒头时帮你判断影响面，更别说直接带着团队往下一步动作走。看起来已经有一套可观测体系了，手里攒下的却主要还是一堆数字。

一堆很安静的数字。

这件事最别扭的地方在于，业务关心的问题都很具体：

• 订单到底有没有成功创建
• 支付成功以后有没有真正发货
• 仓内任务有没有在承诺时间内完成
• 对账结果有没有准时、准确地出来

但系统里最显眼的图，多半还是接口、线程池、队列和数据库。技术对象当然要看，可如果它们始终接不到这些业务问题上，指标就会越做越多，现场还是要靠人脑把“这条线抖了一下”翻译成“哪块业务可能已经出事了”。

而且这里还有一层很现实的使用摩擦。很多面板都是我们这边统一配好再交过去，不是业务 owner 自己一路搭出来的。这样做短期当然快，但副作用也很明显：等出问题时，那个最需要看面板的人，多半不熟这个面板是按什么思路切的，也不知道哪些图该先看，哪些波动其实不用管。面板明明在那里，但它没有真的长进对方的处理习惯里。

我想复盘的就是这件事：为什么很多系统指标做了不少，最后还是看不见该看的问题；以及这件事该怎么从存量补洞，走到增量准入。

一、真正卡住我们的，是指标老在关键时候帮不上忙

线上常见的尴尬，基本都落在两类。

第一类是，业务已经受损了，指标却没把它照出来。

比如接口整体成功率还可以，但失败的偏偏是最关键的一类请求；比如消费速率看着正常，但某类高优先级消息已经延迟很久；比如总吞吐没掉，但某个区域、某个仓、某类业务已经明显退化。

第二类是，出事以后图也在那儿，但团队还是很难靠它快速缩小范围。

面板上能看到服务还活着，能看到有波动，甚至能看到某些均值还不错，但这些信息离判断业务有没有受损、影响面落在哪、问题更像哪一类，还差一大截。

说白了，做出来的更像一个数字陈列柜，不像一套能发现问题的东西。

二、为什么会长出一堆无效指标

现在回头看，这种失效一点都不奇怪。很多指标从一开始就是沿着错误路径长出来的。

先不说技术设计，光是“怎么让人愿意用”这件事，很多团队就已经吃亏了。面板如果需要重新认图、重新学路径，出事时自然没人爱用；如果还要业务同学为了看懂它再学一套 Prometheus 表达式、临时拼查询，那更不现实。现场的约束很简单：根本没有那么多时间给你重新熟悉工具。

1. 指标围着技术对象长，业务风险却一直没接进来

技术指标最容易做。

接口 RT、错误率、QPS、线程池活跃数、消息堆积、数据库慢查询、缓存命中率，这些天然能采，也天然容易上图。

但业务关心的，是这些事：

• 这条业务有没有成功完成
• 关键链路有没有超时
• 有没有漏处理、错处理、重复处理
• SLA 有没有失守
• 用户是不是真的受到了影响

结果就是一个很典型的错位：技术指标很完整，业务风险却不可见。

你知道“服务在跑”，业务是不是健康却还是看不清。

2. 指标只负责展示，不负责动作

还有一种很常见的情况，是指标做出来了，但没有绑定动作。

这个指标异常了，代表什么？ 谁该看？ 先做什么？ 什么时候要升级处理？ 要不要限流、降级、熔断、补偿？

这些问题如果没有答案，指标很快就会退化成背景噪音。图挂在那里，告警偶尔也会响，但团队并不真的靠它做决策。

一个指标异常了，如果大家还是不知道下一步怎么办，这种指标就很难算管控手段，只是被存下来的数字。

3. 这些指标更像在描述“平时”，对“异常怎么长出来”不够敏感

很多图平时看着很稳定，但它们对故障并不敏感。

• 只看平均值，不看分位数，尖刺会被吞掉
• 只看总量，不看分桶，局部故障会被整体数据掩盖
• 只看技术成功率，不看业务完成率，业务失败会被误判成系统正常
• 只看当前值，不看趋势，持续退化很难提前被识别

系统很多时候会先慢慢变坏，再一点点扩散。有价值的指标，应该能把这个“变坏的过程”照出来。

4. 面板明明交付了，为什么真到现场还是没人用

这件事我后来不太愿意轻描淡写带过去，因为这里暴露的是设计问题，不只是推广问题。

很多平台侧做监控时，很容易默认一种交付方式：我们把指标、图、告警都统一配置好，再交给业务团队使用。这样做当然快，也显得很标准。但真到线上出事，这套东西经常会遇到两个很现实的问题。

第一个问题是，不熟就不会用。

人一旦不熟一个面板，就很难在高压状态下自然地打开它、信任它、顺着它排下去。平时看着图很多，真出事时还是会回到自己最熟的路径：翻日志、查 DB、找开发、问业务、看群消息。这不是大家不用心，故障现场根本不会给你留出一段“先重新熟悉面板”的时间。

第二个问题是，面板如果不是自己参与做出来的，真出事时就很难知道该先看什么。

业务 owner 关心的是哪条流程、哪个仓、哪类单据、哪个租户先坏，哪些波动该紧张，哪些其实可以先放过去。这些判断如果不是他自己参与过切维度、挑图、定阈值，最后很容易出现一种状态：平台侧觉得自己已经把面板交付了，业务侧却只觉得“这里图很多，但我不知道先看哪张，也不知道看到这个值以后该不该动”。

所以后来我不太认同“统一配置完再交付”就算治理完成。更稳的做法，通常是平台把基础能力和默认骨架先兜住，再让业务 owner 把自己的结果视角接进去。这样这套东西才更可能真的进入他们平时的处理路径里。

三、什么样的指标，才算真的有用

这些年我更倾向于用四条很朴素的标准去判断一个指标值不值得做。

第一，它得映射业务结果。
至少能回答业务有没有受损，用户有没有感知，承诺有没有失守。

第二，它得能识别异常。
问题刚冒头时它就会先跳出来，而不是等到事故复盘才发现它原来很重要。

第三，它得能辅助定位。
它不一定直接给根因，但至少要帮团队快速缩小范围，判断这是局部问题、全局问题，还是某个环节在退化。

第四，它得能驱动动作。
看到异常之后，团队知道该限流、降级、熔断、切换、补偿，还是先通知业务。

如果一个指标做不到这几件事，它当然也有信息价值，但未必有治理价值。

四、补存量，得补四层能力

很多团队踩坑之后，第一反应都是“再补几个监控”。这一步多半不够。后面其实缺的，是结果、过程、定位和动作这几层能力。

1. 先补业务结果指标，而且先把核心业务和边界说清

这一步最容易被一句空话带过去：要贴近业务。

真落地时，不能只停在这五个字上。更具体的起手式应该是先把两件事说清楚：

第一，当前系统里哪些才算核心业务。
不是所有接口、所有任务、所有状态变化都同样重要。核心业务通常是那些一旦出问题，业务立刻会感知、客户立刻会投诉、或者收入和履约立刻会受影响的流程。

第二，每条核心业务的边界到底是什么。
到底是“请求进来了”就算完成，还是“主流程写库成功”才算完成；是“消息投递成功”就算完成，还是“下游真正处理完并回写结果”才算完成；是“系统返回成功”就算完成，还是“仓库、结算、通知这些后续动作都兑现”才算完成。

这两件事不先定，后面的业务指标很容易做偏。因为你会发现，很多团队其实默认拿系统动作代替业务结果。

比如下单链路里，只看“创建订单接口 200 成功率”通常不够。业务关心的，很可能是：

• 订单有没有真的落单成功
• 支付后的履约有没有准时启动
• 超过承诺时效的比例有没有抬头
• 失败以后有没有进入补偿，补偿最后有没有补回来

再比如仓储或履约链路里，只看消费吞吐也远远不够。业务更关心的往往是：

• 高优先级任务有没有在承诺时间内完成
• 哪类仓、哪类单据、哪类渠道已经开始积压
• 延迟是不是已经影响到出库、签收或结算

所以业务结果指标要回答的，是“这条核心业务的承诺有没有兑现”。比如成功率掉了，还是时效变差了；是最终完成率不达标，还是数据一致性出了问题；是超时比例升高了，还是补偿量、人工介入量开始异常了。

这类指标不直接告诉你根因，但它能第一时间回答最关键的一件事：业务到底有没有受损，损失先落在哪。

2. 再补过程健康信号

结果指标告诉你“有没有出事”，过程指标才帮你看到“问题怎么长出来”。

比如：

• 入口流量是不是异常
• 排队时长是不是在拉长
• 重试率是不是持续上升
• 依赖失败率是不是在抬头
• 某个关键步骤是不是开始超时
• 补偿执行量是不是明显增加

过程指标的意义不在于把每个组件都扫一遍，而在于围绕最容易失守的业务处理环节去布点。

如果核心业务是“支付成功后两分钟内要把履约任务发出去”，那你最该盯的过程信号应该是支付回调有没有堆，履约消息有没有延迟，补偿任务是不是突然变多，而不是某个线程池是不是 70% 活跃。如果核心业务是“晚班波次前必须把关键仓任务清掉”，那过程信号就应该贴着波次、仓、单据类型和积压时长来长，不要只看一个全局消费速率。

3. 再补切开看的定位能力

很多团队不缺总量图，缺的是把问题切开的能力。

总成功率看着没问题，某个区域却已经明显下降；整体延迟还行，某类业务已经开始堆积；总错误率不高，但某个下游依赖其实已经退化得很厉害。

这时候如果指标没有按关键维度分桶，团队最后只能重新回到日志和经验上。

所以成熟一点的指标体系，至少得能按业务类型、区域、仓库、租户、渠道、下游系统、消息类型、集群这些关键维度拆开看。没有这层能力，很多图更适合拿去汇报，不太适合拿来排障。

因为业务现场会追问的，往往就是这些：“是不是华东仓先退化了”“是不是某个租户先扛不住了”“是不是只有新流程、只有某类单据、只有某个下游在出问题”。

4. 最后补动作闭环

这层最容易被忽略，但其实最值钱。

每个关键指标，最好都能回答这些问题：

• 异常阈值是什么
• 谁负责看
• 第一动作是什么
• 多久内要处理
• 要不要升级
• 有没有自动化止损手段

比如堆积时长过阈值，要不要限流入口；依赖超时率持续升高，要不要先熔断非关键流量；关键链路完成率下降，要不要通知业务并切到降级方案。

指标如果不带处理动作，算不上监控，只能叫观赏数据。

四层之间的流向和反馈大致长这样：

flowchart TD
    BIZ["核心业务承诺"] --> R["结果指标<br/>业务有没有受损"]
    R -->|"发现异常"| P["过程信号<br/>问题怎么长出来"]
    P -->|"需要定位"| L["定位维度<br/>按区域/仓/租户切开"]
    L -->|"确认影响面"| A["动作闭环<br/>限流·降级·熔断·补偿"]
    A --> FP["事故复盘"]
    FP -->|"该响没响的指标"| R
    FP -->|"缺失的切分维度"| L

五、存量补齐，最好按风险倒推

存量系统最怕东补一块、西补一块，看起来忙了很久，体系还是不成形。

更有效的做法是倒过来：先不讨论“我现在能采什么”，先讨论“我最怕什么”。

对每条关键流程，都先列失败模式清单：

• 它会怎么失败
• 失败之后业务会怎么感知
• 会不会静默失败
• 会不会局部故障但整体数据看不出来
• 会不会先慢慢退化，再集中爆发

这张清单一旦列出来，指标设计反而会清楚很多。因为这时候你已经在围绕真实风险倒推结果指标、过程指标、定位维度和动作闭环，不是在空想指标。

事故复盘也应该反过来服务这件事。每次复盘，不妨都追三句：

• 事故发生前，有没有本该先响但没响的指标
• 事故发生时，有没有响了却没帮助判断的问题
• 事故发生后，有没有因为缺少关键维度，导致排查明显变慢

很多指标体系都是被事故一遍遍打磨出来的。

六、只补存量还不够，增量必须做准入

如果文章只写到补旧坑，其实还差半步。

更现实的问题是，很多团队一边补老系统的观测盲区，一边在新需求上线时继续制造新的盲区。老债还没还完，新债已经又欠下了。

所以这件事如果只讲存量补齐，始终不完整。视角还得再往前走一步：

• 补存量，是还旧债
• 管增量，是少欠新债

而且增量其实更适合做这件事。因为新需求刚接入时，很多东西天然是清楚的：它要解决什么业务问题，成功标准是什么，最怕什么失败方式，上线后最担心什么风险。这个阶段反而最适合把指标、告警和预案前置进去。

七、增量需求该怎么设计指标

我更认同从下面四个问题倒推，不要只停在一句空话“这个需求也要补监控”。

1. 业务承诺是什么，核心业务边界画在哪

这个需求上线后，业务最在意的到底是什么结果。

是成功率、时效、准确性、一致性、完成率，还是某种 SLA。

但这里还得再往前追一步：这个需求到底落在哪条核心业务上，它的完成边界画到哪。

比如一个“自动补货优化”需求，上线后业务在意的可能是补货建议有没有按时生成、关键 SKU 有没有错过补货窗口、最后有没有影响仓内作业。又比如一个“账单推送”需求，边界最好画到客户侧确实收到了、账单状态确实更新了、失败任务有没有在承诺时间内补回来，而不是停在“消息发出去了”。

指标设计的第一步，要先把这条业务承诺和它的边界说清楚，不要先盯着系统会经过多少组件。没有这个前提，后面的设计很容易重新滑回技术埋点堆砌。

2. 失败模式是什么

这个需求最可能怎么坏。

会不会超时、积压、重复执行、部分成功部分失败、静默失败，还是依赖抖动导致整体退化。

很多过程指标，其实都是从这些失败模式里自然长出来的。先看“这个需求可能怎么失败”，再决定“我该采什么”，路径会顺很多。

3. 影响范围按什么维度切

这个需求如果出问题，最需要按哪些维度切开看。

是区域、仓库、租户、渠道、下游系统、消息类型、新老版本，还是机房集群。

很多线上问题卡在只有总量，没有维度。整体看上去没问题，局部其实早就炸了。增量设计里，应该提前把这些维度想清楚。

4. 异常之后要触发什么动作

哪些指标要配告警，阈值怎么设，谁负责看，异常后的第一动作是什么，要不要降级、限流、熔断、补偿或者人工介入。

如果一个新需求只有埋点，没有告警和处理预案，那它还不具备上线后的可运维性。

八、这件事不能主要靠自觉，最后还是要靠机制

说到这里，最现实的问题就来了：这些道理很多团队都知道，但到了执行层面，未必能稳定做到。

这并不奇怪。真实工程环境里，排期、交付压力、上线窗口，永远会把“先把功能做完”推到最前面。监控、告警、预案这些事，虽然大家都知道重要，但也最容易被压缩掉。

所以如果只是提倡“新需求上线时顺手把指标补齐”，这件事大概率是落不稳的。难点不在认知，还是在机制上有没有东西拦住它被跳过。

我更倾向把它落在三件事上：门禁、模板、平台默认能力。

1. 门禁

在需求评审、技术方案评审阶段，就强制把几个问题说清楚：

• 这次改动对应的是哪条核心业务
• 这条业务的完成边界画到哪里
• 这个需求的业务成功标准是什么
• 失败时业务怎么感知
• 上线后靠哪些指标判断健康
• 哪些指标需要告警
• 谁来处理
• 异常后的第一动作是什么

发布前也应该有更硬一点的校验：核心指标是否已埋点，关键告警是否已配置，仪表盘是否可查看，埋点和告警通路是否至少验证过一次。

2. 模板

只靠门禁，很容易变成填表。还得有模板把经验沉淀下来。

比如评审模板里固定有“可观测性”一栏；新接口、新消费链路、新任务框架都带默认指标清单；不同类型需求都能对应一套最小可用观测模板。

模板的意义，是减少“每次都从头想一遍”的成本，不是让大家再多写一份材料。

但这里有个边界我现在很在意：模板可以统一，面板最好不要只靠平台侧包办到底。

因为业务 owner 会不会用，不取决于我们交付时讲得多完整，而取决于这些面板是不是跟他平时判断业务状态的方式连在一起。只有他自己参与过“我要看哪几个结果、按什么维度切、异常时先盯哪张图”，这些面板才更可能在出事时被真的打开。

所以更稳的方式通常是：平台给默认模板、给基础组件、给最小可用骨架，业务 owner 在这个基础上把自己的核心视角补进去。机制和业务如果不在这一步接上，后面就很容易变成平台觉得自己已经交付了，业务觉得这套东西还是别人的。

这里还要补一句，不然很容易被理解错：我说业务 owner 要自己参与面板，不是说让他们从零写查询、从零拼 PromQL，也不是把监控平台本身甩给业务。更合理的分工应该是，平台把采集、聚合、模板、默认图和基础告警先兜住，把复杂语法和基础设施细节吃掉；业务 owner 负责把“我最关心哪条业务、按什么维度切、哪些结果最不能坏”这层判断放进去。只有这样，业务和机制才算真的接上。

3. 平台默认能力

更成熟的做法，是平台层直接兜底。

比如新接口脚手架默认带基础指标，消息消费默认带吞吐、延迟、失败率、重试率，发布系统默认校验监控配置，仪表盘和告警模板可以自动生成。

有效的治理，是把正确做法变成最省力的默认路径，不要额外要求大家多做一步。凡是依赖“大家记得做”的事情，最后都不稳定。

这里最关键的是低摩擦，不是平台多强。业务团队不可能为了把机制跑起来，再额外学一套 PromQL、记一堆监控平台语法、重新理解一整套面板设计哲学。平台该做的，是把这些复杂度吃掉，让业务 owner 更容易说清“我最关心哪条业务、我想按什么维度看、出问题时先看哪几个信号”，别逼他们先成为半个监控专家，才有资格把自己的业务看明白。

九、怎么防止门禁重新变成形式主义

门禁本身不是万能药。如果最后只是多填一张表、多贴一张截图，它很快就会失去意义。

更有效的办法，是让结果反过来约束过程。每次线上事故复盘时，都追问几件事：

• 这个功能上线时有没有定义核心业务指标
• 有没有本该配置却没配置的告警
• 评审时为什么没识别这个风险
• 这次暴露的是存量盲区，还是增量准入失效

如果一个新功能出了问题，最后发现连最基本的业务指标都没有，这就不只是单点疏漏，说明准入机制本身失效了。

结尾

现在再回头看，这件事最难的，还是“能不能稳定做到”。

大家知道指标要贴近业务，也知道新需求应该前置监控、告警应该绑定动作。难的是，这些正确的事能不能在持续交付、多人协作和上线高压里稳定发生。

所以指标建设的价值，不在于让 Grafana 更好看，也不在于让系统显得更像“有治理”。它的意义在于让团队更早看见问题，更快判断影响，更明确地行动。

说到底，指标做了，然后呢？

我的答案是：它不能只用来证明系统还活着。它得让团队知道哪条业务正在变坏、边界坏在了哪里，以及下一步该做什么。