指标与目标 on Dorkytiger 的小屋

指标分四层，缺一层就无法定位

Mon, 01 Jan 0001 00:00:00 +0000

1.1 指标分四层，缺一层就无法定位

上一节：无　|　下一节：1.2 百分位不可平均配套代码：01-metrics-and-slo/01-four-layers-of-metrics

一句话结论

性能指标分四层：业务层、延迟层、资源层、饱和度层。 只监控前两层，你会在「服务变慢了」和「为什么慢」之间卡住；而饱和度层是最早的预警信号，它在用户受影响之前就开始报警。

一、用汽车仪表盘理解「为什么指标要分层」

想象你开车，车上只有一个速度表：

速度表显示 60 km/h —— 车在正常行驶。
突然，速度掉到 20 km/h。

你知道出问题了，但完全不知道原因：是没油了？发动机过热？轮胎漏气？还是前面堵车？

现在把仪表盘补全：

仪表	对应层级	告诉你什么
速度表	业务层	车跑得快不快（QPS）
乘客的等待时间	延迟层	体验好不好（P99）
油量、转速、水温	资源层	消耗了什么（CPU / 内存 / GC）
水温警告灯、油量警示灯	饱和度层	离出问题还有多远

关键洞察：速度和等待时间都是「已经发生的结果」，而警告灯是「即将发生问题的预警」。

速度掉到 20 km/h 时，问题已经发生了，你只能被动应对。
水温警告灯亮起时，你还有时间靠边停车。

性能工程里最值钱的指标，是那些「用户还没受影响，但系统已经在告警」的指标。 这就是饱和度层。

二、四层指标详解

第 1 层：业务层 —— 「服务好不好用」

指标	含义	常见坑
QPS / RPS	每秒处理的请求数	分母应该是「成功完成」的请求
错误率	失败请求占比	必须与延迟一起看（否则会「优化」出更多错误）
超时率	超时请求占比	与错误率分开统计（超时和报错的处理方式不同）
Apdex	满意度指标（快 / 可接受 / 慢三档）	阈值必须来自业务可感知边界，不能拍脑袋

回答的问题：用户现在体验如何？

百分位不可平均：直方图才是正解

Mon, 01 Jan 0001 00:00:00 +0000

1.2 百分位不可平均：直方图才是正解

上一节：1.1 指标分四层　|　下一节：1.3 测量点配套代码：01-metrics-and-slo/02-percentiles-and-aggregation 前置：0.3 延迟是分布（百分位的定义）

一句话结论

百分位是一个「位置」，不是一个「可加减的量」。 把多台机器的 P99 求平均，得到的数字不代表任何一台机器、也不代表任何用户。正确做法是：采集直方图（分桶统计），在查询时合并后再算百分位。

一、用考试成绩理解「位置」与「数量」的区别

一个班 50 个学生考试。老师说：

「我们班的平均分是 78 分。」「我们班的第 95 百分位分数是 96 分。」

现在把三个班合起来，问「全校的 P95 是多少」：

班级	人数	平均分	P95 分
一班	50	78	96
二班	50	80	97
三班	50	76	95

❌ 错误做法：(96 + 97 + 95) / 3 = 96。

为什么错：「第 95 百分位」是「排在第 95% 位置上的那个分数」。三个班的「第 95% 位置」是三个不同的位置，把它们平均，得到的不是任何一个真实位置上的分数。

✅ 正确做法：把 150 个分数合在一起重新排序，再取第 95% 位置。这个结果可能不是 96、97、95 中的任何一个。

测量点：同一个请求，三个不同的数字

Mon, 01 Jan 0001 00:00:00 +0000

1.3 测量点：同一个请求，三个不同的数字

上一节：1.2 百分位不可平均　|　下一节：1.4 SLO 的四要素写法配套代码：01-metrics-and-slo/03-measurement-points

一句话结论

「这个接口要 200 ms」这句话，缺了最重要的一个信息：在哪测的。 客户端测出 200 ms、网关测出 120 ms、服务端 handler 内部测出 30 ms——三个数字都是对的，但它们回答的是不同的问题。混着用，就会得出错误结论。

二、用快递物流理解「测量点」

你在网上买了一件商品，想知道「多久能到」。可以打卡的地方有很多：

打卡点	记录的时间	用户关心吗
你下单的时刻	起点	✅ 用户从这里开始等
仓库开始打包	分拣耗时	❌ 用户不关心，但仓管关心
打包完成、交给快递	打包耗时	❌ 但能定位「是不是仓库慢」
快递在路上	运输耗时	部分关心
快递到达你所在城市	分拨耗时	❌
快递员按门铃、你签收	终点	✅ 用户等的是这个

