performance-report-analysis

性能报告分析器

解读性能测试结果、识别瓶颈、按严重程度分类，并生成两份结构化报告——一份面向技术人员，一份面向业务相关方。此技能从测试结束后开始发挥作用。

范围边界：此技能涵盖测试运行之后的结果分析与沟通。若要规划运行哪些测试、确定 VU 数量或设置 SLA，请改用 performance-testing-strategy。

输出格式

完成步骤 1–3 后，交付两份产出：

1. 技术报告——面向工程师和 QA：原始发现、根因分析、严重程度分类，以及具体的修复步骤。
2. 业务报告——面向相关方：业务影响说明、风险评级和建议的决策——不包含原始百分位数值。

---

步骤 1 — 收集结果

不要直接开始分析。先提出以下问题，并按逻辑分组。等待对方回答后再继续。目标是从已经运行过测试的人的角度了解结果，而不是规划新的测试。

A 组 — 必须询问（每次分析都要问）

首先询问这些问题，即使用户已经粘贴了原始输出也不例外：

1. **工具和测试类型：**此报告由哪个工具生成？（k6、Gatling、Locust、JMeter、Artillery 或其他）——测试属于哪种类型？（负载、压力、峰值、耐久性、冒烟）
2. **测试是否完成？**测试是否运行了完整的配置时长，并达到目标用户数 / RPS？如果没有，结果可能不完整或不可靠。
3. **谁会阅读报告？**只有工程师和 QA？经理或团队负责人？业务相关方或高管？——这决定了要生成技术报告、业务报告，还是两者都生成。

B 组 — 仅在粘贴的输出中缺少相关信息时询问

只询问用户分享的数据中尚未提供的信息：

• **百分位数：**是否有 p95 和 p99，还是只有平均值 / 均值？
• **SLA 目标：**通过 / 失败的阈值是什么？（例如，p95 < 800ms、错误率 < 1%）——如果未设定阈值，询问：对用户来说，什么样的响应时间是不可接受的？
• **错误详情：**错误是否有具体消息？（超时、连接被拒绝、5xx、断言失败）——错误类型会影响诊断结果。

C 组 — 输出显示异常时询问

仅当分析发现需要更多上下文的问题时才询问：

• **基础设施数据：**测试期间是否启用了监控？（CPU、内存、数据库指标、APM）——缺少这些数据，就无法确认瓶颈假设。
• **基线：**是否有之前运行相同测试的结果？——检测回归时必须提供。
• **基础设施事件：**测试期间是否发生任何异常情况？（部署、重启、告警、外部事件）

**规则：**如果只有平均值 / 均值，没有百分位数，也没有 SLA 目标，切勿进入步骤 2。 如果用户无法提供 SLA，则采用行业默认值：p95 < 1000ms、错误率 < 1%，并在报告中明确说明这一假设。

仅当用户粘贴了 k6、Gatling、Locust、JMeter 或 Artillery 的原始输出，并需要帮助阅读或解读该工具报告中的特定字段、图表或部分内容时，才加载 references/TOOL-REPORT-FORMATS.md。

仅当用户询问某项指标为何下降——例如 CPU 飙升、内存增长、查询缓慢、连接池耗尽或第三方依赖缓慢——才加载 references/BOTTLENECK-PATTERNS.md。

仅当准备好生成最终技术或业务报告草稿时，才加载 references/REPORT-TEMPLATES.md。

---

步骤 2 — 分析发现

2.0 排查顺序 — 始终从这里开始

收到结果后，按以下顺序评估。如果在任何一步发现阻断问题，请停止并报告：

1. 先看错误率 — 如果基线负载下出现错误，那就是 Bug，而非容量问题。修复 Bug 之前，容量数据无效。
2. 测试是否达到目标负载？ — 如果 VU 数量或 RPS 始终未达到配置的峰值，结果就是不完整的。请明确说明这一限制。
3. 全局 p95 与 SLA — 稳态下最重要的 SLA 是否达标？
4. 延迟随时间的变化趋势 — 测试过程中性能是否稳定，还是中途出现了下降？（内存泄漏、预热、资源耗尽）
5. 各端点细分数据 — 问题具体出在哪个端点？如果有各端点的数据，切勿只报告全局指标。

