稳定性监控：从指标到治理

SLI/SLO/SLA

SLI：服务等级指标（Measure，用来 “量化” 的尺子） 客观、可采集、可计算的原始监控指标，是衡量服务稳不稳定的实际数据，不带目标值，只是 “观测值”。 SLO：服务等级目标（Target，设定的合格标准） 基于 SLI，人为约定可接受的指标阈值，是内部研发 / 运维的质量红线；系统正常运行要满足这个目标。 SLA：服务等级协议（Contract，对外承诺 + 违约后果） 面向客户 / 业务方的正式协议，把 SLO 包装成对外承诺，一旦达不到约定标准，会有赔付、补偿、降级等处罚条款。 简单一句话区分： SLI = 你监控到的数据（比如接口成功率 99.95%） SLO = 你要求达到的标准（比如接口成功率≥99.9%） SLA = 写进合同的对外承诺（达不到就赔）

把监控分为“业务指标”和“技术指标”，作为汇报目录可以，但作为稳定性治理体系不够合理。它最大的问题不是分错，而是分类维度太粗，无法直接回答三个关键问题：

1. 用户是否已经受影响？
2. 系统为什么出问题？
3. 谁应该采取什么动作？

例如“账户查询成功率”既是业务指标，也是 HTTP/RPC 技术指标；“交易量下降”可能代表系统故障，也可能只是正常业务波动。业务与技术并不是互斥集合。

更合理的主分类：按稳定性因果链分层

我建议采用“用户结果 → 服务质量 → 应用 → 依赖 → 资源 → 变更”的分层方式。

层级	回答的问题	典型指标	作用
L0 用户与业务结果	核心业务是否真的完成	核心流程成功量、业务成功率、金额/数量异常、处理时效、数据正确率	判断实际业务影响
L1 服务质量 / SLO	服务对消费者是否可用	可用率、错误率、P95/P99 延迟、超时率、数据新鲜度	告警和稳定性目标的核心
L2 应用行为	哪个接口或模块异常	请求量、错误率、耗时、线程池、队列堆积、异常类型	定位故障模块
L3 外部依赖	是否由上下游或中间件导致	Dubbo 调用、数据库连接池、缓存命中率、MQ 延迟、第三方接口	判断故障边界
L4 基础资源	是否存在容量或运行环境问题	CPU、内存、GC、磁盘、网络、Pod 重启、连接数	根因分析和容量预测
L5 变更与风险事件	为什么现在发生	发布、配置变更、扩缩容、流量切换、依赖升级	建立故障与变更的关联
L6 监控系统自身	监控结论是否可信	up、抓取失败、数据延迟、序列数突变、告警链路状态	防止“系统坏了但监控也瞎了”

你当前 mid-account 的指标基本集中在 L2～L4，例如：

• L2：http_server_requests_seconds_*、tomcat_global_error_total
• L3：dubbo_*、druid_*
• L4：jvm_*、process_cpu_usage、system_cpu_usage
• L6：up、scrape_*

明显缺少的是 L0 和 L1。如果直接拿现有 JVM、Druid、Dubbo 指标构建稳定性大盘，它会成为“技术运行状态大盘”，但不能可靠说明账户服务是否正常。

不要只做一套互斥分类

更成熟的做法是：使用上述因果链作为主目录，再给每个指标增加几个正交属性。

1. 症状指标与原因指标

• 症状：成功率、延迟、正确率、业务量异常。
• 原因：CPU、GC、连接池、线程池、依赖超时。

告警应优先基于症状，原因指标用于诊断。仅因为 CPU 达到 80% 就叫醒值班人员，通常是不合格的告警；CPU 高但服务正常未必需要立即处理。

2. 领先指标与滞后指标

• 领先指标：线程池队列增长、数据库连接池接近耗尽、磁盘剩余空间下降。
• 滞后指标：请求失败、业务成功量下降、客户投诉。

只看滞后指标发现得太晚；只看领先指标又容易制造大量误报，两者要配合。

3. 黑盒与白盒

• 黑盒：从消费者角度主动访问系统，检查能否真正完成关键流程。
• 白盒：系统内部暴露的 HTTP、JVM、数据库连接池等指标。

Prometheus 中应用自报的 http_server_requests_* 并不能替代黑盒探测，因为应用实例失联时，它可能连指标都无法上报。

指标方法可以复用，但不应成为顶层分类

常见方法适合放在不同层级中：

• 接口和服务用 RED：请求率、错误率、耗时。
• 基础资源用 USE：使用率、饱和度、错误。
• 用户体验用四个黄金信号：流量、错误、延迟、饱和度。
• 稳定性目标用 SLI/SLO：可用性、延迟、正确性、数据新鲜度等。

它们是指标设计方法，不是完整的监控治理框架。

我的结论

“业务指标 + 技术指标”可以保留为面向管理层的简化视图，但不建议作为监控体系的顶层设计。更合理的是：

以用户结果和 SLO 判断影响，以应用、依赖、资源指标定位原因，以变更事件解释时间关联，以监控自检保证数据可信。

真正有效的大盘也不应该简单堆指标，而应按故障处理顺序组织：

1. 用户和核心流程是否受影响；
2. 哪个服务、接口、地域或租户受影响；
3. 是应用、依赖还是资源问题；
4. 故障前发生过什么变更；
5. 当前该由谁采取什么动作。

如果一个指标发生异常后无法对应明确动作，它通常不应该成为告警，只适合留在诊断大盘中。