「送达需要 3 天」这句话：

从「下单」算：3 天。这是用户体验。
从「出库」算：2.5 天。这是物流公司内部的绩效。
从「到达本市」算：6 小时。这是末端配送的效率。

三个数字都对，但你不能拿「末端配送 6 小时」去论证「用户 3 天能收到」。

后端的测量点完全同理。

三、三个测量点

3.1 客户端（压测工具 / 真实用户浏览器 / App）

延迟 = 收到响应的时刻 − 发出请求的时刻

包含：客户端排队 + 网络往返 + 网关 + 服务排队 + 服务处理 + 响应传输。

SLO 的四要素写法

Mon, 01 Jan 0001 00:00:00 +0000

1.4 SLO 的四要素写法

上一节：1.3 测量点　|　下一节：1.5 延迟预算配套代码：01-metrics-and-slo/04-writing-slo

一句话结论

「P99 < 200 ms」不是一个 SLO，只是一半句话。 完整的 SLO 必须包含四要素：指标 + 阈值、负载与数据前提、测量点、持续时长。少了任何一项，验收时都会吵架（而且通常是上线后才吵）。

一、用「验收合同」理解 SLO

假设你要装修房子，和施工队签合同。你在合同上写：

「装修要好。」

施工队会问你一堆问题：

你的原话	施工队必须追问	对应 SLO 的要素
「装修要好」	「哪方面好？水电？墙面？隔音？」	指标
「墙面要平」	「多平算平？误差几毫米？」	阈值
「要平」	「房子多大？什么结构？现在什么状况？」	负载与数据前提
「要平」	「用谁的尺子量？从哪量到哪？」	测量点
「要平」	「验收时看一次，还是住半年后还得平？」	持续时长

SLO 就是你和系统签的验收合同。 一份只有「装修要好」的合同，结局一定是扯皮。

二、四要素详解

要素 1：指标 + 阈值

必须明确是哪个指标（P99？P95？错误率？吞吐？）和具体数值。

❌ 模糊	✅ 明确
「响应要快」	P99 < 200 ms 且 P999 < 500 ms
「要稳定」	错误率 < 0.1%，超时率 < 0.05%
「能扛住」	稳定支撑 500 RPS

要点：延迟类 SLO 至少写两个分位数（P99 + P999，或 P95 + P99）。只写一个分位数时，你不知道「剩下那 1% 有多糟」。

延迟预算：把 200 ms 拆到每一跳

Mon, 01 Jan 0001 00:00:00 +0000

1.5 延迟预算：把 200 ms 拆到每一跳

上一节：1.4 SLO 的四要素写法　|　下一节：1.6 基线与容量曲线配套代码：01-metrics-and-slo/05-latency-budget

一句话结论

延迟预算把「优化」从「猜哪里慢」变成了「看哪一跳超预算」。 它还能顺带解决一个高频故障源：超时设置必须逐层递减，否则会出现「上游已经超时返回，下游还在傻等」的级联堆积。

一、用「出门旅行的预算」理解延迟预算

假设你今天上午有 4 小时（240 分钟）要完成三件事：去银行、去超市、回家做饭。

你会本能地做预算：

环节	预算	实际
路上通勤	40 min	35 min ✅
银行排队 + 办理	60 min	95 min ⚠️
超市采购	50 min	45 min ✅
做饭	60 min	55 min ✅
余量	30 min	10 min

结果一目了然：超预算的是「银行」这一环，其他都正常。你不需要分析每件事，直接就知道问题在哪。

如果没有预算，你只知道「今天超时了 25 分钟」，然后要挨个回忆哪一步慢了。

后端的延迟预算完全同理——把总延迟拆给每一跳，谁超了就是谁的问题。

二、一个完整的延迟预算表

目标：订单查询接口，客户端视角 P99 ≤ 200 ms。

环节	预算 (P99)	说明
客户端 → 网关（网络 + 客户端排队）	25 ms	同城网络、连接复用
网关处理（TLS / 鉴权 / 限流）	15 ms	含一次鉴权缓存查询
应用排队（调度 / 线程 / 连接）	20 ms	饱和度升高时最先牺牲的一项
应用逻辑（业务 + 序列化）	50 ms	你写的代码
├ PostgreSQL	60 ms	复杂查询上限
├ Redis	5 ms	单次命令
└ 下游 HTTP 依赖	40 ms	含重试预算
响应传输	10 ms	—
余量	— 已超	见下方说明

先别急着看数字——这张表其实是故意算错的，用来讲第二件事：预算必须自洽。

基线与容量曲线：拐点才是容量

Mon, 01 Jan 0001 00:00:00 +0000

1.6 基线与容量曲线：拐点才是容量