2.1 SLA 合规性检查

对每项指标，将实际值与目标值进行比较：

指标	目标	实际值	状态
p95 响应时间	< X ms	Y ms	PASS / FAIL
p99 响应时间	< X ms	Y ms	PASS / FAIL
错误率	< X%	Y%	PASS / FAIL
吞吐量	≥ X RPS	Y RPS	PASS / FAIL

切勿对百分位数取平均值。 p95 = 所有请求的第 95 百分位数 — p95 为 1.2s，意味着 5% 的用户经历了 ≥ 1.2s 的延迟。这是一个精确值，不是平均值。

2.2 延迟分布分析

健康与退化的特征：

模式	表示的情况
p50 ≈ p95（分布集中）	性能稳定且可预测
p95 >> p50（分布宽、长尾）	存在异常值 — GC 暂停、锁竞争、缓存未命中、数据库延迟突增
p50 随负载上升	达到饱和 — 系统正在对请求排队
p99 >> p95	偶发严重停顿 — 排查重试、超时、外部依赖
p95 随用户数增加而线性上升	符合预期 — 并非 Bug；确认其仍在 SLA 范围内
p95 超过某个阈值后呈指数级上升	已到达拐点 — 找出曲线的膝点

2.3 错误率分析

诊断前先对错误分类：

• 超时错误 — 请求始终未能完成：表示系统达到饱和或下游响应缓慢
• 4xx 错误 — 负载下出现客户端错误：通常是测试数据问题（令牌过期、数据缺失）
• 5xx 错误 — 服务端故障：过载、未处理的异常、OOM 崩溃
• 连接错误 — 连接被拒绝或重置：基础设施限制（连接池、防火墙、最大线程数）

随负载增长而出现的错误率（基线下不存在）是容量信号，而非 Bug 信号。即使在低负载下也存在的错误率则是 Bug — 应先修复，再解读容量数据。

2.4 回归检测

存在基线时，始终计算变化量：

指标	基线	当前值	变化量	是否标记？
p95	A ms	B ms	+X%	回归 > 20% 时标记
错误率	A%	B%	+X pp	任何增幅都标记
吞吐量	A RPS	B RPS	-X%	降幅 > 10% 时标记

回归阈值（默认值，可根据 SLA 调整）：

• p95 或 p99 回归 > 20% → 标记为性能退化
• 错误率增加 > 0.1 pp（从接近零开始）→ 立即标记
• 相同负载下吞吐量下降 > 10% → 标记为容量回归

2.5 按端点分析

全局指标会掩盖具体是哪个端点导致了问题。如果有按端点划分的数据：

1. 按 p95 降序排列端点——排名前 3 的端点是调查目标
2. 检查故障端点是否有共同模式（使用相同的 DB 表、相同的外部依赖、相同的服务）
3. 判断是某个缓慢的端点拉高了全局 p95，还是问题普遍存在？
4. 如果 SLA 按端点定义，需报告各端点的 SLA 合规情况，而不只是全局情况

情况	报告内容
10 个端点中有 1 个导致 SLA 违约	明确指出该端点——不提供此背景时，全局 SLA 违约情况会产生误导
所有端点同时性能下降	存在共享资源瓶颈——调查 DB、网络或基础设施
只有 POST 端点失败	调查写入路径：DB 锁、校验、下游写入
只有经过身份验证的端点失败	调查身份验证中间件、令牌校验、会话存储

2.6 图表解读

用户分享或引用可视化报告（Gatling HTML、k6 仪表板、Locust 图表）时：

