3. 异常波动分类体系
在压力测试中，异常波动的表象千差万别，但归纳起来，可以从两个维度建立清晰的分类体系：按现象分类（解决“看到了什么”）和按根因分类（解决“为什么发生”）。掌握这套分类体系，是快速定位根因的第一步。
3.1 按现象分类：四类核心指标异常
压力测试的异常波动最终都会体现在四个核心指标上：TPS（吞吐量）、RT（响应时间）、错误率、资源利用率。下表总结了每类现象的典型特征与排查方向：
| 现象类别 | 核心指标 | 典型特征 | 初步排查方向 |
|---|---|---|---|
| TPS 骤降 | TPS 曲线断崖式下跌 | 并发用户数未变，TPS 突然从高位跌至接近 0 或低位 | 连接池耗尽、线程池阻塞、数据库死锁、网络分区 |
| RT 飙升 | 平均/TP99 响应时间陡增 | 响应时间从毫秒级升至秒级甚至分钟级 | CPU 争抢、GC 停顿、慢查询、IO 等待、队列堆积 |
| 错误率突增 | HTTP 5xx/4xx、业务错误码激增 | 错误率从接近 0% 突然升至 10% 以上 | 超时配置、限流触发、依赖服务熔断、数据校验失败 |
| 资源打满 | CPU/内存/磁盘 IO/网络带宽 100% | 资源利用率持续高位，伴随其他指标恶化 | 代码死循环、内存泄漏、日志刷盘、大流量冲击 |
实战提示：四类现象往往不是孤立出现的。例如，TPS 骤降通常伴随着 RT 飙升和错误率突增，而资源打满可能是前三种现象的根因。排查时建议以“最先出现的异常指标”作为切入点。
下图展示了四类异常现象在时间轴上的典型表现形态：
3.2 按根因分类：四大根因域
现象只是表象，根因才是解决问题的关键。根据实战经验，异常波动的根因可以归纳为四个领域：代码、中间件、基础设施、外部依赖。每个领域都有典型的故障模式。
| 根因域 | 典型故障模式 | 常见表现 | 排查手段 |
|---|---|---|---|
| 代码 | 死循环、内存泄漏、线程阻塞、慢 SQL、大对象分配 | CPU 打满、堆内存持续增长、线程池耗尽、RT 抖动 | 火焰图、堆转储分析、代码 Review、慢查询日志 |
| 中间件 | 连接池耗尽、GC 停顿、队列堆积、缓存穿透、主从延迟 | TPS 骤降、RT 飙升、连接超时、错误率突增 | 中间件监控面板、GC 日志、连接池指标、队列深度 |
| 基础设施 | CPU 争抢、内存不足、磁盘 IO 打满、网络带宽瓶颈、宿主机干扰 | 资源利用率 100%、系统负载高、IO 等待长 | 系统监控（CPU/Mem/IO/Net）、容器指标、宿主机排查 |
| 外部依赖 | 下游服务超时、第三方 API 限流、数据库连接失败、DNS 解析慢 | 错误率突增、RT 飙升、部分请求成功部分失败 | 链路追踪、依赖健康检查、超时/重试配置、熔断状态 |
避坑指南：不要被现象迷惑。例如，TPS 骤降时，如果只盯着中间件排查，可能忽略了代码中的死锁问题。建议按照“现象 → 根因域 → 具体组件”的路径逐层下钻，而不是跳跃式猜测。
下图展示了从现象到根因域的映射关系，以及每个根因域包含的典型组件：
3.3 分类体系实战应用：从现象到根因的排查路径
在实际压测中，建议按照以下步骤应用分类体系：
- 识别现象：通过监控面板确认是 TPS 骤降、RT 飙升、错误率突增还是资源打满，或者多种现象组合。
- 定位根因域：根据现象组合和资源指标，初步判断根因属于代码、中间件、基础设施还是外部依赖。
- 下钻到组件：在确定的根因域内，使用对应的排查工具（火焰图、GC 日志、系统监控、链路追踪）定位具体组件。
- 验证修复：修改后重新压测，确认异常波动消失，且没有引入新的问题。
案例速览：某次压测中，TPS 从 5000 骤降至 200，同时 RT 从 20ms 飙升至 5s，错误率从 0% 升至 15%。按照分类体系：现象组合为 TPS 骤降 + RT 飙升 + 错误率突增，资源指标显示 CPU 未打满但连接池活跃数达到上限。根因域定位为中间件，下钻发现数据库连接池最大连接数配置过小，压测流量超过连接池上限导致请求排队超时。调整连接池大小后，TPS 恢复至 4800，RT 降至 25ms，错误率归零。
3.4 分类体系的价值总结
建立异常波动分类体系的核心价值在于：
- 标准化沟通：团队成员使用统一的术语描述问题，减少沟通成本。
- 加速排查：通过现象到根因域的映射，快速缩小排查范围，避免盲目猜测。
- 知识沉淀：每次压测异常都可以归类归档，形成组织级的故障模式库。
- 自动化预警：基于分类体系，可以设计更精准的告警规则，减少误报和漏报。