上一节：1.5 延迟预算　|　下一节：1.7 实验元数据配套代码：01-metrics-and-slo/06-baseline-and-capacity-curve

一句话结论

「CPU 打满时的 QPS」不是容量，「延迟开始非线性上升的那个点」才是容量。 前者是崩溃点，后者是拐点。容量规划要取拐点再打折，取崩溃点等于计划着让服务宕机。

一、用「高速公路」理解容量曲线

高速公路的通行能力，是一个非常好的类比：

车流量	表现
很少（20%）	你可以跑到 120 km/h，速度稳定
中等（50%）	还是 120 km/h，几乎不受影响
偏多（75%）	偶尔要减速，速度掉到 100 km/h
接近饱和（90%）	速度骤降到 40 km/h，开始走走停停
完全饱和（100%）	完全堵死，通行量反而下降

注意最后一行：车流再多，路的通行量反而下降（因为车距变小、刹车波传播）。这在交通工程里叫「相变」，在排队论里就是第 0 章讲的非线性。

关键洞察：

你绝对不会说「这条路能通行 100% 的车流」——那意味着堵死。
你会说「这条路在开始堵之前，每小时能过 2000 辆车」。
那个「开始堵」的点，就是拐点（knee）。

后端服务完全一样：

QPS 低时，延迟平稳；
QPS 到某个点后，延迟开始非线性上升（拐点）；
继续加压，延迟爆炸、错误率上升（崩溃点）；
再加压，实际 QPS 反而下降（因为请求超时、重试、连接被占满）。

二、基线：没有参照物的数字没有意义

2.1 一个残酷的类比

你家的体重秤显示 70 kg。这个数字是好是坏？

如果你上个月是 65 kg → 涨了 5 kg，需要关注。
如果你上个月是 75 kg → 减了 5 kg，进展良好。
如果你从来没有称过 → 你只知道「70 kg」，无法判断。

性能数字完全一样：

实验元数据：没有它，数字等于没有

Mon, 01 Jan 0001 00:00:00 +0000

1.7 实验元数据：没有它，数字等于没有

上一节：1.6 基线与容量曲线　|　下一节：1.8 案例解剖配套代码：01-metrics-and-slo/07-experiment-metadata

一句话结论

一个性能数字，如果没有配套的「实验条件」，就是不可用信息。 就像菜谱写「加盐适量」——你自己下次也做不出同一道菜。元数据清单的作用是：让三个月后的你（或另一个工程师）能复现出同样的数字。

一、用「菜谱」理解元数据

一份能用的菜谱：

中火，橄榄油 15 ml，蒜末 10 g，翻炒 90 秒，加盐 2 g。

一份没用的菜谱：

用合适的火候，加点油和蒜，炒一会儿，调味。

差别就在于「条件是否可复现」。 性能数据完全一样：

没用的说法	有用的说法
「压测了一下，P99 是 180 ms」	「JDK 21 + 默认 GC、4C8G、100 万行齐夫分布、k6 恒定到达率 500/s、预热 60 秒、稳态 5 分钟，客户端测得 P99 = 180 ms」

第二句话，别人能复现；第一句话，只是一次性的观察。

二、九项清单（缺一项都可能无法复现）

① 代码版本

内容：commit hash 或镜像 tag。
为什么必须：代码变了，性能就变了。这一项缺失，整个实验无法回溯。

② JVM 版本与完整参数

内容：JDK 发行版与版本号 + 完整的 JVM 启动参数（堆大小、GC 选型、-XX 开关）。
为什么必须：-Xmx 从 2g 改到 4g，GC 行为完全不同；换一个 GC 可能让吞吐差 20%。
常见错误：只写「JDK 21」，不写堆大小和 GC 类型。

③ 机器规格

内容：CPU 型号与核数、内存、磁盘类型（SSD/网络盘）、NUMA、是否容器。
为什么必须：「4 核」不等于「4 核」——不同代 CPU 的单核性能可能差 2 倍。
常见错误：写「8 核 16G」，但没写是物理机、云主机还是容器。

④ 容器与编排配置

内容：CPU limit / request、内存 limit、是否有 sidecar、副本数。
为什么必须：容器 CPU 节流是「本地压测很好、上线就慢」的头号原因。limit 设成 1 核时，即使宿主机有 32 核，你的进程也只能用 1 核，而且会被周期性掐停。

⑤ 操作系统与内核参数

内容：OS 与内核版本、文件描述符上限、somaxconn、CPU governor。
为什么必须：文件描述符上限会直接限制并发连接数；CPU governor 设为省电模式会导致频率波动，让数据抖动。

⑥ 数据库与中间件

