《后端架构设计·高性能与高可用》附录 B 性能指标速查

指标分四层

看性能问题时，先确认指标属于哪一层。层次混在一起，讨论就会失焦。

业务指标是最终判据，应用指标用于定位，依赖和主机指标用于解释原因。只有主机指标没有业务指标，会出现“机器很闲但用户在下单失败”；只有业务指标没有应用指标，知道出事了却不知道在哪一层。

延迟指标

常用分位数

延迟必须带口径：客户端、服务端入口、业务内部还是下游单次。同一个请求，四种口径能差出几倍。报告里写“P99 20ms”而不写口径和样本量，等于没写。

直方图与合并

分位数不能直接平均。两个实例各报 P99，一个是 10ms，一个是 1s，平均得 505ms，但合并后的真实 P99 是 1s。下面这段输出来自 .local/reports/be-arch/be-arch-perf-02-3-result-capacity-headroom-run.txt，总样本 2000：

instance_a_p99=10ms instance_b_p99=1s average_of_p99=505ms merged_p99=1s total=2000

正确做法是合并直方图的桶计数，再重新计算分位数。合并的前提是桶边界一致；桶不一致时，只能重新采集，不能强行合并。代码里如果只存了一个 p99 字段，这个指标在聚合后就失去意义。

分位数之外

分位数描述分布，但不描述“多久”。两个系统 P99 都是 100ms，一个每 10 秒出现一次尖峰，一个持续抖动，用户体验不同。补充指标：

• 超时率：超过 SLO 上限的请求占比；
• 慢请求数：绝对数量，避免小流量下分位数失真；
• 最大延迟：用于发现极端个案，但不能作为 SLO；
• 延迟分布：按 10ms、50ms、100ms、500ms、1s 分桶，直观看形状。

吞吐指标

压测报告至少给三组数：到达、完成、拒绝。只给一个“QPS 5000”，无法判断系统是轻松完成还是靠拒绝维持。

吞吐和延迟不是独立指标。系统接近饱和时，吞吐趋于平稳，延迟快速上升；这时再加压力，完成的请求不会变多，只会让排队更深。

并发与排队

利特尔法则

稳定系统中：

并发数 L = 到达率 λ × 平均停留时间 W

例如到达率 200 rps、平均停留 50ms，则平均在途请求为 10。反过来，若连接池只有 8 个，系统会在池上排队，实际停留时间变长，直到 L 与池容量重新平衡。

利特尔法则只适用于稳定状态。压测刚开始、流量突增、系统正在恢复时，L 与 λ×W 不相等，不能拿瞬时值硬套。

排队指标

排队是非线性的。利用率 50% 时，延迟约等于服务时间；利用率 80% 时，排队显著增加；利用率 95% 时，轻微波动就会造成长队列。容量规划留余量，本质上是在避开这段非线性区。

错误与可用性

可用性“几个 9”的年度停机时间：

这些数字是理论上限，不是承诺。达到几个 9，取决于故障检测、切换和恢复的实际速度，而不是写在文档里的目标。

错误预算

错误预算 = 1 − SLO。月 SLO 99.9% 意味着每月允许约 43.8 分钟不可用，或者按请求折算的失败比例。预算用完，应该冻结变更、优先修复；预算充足，可以承担更高风险的发布。错误预算的作用是把“要不要发”从争论变成算式。

资源饱和度

饱和度指标要结合延迟看。CPU 90% 但 P99 稳定，可能只是压测机忙；CPU 50% 但 P99 飙升，瓶颈可能在锁、I/O 或下游。

缓存指标

命中率不是越高越好。把不常访问的数据也缓存起来，命中率可能上升，但内存被占满后淘汰增加，真实收益下降。更有用的指标是“命中带来的延迟节省”和“回源给下游的压力”。

治理指标

这些指标要能按调用方、按接口、按实例拆分。只有一个全局“熔断次数”，无法判断是哪个下游、哪个版本、哪台机器触发的。

公式速查

公式只给数量级，不能替代实测。峰值系数、单实例容量、冗余系数都要用真实数据校准；没有数据时，写“示例值”。

单位换算

报告里统一用 ms 和 QPS，避免同一张表里出现秒、毫秒、微秒混用。带宽和存储的 GB 含义不同（十进制与二进制），跨团队沟通时写清单位。

