报告结构是什么
性能报告的结构决定它能否被决策使用：先给结论（达标或不达标、瓶颈在哪），再给证据（指标、图表、资源曲线），最后给条件（环境、数据量、脚本版本）。只堆数字没有结论的报告没人看，只给结论没有证据的报告没人信。
基本信息
| 首页 | 一句话结论加关键指标表，让读者三十秒看懂 |
|---|---|
| 范围 | 测了什么、没测什么，明确边界 |
| 环境 | 拓扑、配置、数据量、版本，全部可复现 |
| 模型 | 并发、时长、流量比例、思考时间 |
| 结果 | 吞吐、错误率、分位、资源曲线四件套 |
| 分析 | 瓶颈定位与证据链：谁先饱和、拐点在哪 |
章节骨架示意
章节骨架示意
1 结论：核心接口 p95 220ms 达标；下单链路并发 500 时错误率 2.1% 未达标
2 范围：本次验证发版性能与扩容方案，不含全链路容量
3 环境：8C16G 两台、MySQL 8、订单表 2000 万行、预发独立集群
4 模型：浏览比下单 9:1，思考时间 3 秒，持续 30 分钟
5 结果：吞吐 / 错误率 / p95 p99 / 资源曲线（附图）
6 分析：数据库 CPU 先到 90%，慢查询 TOP3 见附录
7 建议：按影响面排序的行动清单（索引、连接池、缓存）典型使用场景
- 版本发布性能验收：达标结论直接进发布评审
- 容量规划评审：为扩容数量提供数据依据
- 事故复盘：附上与事故相关的压测与监控数据
- 跨团队汇报：把压测过程翻译成决策语言
- 存档对比：与上一版报告对照看劣化趋势
章节与常见错误
| 章节 | 常见错误 | 要求 |
|---|---|---|
| 结论 | 埋在文末，读者找不到 | 首屏一句话说清 |
| 证据 | 只有截图没有原始数据 | 附数据文件与脚本版本 |
| 环境 | 配置缺失或含糊 | 可复现到具体版本与参数 |
| 分析 | 把现象当原因 | 给出证据链与验证方式 |
图表优先用时间轴曲线而非单点柱状：曲线暴露拐点、劣化趋势与资源饱和顺序，这些是单点看不出的。
报告里每个数字都要能回答「什么条件下测的」；回答不了的数字不要写进结论，宁缺毋滥。
环境与线上差一个数量级时不要下容量结论：数据量、核数、网络任一差异都可能让结论反向。