2. 关键性能指标（KPI）体系：指标树结构
做压测最怕什么？不是数据跑不准，而是不知道到底该看哪些指标。我刚带团队那阵子，项目组测完把几百行数据扔过来，问“性能怎么样”，我对着屏幕愣了五分钟——TPS挺高，但用户抱怨慢；CPU没跑满，但内存报警。后来我才明白：指标没串起来，等于白测。
这一章咱们就聊聊怎么把杂乱的技术数据整理成一棵“指标树”，从业务感知一直挖到系统内核。你想想看，CEO 关心的是“用户能不能正常下单”，运维盯的是“CPU 负载多少”，这俩中间缺的就是层映射关系。
2.1 为什么需要指标树？
说白了，业务方和技术方的关注点天然隔着一层墙。业务要的是“接口成功率 99.9%”，可工程师拿到的却是“HTTP 500 次数/秒”。不建好映射，就会出现——
- 底层优化脱节：程序调了连接池，业务说“没感觉快”，因为没有映射到响应时间变化。
- 资源浪费：压测时只盯着 TPS，结果缓存命中率掉到 30% 都没发现，硬抗了一堆慢查询。
- 决策困难：上线前该加机器还是优化代码？指标树能帮你一眼看出瓶颈点。
我个人的习惯是：压测前先画一张指标树草图，哪怕只写几个框。等项目跑完，拿着真实数据往上一填，问题就暴露了。
2.2 指标树的层次结构
指标树分三层：业务层 → 技术层 → 资源层。往下是层层支撑，往上是层层推导。举个例子——
业务层定义“请求成功率 ≥ 99.5%”，映射到技术层就是“HTTP 4xx/5xx 占比 ≤ 0.5%”，再往下需要资源层保证“CPU 负载 ≤ 70%、内存使用率 ≤ 80%”。你会发现，任何一个业务指标最终都能拆解到若干个技术指标和资源指标上。
我曾经在某支付系统的压测里吃过亏：业务要求“下单接口 3 秒内完成 95%”，我盯着 TP99 死磕，结果发现 TP50 一直是 200ms 很漂亮，但偶发的长尾请求（2000ms+）把 TP99 拉到了 4 秒。后来查 是 数据库连接池偏小，慢请求排队了。这个教训告诉我：指标树里不能只看平均值，分位值的映射同样关键。
| 层级 | 关注点 | 典型指标 | 数据来源 |
|---|---|---|---|
| 业务层 | 用户体验、业务目标 | 接口成功率、平均响应时间、吞吐量（订单/秒） | APM、业务监控 |
| 技术层 | 服务维度、调用链 | QPS、TP50/TP90/TP99、错误率、连接池等待数 | 中间件指标、日志采集 |
| 资源层 | 主机、容器、网络 | CPU 使用率、内存使用量、磁盘 IOPS、网络带宽 | OS 监控、云平台 |
2.3 从业务到技术的映射方法
映射不是简单的翻译，它包含两步：分解和定量。
- 分解：把业务指标拆成多个技术分项。例如“下单成功率”拆为“登录接口成功率 + 订单创建接口成功率 + 支付回调接口成功率”。每个技术接口再往下拆资源依赖。
- 定量：给每个技术指标定一个可测量的阈值。比如业务要求“99.9% 成功率”，那技术层“登录接口失败率”就不能超过 0.03%（因为几个接口串行失败率叠加后要满足总失败率 ≤ 0.1%）。
嗯，这里有个坑——很多人在定量时忘了“误差叠加”。比如说一个接口调用下游三个服务，每个服务的 TP99 都是 100ms，你以为总耗时是 300ms？错了，实际是 P(三个独立变量同时 99%) 极低，但末端 TP99 往往比简单相加要高 40%~60%。我之前就因为这个估算偏差，出现场景设计过度，测出来完全不达标，白白多配了三台机器。
2.4 指标树的可视化设计
光有结构还不够，得画出来。平时我习惯用 SVG 或图表工具做单页的指标树图，压测前贴在墙上，验收时逐层打勾。下面是我常用的一张结构图——
2.5 指标之间的关联与权衡
指标树画出来只是第一步。真正的价值在于你发现 指标之间的“跷跷板”关系。我碰到的典型例子是——
- 吞吐量 vs 响应时间：提高并发数，吞吐量上去了，但 TP99 往往跟着涨。你得找到一个平衡点。曾经有个系统，我们硬把并发从 200 压到 500，TPS 涨了 40%，但 TP99 从 500ms 跳到了 3s，业务直接炸锅。后来我们把并发限制在 300，配合连接池优化，才同时达标。
- 资源利用率 vs 错误率：把 CPU 推到 95% 确实能压出更高 TPS，可一旦 CPU 满负载，GC 变频繁、线程调度变慢，错误率就抬头。我的血泪教训是：线上环境的 CPU 安全线最好设在 70%，压测时最多冲到 80% 就停。
- 缓存命中率 vs 数据一致性：为了压测时缓存命中率高，有人把过期时间设到 1 小时，结果数据不一致导致业务逻辑出错——缓存命中率上去了，但业务层成功率下来了。指标树里必须在同一层级互相约束。
权衡的本质：指标树不是静态的“分层达标”，而是一张动态的权衡网。每改动一个资源指标，都要回溯到业务层验证整体 KPI 是否依旧满足。我个人压测最后一步永远是：回到业务层，重跑一遍端到端场景看全链路。
2.6 如何用指标树指导压测设计
当你手里有了一棵完整的指标树，压测场景设计就变成了一门填空艺术：
- 反向推导：从底层逐步向上压，先确认资源层能否扛住目标负载，再验证技术层，最后用业务场景收尾。这样哪层先爆一目了然。
- 边界点注入：关键指标（如 TP99、错误率）往往在某个资源临界点附近发生突变。我习惯在指标树上标记 轻、中、重 三个区间，然后用压测工具逐级加压，观察哪条“链路”先断。
- 建立告警映射：上线后把指标树的叶子节点挂到监控上，任何一个资源指标抖动，都能向上追溯到影响的技术指标和业务指标。这就叫“根因可追溯”。
常见误区：很多团队只关注技术层指标（QPS、TP99），忽略了资源层和业务层。结果上线时 QPS 完美，但业务反馈“卡”，一查发现资源层内存泄漏已在悄悄积累。记住：业务层才是最终判官。
总结一下这一章的核心：指标树把模糊的业务要求变成了可测量、可调试的技术路线。它既是一张压测前的 设计图纸，也是压测后的 故障诊断图。你想想看，如果只盯着散落的 CPU、QPS、成功数，这和瞎子摸象有什么区别？
下一段咱们会讲怎么给每个指标定 基线 和 基线漂移 的阈值——说白了，就是告诉机器：什么数值是正常的，什么数值该报警。而这些都基于你刚刚画好的那棵指标树。