接口突然变慢，如何用可观测性体系排查？

简化版

接口突然变慢时，先看指标确认影响范围：是单接口、单服务、单机房还是全局；再看 P95/P99、错误率、QPS、资源和依赖指标；然后用链路追踪找慢 Span，判断慢在网关、业务逻辑、数据库、缓存、RPC 还是 MQ；最后用日志查看错误码、参数特征和上下文，并结合发布、配置变更和下游状态定位原因。

核心思路是：指标看范围和趋势，Trace 看调用路径和耗时，日志看具体事件和业务细节。

详细版

排查不能一上来就猜数据库或重启服务。第一步要确认问题范围：所有用户都慢还是部分用户慢，所有接口慢还是某个接口慢，所有实例慢还是某几台实例慢，是否刚发布、刚改配置、流量是否突增。

第二步看指标。接口 QPS、错误率、P99 延迟、线程池队列、连接池、CPU、GC、数据库慢查询、Redis 延迟、MQ 积压都可能提供线索。第三步查 Trace，找慢请求样本，看耗时集中在哪个 Span。第四步看日志，确认错误码、请求参数、下游响应和异常堆栈。

最后要把结论落到处置动作：回滚发布、调整配置、限流降级、扩容、修复慢 SQL、切换下游、清理热点 Key 等。可观测性不是为了看图，而是为了快速定位和恢复。

完整版教学

一、先确认影响范围

排障第一步不是找原因，而是确定影响范围。范围决定优先级和排查路径。

要问：

是所有接口慢，还是某个接口慢。
是所有用户慢，还是某类用户慢。
是所有实例慢，还是某几台实例慢。
是所有机房慢，还是单机房慢。
是从什么时候开始慢，是否关联发布或配置变更。

范围越清楚，排查越不容易走偏。

二、用指标看趋势

指标能快速判断问题形态。比如 QPS 突增说明可能是流量冲击；错误率升高说明可能有依赖故障；P99 升高但平均值正常说明尾延迟问题；CPU 不高但线程池队列堆积说明可能阻塞在下游。

接口层看 RED：请求量、错误率、耗时。资源层看 USE：使用率、饱和度、错误。依赖层看数据库、缓存、RPC、MQ 指标。

指标用于把问题从“感觉慢”变成“哪类指标异常”。

三、用 Trace 找慢在哪里

找到慢请求样本后，打开 Trace。看整条链路中哪个 Span 耗时最高，是否有重试、超时、排队、跨机房调用。

常见情况：

网关 Span 慢：可能限流、鉴权、网络或入口排队。
业务服务 Span 慢：可能线程池、锁、GC、代码逻辑。
数据库 Span 慢：可能慢 SQL、锁等待、连接池耗尽。
Redis Span 慢：可能大 Key、热 Key、网络抖动。
RPC Span 慢：可能下游服务或网络问题。
MQ Span 慢：可能消费积压或异步链路延迟。

Trace 的价值是把总耗时拆开。

四、用日志看具体细节

Trace 告诉你慢在哪一段，日志告诉你那一段发生了什么。通过 TraceId 查询日志，可以看到请求参数、业务分支、错误码、异常堆栈、下游返回和关键状态。

日志要帮助确认具体原因。例如数据库慢是因为哪个 SQL，库存失败是因为哪个商品 ID，缓存异常是哪个 Key，RPC 错误是超时还是连接失败。

没有日志细节，Trace 只能告诉你慢在某个服务，不能解释业务原因。

五、结合变更和依赖状态

很多故障和变更相关。排查时要看最近是否有代码发布、配置变更、扩缩容、注册中心变更、数据库变更、缓存迁移、网络调整。

如果问题开始时间和某次发布高度吻合，回滚可能是最快恢复手段。先恢复，再深挖原因，通常比在线上长时间分析更安全。

依赖状态也很重要。自己的服务变慢，根因可能是下游数据库或第三方接口。

六、从定位到处置

排查不是为了写报告，而是为了恢复服务。不同原因对应不同动作：

流量突增：限流、扩容、降级。
慢 SQL：回滚查询、加索引、临时降级相关功能。
下游超时：熔断、缩短超时、切换备用依赖。
热点 Key：本地缓存、请求合并、热点限流。
发布问题：回滚版本。
线程池耗尽：隔离下游、调整队列和并发。

可观测性要能支持这些动作的选择。

七、面试回答建议

回答这道题时，按“范围 → 指标 → Trace → 日志 → 变更 → 处置”顺序。这样非常像真实值班排障流程。

不要一上来就说查日志。日志是细节，指标和 Trace 能更快确定方向。也不要只定位原因，要说如何恢复。

八、常见追问和落地边界

面试官常追问如果 Trace 没采到怎么办。此时要回到指标和日志：先用指标确认异常维度，再用日志按错误码、实例、版本、用户类型等过滤。如果是关键故障，可以临时提高采样率，复现或等待下一批异常样本。

还有一个落地边界是先恢复再复盘。线上接口严重变慢时，如果已经明确和某次发布或配置变更相关，优先回滚或降级恢复服务；可观测性帮助你定位，但不应该让团队为了追求根因分析而拖延止血。

九、常见误区与追问

这道题要紧扣「用可观测性排障」本身回答，不能把它混成泛泛的可观测性套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖日志、指标、追踪、上下文传播、采样、告警和排障闭环。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	排障要从告警定位影响，再用指标看范围、Trace 找慢点、日志查细节，最后验证恢复	不要停在名词解释
流程机制	收到告警 -> 确认影响范围 -> 看指标定位服务 -> 用 Trace 找调用瓶颈 -> 查日志和变更 -> 止血并验证恢复	要说清触发点、状态变化、确认点和失败兜底
工程取舍	下单错误率从 0.1% 升到 5%，先看是否单接口、单机房或单版本，再钻 Trace 和日志	可观测性不能替代稳定性设计，它用额外采集、存储和分析成本换更快定位问题

用可观测性排障 面试拆解：
1. 收到告警
2. 确认影响范围
3. 看指标定位服务
4. 用 Trace 找调用瓶颈
5. 查日志和变更
6. 止血并验证恢复

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「用可观测性排障」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

误区：排障就是先看日志。 日志细但范围感弱，通常先看指标定位范围，再用 Trace 和日志深入。
误区：只有异常才需要可观测性。 慢请求、流量突增、依赖饱和也需要指标和 Trace。
误区：找到报错服务就等于找到根因。 报错可能是下游依赖、配置变更或容量问题传导。
追问：三板斧是什么？ 指标看范围，Trace 看路径，日志看细节。
追问：如何关联一次故障？ 按时间线把发布、流量、错误率、依赖状态和告警串起来。
追问：止血动作有哪些？ 回滚、降级、限流、扩容、摘除实例和切换依赖。

十、加强记忆

排查慢接口可以记成“三把手电筒”：指标照大范围，Trace 照调用路径，日志照具体细节。

先看影响面，再找慢在哪，再看为什么慢，最后选择恢复动作。

简化版

详细版