SLO 怎么写

SLO 不是“系统要稳定”，而是一句可计算的承诺。一个可用的写法包含四部分：

完整表述是：“28 天滚动窗口内，下单接口 99.9% 的请求 P99 延迟不超过 400ms。” 这句话能直接换成查询，也能直接算错误预算。

SLI、SLO 与 SLA

SLA 一般比 SLO 宽松，留出内部缓冲。把 SLO 直接写成 SLA，等于没有缓冲；把 SLA 当 SLO，团队会长期在“刚好不赔钱”的边缘运行。

选择指标的三个原则

第一，从用户动作出发。用户关心“下单成功且不太慢”，不关心某台机器的 CPU。

第二，少而可行动。一个核心链路三到五个 SLO 足够，太多会没人看。

第三，能被现有数据计算。没有采集的指标，先补采集，再谈 SLO。

指标采集的三种方式

三种方式可以并存，但同一指标不要用两种方式重复采集，否则会出现两个略有差异的数字，排查时互相打架。

标签与基数

标签让指标可下钻，也会让序列数量爆炸。安全的标签：接口名、状态码、实例、区域、版本。危险的标签：用户 ID、订单号、请求 ID、原始 URL、错误消息。

一个粗略的判断：标签取值超过几百个，就要考虑换成日志或追踪。时间序列数量 = 指标数 × 每个标签的取值数之积；四个标签各 100 个取值，就是一亿条序列。

从指标到行动

指标本身不产生价值，能触发动作才有价值。建议给每个核心指标配一条判断路径：

这张表的作用是防止“看到指标就动手”。大部分错误处置不是因为不看指标，而是因为看了指标却跳过了定位。

十种常见误读

第一，平均延迟正常就认为系统正常。平均值掩盖尾部，P99 才是用户感知。

第二，把两个实例的 P99 平均。分位数不可平均，必须合并直方图。

第三，把到达数当吞吐。开环压测的到达数由速率决定，与系统能力无关。

第四，把拒绝算成错误。限流拒绝是保护生效，应单独统计。

第五，只看 QPS 不看完成率。高 QPS 伴随高超时，等于系统在空转。

第六，用 CPU 使用率判断瓶颈。CPU 不高但延迟高，问题可能在锁、I/O 或下游。

第七，忽略排队时间。连接池等待、队列等待都是用户真实等待。

第八，把命中率当缓存效果。命中率上升但回源延迟没降，说明缓存的是便宜数据。

第九，拿不同口径的数字比较。客户端 P99 和服务端 P99 不是一回事。

第十，用单次压测证明容量。单次结果受机器、数据、预热影响，至少三次并给区间。

最小仪表盘

如果只能保留一屏指标，建议按下面排列：

每个指标都要能下钻到接口、实例和时间段。不能下钻的仪表盘，只能告诉你“出事了”，不能告诉你“去哪看”。

常见错误与边界

第一，指标没有单位。延迟是 ms 还是 s，吞吐是每秒还是每分钟，必须在图名和字段名里写清。

第二，采样率不一致。有的指标每秒采一次，有的每分钟一次，放在同一张图上会出现虚假的尖峰和平台。

第三，聚合维度丢失。只保留全局值，无法区分是单实例故障还是全站问题。

第四，保留时间太短。故障复盘常需要上周甚至上月的对比数据，至少保留 30 天。

第五，指标基数爆炸。把用户 ID、订单号放进标签，会导致时间序列数量失控；需要高基数分析时用日志或追踪，不用指标。

第六，把目标值画成实测值。SLO 线和实际延迟线要视觉区分，否则会被误读为“一直达标”。

小结

性能指标分业务、应用、依赖、主机四层。延迟看分位数和分布，不看平均；分位数不能平均，只能合并直方图。吞吐要区分到达、完成和拒绝。并发用利特尔法则估算，排队在利用率超过 70%–80% 后非线性上升。错误率、超时率和拒绝率要分开统计，可用性目标要能换算成错误预算。

资源、缓存和治理指标用于解释原因，不用于下最终结论。所有指标都要带单位、口径、聚合维度和采样周期。附录 C 把这些读数放进故障演练的检查表，确保演练时看的是同一组信号。