干了这么多年 Linux 运维我越来越觉得“排查问题”这件事真正拉开差距的往往不是谁记得的命令多而是谁脑子里的排查路径更清晰。尤其面试的时候面试官问“服务器负载高了你怎么排查”其实他根本不在乎你背了多少命令他想听到的是一套完整的、有逻辑的思考过程。换句话说面试考的不是“你用过什么”而是“你遇到问题先干什么、再干什么、为什么这么干”。这篇文章我就把自己这些年实际跑生产环境攒下来的排查思路、命令组合、以及面试里能让面试官眼前一亮的回答框架完整梳理一遍。内容会覆盖从信息收集、分层排查到具体的高频故障场景处理再到面试话术模板。不管你是刚入行的运维新人还是准备跳槽的进阶选手这篇文章都能直接拿来用。1. 排查问题的底层思路先定边界再动手1.1 面试官要的不是命令是思路很多人面试的时候一听到“CPU 高怎么排查”上来就说“用 top 看”。这不能算错但给面试官的观感就是——你只会执行命令没有形成系统性的判断框架。真正标准的回答应该是先确认问题性质、影响范围、时间窗口再逐层缩小排查边界。我给你打个比方。服务器出问题就像家里水管漏水你不会先拿抹布去擦地而是先看是墙内管漏还是接头漏、是冷水管还是热水管、什么时候开始漏的。排查服务器也是一个逻辑先确认问题是什么、出现在哪一层、什么时候开始的、影响多大然后再决定用哪组命令去定位。我自己的排查流程常年固定为四步收集信息 - 定位层级 - 聚焦进程 - 确认根因。每一次出问题都走这个流程不跳步基本能砍掉 90% 以上的无效操作。1.2 第一步确认问题现象与时间线接到告警或者被业务方拉进群的时候第一件事不是 ssh 上去敲命令而是先问清楚几个问题业务表现是什么是页面打不开、接口超时、还是数据写不进去这个问题是刚刚发生的还是昨天晚上就有了最近有没有发过版本、改过配置、扩过流量这些问题看起来很简单但极其重要。我见过太多人一接到告警就冲上去看 top、看日志折腾了几个小时最后发现是业务方自己发版导致的问题跟服务器一点关系都没有。先花两分钟确认现象和时间线能帮你避免一上午的无用功。另外一定要养成看告警时间的习惯。很多监控系统会记录故障开始的时间点把这个时间点和业务发版记录、定时任务执行时间、备份任务时间做交叉比对往往一下就能缩小排查方向。我自己排查问题时至少有一半的根因是通过“时间线比对”发现的而不是靠命令敲出来的。1.3 信息收集的黄金三条命令组合确认完现象之后登进服务器第一件事跑哪几条命令我常年用的是这三条组合起来能快速了解机器的整体状态uptime看系统运行时间和平均负载快速判断当前负载是否异常。top或htop看 CPU、内存、进程的整体占用情况。dmesg -T | tail看内核层面的日志有没有 OOM、硬件错误、文件系统报错。为什么先跑这三条因为它们能帮你建立“全局视图”。就像去医院看病医生先给你量体温、测血压、听心跳而不是直接让你去拍 CT。先知道是哪一类问题再决定用哪一把更精细的“手术刀”。注意dmesg很多人会用但容易忽略-T参数。加上-T之后内核日志的时间会显示成可读的日期格式而不是“3.141592 秒”这种开机后经过的时间。排查问题的时候时间对齐非常重要不然你根本不知道 OOM 是今天凌晨发生的还是三天前发生的。2. 分层排查模型从上到下还是从下到上2.1 应用层、系统层、硬件层的顺序怎么选服务器是一个多层结构从上到下依次是应用进程、系统内核、硬件资源、网络链路。排查问题的时候大多数人喜欢“从上到下”也就是先看应用日志、再看系统资源、最后看硬件。这个顺序适合大多数业务型故障因为接入层的问题最明显、也最容易确认。但有些情况要反过来。比如整台机器 ssh 都登不上去或者所有应用同时卡死这种时候大概率是底层出问题了应该“从下到上”——先看硬件磁盘灯、ipmi 告警、再看内核日志、最后看应用。排查顺序不是死的取决于故障的表象是“局部”还是“全局”。我自己的经验是能用“从上到下”就用“从上到下”因为它和人的直觉一致排查成本最低。只有确认全局性故障时才切到“从下到上”。2.2 网络层排查容易被忽略的一层很多人排查应用卡顿的时候盯着 CPU 和内存看半天结果最后发现是网络丢包。网络层是最容易背黑锅、也最容易甩锅的一层所以我每次排查都会单独过一遍网络的状态。常用命令就这几个ping网关或对端地址确认基础连通性和延迟。ss -ntpl看当前服务的监听端口和连接状态。sar -n DEV或ifstat看网卡流量、错误包、丢包率。ethtool -S eth0看网卡驱动层的丢包和错误计数。这里重点说一个小坑netstat已经逐渐被ss取代了但很多老运维还是习惯敲netstat。在连接数特别大的服务器上netstat会慢到让人怀疑人生因为它要读取/proc/net/tcp的完整内容并解析。ss用的是内核 socket 信息速度要快一个数量级。我现在所有涉及端口、连接数的场景都直接用ss。2.3 一个真实的排查案例演示讲一个我印象很深的案例。某天下午业务方反馈接口偶尔超时不是一直不可用是“时不时卡一下”。我上去跑了uptime负载不高top看了一眼CPU 和内存都正常然后看应用日志发现很多请求的耗时都超过了 3 秒但没有报错。到这里如果只盯着应用看很容易陷入死胡同。我转到网络层用sar -n DEV看了一小时的历史数据发现网卡的rxerrs和txerrs有持续的少量递增。再配合ethtool -S确认网卡存在 FIFO 丢包原因是网卡中断没有充分分散到多核 CPU。调整了 RSS 队列和中断绑定之后超时问题消失。这个案例想说明一个道理很多“应用慢”的问题根因并不在应用本身而在更底层的链路里。如果没有分层排查的框架很容易在应用层浪费大量时间。3. 高频故障场景与标准处理动作3.1 CPU 负载过高先分清“高 CPU”和“高负载”面试官特别爱考 CPU 相关问题但这里有个隐蔽的区分点CPU 使用率高和系统负载高是两个概念。CPU 高说明计算密集进程在持续消耗 CPU负载高除了 CPU 密集之外还可能是大量的 D 状态进程不可中断睡眠通常是磁盘 IO 等待把负载拉高了。所以遇到“系统很慢”的时候第一件事永远是top然后按1看每个核的使用率再按x高亮排序列看是哪个进程吃 CPU。同时看一眼进程状态列如果有很多 D 状态的进程那问题大概率在磁盘 IO 上而不是 CPU 上。定位到具体进程之后如果这个进程是 Java 应用我一般会用top -Hp pid找到具体线程再用jstack抓线程栈看它在干什么。如果是 Python 应用就用py-spy dump --pid pid来抓。这一步能帮你区分是“业务代码死循环”“GC 频繁”还是“等待外部资源”。注意不要一上来就kill -9。我曾经见过一个同事定位到某个脚本进程 CPU 高直接 kill 掉了结果这个脚本是另一个核心服务的守护进程杀掉之后核心应用直接停了。CPU 高的进程除非你已确认它是僵尸或者可重建的一次性任务否则不要贸然 kill先看清楚它的父子进程关系再说。3.2 内存不足与 OOM看日志比看数字更重要内存问题的排查套路比 CPU 更固定。先free -h看整体水位再用top按内存排序大写M看具体进程。但真正的杀手锏是看 OOM 日志——dmesg -T | grep -i oom或者直接看/var/log/messages。OOM 发生时内核会记录被杀的进程、当时的内存水位、各进程的 oom_score。拿着这些信息才能判断是单一进程内存泄漏还是整体内存规划不足。如果只是某个进程反复被杀那基本可以断定是它自己的问题——可能内存泄漏了也可能堆大小配置不合理。这里要特别提醒一个常被误解的点Linux 的内存机制里free显示的available才是真正可以拿来用的内存而不是free那列。因为 Linux 会尽量用空闲内存做 page cache所以free显示“只剩几百 MB”不代表内存不够反而说明缓存利用得很充分。判断内存是否紧张要看available是否持续接近 0同时伴随大量的 swap 使用或 OOM 事件。3.3 磁盘空间满与 inode 耗尽两个“满”不一样磁盘问题也是面试高频场景而且面试官特别喜欢挖一个点df -h显示空间还有很多但应用报“No space left on device”。这时候就没经验的人就懵了有经验的人会立刻敲df -i看 inode 是否耗尽。inode 是什么你就把它理解成文件系统的“户口本索引”。每个文件都要占一个 inode如果磁盘上小文件数量爆炸比如某个程序疯狂写日志每条日志一个文件inode 会被耗光此时即使磁盘还有几十 GB 剩余空间也创建不了任何新文件。排查方法很简单df -i看 inode 使用率find /路径 -xdev -type f | wc -l统计文件数量for dir in $(find / -maxdepth 3 -type d); do echo $dir: $(find $dir -xdev -type f 2/dev/null | wc -l); done找到小文件集中地另外还有一个常见坑日志文件被删除后进程还持有文件句柄导致空间不释放。这时候df显示已满但你用du去磁盘上找却找不到“占用者”。处理方法是用lsof | grep deleted找出还握着已删除文件句柄的进程重启它空间才会真正释放。3.4 进程异常与僵死从 ps 输出里读信息进程类的排查核心命令就是ps和ss。先ps -ef看进程是否在运行再看ps -eo stat,pid,ppid,cmd看状态。如果发现进程状态是Z僵尸说明它的子进程已经退出但父进程没有回收此时处理方式不是 kill 僵尸进程本身杀不掉而是要处理它的父进程让父进程去wait或者直接重启父进程。但比僵尸进程更可怕的是“进程活着但服务不可用”。这时候要用ss -ntpl确认端口是否在监听再用curl本机回环地址测试是否真的能响应。我最常干的一件事是curl -v http://127.0.0.1:端口/healthz如果回环都通那问题就出在网络链路或外部防火墙如果回环都不通说明服务本身已经假死需要抓线程栈、看 GC 日志、或者查连接数是否打满。注意排查服务不可用的时候不要只看端口。很多服务会开了一个端口但内部线程池已经全部卡死此时连接能建立、端口也在监听但请求就是没有响应。这种“假活”状态只有通过实际请求才能暴露出来。3.5 网络异常连接数、超时与丢包网络问题的排查要从三个维度展开连通性、连接数、丢包率。连通性用ping和telnet或nc测连接数用ss -s看整体统计ss -ant state established看当前建立的连接丢包率用sar -n EDEV或者ifconfig看 error 计数。生产环境中一个很典型的场景是“连接数被打满”。有些服务的默认配置比如单个端口最大连接数、或者net.core.somaxconn设置过小在高并发下会导致半连接队列溢出客户端表现就是“连接超时”或“连接被重置”。排查时用ss -lnt看Send-Q的值如果Recv-Q长期积压说明 accept 速度跟不上。处理这种问题的方法除了调大队列参数更重要的是确认是不是有大量的无效连接在占用资源。用ss -ant | awk {print $1} | sort | uniq -c | sort -n看一下连接状态的分布很快就能发现是不是 TIME_WAIT 堆积如山或者 SYN_RECV 异常增多。4. 面试回答的标准框架与话术4.1 用“现象-假设-验证-结论”四段式组织语言面试和实际排查有一个很大的不同面试官不会真的让你去敲命令他要听的是你的表达能不能体现出结构化的思维。我建议你们把所有问题排查的回答都套进一个四段式框架里描述现象 - 提出假设 - 逐个验证 - 得出结论。举个例子面试官问“服务器 CPU 100% 怎么排查”差的回答是“用 top 看一下然后 kill 掉进程就好了。”——这听起来就像个执行脚本的机器人。好的回答是“首先我会确认现象是用户反馈服务卡顿还是监控告警然后登到机器上跑 top 看 CPU 使用率和负载确认是不是真的 CPU 瓶颈而不是 IO 等待接着定位到具体进程用 top -Hp 找到线程结合 jstack 或者日志判断是业务代码死循环还是 GC 问题最后根据根因采取扩容、优化代码或调整参数的措施。”——每个环节都有明确的目的这就是面试官想听到的“标准回答”。4.2 高频问题的实战话术示例我在这里整理几个面试最高频的问题以及我认为比较标准的回答思路你可以直接拿来背但更重要的是理解背后的框架。问题一服务器负载突然很高你如何排查回答思路先uptime确认负载值和 1/5/15 分钟的走势判断是突发还是持续。再用top看 CPU 和 IO 等待用iostat看磁盘。接着用ps定位负载来源如果是 D 状态进程导致查磁盘如果是 R 状态进程导致查 CPU 密集型任务。最后看内核日志dmesg排除硬件或 OOM 干扰。问题二服务无法访问你怎么排查回答思路按链路逐层测。先 curl 本机回环确认服务本身是否活着再 ping 网关确认网络链路是否通再用 telnet 测端口连通性最后看防火墙规则iptables或firewalld和云安全组。每一层都有对应的工具和结论一层层缩小范围。问题三磁盘空间还有但报磁盘满是什么原因回答思路先df -h和df -i对比确认是 inode 耗尽还是文件系统层面的隐藏占用。如果是 inode 问题用find统计小文件数量并定位目录。如果是空间未释放用lsof | grep deleted找到持有已删文件句柄的进程。这个回答能把普通运维和资深运维区分开。4.3 面试官追问时如何“接住”面试官最爱干的事是在你回答完之后追问一句“那你怎么确认是这个问题”或者“有没有其他可能”这时候千万不要慌更不要强行圆场。正确的做法是承认多种可能性然后说明你如何通过证据链排除干扰项。比如你说了“可能是 CPU 问题”面试官反问“怎么排除磁盘问题”你可以回答“CPU 导致的问题top里看到的应该是 %CPU 高而 %iowait 低磁盘导致的负载高top里会看到大量 D 状态进程且 %iowait 高。两者在top输出中的特征不一样还可以用iostat -x 1看磁盘的%util和await来进一步确认。”——这种回答出来面试官根本没法继续刁难因为它展示了你对工具输出背后的含义有真正的理解。5. 常用命令速查表与实战避坑心得5.1 按场景划分的核心命令速查表命令太多记不住是很多人面试前的焦虑来源。但实际上面试和工作中高频用到的就那几个我整理了一个按场景划分的速查表你们可以直接截图保存。排查场景核心命令关键输出指标全局状态uptimeload average 三个值CPU/内存top%CPU、%MEM、D 状态进程磁盘空间df -h/df -i容量使用率、inode 使用率磁盘性能iostat -x 1%util、await、svctm内存细节free -havailable、swap 使用内核/硬件日志dmesg -TOOM、I/O error、硬件报错端口连接ss -ntpl监听端口、连接状态进程详情ps -ef/ps -eo stat,pid,cmd进程状态、父子关系实时流量sar -n DEV 1rxkB/s、txkB/s、错误包文件句柄lsof | grep deleted已删除但被占用的文件这些命令没有一个是冷门的但组合在一起就能覆盖 90% 以上的服务器问题排查场景。面试之前把这张表里的命令都敲一遍、理解每个输出字段的含义比盲目背一百条命令有用得多。5.2 我踩过的几个坑写出来给你们避雷干运维这些年我踩过不少坑有些坑甚至是在“看起来一切正常”的时候踩的。挑几个最典型的分享出来。第一个坑top显示的 CPU 使用率是平均值可能掩盖单核飙高。很多应用是单线程模型某个核已经是 100% 了但top全局显示只有 8%16 核机器上。不看细节、只看平均值你会漏掉真正的瓶颈。所以我习惯每次都按1展开每个核的状态。第二个坑排查网络问题时不要忘了云平台的安全组/防火墙。传统物理服务器时代防火墙就在本机上iptables -L一查就知道。但现在是云环境为主有时候本机防火墙是放行的流量却在云平台的安全组被拦了。这种问题靠服务器上的命令是查不出来的只能去云控制台排查或者用不同网段的机器测试。遇到网络不通的问题一定先想清楚“这台机器是不是在云上、有没有安全组策略”。第三个坑dmesg日志可能被刷掉了。有些机器运行时间长、内核日志量大等你发现问题的时候dmesg里早期的 OOM 或硬件错误已经被刷掉了。要避免这个问题最好提前配置好rsyslog把内核日志持久化到文件或者至少确保系统日志服务在正常运行这样出问题时能查到历史记录而不是只有“当下的片段”。5.3 把排查过程沉淀成脚本和文档最后分享一个我坚持了很久的习惯每排查完一个复杂问题就把整个排查过程中的命令、当时的输出、根因分析、解决措施整理成一页文档沉淀到团队的知识库里。一开始会觉得麻烦但积累一年之后你会拥有一个非常宝贵的“故障历史库”。以后再遇到相似的问题直接搜历史文档就能定位方向排查效率会翻倍。面试的时候如果被问到“做过最复杂的排查是什么”你也能拿出一个有完整故事线、有技术深度的案例来讲——这比任何自我介绍都有说服力。而且这些文档本身就是你从“会敲命令的运维”进阶到“能解决问题的运维”的最有力证明。我个人这些年最大的体会是排查服务器问题的能力本质上不是靠记忆而是靠框架和积累。把文章里这套“先定边界、再分层次、聚焦进程、确认根因”的方法跑熟把高频命令的每一个输出字段都看懂再遇到什么诡异的问题你心里都会有一条清晰的路径。面试也是如此——你不需要背下来所有的标准答案你只需要证明自己有一套稳定、可靠、可复用的排查方法论就已经超越了大部分的面试者。