接口慢和 timeout 这类事故，难的往往不是不会查，而是现场一乱，大家又回到临时拼顺序：

• 日志和 trace 哪个先看
• 线程池和数据库哪边更该先查
• 网关 504 多了，是否就该先找网关
• 什么时候该先止血，什么时候还可以继续取证

这种场景我见得多了，真正拖慢处理的通常不是知识缺口，而是第一轮动作没有沉成同一套做法。

结果通常就是：

• 熟练的人在场时，现场还能收得住
• 换个人值班，第一轮方向就容易查偏
• 同一种故障重复出现，但每次都像第一次处理

所以真正值得补的，不是再堆几篇说明文，而是：

一份值班时能直接拿来用、能帮人先切范围、再抓证据、再决定止血动作的检查表。

检查表不是替你做判断，而是把现场最容易漏、最容易争论、最容易被个人经验带偏的部分先钉住。

换句话说：

• 检查表不负责解释所有根因
• 检查表负责保证第一轮动作别乱

如果你已经受够了每次 timeout 都要重新讨论排查顺序，这篇就把第一轮动作整理成一张现场真能拿来用的单子。

哪些值班场景适合直接拿这张检查表

你现在更缺什么	先看什么	先解决什么
想把慢接口 / timeout 现场沉成固定动作单和取证清单	直接沿这张检查表往下走	把检查表的结构和顺序定下来
线上已经在 timeout，但你还没分清慢在应用、网络还是下游	接口超时增多时，先区分应用、网络还是下游依赖？	先分清慢在哪一层，再整理检查表
你在 timeout 风暴里纠结先止血还是先定位	接口超时风暴里，先止血还是先定位？如何判断分界线？	先把止血和取证的分界线定住
你想把这套值班动作继续上升到治理顺序或容量预算	稳定性治理先做容量评估、慢链路梳理还是告警分层？	先去看治理层怎么排优先级

这张检查表主要解决什么

如果你想把慢接口和 timeout 的第一轮动作固定下来，直接拿给值班同学照着走，下面就是这张动作单的主体。

它不替你判断根因，也不打算把所有 timeout 类型一次讲完；它更像一张现场动作单，把值班时该问什么、该看什么、该记什么收成一个顺手的顺序，再决定要不要止血。

一、为什么接口慢 / 超时最值得先做检查表

因为这类问题最常见，也最容易放大。

典型链路通常是：

• 某个接口 RT 先抬高
• 一部分请求开始 timeout
• 线程池、连接池、下游依赖一起被拖慢
• 上游重试、网关 504、客户端超时开始成片出现

这类问题有几个很麻烦的特点：

1. 跨层

它会同时牵涉：

• 网关
• 应用线程池
• 数据库连接池
• 下游 HTTP / RPC
• 缓存和数据库
• 客户端 timeout

所以只靠某一层经验很容易误判。

2. 很讲究排查顺序

很多时候并不是不会查，而是：

• 先查错层了
• 先抓错证据了
• 或者先做了破坏现场的大动作

3. 很容易需要在“止血”和“定位”之间切换

这类事故不只是找根因，还经常要边查边保护核心链路。

因此，接口慢 / 超时问题特别适合做成检查表：

• 先固定第一轮范围切分
• 再固定证据采集顺序
• 再固定常见止血动作边界

二、明确一点：检查表不是知识库目录，而是值班现场动作单

很多团队写检查表，最后会写成：

• 看日志
• 看监控
• 看链路
• 看数据库
• 看缓存

这些都对，但几乎没有现场执行价值。

真正能用的检查表，至少要满足三件事：

1. 能按时间顺序执行

值班人员拿到以后，应该知道前 5 分钟先做什么，接下来 10 分钟做什么。

2. 能帮助排除高频误判

比如：

• 不要一看到 504 就只盯网关
• 不要一看到 timeout 就默认是下游挂了
• 不要一看到连接池高就先调大池子

3. 能映射到清晰动作

每一项都最好能回答：

• 为什么看这个
• 看到了什么意味着什么
• 下一步往哪条线继续收敛

如果做不到这三点，它更像知识目录，不像值班检查表。

三、检查表别按组件摊开，按值班阶段组织更顺手

接口慢 / 超时值班检查表，我更倾向按下面 4 个阶段组织，而不是按组件组织。

1. 范围切分：先确认影响面和时间线
2. 链路定位：判断慢在应用、网络还是下游
3. 放大识别：确认是否已进入线程池 / 连接池 / 重试放大
4. 动作决策：决定先止血还是继续深挖

这个结构的好处是：

• 值班时能顺着走
• 同一份检查表能覆盖大部分超时现场
• 不会因为系统组件多就越写越散

四、阶段一：范围切分清单，避免第一步就查偏

第一阶段的目标，不是定位根因，而是先回答：

