现场是这样的。推理服务看板 P99 稳定在 1.2 秒，客服却持续收到卡顿反馈，抽出投诉里的 100 个 request_id 逐个查，有 7 条耗时超过 30 秒，全部落在最后 0.5% 里。
中间走过弯路，把「统计只算成功请求，超时的那批被排除在外」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。P99 本身就会截掉最慢的那百分之一；指标按小时聚合，几十秒的尖峰被平均掉了；没有按租户或接口拆开，慢请求集中在一处看不出来。
补一列 P99.9 与最大值
python -c "print(['p99','p999','max'])"从原始日志按分钟重算长尾
python agg.py --log req.log --field latency --percentile 99.9然后按租户分组找集中点
python agg.py --group tenant --top 10剩下的就是把超时请求也纳入统计
python -c "print('include_timeout=True')"怎么算真的好了，看的是同一批现象。P99.9 与最大值进入看板，长尾请求能落到具体租户，超时请求在统计里的占比可见。
平均值和 P99 都可以很好看，真正决定体验的是那百分之零点几，看板必须带最大值这一列。这类问题最好一次改到位，反复小改反而容易把原因搅混。