线上服务突然大量超时，你的排查思路是什么？

我按『先止血再查因』来：先看监控确认范围——全局还是单接口、单机还是所有节点；如果是单接口大概率是该功能依赖出问题，查它的下游调用；全局性的先看最近变更，能回滚先回滚。实习时我遇到一次缓存实例故障引发超时，定位链路是错误日志里连接超时的目标 IP 集中指向该实例。

我处理过一次大促前的线上超时。时间线：告警群收到 P2，先看大盘区分是入口层还是服务层；入口层正常但服务层 RT 飙升，下钻依赖拓扑发现 DB 连接池耗尽；临时扩容连接池止血，事后根因是一条未走索引的查询在大数据量下拖垮池子。复盘沉淀了慢查询自动告警和连接池饱和度巡检。

超时排查我的框架是三张图：依赖拓扑图定位哪一跳、时间线对齐图找变更与故障的时间相关性、容量水位图排除资源瓶颈。处置有分级预案：限流降级保核心、读切备、写异步化。资深与初级的差别不在单次排查，而在有没有把每次故障变成防御建设——预演、预案和自动止损。

追问『超时时间怎么设』：按依赖的 P99 加缓冲分级设置，链路上游超时要小于下游总预算，避免无效等待；『重试会不会加重问题』：会，必须配合退避和预算，比如重试一次加 0.5 倍抖动，且设置整体重试预算熔断；『怎么区分网络和服务问题』：tcping 与应用层探活对比。