标准答案
- 先确认是所有接口、某个路由、某个租户还是某个版本受影响，并对比发布、配置和流量变化时间线。
- 查看网关的排队、TLS、上游连接和状态码；再看应用的线程或事件循环、GC、CPU、队列和业务耗时。
- 检查缓存命中率、热 Key、数据库慢查询和锁等待，以及下游服务的 Trace Span、超时和错误率。
- 定位后先采取风险最低的止血措施，例如回滚、限流、关闭非关键功能或隔离慢依赖，再做根因修复。
题目解析
P99 关注尾部请求，平均值往往正常。常见根因包括少量慢查询、连接池等待、缓存失效、重试风暴和特定下游分片异常。
层层定位需要统一时间、Trace 和版本维度。没有关联标识时，很容易把结果当原因，例如看到数据库慢却忽略上游重试把数据库压慢。
常见误区
- 只看应用 CPU，忽略网关排队和下游调用。
- 看到慢 SQL 就直接加索引，没有先确认它是否解释了 P99 样本。
- 未经验证就扩容，导致负载和重试进一步放大。