同样排查线上故障，新人花 3 小时大佬只用 5 分钟，差距在哪

上周组里又上演了一次经典场面。 新人小周收到线上接口超时告警，一头扎进服务器里捞日至，从应用日志翻到 nginx 日志，又去搜数据库慢查，折腾了快三个小时，满头是汗连问题根因在哪都没摸到。旁边老陈路过凑过去看了一眼，打开监控大盘扫了三十秒，登服务器敲了三条命令，前后五分钟，定位到是缓存里的大对象没设过期时间，把老年代占满了一直在 Full GC。

群里有人开玩笑说老陈是开了挂，熟门熟路碰运气。其实真不是。我干这行快十年，见过太多新人排障，跟无头苍蝇一样东撞西撞，三个小时真不算久，熬通宵的都有。大佬和新人的差距，从来不是 “认不认识报错” 这么简单，差的是一整套思考方式和做事习惯。

很多新人上来第一步就错了。收到告警第一反应就是登服务器搜 error、搜 Exception，仿佛日志里藏着标准答案。问题是线上故障哪回都给你明明白白打印个异常栈？真要是空指针、类不存在这种低级错误，监控告警刚出来你就该定位到了。那些真正耗时间的疑难杂症，日志里往往干干净净，连个 ERROR 级别的日志都没有，就是单纯的慢、卡、超时。 你拿着关键词翻三个小时日志，翻到最后啥也没找着，心态先崩了，开始瞎猜：是不是网络波动了？是不是数据库挂了？是不是上游调用出问题了。一个个去试，时间全浪费在试错上。

大佬排障第一步，从来不是捞日志，是先划边界。 什么时候出的问题？出问题前有没有发版、有没有改配置。是全量接口都慢还是只有某几个？是所有节点都异常还是单台机器？影响了多少用户？ 这几个问题问完，方向直接就砍掉一大半。比如这次故障，老陈先看监控发现是 10 点整全节点同时开始响应变慢，所有接口都受影响，那直接就排除了单节点故障、排除了某段业务代码写坏了。再往下看系统指标，CPU 没爆，内存使用率涨了一截，GC 指标里 YGC 频率一分钟十几次，老年代使用率卡在 95% 下不来。 到这步还用猜吗？明显是内存问题，往 GC 上靠就完了。前后加起来不到一分钟，范围直接从 “整个服务的所有代码” 缩小到 “JVM 堆内存异常”，你跟逐行翻日志的比，效率能一样吗。