图表类型	关注点	危险信号
随时间变化的响应时间	稳态期间应保持平稳	趋势向上 = 泄漏或饱和；出现峰值 = GC 或重试风暴
随时间变化的活跃用户数 / VU 数	应符合已配置的渐增曲线	低于目标值的平台期 = 测试运行器瓶颈或速率限制器过于严格
每秒请求数	应随 VU 数变化	VU 数增加但 RPS 停滞 = 系统已饱和
随时间变化的错误率	应接近零	出现峰值后恢复 = 瞬时问题；持续增长 = 容量限制即将到来
响应时间分布	应呈右偏分布（少数异常缓慢值）	双峰分布 = 两类不同的用户群体，或缓存命中与未命中的差异

2.7 峰值测试和预热分析

峰值测试——需核实以下三点：

1. 系统是否达到已配置的峰值？（查看 VU/RPS 图表）
2. 峰值时的错误率和 p95 是多少？（压力最大的时刻）
3. 负载下降后，系统用了多长时间恢复？（恢复时间 = p95 回到基线值 ± 10% 所需的时间）

预热 / 冷启动——何时不纳入 SLA 评估：

• 如果前 2–5 分钟延迟较高，之后趋于稳定 → 将预热时间段排除在 SLA 测量之外
• 仅在稳态期间评估 SLA（渐增阶段结束后）
• 在报告中注明预热时长——这对自动扩缩容和就绪探针配置很重要

---

第 3 步——划分严重程度

在编写任一报告之前，为每项发现指定严重程度。

严重程度	定义	示例
严重	SLA 违约；生产环境中的用户无法使用系统或受到性能影响	p95 > SLA × 2，错误率 > 5%
高	SLA 违约；部署后会对用户造成显著影响	p95 > SLA，错误率 1–5%
中	符合 SLA，但趋势令人担忧；未来可能违约	p95 达到 SLA 的 90%，且随负载增加而上升
低	符合 SLA；有轻微优化空间	p95 达到 SLA 的 60%，没有趋势变化
信息性	值得注意的情况，无需采取行动	GC 期间出现延迟峰值，随后立即恢复

报告中的每项发现都必须标注严重程度。

---

第 4 步——技术报告

按以下结构编写技术报告。务必具体：包括实际数值、工具输出摘录，以及明确后续步骤和负责人。

## Performance Test Technical Report
**Date:** [date]
**Test type:** [Smoke / Load / Stress / Spike / Endurance]
**Tool:** [k6 / Gatling / Locust / JMeter / other]
**Environment:** [staging / perf / prod-clone]
**Load profile:** [X users, Y RPS, Z minutes duration]

---

### Executive Summary (3 sentences max)
[What was tested. Whether SLAs were met. Top finding in plain language.]

---

### SLA Compliance

| Metric | Target | Actual | Result |
|---|---|---|---|
| p95 response time | ... | ... | PASS/FAIL |
| p99 response time | ... | ... | PASS/FAIL |
| Error rate | ... | ... | PASS/FAIL |
| Throughput | ... | ... | PASS/FAIL |

---

### Findings

#### [CRITICAL/HIGH/MEDIUM/LOW] Finding 1 — [Short title]
**Observed:** [What the data shows, with exact numbers]
**Root cause hypothesis:** [Why this likely happened — infrastructure, code, config]
**Evidence:** [Specific metric, timestamp, or tool output that supports this]
**Recommended action:** [Concrete next step — code change, config tuning, infra scaling]
**Owner:** [Team or role responsible]
**Retest required:** Yes / No

#### [severity] Finding 2 — ...
[repeat for each finding]

---

### Regression vs. Baseline

| Metric | Baseline | Current | Delta | Status |
|---|---|---|---|---|
| p95 | — | — | — | — |
| Error rate | — | — | — | — |

[Note: omit section if no baseline exists]

---

### Infrastructure Observations
[CPU, memory, DB, network observations during the test. Flag any resource that peaked
above safe thresholds (CPU > 70%, memory upward drift, connection pool saturation).]

---

### Recommendations Summary

| Priority | Action | Owner | Target date |
|---|---|---|---|
| P1 | ... | ... | ... |
| P2 | ... | ... | ... |

---

### Test Conditions
[Document: environment, dataset size, any known limitations that affect validity of results]

---

第 5 步——业务报告

