核心接口延迟持续上升，但 CPU 和错误率看似正常；你会如何结合 SLI、分布式追踪和依赖指标定位瓶颈，并调整告警以减少噪声？

我会先把这个问题当成“用户侧体验变差，但资源和错误率没有明显异常”的性能问题来处理，重点不只看 CPU 和 5xx，而是看延迟 SLI、调用链和下游依赖。

我的排查思路大概是这样：

先确认 SLI 是否真的劣化，以及劣化范围。 我会看核心接口的延迟分位数，比如 p50、p90、p95、p99，而不是只看平均值。平均值正常但 p99 上升，通常说明有一部分请求被某个慢依赖、锁、连接池或队列拖住。 同时会按维度拆分：接口、机房、实例、租户、用户类型、请求参数、版本、灰度批次，看是全局变慢还是局部变慢。

比如我会重点确认：

p95 / p99 是否持续上升 QPS 是否有变化，是否有流量倾斜 成功率是否正常，是否存在慢成功请求 请求耗时是整体抬升，还是尾延迟变差 是否只发生在某些实例、某个可用区、某类用户或某个版本

然后用分布式追踪拆调用链。 如果这个接口链路比较长，我会从 trace 里看一条慢请求的完整 span，重点看耗时分布在哪一段：

网关到服务是否慢 服务内部业务逻辑是否慢 RPC 调用是否慢 数据库查询是