debug 排查性能运维

报警排查 && 性能分析的常用步骤

从"是不是单机房"到"模块互相影响"的五步排查清单

Posted by BY on April 25, 2026

原始笔记是一份带有真实案例的排查清单，这里把”通用步骤”和”具体案例”分开，原文要点都保留。

当前保留内容

一、如何排查定位

固定按下面这条主线往下走，能少走很多弯路：

判断是否单机房故障 先看影响范围是不是只局限在某个机房 / 区域，不要一上来就钻到代码里。
进一步判断是否单实例问题 单机房故障再细化：是某一台 / 一组实例的问题，还是机房整体？
排查最近的变更 配置变更、上线、依赖升级、数据迁移……越靠近报警时间点的变更越可疑。
工作负载分析（宿主机 + 实例） 重点回答：”哪些资源受限了？”
- 单实例视角：Redis / MySQL 的线程池、连接数；
- 集群视角：Redis / MySQL 集群允许的最大连接数；
- 比对历史正常水位，看哪一项被压到了上限。
宿主机上部署的模块汇总分析 多模块共宿主机时，模块之间会互相影响：某一模块或某一接口、功能的流量突增，会拖累同机其他模块的资源。

二、配套的真实案例

按上面的步骤走，曾经定位到的一类问题：

排查发现 Redis 函数耗时变大，且这部分耗时能汇聚到某一个业务上；
仔细看函数处理逻辑：save 消息之后存在清理逻辑，会清理过期的 key；
推测原因：历史消息太多，清理 key 的过程阻塞了 Redis，进而拉长了耗时；
再看 QPS：有群发消息，导致短时流量突增，进一步放大了上面的影响。

后续可补的方向

这篇后续如果继续整理，建议至少补下面几类内容：

每一步对应的常用工具和指标面板（监控看板、Top SQL、慢查询、连接数曲线等）
单机房 / 单实例故障常见 root cause 分类
“变更回滚”的标准操作流程（SOP）
多模块共宿主机时的隔离手段（cgroup、QoS、限流降级等）

当前这篇先当作一个”通用排查 SOP + 案例库”的待扩充占位条目。