内容：版本、规格、关键配置（连接数上限、缓存大小、隔离级别）、连接池配置。
为什么必须：PostgreSQL 的 max_connections、shared_buffers 直接决定性能上限。

⑦ 数据集：规模 + 分布

内容：数据量级、访问分布（均匀 / 幂律，幂律要写 alpha）、是否预热缓存、连接是否复用。
为什么必须：这是最常被忽略的一项。1 万行 vs 1 亿行会导致执行计划完全不同；均匀分布 vs 幂律分布会让缓存命中率差几倍。

⑧ 压测方式

内容：工具与版本、流量模型（到达率 / 虚拟用户）、目标 QPS、预热时长、测量时长、脚本 commit。
为什么必须：闭环模型会系统性低估尾延迟（第 0 章 0.6 节）。不写模型，读者无法判断数据可信度。

⑨ 测量点与观测工具

内容：客户端 / 网关 / 应用内（见 1.3 节）、观测工具与采样频率、直方图桶边界。
为什么必须：不同测量点的数字不能比较；桶边界不对会让分位数失真。

三、两个真实的反例

反例 1：漏了 JVM 参数

实验 A（上周）：P99 = 120 ms
实验 B（本周）：P99 = 95 ms，结论「优化有效，提升 21%」

真相：本周换了 JVM 参数（堆从 2g 到 4g，GC 从 G1 换 ZGC），
      代码一行没改。所谓「优化」是环境变化带来的。

教训：只有 JVM 参数被记录，这个错误才能被发现。

案例解剖：P99 达标，用户仍然不满

Mon, 01 Jan 0001 00:00:00 +0000

1.8 案例解剖：P99 达标，用户仍然不满

上一节：1.7 实验元数据　|　下一节：1.9 Lab 1

一句话结论

「指标达标」和「用户满意」之间的差距，通常不是测量精度问题，而是四个具体的方法错误。 这一节把第 0、1 章的所有检查点，装进一个完整的排查故事里。

一、案例背景

产品经理的投诉：

「我们的订单详情页最近用户投诉变多了，说很卡。但你们的监控显示 P99 只有 180 ms，完全达标啊？」

技术团队手上的数据：

指标	数值	状态
订单查询接口 P99（服务端埋点）	180 ms	✅ 达标（SLO 是 200 ms）
错误率	0.05%	✅
QPS	850	✅
CPU	55%	✅

表面上一切正常，但用户确实在抱怨。 接下来是排查过程。

二、四个原因，逐个揪出来

原因 ❶：只统计了成功请求

检查动作：看延迟统计的分母是什么。

// 问题代码
val timer = Timer.builder("http.server.requests").register(registry)
timer.record(duration) { /* 只有走到这一步的请求才被记录 */ }

// 请求在超时或抛异常时，根本没有走到 record()

发现：这个接口有 3% 的请求在 2 秒后超时并被网关中断，但这些请求根本没进入延迟统计——它们被算成了「错误」，从延迟样本中消失了。

结果：统计里只剩「又快又成功」的请求，P99 自然漂亮。

Lab 1：写出你的第一份 SLO 与延迟预算

Mon, 01 Jan 0001 00:00:00 +0000

1.9 Lab 1：写出你的第一份 SLO 与延迟预算

上一节：1.8 案例解剖　|　下一节：第 2 章 Kotlin/JVM 性能基础配套代码：01-metrics-and-slo/09-lab1 预计时长：60 分钟

一、这个 Lab 的目标

把本章的理论变成两张能贴在墙上的表，以及一个被修正的埋点。

不需要你压测出数据（那是第 3–4 章的事），只需要你把「要测什么、怎么算达标」想清楚。这一步想不清楚，后面所有压测都是白压。

二、任务清单

#	任务	产出	时长
1	选 2 个接口，写完整 SLO 表	`docs/slo.md`	20 min
2	为较复杂的接口写延迟预算表	同上文件	20 min
3	找出并修正一个错误埋点	代码改动 + 说明	15 min
4	建实验档案	`docs/experiments/E01-.../README.md`	5 min

三、任务 1：SLO 表

接口选择建议：选一个「读多写少、调用数据库」的接口，和一个「写操作、有事务」的接口。这样能覆盖两种不同的延迟特征。

SLO 表必须包含四要素（见 1.4 节）：

字段	你的填写
接口
关键路径	客户端 → ? → ? → ?
目标 QPS	（写峰值，不是平均）
P50 / P95 / P99 / P999
错误率阈值
负载前提（数据量 + 分布 + 缓存状态）
测量点	客户端 / 网关 / 应用内
持续时长（预热 + 稳态）
环境（实例规格、副本数）
崩溃线（压力测试终止条件）
测量日期与版本

自检三问（答不上来就重写）：