后端系统和服务稳定性，核心指标通常可以分成 6 组来看：
SLA（Service Level Agreement）
QPS（Queries Per Second）
文章目录
-
- [1. 可用性指标](#1. 可用性指标)
- [2. 延迟指标](#2. 延迟指标)
- [3. 吞吐与容量指标](#3. 吞吐与容量指标)
- [4. 资源健康指标](#4. 资源健康指标)
- [5. 依赖稳定性指标](#5. 依赖稳定性指标)
- [6. 恢复能力指标](#6. 恢复能力指标)
- [如果只能抓最核心的 8 个](#如果只能抓最核心的 8 个)
- 不同角色最该看什么
- 一个常见的指标分层方法
- 一个经验结论
1. 可用性指标
这是最核心的一层，回答"服务是不是能正常用"。
-
Availability / SLA / SLO
- 可用率，例如 99.9%、99.95%
- 常见公式：
成功服务时间 / 总服务时间
-
错误率
- 5xx 比例
- 业务失败率
- 接口异常率
-
成功率
- 请求成功数 / 总请求数
- 有时比"错误率"更直观
这组指标最适合做高层稳定性看板。
2. 延迟指标
服务没挂，不代表服务可用；慢到超时，本质上也等于不可用。
-
平均响应时间
- 参考意义有限，容易被掩盖
-
P50 / P90 / P95 / P99 延迟
- 最重要的是尾延迟，尤其是 P95/P99
-
超时率
- 请求超时占比
-
排队时间
- 在线程池、连接池、消息队列里等待的时间
稳定性场景里，P99 延迟通常比平均延迟更值得盯。
3. 吞吐与容量指标
回答"系统在多大压力下还能稳住"。
-
QPS / RPS / TPS
- 每秒请求数、事务数
-
并发数
- 同时处理中的请求数
-
带宽/流量
- 入站、出站流量
-
队列堆积
- MQ backlog
- 任务积压数
-
容量使用率
- 当前负载占设计容量的百分比
这组指标用来判断是不是"流量打满导致不稳定"。
4. 资源健康指标
回答"服务为什么不稳，底层资源有没有问题"。
-
CPU 使用率 / Load
-
内存使用率
- 尤其关注 OOM、内存泄漏趋势
-
GC 指标
- GC 次数、GC 停顿时间（JVM 很关键）
-
磁盘
- IOPS、磁盘使用率、磁盘延迟
-
网络
- 丢包率、重传率、连接数
-
文件句柄 / 线程数 / 连接池使用率
- 很多服务雪崩都卡在这些地方
这类指标更偏"根因定位"。
5. 依赖稳定性指标
后端服务通常不是单机问题，而是依赖链问题。
-
数据库指标
- 连接数
- 慢查询数
- 锁等待
- 主从延迟
-
缓存指标
- 命中率
- 淘汰率
- 连接超时
-
消息队列指标
- 积压量
- 消费延迟
- 重试率
-
下游 API / 微服务依赖
- 成功率
- 延迟
- 超时率
- 熔断次数
-
DNS / 注册中心 / 配置中心
- 可用率、错误率、响应时间
实际线上故障里，很多"本服务故障"本质是 依赖故障放大。
6. 恢复能力指标
稳定性不只是"少出故障"，还包括"故障后恢复得快不快"。
-
MTTR（平均恢复时间）
- Mean Time To Recovery
-
MTBF（平均故障间隔）
- Mean Time Between Failures
-
故障次数
- 按周、按月统计
-
告警到发现时间
-
发现到止损时间
-
止损到恢复时间
管理层和稳定性负责人通常会非常关注这组指标。
如果只能抓最核心的 8 个
很多团队一开始不要铺太多，先盯这 8 个最有效：
- 可用率
- 请求成功率
- 5xx 错误率
- P95 / P99 延迟
- QPS / 并发数
- CPU / 内存使用率
- 下游依赖成功率和延迟
- MTTR
不同角色最该看什么
管理层/项目负责人
更关注结果型指标：
- 可用率
- 严重故障次数
- MTTR
- 业务成功率
- 核心链路 SLO 达成率
开发/架构/运维
更关注过程型指标：
- P99 延迟
- 错误率
- 资源使用率
- 数据库慢查询
- 缓存命中率
- 队列积压
- 依赖服务异常
一个常见的指标分层方法
可以按这三层设计监控体系：
- 用户层：成功率、延迟、可用率
- 服务层：QPS、错误率、线程池、连接池
- 基础设施层：CPU、内存、磁盘、网络
- 依赖层：DB、Redis、MQ、下游服务
一个经验结论
稳定性里最容易犯的错有两个：
- 只看平均值，不看分位数
- 只看自己服务，不看依赖链路
所以实践里，通常会把：
成功率 + P99 延迟 + 依赖成功率 + MTTR
作为最小闭环。