• 是单接口还是多接口
• 是单实例还是整组服务
• 是局部租户还是全量用户
• 是最近几分钟突然开始，还是高峰期逐渐抬头

建议固定放进检查表的问题

1. 影响面

• 哪些接口慢 / timeout
• 哪些用户、租户、业务线受影响
• 是所有实例都差，还是少数实例更差
• 是否只在灰度、某个节点、某个机房明显

2. 时间线

• 第一个明显异常是什么时候开始
• 最近是否有发布、切流、配置变更、批任务、缓存清理
• 是突然抬头，还是逐步恶化

3. 类型判断

• 单接口慢还是整站慢
• 只慢但未大量超时，还是已经超时成片
• 是否伴随 504、连接池等待、线程池堆积、重试上涨

为什么这一阶段最值钱

因为它直接决定后面优先怀疑什么：

• 单接口 / 局部实例：更偏业务链或实例差异
• 多接口 / 多服务一起慢：更偏共享依赖或公共资源
• 发布后开始：变更优先级显著上升

五、阶段二：链路定位清单，先判断慢在哪一层

这一阶段的目标，是把接口慢 / timeout 先粗分成三类：

• 应用内部慢
• 网络路径慢
• 下游依赖慢

建议固定放进检查表的问题

1. 请求是否真正进入应用

• 网关 / access log 是否看到请求进入
• trace 是否显示大头时间耗在本服务内部
• 下游日志是否有对应请求

2. timeout 类型是什么

• connect timeout
• read timeout
• 网关 504
• 客户端整体超时
• 应用内部 future / 异步等待超时

3. 时间主要耗在哪

• 本服务线程排队
• 获取数据库连接
• 获取线程池线程
• 调某个下游
• 数据库查询 / 锁等待
• DNS / 建连 / TLS / 网络层

这一阶段的输出应该是什么

不是“找到根因”，而是收成类似这样的判断：

• 更像本服务内部等待先起来
• 更像某个下游 RT 抬高在前
• 更像网络或接入层先有问题

只要做到这一步，排查方向已经能明显收敛。

六、阶段三：放大识别清单，确认现场是不是已经不只是“慢”

很多事故真正危险的地方，不是开始慢，而是开始放大。

所以检查表里一定要有一段专门识别放大器。

建议固定放的观察项

1. 线程池

• active 是否持续打满
• queue 是否持续上涨
• reject 是否开始出现

2. 连接池

• active / idle / pending 水位
• 获取连接耗时是否上升
• 获取连接超时是否出现

3. 重试

• 上游调用量是否明显高于原始入口流量
• SDK / 网关 / 业务代码是否存在多层 retry
• timeout 是否集中卡在统一阈值附近

4. 外层暴露

• 网关 504 是否成片出现
• 客户端 timeout 是否快速增多
• 错误率和 RT 是否一起抬头

为什么这一段必须有

因为它决定你接下来是：

• 还能继续按局部问题取证
• 还是已经要先削放大器、保护核心链路

这一步其实就是把“慢问题”和“事故问题”分开。

七、阶段四：动作决策清单，决定先止血还是先定位

值班检查表如果只做到“看什么”，还不够。它还应该至少帮人做出一个第一轮决策：

• 先止血
• 先抢证据
• 边止血边定位

建议固定的判断项

1. 影响面是否还在扩大

• 从单接口向多接口扩散
• 从局部实例向全量扩散
• 错误率、超时率、504 是否持续走高

2. 关键资源是否逼近硬上限

• 线程池
• 连接池
• 网关转发预算
• 数据库锁等待 / 活跃事务

3. 是否存在低风险、可逆的止血动作

• 限流入口
• 关闭高风险 retry
• 降级非核心依赖
• 暂停批任务
• 回撤灰度或最近变更

4. 证据窗口是否在快速流失

• 异常实例是否快被重启或摘流
• 线程栈、慢 SQL、配置差异是否马上看不到

检查表里要给出的不是唯一答案，而是切换条件

更实用的表达通常是：

• 如果影响面持续扩大且关键资源逼近上限，优先止血
• 如果问题仍局部且证据窗口很值钱，优先保留现场再做最小止血

八、检查表里最好有一页“固定证据清单”

这是很多团队最容易漏掉但特别实用的一页。

接口慢 / 超时类故障里，第一轮最值得固定采集的证据通常包括：

• 影响接口列表
• 异常开始时间
• 最近一次发布 / 配置 / 切流时间
• 线程池 active / queue / reject 快照
• 连接池 active / idle / pending 快照
• 关键下游 RT / 错误率 / timeout 快照
• 慢 SQL / 锁等待 / 活跃事务快照
• 网关 504 与客户端 timeout 分布
• 重试次数和原始入口流量对比