说起来前阵子还有个更夸张的。运维组新人查磁盘使用率告警，居然一个个文件夹点开看大小，翻了半个多小时还没找到大文件在哪。老运维过去一条 du -sh /* 扫下来，三秒就看见是某个服务的日志文件没做切割，攒了七十多 G。你说这是技术差距吗？是个人都知道 du 命令，但新人就是想不到先全局扫一眼，上来就钻细节里去了。

还有个很常见的差距：新人只会看 “报错”，大佬会看 “指标”。 很多新人脑子里有个误区：没报错就是没毛病。但线上大部分性能问题，根本不会给你抛异常。死循环会让 CPU 拉满，但不会打 error；内存泄漏会让 GC 变频繁，不到最后 OOM 根本不会有异常栈；连接池耗尽会让请求卡住，日志里可能就只有个超时。 你死盯着日志搜关键词，当然搜不到东西。大佬的思路是，任何系统异常，一定会先反应在指标上。CPU、内存、磁盘 IO、网络、GC、线程数、连接数，这些东西是系统的 “脉搏”。是用户态 CPU 高还是内核态高？是堆内存涨还是堆外内存涨？是读 IO 高还是写 IO 高？这些指标一对上，问题方向基本就定了。 就像上次有个新人查接口超时，翻了俩小时日志啥异常都没找着，我过去 top 一眼看见 CPU 占满了，jstak 一拉线程栈，正则表达式死循环。前后加起来两分钟。你说很难吗？不难，但你要是没看 CPU 指标的习惯，你就永远想不到往这查。

对了还有种新人我特别服，问题还没定位清楚呢，先开始改代码了，一口咬定就是这段逻辑有问题，要紧急发版。上次有个小伙子查了一小时没查出啥，直接改了段业务逻辑要上线，最后发现是 redis 配置的连接数设小了，白改半天代码，还差点带出新问题。

再说说心态上的差距。很多新人怕线上环境，碰都不敢碰，出了问题只会喊 “要不要回滚？要不要重启？”。 重启谁不会啊？重启是能恢复服务，但现场也没了。这次稀里糊涂好了，下次同款故障还得接着出。大佬的习惯是，先保现场，再谈恢复。出问题第一时间先抓快照：线程 dump 打一份，内存 dump 看情况打，网络连接状态截个图，GC 情况存个档，先把证据留好，再考虑要不要回滚、要不要重启。 而且很多人怕，觉得敲命令会把线上搞挂。其实常用的排查命令，jstat、jstack、ss、netstat、vmstat 这些全是只读的，根本不会对运行中的服务产生什么影响。你连这些命令都不敢敲，那排障效率自然上不去。当然了，jmap -dump 这种要暂停应用的，线上得谨慎，但大部分场景根本轮不到用这个。

顺手列几个日常排障用的最多的命令，新人可以存一下； top /htop 看系统整体资源占用 vmstat 1 看系统上下文切换、内存、IO 情况 jstat -gcutil 进程 id 1000 实时看 GC 情况 jstak 进程 id 打印当前线程栈 ss -antp 看网络连接状态 du -sh 目录 看目录大小

有人说，不就是经验多吗，干的久了自然就会了。这话对，但不全对。 我见过干了五六年的老开发，排障还是东一榔头西一棒子，碰到问题全靠瞎试。也见过工作两年的小伙子，排障思路特别清晰，碰到问题一步步来，效率比很多老员工都高。 差距在哪？在有没有总结自己的排查套路。 大佬脑子里都有自己的一张排查路径图。比如碰到接口超时，按顺序走：先看监控定影响范围→查系统资源（CPU、内存、磁盘、网络四大件）→查应用层状态（GC、线程池、日志）→查下游依赖（DB、缓存、MQ、第三方接口）→最后才去抠代码逻辑。 按这个路径走，每一步都在缩小范围，不会走回头路。新人呢？想到啥查啥，刚看了两眼日志，突然想起来会不会是数据库问题，又去查数据库，查一半又觉得可能是网络，来回跳，时间全耗在无效路径上了。 再就是基础知识的熟练度。你连 jstat 输出的每一列是什么意思都记不住，每次都要去搜 “jstat 参数详解”；你连 netstat 和 ss 的区别都搞不清，查个端口号还要百度。等你搜完搞明白，故障都扩散十分钟了。 大佬敲这些命令都是肌肉记意，手上敲着命令，脑子里已经在想下一步该查什么了，根本不用停下来查资料。这差距不就拉开了。

最后说句实在的，排障这事儿真没什么捷径，也没什么高深的技术门槛。 无非就是多踩坑、多复盘，每次处理完故障都写下来：问题是什么、根因是什么、排查路径是什么、哪步走了弯路、下次怎么能更快。 别每次故障解决了就完事了，过俩礼拜再碰到同款问题，还是一样手忙脚乱。那你干十年也还是新人水平。 等你踩的坑够多，总结的套路够熟，碰到问题条件反射就知道先查什么后查什么，你也能做到别人花三小时，你五分钟搞定。

哦对了，最后补一句。 别总觉得大佬是记忆力好，什么都知道。 人家只是不会上来就钻细节，先站在高处把范围划清楚，再一步步往下挖。 就像找东西，你上来就翻抽屉，人家先看是哪个房间丢的，能一样吗。