平均耗时可能被大量快速请求拉低，少数关键请求仍然等待很久。用户体验分析需要看分布、错误和业务类型，尤其是大客户、复杂查询与高峰时段。
先按业务场景观察
把轻量健康检查与真实业务接口混在一起，会掩盖问题。按稳定的操作类型、环境和必要维度查看耗时，避免引入无限标签。对不同数据规模的客户也需要有受控的分析方法。
高分位也要配合样本量
P95 或 P99 帮助观察尾部，但低流量时统计可能波动明显。应说明时间窗口、样本数与成功失败范围。不同实例或窗口的百分位不能简单平均后当成总体百分位。
慢请求需要具体证据
通过链路、数据库等待与资源记录定位耗时组成。请求可能在连接池、线程或下游等待，不能看到接口总时间高就判断代码计算慢。发布记录也应纳入对比。
验收用户影响是否改善
对相同场景比较耗时分布、超时和成功率，确认优化没有只改善平均值。对极端数据样本保留回归验证，避免后续改动再次引入尾部退化。
常见问题：只关注 P99 就够了吗？
不够。还要结合吞吐、错误、样本量与业务目标，单个统计值无法完整描述用户体验。
技术参考：OpenTelemetry：指标。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。