把这些固化成模板，值班时就不会总忘记“该先留什么现场”。

九、给你一个值班时真能落地的检查表示例

下面这套写法更像我会放给值班同学直接用的版本，不是最终格式，但已经足够拿去起模板。

A. 事件概览

• 事件开始时间：
• 受影响接口：
• 受影响范围：单接口 / 多接口 / 全站
• 受影响实例：全部 / 部分 / 灰度
• 最近变更：有 / 无

B. 第一轮范围切分

• 是否单实例异常：
• 是否某个依赖共同异常：
• 是否某个机房 / 节点集中：
• 是否伴随批任务 / 热点 / 流量变化：

C. 链路定位

• 请求是否进入应用：
• timeout 类型：connect / read / gateway / client / internal
• 主要耗时位置：线程池 / 连接池 / 下游 / 数据库 / 网络

D. 放大信号

• 线程池是否持续堆积：
• 连接池是否持续等待：
• retry 是否明显放大：
• 504 / timeout 是否持续扩散：

E. 决策

• 当前优先级：定位优先 / 边查边止血 / 止血优先
• 已执行止血动作：
• 已保留证据：
• 下一轮收敛方向：

这个骨架的重点不是格式，而是：

• 一页里把值班第一轮最关键的判断和动作串起来

十、关键误判

误判 1：检查表写得越全越好

太长、太细、太像知识库，现场反而没人会用。

误判 2：按组件写最清楚

接口慢 / timeout 这类检查表，更应该按值班阶段写，而不是按 Redis、DB、网关分章节。

误判 3：检查表只写“查什么”，不用写“为什么”

值班人员如果不知道这一步的判断意义，现场很容易机械勾选却不收敛。

误判 4：检查表只服务新手

真正成熟的团队，熟手也需要检查表来保证现场动作一致、证据一致、复盘可追溯。

误判 5：检查表定稿后不用更新

只要系统架构、依赖、线程池模型、常见故障模式变了，检查表就要跟着更新。

十一、做这份值班检查表时最常被问到的几个问题

1. 检查表应该放多少项？

第一版宁可只保留最常用、最影响方向的 10 到 20 项，也不要一次写成一份大百科。

2. 检查表和 runbook 有什么区别？

检查表更强调第一轮顺序和确认项；runbook 可以更详细，包含具体命令、页面、工具入口和应急动作。

3. 是不是每个接口都要单独做检查表？

不一定。更实用的是先做“接口慢 / 超时”专题通用版，再针对几个高价值核心链路补专属版本。

4. 怎样判断检查表有没有用？

看三件事：

• 值班现场第一轮是否更快收敛范围
• 复盘里是否少了重复漏项
• 新老值班人员处理同类事故时动作是否更一致

十二、最后收束一下：检查表不是替你想，而是别让现场再乱一遍

接口慢 / timeout 类故障最容易把团队拖慢的，不是没人懂原理，而是每次现场都得临时再拼一次顺序。

我更认可的主线是：

把范围切分、链路定位、放大识别和动作决策这四个阶段固定下来，再把最关键的证据项和止血边界固化成清单。

这条主线立住以后，检查表才不会只是挂在墙上的文档，而会变成事故现场真能帮团队少走弯路的一张动作单。

它在值班体系里放在哪一层

它本质上就是一张事故现场的第一轮动作单：先切范围，再找链路位置，再看有没有放大器，最后才决定止血还是继续下钻。

还想把值班动作补完整的话

• 想先把治理顺序理顺：看 稳定性治理先做容量评估、慢链路梳理还是告警分层？
• 想把 timeout / 重试 / 熔断参数补成一套：看 一个接口的超时、重试、熔断参数，应该怎样整体设计？
• 想把高风险故障链做成日常演练：看 缓存故障链应该有哪些演练场景，才能避免线上现学？

如果 timeout 已经开始沿链路扩散

• 接口超时增多时，先区分应用、网络还是下游依赖？
• 网关 504、应用超时、客户端超时，到底谁先超时？
• 值班时看到多个告警同时响，第一轮该怎样做范围切分？
• 接口超时风暴里，先止血还是先定位？如何判断分界线？

往下接时，可以这样看

1. 把这篇里的 范围切分 -> 链路定位 -> 放大识别 -> 动作决策 骨架走顺，确保第一轮动作别乱。
2. 如果眼前最缺的是第一轮范围判断，就继续看 值班时看到多个告警同时响，第一轮该怎样做范围切分？。
3. 如果现场总在“先止血还是先定位”上摇摆，再继续看 接口超时风暴里，先止血还是先定位？如何判断分界线？。
4. 如果你准备把这份检查表再往治理层落实，就把 稳定性治理先做容量评估、慢链路梳理还是告警分层？ 和 一个接口的超时、重试、熔断参数，应该怎样整体设计？ 接着看。