线上故障排查实战:5 个经典场景的完整排查链路(运维面试必问)CPU 飙高、容器 OOM、磁盘满了、502/504、慢查询突增——这 5 个场景几乎覆盖了 80% 的线上故障。本文给出每个场景的完整排查链路、止损动作和面试答法,文末附自用刷题小程序。为什么面试官爱问你怎么排查因为排查过程最能看出一个人的基本功:知不知道先止损还是先定位每一步为什么看这个指标(而不是背命令)有没有机制沉淀(而不是重启解决)下面 5 个场景,每个都按「现象 → 排查链路 → 根因分类 → 止损 → 预防」拆开讲。场景一:CPU 飙到 100%排查链路# 1. 确认范围:是单机还是整个集群?load 多高?topuptime# 2. 定位进程(按 CPU 排序)top-P# 3. 定位线程(Java 应用关键一步)top-Hppid# 4. 线程号转十六进制printf%x\ntid# 5. 抓栈(Java)jstackpid|grep-A30hex# 通用手段:看热点函数perftop-ppid根因分类现象可能根因用户态高(us)业务死循环、频繁 GC、锁竞争内核态高(sy)系统调用频繁、上下文切换、软中断(si 高 网络)频繁 GCjstat -gcutil pid 1000看 FGC 次数与耗时止损与预防先保留现场(抓栈、dump),再重启/降级能限流先限流,别让雪崩扩散预防:CPU 告警、压测覆盖、代码评审面试加分点“我会先区分用户态还是内核态——这决定了是查代码还是查系统调用;另外我会先抓栈保留现场再重启,否则根因就丢了。”场景二:容器反复重启(OOMKilled)排查链路# 1. 看 Pod 状态与退出原因kubectl describe podpod|grep-A5Last State# 2. 看退出码# 137 OOM 或被 kill;1 应用报错;143 SIGTERM# 3. 看上次容器日志kubectl logspod-p# 4. 进容器看进程内存kubectlexec-itpod--top关键判断是内存泄漏还是峰值超限?持续增长 → 泄漏(查堆内存、堆外内存)平时正常、高峰被杀 → limits 太小或流量突增Java 堆外内存容易被忽略:DirectByteBuffer、Netty、JNI止损与预防止损:调大 limits、限流、重启预防:压测摸清峰值、加内存监控、JVM 参数调优场景三:磁盘满了第一步:区分两种满df-h# 空间满df-i# inode 满(大量小文件)这两种满的处理方式完全不同。第二步:定位大目录du-sh/*2/dev/null|sort-rh|head常见元凶:日志、core dump、容器日志(/var/lib/docker/containers)、K8s(/var/log/pods)。经典陷阱:删了文件,空间没释放文件被进程持有句柄,rm只解除目录引用,inode 仍被占用。lsof|grepdeleted# 找到持有进程# 处理:重启/reload 该进程;日志类可 kill -USR1 让其重开日志预防logrotate 轮转 max-size/max-file磁盘与 inode 双告警应用侧禁止往 stdout 打海量 debug 日志场景四:网关 502 / 504两者本质不同状态码含义排查方向502upstream 没接住请求后端进程挂了、端口不通、连接被拒504连上了但处理超时后端慢:慢查询、下游依赖、GC 停顿排查链路# 1. 看网关错误日志tail-f/var/log/nginx/error.log# 502 → connect() failed / connection refused# 504 → upstream timed out# 2. 绕过网关直连后端,确认是网关还是服务问题curl-vhttp://backend-ip:port/health# 3. 看连接数是否打满ss-snetstat-an|grepport|wc-l止损与预防502:先恢复后端(重启/扩容),再查为什么挂504:先看后端耗时分布(是全部慢还是个别接口),必要时降级非核心依赖预防:健康检查、超时与重试配置、连接池监控场景五:MySQL 慢查询突然增多排查顺序(很重要)先看变更:最近有没有发布、加索引、数据量增长、流量突增定位 TOP SQL:-- 慢查询日志按耗时排序mysqldumpslow-s t/var/log/mysql/slow.log|head看执行计划:EXPLAINSELECT...;-- 重点:type(ALL 全表扫)、rows(扫描行数)、Extra(filesort/temporary)看锁与连接:show processlist、show engine innodb status常见根因索引失效:函数操作、隐式类型转换、前导通配符、不满足最左前缀深分页:limit 100000, 20→ 游标分页或延迟关联大事务、锁等待止损与预防应急:kill 慢查询、限流、降级非核心查询根治:加/改索引、SQL 改写、历史数据归档预防:慢 SQL 门禁进发布流程、定期巡检 TOP SQL面试怎么答:一个通用框架不管问哪个场景,按这个结构答就不会乱:现象与影响面 → 止损动作 → 定位过程(逐步缩小范围) → 根因 → 改进与沉淀四个加分点:先止损后根因——说清为什么先做这个动作说判断依据——不是背命令,而是看到 A 说明 B,所以查 C给量化结果——“P99 从 800ms 降到 120ms”讲沉淀——文档、SOP、监控告警、演练机制反面例子:“重启一下就好了” —— 面试官听到这句基本就结束追问了。这些排查链路我整理成了一个小程序上面这些场景的题目(以及更多)我整理成了一个小程序「系统运维面试题学习随手记刷」,295 道题,按 8 个模块分类:中间件 · DevOps · SRE · 云原生 · Linux · AIOps · Shell · 综合开放题题库全部免费,不用登录,每题都有参考答案,就是本文这种排查步骤 回答结构的形式把简历和 JD 粘进去,会出 20 道针对你经历的押题,并给一份适配度分析还有录像练习:摄像头答题 → 回放 → 按要点自评,练表达(本地处理,不上传)微信搜索小程序「系统运维面试题学习随手记刷」你遇到过最离谱的线上故障是什么?评论区聊聊。