性能报告：平均值之外还要说明什么
平均响应时间能描述总体趋势，却会掩盖少量请求的长尾。性能报告至少应给出测试窗口、样本数、P50、P95、P99、错误率和负载条件；样本量很小时，过高分位数没有稳定解释，不应为了显得全面而硬报。
先交代样本与聚合口径
分位数也需要口径一致。直方图桶、聚合维度、是否排除失败请求都会改变结果。报告中应说明请求类型、并发模型、数据集、服务版本和机器资源，否则两个 P99 无法比较。
反例是把成功请求单独计算延迟，把超时和错误从分母剔除。平均值和分位数会变好，但用户体验没有改善。失败应作为独立指标展示，并与下游错误、GC 或队列等待在同一时间线上分析。
验证时用固定负载重复运行，检查分位数和错误分类的趋势；若变更只改善某一种请求，也要按类型报告。性能数据的作用是帮助选择下一步排查方向，不是用一个数字宣布系统足够快。
让告警和排查使用同一套证据
操作层面，先让服务按路由、状态码或依赖类型打出低基数指标，再从 trace 和日志补充单次细节。告警可组合持续的错误率、队列等待和资源饱和，避免仅因一个慢请求频繁触发。分位数突升时，先检查请求量和下游变化，再查看 CPU、GC 与连接池，不要直接把责任归到应用代码。
报告还要说明是否发生预热、缓存状态如何、压测客户端是否成为瓶颈。上线后的真实指标可以验证压测假设，但不能与不同流量形态下的压测数字直接对比。把环境差异写清楚，性能讨论才不会变成数字争论。
同一条接口的快慢也可能由请求体大小和缓存命中决定。若报告只按路由聚合，短请求把大量重计算请求平均掉，结论就会失真。可以按业务上有意义的区间分组，例如输入大小、是否命中缓存或是否调用下游服务；分组数量要受控，不能把用户标识之类的高基数字段塞进监控系统。目的是发现哪类负载退化，而不是制造更多图表。
性能变更的结论要能指导动作。P99 升高且队列等待同步增加，优先看并发额度和下游处理能力；若只有某个数据规模的请求变慢，再检查算法和索引。没有这层关联时，“平均延迟下降”只是描述，不足以支持扩容、限流或回滚。报告可以保留原始查询链接或采样规则，方便后来的人沿着同一证据复查。
采样也会影响性能报告。追踪全部请求可能增加开销，只采样成功请求又会漏掉慢和错的关键路径。应说明哪些数据来自全量指标、哪些来自抽样 trace，以及采样规则是否在测试期间改变。遇到低频但严重的尾延迟，可以临时提高特定路由的采样比例，但要注明这会改变观测成本和统计代表性。
同样的报告格式要能服务发布前后的比较。变更前先记录基线，变更后在相近的流量条件下看差异，并列出可能干扰结论的因素。若没有可比环境，就把结果写成一次观察，不要伪装成严格对比。工程决策经常要在不完美的数据下做，但报告应诚实说明它能支持到什么程度。