业务报告将技术发现转化为决策和风险。**切勿包含原始百分位数、工具名称或技术术语。**将每项指标都转化为用户或业务影响。

翻译表 — 将指标转化为业务语言

技术指标	业务解读
p95 = 1.8s（SLA：< 1s）	每 20 位用户中，就有 1 位等待时间接近可接受时长的 2 倍
高峰期错误率 = 3%	忙碌时段每 100 笔交易中，就有 3 笔失败
系统在 800 位用户时崩溃	当前容量仅为预期峰值 1,300 位用户的 60%
p95 比上一版本退化 40%	最近一次发布显著恶化了响应最慢用户的体验
耐久性测试：4 小时内内存增长 2GB	部署后，该服务每隔几小时就需要重启一次，以避免服务中断

## Performance Test — Business Summary
**Date:** [date]
**System:** [product or service name]
**Test conducted by:** [team]

---

### What Was Tested
[One paragraph. What system, what scenario, what load level — in plain language.
No tool names. Example: "We simulated 500 users purchasing products simultaneously,
representing the expected traffic during the upcoming sale."]

---

### Key Question: Is It Ready?

**Overall verdict:** [Ready to deploy / Not ready — risks identified / Ready with conditions]

[One paragraph summary of what this means for the business.]

---

### Risk Summary

| Risk | Impact | Likelihood | Recommended action |
|---|---|---|---|
| [plain-language risk] | High/Med/Low | High/Med/Low | [decision recommendation] |

---

### What Happens If We Deploy Now
[Honest assessment of the user-facing impact if the system goes live as-is.
Focus on conversion, user experience, or revenue impact where applicable.]

---

### What Needs to Happen Before Go-Live
[Bullet list of must-fix items in plain language. Each bullet should say what needs
to happen and why it matters to users or the business — not how to fix it technically.]

---

### What We Can Defer
[Low/informational findings that do not block launch but should be addressed post-launch.]

---

### Decision Required
[If there is a go/no-go decision pending, state it explicitly with a recommendation
and the tradeoff of each option.]

---

结果解读中的常见错误

1. 用平均响应时间代替百分位数

平均值会掩盖异常值。如果 p99 = 8s，那么 200ms 的平均值毫无意义。对于用户感知的性能，务必优先报告 p95 和 p99。

2. 忽略错误率的增长模式

错误率从 100 位用户时的 0% 跳升到 200 位用户时的 5%，说明容量可能不足。若所有负载级别的错误率都为 5%，则说明存在 bug。这需要采取不同的修复措施。

3. 因为 SLA「平均达标」就宣布成功

必须按百分位数评估 SLA，而不能看平均值。「p95 达标」和「平均值达标」 并不是一回事。

4. 对比不同环境中的结果

预发布环境的结果与生产规模环境的结果不可直接比较。务必记录环境差异，并明确说明结果能证明和不能证明的内容。

5. 在业务报告中使用技术数字

对业务相关方说「p95 = 1,240ms，超过了 800ms 的 SLA」，不会促成任何行动。应该说「每 20 位用户中，就有 1 位经历了比目标长 55% 的延迟。」

6. 没有基线，却将首次运行判定为通过

没有基线，你只能说「SLA 达标」，却无法判断性能是否退化。务必采集并保存首次运行结果，作为后续对比的基线。

7. 未验证恢复情况就宣布压力测试的故障点

找到故障点只是压力测试的一半。负载移除后，务必确认系统能够恢复。崩溃后无法恢复的系统，远比能够平稳降级的系统危险。

8. 将预热阶段当作稳态进行分析

测试开始后的前 2–5 分钟内 p95 较高，通常是由于 JIT 编译、延迟连接初始化或 DNS 解析导致的，而非应用性能问题。评估 SLA 是否达标时，务必排除爬坡／预热阶段。

9. 有端点级数据时却只报告全局指标

全局 p95 为 900ms，可能意味着 10 个端点都很慢（基础设施问题），也可能意味着某个端点的响应时间为 9,000ms（特定 bug）。得出结论或提出建议前，务必细分到端点级别。