做运维这些年我最深的体会是真正拉开水平差距的不是背了多少条Linux命令而是系统出问题时能不能在最短时间内定位到根因。市面上的Linux教程大多是按“命令大全”“系统管理”这种纵向结构写的但等你上了生产环境面对的是一个一个具体的故障现场——磁盘满了、服务起不来、网络时通时不通、应用突然卡死这时候翻书根本来不及。这也是为什么像《191页Linux系统运维故障排查手册》这类资料在运维圈流传很广。它本质上不是一本系统教程而是一套以“故障现象”为入口的排查索引告诉你遇到某个问题该看哪个日志、敲哪条命令、按什么顺序排除。这份手册适合三类人刚入行的运维新人需要一个成体系的排查思路从开发转运维的同学缺少故障现场的处置经验以及准备面试的工程师很多面试题其实就是从真实故障里提炼出来的。这篇内容我就把手册背后的核心思路和几类高频故障的排查方法拆开讲讲配合实际命令和踩坑经验希望能给你一套能直接拿去用的排查框架。1. 手册到底在讲什么故障排查的底层逻辑1.1 从“191页”看故障排查手册的架构思路很多同学拿到这类手册第一反应是翻到命令列表那页赶紧背。但真正值得研究的是它的目录结构。191页看着不少但拆开看其实就几大块系统启动阶段、用户与权限、文件系统与存储、网络通信、进程与服务、内核参数、日志分析、常见应用部署。这其实就是Linux系统的分层体系在故障维度的映射。系统的任何故障都能映射到某一层去排查。比如开机起不来问题大概率在引导加载器、initramfs、systemd服务这几层网络不通可能出在物理链路、IP配置、路由策略、防火墙规则这些层级。手册之所以按这个结构编排就是为了让你在碰到问题时先“分层定位”而不是眉毛胡子一把抓。这种分层思维比记住多少命令都重要因为命令是工具分层定位才是方法论。我自己的习惯是拿到一个故障先把现象写下来然后问自己三个问题这个问题发生在哪个层面这个层面的日志在哪里哪条命令能最快验证我现在对这个层面的判断如果这三个问题都能答上来80%的故障其实都能独立解决。1.2 故障排查的通用闭环现象确认、日志定位、命令验证、修复回归手册里反复强调的排查顺序总结起来就是四步。第一步是确认现象这里特别容易踩坑——很多同学一看负载高了就直接kill进程但负载高和CPU高不是一回事负载高可能是在等I/O这时候 kill 进程反而会把服务搞挂。要先弄清楚“到底哪里不对劲”是响应慢了、连接断了、还是数据不对了现象描述得越具体排查方向越清晰。第二步是采集信息核心是看日志。系统级的问题找journald日志内核的问题找dmesg应用的问题找应用的log文件网络的问题可以同时看tcpdump抓包和conntrack表。第三步才是用命令验证猜测比如你觉得是磁盘满了就用df -h确认觉得是文件句柄耗尽就用lsof -p | wc -l数一下。最后一步是修复和回归修复完不能直接下班要观察一段时间确认故障没有复发还要把临时措施转成永久配置比如手动释放了磁盘空间得想想是不是要加日志轮转策略。这套闭环说起来简单但真正执行到位的人不多。我见过很多人在“确认现象”这步就省了凭感觉直接上个命令结果越改越乱。排查故障最忌讳的就是“没确认就开始动”动生产环境之前永远先备份和评估影响范围。1.3 手册怎么用效率最高这类手册不建议从头到尾硬啃更适合当工具书和自查清单。我的用法是这样的先花一个晚上把目录看一遍在脑子里建立“遇到什么问题该去哪个章节找答案”的映射然后挑自己工作中最高频的几类故障——比如磁盘、网络、服务管理——把对应的章节精读一遍敲一遍里面的命令剩下的章节等真正遇到故障时再边查边学这样印象最深。另外非常推荐大家对照手册做一份自己的“故障记录表”每一次故障都记上故障现象、影响时间、排查经过、根因分析、修复措施、后续改进。坚持半年你就有了一份比任何手册都贴合自身业务环境的排查手册这才是手册使用的最优解。2. 高频故障的定位思路与实操命令2.1 磁盘空间与inode耗尽两条命令分辨两种“假满”工作中碰到“No space left on device”是最常见的问题之一但这个报错并不一定真的是磁盘空间满了。Linux下有两个不同的容量概念块空间和inode。块空间是数据实际占用的空间inode是文件元数据的索引数量。很多新手只记得df -h却忘了df -i结果排查半天发现空间明明还有剩余但就是写不进文件。如果df -h显示空间满了第一步别急着删文件先找到到底是谁占了空间。用du -sh /* 从根目录开始逐层往下看很快就能找到巨大的目录。但还有另一种情况更隐蔽一个文件被进程打开并删除了空间却没有释放。用lsof | grep deleted可以找出这些“已被删除但仍在占用磁盘”的进程这些文件占用的空间只能通过重启进程或重启系统来释放。我在生产环境处理过一次磁盘满就是nginx的access.log被误删了但master进程还持有文件句柄导致磁盘空间一直不降。所以排查磁盘空间时df、du、lsof这三条命令要配合使用。如果df -h显示空间充足但报错还是No space left那基本就是inode耗尽。这种情况常见于小文件非常多的目录比如邮件队列、squid缓存目录、docker容器层、node_modules这种依赖目录。用df -i确认inode使用率达到100%然后找出小文件最集中的目录清理。批量删除大量小文件时建议用find xargs的方式写成find /data/xxx -type f -mtime 30 -name *.log -print0 | xargs -0 rm -f注意-print0和-0必须配对使用否则遇到含空格的文件名会出问题。另外千万不要在大量小文件目录里用ls直接数文件数量非常慢用find /data/xxx -type f | wc -l更高效。2.2 服务起不来、端口被占systemctl状态排查法服务无法启动很多同学第一反应就是看配置文件但正确的顺序是先看服务当前状态再看日志。用systemctl status 服务名它会把服务的主进程PID、启动时间、最近几条日志、是否报错一次性列出来。如果只显示failed但没有细节就用journalctl -u 服务名 -n 50 --no-pager看最近的服务日志基本都能看到具体报错。端口被占用是另一类高频问题特别是用Nginx、Tomcat、MySQL这类固定端口的服务时。排查的思路是先确认端口被谁占了再判断这个进程该不该被处理。常用的命令包括ss -lnpt | grep 端口号它比netstat -tlnp更推荐因为ss直接从内核socket信息读取数据速度快且准确。找到占用进程的PID后用ps -fp 看是什么程序再判断后续处理。如果确认要强制结束进程用fuser -k 端口号/tcp也能直接杀掉占用该端口的进程但这条命令比较暴力生产环境慎用。还有一类情况是端口明明没被占用但服务还是起不来这时候要往两个方向查一是监听的IP地址比如服务配置成监听127.0.0.1外部自然访问不到但服务本身是正常的二是文件的权限问题比如socket文件、pid文件、日志目录的属主不对服务进程没权限写入。启动服务时报权限类错误一般journalctl日志里都会有明确提示仔细看就不会绕弯子。2.3 系统负载飙高看懂load average背后的I/O等待陷阱load average这个指标经常让刚接触Linux的同事一头雾水。它统计的是处于运行态和不可中断态的进程数量也就是正在用CPU的和正在等待I/O的进程总和。所以负载高不一定代表CPU不够用了还可能是磁盘I/O卡住了大量的进程。判断方法是配合top和iostat来看。先用top看整体情况按1键查看每个CPU核心的使用率如果us用户态CPU占用很高那是计算密集型问题用pidstat -p ALL 1定位具体进程如果waI/O等待很高问题就在磁盘用iostat -x 1看一下%util和await如果%util长期超过80%基本可以断定磁盘是瓶颈。还有一种情况是CPU和I/O都不高但负载还是很高这时候要考虑是不是进程处于D状态不可中断睡眠的数量太多可能是NFS挂载点异常、内核模块卡住导致的用ps -aux | grep D状态查一下就能确认。负载问题的排查还有个大坑云服务器上看到的load可能被“窃取”的CPU时间影响。用top看可以留意一下ststeal这一项如果st很高说明宿主机上的其他虚拟机在争抢CPU这是云服务商层面的问题自己在系统内部怎么调都很难解决。遇到这种情况先把能确认的进程层面问题处理掉剩下的就要考虑迁移实例或者和云厂商核实了。2.4 应用无法启动的五个通用排查点应用起不来除了服务管理的问题还可能出在运行环境上。我一般按“权限、依赖、端口、内存、日志”五个方向排查。首先是权限看应用目录、日志目录、配置文件是否对运行用户可读可写特别是用非root用户跑应用的时候权限问题发生概率非常高。其次是依赖比如动态链接库是否齐全用ldd 可执行文件可以查看依赖的.so文件是否都能找到缺了哪个就装哪个。很多从源码编译的程序在CentOS上能跑换到Ubuntu上报错基本都是这个原因。依赖过了看端口确认应用要监听的端口没被其他进程占用然后看内存用free -h确认可用内存是否充足如果内存不足导致OOM系统日志里会记录内核杀进程的信息用dmesg | grep -i oom可以看到或者直接看journalctl里面的oom事件。最后才是看应用自身的日志比如Java应用就去看catalina.out或类似日志Python应用看supervisor或gunicorn的日志。按这个顺序走下来90%的“起不来”问题都能找到原因。3. 网络层排查从连通性到抓包的完整路径3.1 先分层测试连通性二层、三层、四层逐层确认网络故障排查是最容易让人血压升高的场景因为网络涉及链路、地址、路由、防火墙、应用协议等多个层面任何一个环节出了问题都会表现为“不通”。我的习惯是从下往上逐层确认不要一上来就ping不通就怀疑防火墙。第一步看链路层用ip link show确认网卡状态UP才是正常的如果显示DOWN就说明物理链路有问题检查网线、交换机端口或者用ethtool 网卡名查看协商速率和链路状态。第二步看网络层用ping测试对端IP的连通性能通说明物理链路和IP配置基本正常ping不通就查IP地址配置是否正确、网关是否可达用ip route查看路由表。第三步看传输层很多服务对ICMP不响应但TCP端口是通的所以ping不通不一定代表服务不可用用telnet 目标IP 端口号或者nc -vz 目标IP 端口号做一次端口连通性测试。这一步常常能把“网络不通”缩小为“某个服务没监听”或“防火墙拦截了特定端口”。如果前三层都通了但业务还是报错那就要上抓包工具了。tcpdump是Linux下最常用的抓包工具基本用法是tcpdump -i eth0 host 目标IP -nn -c 100抓完用Wireshark打开分析。不要被复杂的抓包参数吓到最常见的用法只需要管住网卡、主机、端口这几个筛选条件。抓包能直接看到TCP三次握手是否完成、有没有RST重置、重传率是否过高这些信息在排查“时通时不通”“连接被重置”“响应慢”这类问题时非常有用。3.2 DNS解析异常resolv.conf和systemd-resolved的拉锯战DNS问题在故障排查里占有不小的比例而且症状千奇百怪——有的域名能解析有的不行、内网域名时而生效时而失效、ping域名报错但用IP访问完全正常。这类问题首先要看系统用的DNS服务器是谁用cat /etc/resolv.conf查看但这个文件在很多系统上可能只是符号链接指向systemd-resolved或NetworkManager生成的文件所以手动改完再被覆盖是常见的事。现在的系统里常年有一个“打架”的场景/etc/resolv.conf里的配置和systemd-resolved的配置不一致。如果用了systemd-resolved推荐用resolvectl status看实际生效的DNS配置用resolvectl query 域名做解析测试。如果想手动改DNS且不想被覆盖最稳妥的办法是配置NetworkManager的连接设置而不是直接改resolv.conf。排查时还要区分是本地解析问题还是上游DNS服务器问题用dig 域名 8.8.8.8这种指定上游服务器的方式测试一下如果指定DNS服务器能解析而默认配置解析不了问题就在本地DNS配置或网络路径上。对了排查DNS还要注意一个细节域名解析结果可能被缓存了修改DNS服务器或hosts文件后要清掉缓存才能生效。systemd-resolved的缓存可以用resolvectl flush-caches清空用dnsmasq的重启dnsmasq服务Nginx、Java等应用自己也有一层DNS缓存改完hosts后服务不重启就可能一直用的是旧解析结果。这些都是实际环境中非常容易踩的隐藏坑。3.3 虚拟化与云环境的网络排查KVM、虚拟机、网桥不再黑盒现在大家生产环境里虚拟机用得很普遍不管是KVM还是其他Hypervisor虚拟机里的网络问题有时候只是“宿主机的网桥没配好”。KVM最常使用的网络模式是桥接模式宿主机上会有一个虚拟网桥设备虚拟机网卡绑定到这个网桥上。排查虚拟机网络的时候先在宿主机上用brctl show或ip link show type bridge查看网桥状态确认虚拟机网卡是不是正常挂载在桥上很多“虚拟机突然上不了网”的问题重启一下虚拟网卡或者重新添加接口就能解决。Virbr0是KVM默认安装时自动创建的一个NAT网桥用它的时候虚拟机通过宿主机访问外部网络NAT规则由iptables维护。如果虚拟机之间要互通或者要对外提供服务尽量配置成桥接模式直接把虚拟机接到物理网络里。判断当前虚拟机用的是什么模式用virsh net-list和virsh net-dumpxml 网络名称可以看到虚拟网络的详细配置。云主机和容器环境还有一类网络问题宿主机上iptables规则或conntrack表异常导致流量转发失败。外部访问TCP服务时通时不通、连接建立后立刻被重置这类问题建议查一下conntrack的状态用conntrack -L | grep 内网IP看看状态是否在变如果conntrack表满了内核会直接丢包表现为网络间歇性抽风。这时候可以临时增大net.netfilter.nf_conntrack_max参数但根治还要看是不是有连接泄漏的进程。3.4 外接显示器与桌面环境的显示问题排查这个和服务器关系不大但在使用Linux做桌面工作站的同事那里经常碰到典型症状是笔记本外接显示器后完全没有信号。首先要确认Linux内核和显卡驱动是否识别了外接显示器的热插拔事件使用dmesg -wT然后重新插拔一次HDMI/DP线看是否有新的DRM或显卡相关日志输出。如果内核没有任何反应大概率是线材、转接头或者接口本身的问题如果内核有日志但屏幕仍然不亮可能是桌面环境的显示配置问题。在GNOME桌面下可以试一下按Super键搜索Displays看系统是否检测到第二台显示器或者直接用xrandr命令查看当前的显示输出状态xrandr里会列出检测到的所有输出接口比如eDP-1、HDMI-1、DP-1等。确认系统识别到了显示器才能进一步调整分辨率、刷新率或扩展模式。还要注意有些Linux发行版默认安装的是开源驱动对NVIDIA或AMD的新卡支持不到位导致DP接口无输出换用闭源驱动或者更新内核版本往往能解决。4. 部署与软件安装的踩坑记录4.1 Linux下安装Python/JDK环境变量和多版本管理的正确姿势现在Linux发行版自带的软件源版本普遍偏旧很多同学在装Python或JDK的时候会选择从官网下载压缩包自己解压部署。这个方式本身没问题但经常败在环境变量配置上。以JDK为例解压到/opt/jdk-17后要配置JAVA_HOME和PATH记得还要把export PATH$PATH:$JAVA_HOME/bin写进/etc/profile.d/目录下的独立脚本里这样比直接改全局profile更干净卸载时直接删脚本就行。Python这里有个经典的坑系统自带的python3可能是/lib下的你手动装的新版本在/usr/local/bin两个版本同时存在pip又对不上Python版本。我建议用update-alternatives来管理先update-alternatives --install把多个版本注册进去再用update-alternatives --config python3切换默认版本。还有一点特别重要不要动系统自带的/usr/bin/python3很多系统工具依赖它如果把它的指向改成新版本整个系统的包管理器都可能挂掉。版本切换完还要确认pip指向的Python版本用pip --version看输出如果发现pip装到了别的版本里就用python3 -m pip install 包名这种模块方式调用确保装到当前正在使用的解释器里。这类“装好了但怎么都调不起来”的问题九成都是环境变量和版本对应关系没理清。4.2 解压乱码、7z压缩包处理这些压缩格式问题一次说清Linux下处理压缩包最常见的报错是解压Windows传来的zip文件时中文文件名变成乱码。原因不复杂老版本zip工具默认编码是GBK而Linux默认按UTF-8解码文件名自然就乱码了。解决办法是用unzip -O GBK 文件名.zip指定解压编码或者用7z命令7z对编码兼容性好一些。如果你的系统unzip不支持-O选项可以试试装p7zip再解压。遇到.7z格式的压缩包常规的tar和unzip都解不了需要先装p7zip然后使用7za x 文件名.7z或者7z x 文件名.7z解压。7z命令行参数不多最常用的是x解压到目录和a打包压缩解压时注意-r递归参数在7z里是默认动作不需要额外指定。另外.tar.gz、.tar.bz2、.tar.xz这一系列的区别只在于压缩算法不同使用tar -xf的统一格式就能解压tar会根据文件后缀自动选择解压方式不用背那么多带参数的命令。4.3 虚拟机安装Linux常见蓝屏/黑屏与创建向导的配置细节很多人第一次装虚拟机时就被劝退了现象是VMware里启动Linux安装镜像结果蓝屏或黑屏。这类问题最常见的有三个原因一是虚拟机固件类型选错了现在主流Linux发行版对UEFI支持很好但某些老系统镜像用UEFI启动会起不来反过来有些新镜像用传统BIOS模式也会异常创建虚拟机时务必定好镜像类型再选固件二是CPU虚拟化没开启在BIOS里要确认Intel VT-x或AMD-V已启用否则虚拟机性能极差甚至无法启动三是内存分配太少安装图形界面的Linux至少2GB以上只给512MB大概率卡死或黑屏。还有一个几乎每个新手都会踩的坑创建虚拟机时会提示“已检测到操作系统”并自动选择系统版本但这个自动检测偶尔不准。手动在虚拟机设置里改成正确的操作系统版本比如CentOS 7、Ubuntu 22.04、Kali Linux等虚拟机会自动匹配更合适的硬件配置。如果新建虚拟机后连引导都进不去先在虚拟机设置里把“启动时连接”的光驱、软驱确认一下删除不用的设备很多启动黑屏其实是固件试图从空软驱或错误的光驱引导导致的。安装完成后同样可能出现“重启后直接进入黑屏”的问题这种一般是显卡驱动没装好。文本界面安装的服务器多等等或按CtrlAltF2切到另一个tty看能不能进入字符界面能进说明系统其实已经起来了只是显示服务挂了优先排查图形界面组件。4.4 WSL删除文件后空间没释放的清理办法WSL用得多了会发现Windows的磁盘空间只涨不跌明明在WSL里删了几十G的文件Windows的磁盘可用空间却纹丝不动。这是因为WSL默认使用一个动态增长的虚拟磁盘文件删除的文件只是从文件系统层面释放了但虚拟磁盘文件本身没有自动收缩。清理的办法有几种。如果你用的是WSL 2且虚拟磁盘在ext4分区里删除文件后在Windows的PowerShell管理员模式下运行wsl --shutdown然后使用diskpart或者wsl --manage 发行版名 --set-sparse true旧版本则需要打开diskpart选择虚拟磁盘并compact它。一个更省事的方法是直接使用官方近期推出的wsl --manage命令它能自动压缩虚拟磁盘。顺手提一句WSL提示“your version of windows subsystem for linux (wsl) is too old”的话先在PowerShell里执行wsl --update把WSL组件更新到最新版很多空间释放功能在新版本里才支持。日常使用WSL还有个建议把Docker的数据目录、conda环境这类体积大的目录放到WSL外的Windows文件系统里或者定期用docker system prune清理无用镜像和容器尽量避免把WSL虚拟磁盘撑到上百G再去收拾。4.5 国产化环境与办公软件的适配排查这几年国产Linux发行版在政企办公、教育等领域越来越多相关的问题也多了起来。比如在教育场景里希沃白板有Linux版安装时要注意它依赖的一些音视频和网络组件是否齐全企业微信和豆包这类Linux客户端常见的故障点是登录界面上不来、消息通知收不到排查方向集中在系统缺少字体包、缺少桌面通知服务或者GTK/Qt依赖库版本太旧上。国产化系统还有一个共同特点很多默认是关闭了第三方软件源的软件安装会遇到依赖包缺失。遇到这种问题优先查系统自带的软件仓库里有没有兼容版本不要一上来就下载通用发行版的deb/rpm包。要做跨发行版兼容先确认软件包依赖的glibc版本、桌面环境GTK还是Qt再用dpkg -i、rpm -ivh尝试安装缺依赖时用yum/dnf/apt自动补全。很多Linux客户端装完打不开在终端里手敲命令启动就能看到具体的动态库缺失报错。5. 故障现场的黄金命令组合与冷门排查技巧5.1 故障发生后的第一分钟先用这几条命令把现场固定住故障能不能快速解决很多时候取决于第一时间有没有收集到足够的信息。我的习惯是接到故障后先把下面这几条命令的输出保存下来再做任何别的操作。第一条是uptime看系统负载和开机时长开机时长能帮你判断是重启后故障消失还是持续故障第二条是free -h别小看它内存和swap的使用情况是很多“疑难杂症”的破案线索第三条是dmesg -T | tail -50看内核有没有报硬件错误、OOM、文件系统异常第四条是journalctl -xe这条命令几乎是systemd系统下的第一排查指令直接拉出最近的系统日志和出错的服务信息。这套命令组合的意义在于故障现场的信息是“活”的它是动态变化的很多日志滚得很快稍纵即逝。如果一开始不存档等你东查西查半天再回头想看第一时间的状态可能已经被后续操作覆盖了。存下来的现场信息就算这次用不上也能作为复盘素材。5.2 排查效率翻倍的两个冷门技巧strace和lsof有些故障用系统日志怎么都看不到根因比如某个程序启动时莫名其妙卡住、配置文件明明没问题但程序就是起不来。这时候我的杀手锏是strace它可以跟踪进程的所有系统调用看到程序卡在哪个环节上是访问文件权限不足、是在等待网络socket、还是在加载某个动态库时阻塞。使用strace -f -p 附加到一个运行中的进程或者用strace -f 启动命令来观察启动过程。输出会很多但通常看最后几十行就能定位问题。另一个冷门但好用的命令是lsof它能列出打开的文件和网络连接。排查“文件无法删除”“磁盘无法卸载”“端口被神秘进程占用”这类问题lsof都比ps更能说明问题。lsof D 目录可以列出目录下被打开的文件lsof -p 能查看进程所有的文件句柄很多句柄耗尽或文件锁定问题靠它一眼就能看穿。5.3 时间同步问题一个容易误导排查方向的隐形杀手最后分享一个我踩过的大坑NTP时间不同步会导致故障排查出现完全错误的判断方向。比如你用日志时间关联两个系统的操作记录发现A系统在10点发的请求B系统在9点收到怎么都解释不通最后才发现两个系统时钟差了整整一个小时。生产环境里多个服务器的时间必须一致尤其是涉及数据库事务、消息队列、证书校验的时候。排查步骤是先用date查看本地时区和时间再用timedatectl status确认NTP同步是否启用。系统日志里明明显示服务在“未来时间”报错那就要警觉是不是时间同步失效了。日志轮转也是一个值得提前配置的事很多“磁盘突然满了”的故障根本原因是没有配置logrotate一个日积月累的日志文件占了上百G。把日志轮转策略提早在所有服务器上铺开比事后清理要省心得多。这些年处理过的故障不计其数最大的心得就是排查故障没有银弹靠的是对系统运行机制的理解、清晰的分层思路、以及熟练使用工具的习惯。《191页Linux系统运维故障排查手册》这样的资料能帮你把散落的知识串起来但真正能内化成能力的还是你自己亲手解决过一个又一个问题后的积累。遇到故障别慌按照“确认现象、采集信息、定位根因、修复验证”的流程来绝大多数问题都能在半小时内找到出路。也建议每个人维护一份自己的笔记把每次处置的命令、日志片段、根因和结论沉淀下来时间越久你会越感谢当时的自己。
Linux运维故障排查实战：从磁盘满到网络异常的定位思路
做运维这些年我最深的体会是真正拉开水平差距的不是背了多少条Linux命令而是系统出问题时能不能在最短时间内定位到根因。市面上的Linux教程大多是按“命令大全”“系统管理”这种纵向结构写的但等你上了生产环境面对的是一个一个具体的故障现场——磁盘满了、服务起不来、网络时通时不通、应用突然卡死这时候翻书根本来不及。这也是为什么像《191页Linux系统运维故障排查手册》这类资料在运维圈流传很广。它本质上不是一本系统教程而是一套以“故障现象”为入口的排查索引告诉你遇到某个问题该看哪个日志、敲哪条命令、按什么顺序排除。这份手册适合三类人刚入行的运维新人需要一个成体系的排查思路从开发转运维的同学缺少故障现场的处置经验以及准备面试的工程师很多面试题其实就是从真实故障里提炼出来的。这篇内容我就把手册背后的核心思路和几类高频故障的排查方法拆开讲讲配合实际命令和踩坑经验希望能给你一套能直接拿去用的排查框架。1. 手册到底在讲什么故障排查的底层逻辑1.1 从“191页”看故障排查手册的架构思路很多同学拿到这类手册第一反应是翻到命令列表那页赶紧背。但真正值得研究的是它的目录结构。191页看着不少但拆开看其实就几大块系统启动阶段、用户与权限、文件系统与存储、网络通信、进程与服务、内核参数、日志分析、常见应用部署。这其实就是Linux系统的分层体系在故障维度的映射。系统的任何故障都能映射到某一层去排查。比如开机起不来问题大概率在引导加载器、initramfs、systemd服务这几层网络不通可能出在物理链路、IP配置、路由策略、防火墙规则这些层级。手册之所以按这个结构编排就是为了让你在碰到问题时先“分层定位”而不是眉毛胡子一把抓。这种分层思维比记住多少命令都重要因为命令是工具分层定位才是方法论。我自己的习惯是拿到一个故障先把现象写下来然后问自己三个问题这个问题发生在哪个层面这个层面的日志在哪里哪条命令能最快验证我现在对这个层面的判断如果这三个问题都能答上来80%的故障其实都能独立解决。1.2 故障排查的通用闭环现象确认、日志定位、命令验证、修复回归手册里反复强调的排查顺序总结起来就是四步。第一步是确认现象这里特别容易踩坑——很多同学一看负载高了就直接kill进程但负载高和CPU高不是一回事负载高可能是在等I/O这时候 kill 进程反而会把服务搞挂。要先弄清楚“到底哪里不对劲”是响应慢了、连接断了、还是数据不对了现象描述得越具体排查方向越清晰。第二步是采集信息核心是看日志。系统级的问题找journald日志内核的问题找dmesg应用的问题找应用的log文件网络的问题可以同时看tcpdump抓包和conntrack表。第三步才是用命令验证猜测比如你觉得是磁盘满了就用df -h确认觉得是文件句柄耗尽就用lsof -p | wc -l数一下。最后一步是修复和回归修复完不能直接下班要观察一段时间确认故障没有复发还要把临时措施转成永久配置比如手动释放了磁盘空间得想想是不是要加日志轮转策略。这套闭环说起来简单但真正执行到位的人不多。我见过很多人在“确认现象”这步就省了凭感觉直接上个命令结果越改越乱。排查故障最忌讳的就是“没确认就开始动”动生产环境之前永远先备份和评估影响范围。1.3 手册怎么用效率最高这类手册不建议从头到尾硬啃更适合当工具书和自查清单。我的用法是这样的先花一个晚上把目录看一遍在脑子里建立“遇到什么问题该去哪个章节找答案”的映射然后挑自己工作中最高频的几类故障——比如磁盘、网络、服务管理——把对应的章节精读一遍敲一遍里面的命令剩下的章节等真正遇到故障时再边查边学这样印象最深。另外非常推荐大家对照手册做一份自己的“故障记录表”每一次故障都记上故障现象、影响时间、排查经过、根因分析、修复措施、后续改进。坚持半年你就有了一份比任何手册都贴合自身业务环境的排查手册这才是手册使用的最优解。2. 高频故障的定位思路与实操命令2.1 磁盘空间与inode耗尽两条命令分辨两种“假满”工作中碰到“No space left on device”是最常见的问题之一但这个报错并不一定真的是磁盘空间满了。Linux下有两个不同的容量概念块空间和inode。块空间是数据实际占用的空间inode是文件元数据的索引数量。很多新手只记得df -h却忘了df -i结果排查半天发现空间明明还有剩余但就是写不进文件。如果df -h显示空间满了第一步别急着删文件先找到到底是谁占了空间。用du -sh /* 从根目录开始逐层往下看很快就能找到巨大的目录。但还有另一种情况更隐蔽一个文件被进程打开并删除了空间却没有释放。用lsof | grep deleted可以找出这些“已被删除但仍在占用磁盘”的进程这些文件占用的空间只能通过重启进程或重启系统来释放。我在生产环境处理过一次磁盘满就是nginx的access.log被误删了但master进程还持有文件句柄导致磁盘空间一直不降。所以排查磁盘空间时df、du、lsof这三条命令要配合使用。如果df -h显示空间充足但报错还是No space left那基本就是inode耗尽。这种情况常见于小文件非常多的目录比如邮件队列、squid缓存目录、docker容器层、node_modules这种依赖目录。用df -i确认inode使用率达到100%然后找出小文件最集中的目录清理。批量删除大量小文件时建议用find xargs的方式写成find /data/xxx -type f -mtime 30 -name *.log -print0 | xargs -0 rm -f注意-print0和-0必须配对使用否则遇到含空格的文件名会出问题。另外千万不要在大量小文件目录里用ls直接数文件数量非常慢用find /data/xxx -type f | wc -l更高效。2.2 服务起不来、端口被占systemctl状态排查法服务无法启动很多同学第一反应就是看配置文件但正确的顺序是先看服务当前状态再看日志。用systemctl status 服务名它会把服务的主进程PID、启动时间、最近几条日志、是否报错一次性列出来。如果只显示failed但没有细节就用journalctl -u 服务名 -n 50 --no-pager看最近的服务日志基本都能看到具体报错。端口被占用是另一类高频问题特别是用Nginx、Tomcat、MySQL这类固定端口的服务时。排查的思路是先确认端口被谁占了再判断这个进程该不该被处理。常用的命令包括ss -lnpt | grep 端口号它比netstat -tlnp更推荐因为ss直接从内核socket信息读取数据速度快且准确。找到占用进程的PID后用ps -fp 看是什么程序再判断后续处理。如果确认要强制结束进程用fuser -k 端口号/tcp也能直接杀掉占用该端口的进程但这条命令比较暴力生产环境慎用。还有一类情况是端口明明没被占用但服务还是起不来这时候要往两个方向查一是监听的IP地址比如服务配置成监听127.0.0.1外部自然访问不到但服务本身是正常的二是文件的权限问题比如socket文件、pid文件、日志目录的属主不对服务进程没权限写入。启动服务时报权限类错误一般journalctl日志里都会有明确提示仔细看就不会绕弯子。2.3 系统负载飙高看懂load average背后的I/O等待陷阱load average这个指标经常让刚接触Linux的同事一头雾水。它统计的是处于运行态和不可中断态的进程数量也就是正在用CPU的和正在等待I/O的进程总和。所以负载高不一定代表CPU不够用了还可能是磁盘I/O卡住了大量的进程。判断方法是配合top和iostat来看。先用top看整体情况按1键查看每个CPU核心的使用率如果us用户态CPU占用很高那是计算密集型问题用pidstat -p ALL 1定位具体进程如果waI/O等待很高问题就在磁盘用iostat -x 1看一下%util和await如果%util长期超过80%基本可以断定磁盘是瓶颈。还有一种情况是CPU和I/O都不高但负载还是很高这时候要考虑是不是进程处于D状态不可中断睡眠的数量太多可能是NFS挂载点异常、内核模块卡住导致的用ps -aux | grep D状态查一下就能确认。负载问题的排查还有个大坑云服务器上看到的load可能被“窃取”的CPU时间影响。用top看可以留意一下ststeal这一项如果st很高说明宿主机上的其他虚拟机在争抢CPU这是云服务商层面的问题自己在系统内部怎么调都很难解决。遇到这种情况先把能确认的进程层面问题处理掉剩下的就要考虑迁移实例或者和云厂商核实了。2.4 应用无法启动的五个通用排查点应用起不来除了服务管理的问题还可能出在运行环境上。我一般按“权限、依赖、端口、内存、日志”五个方向排查。首先是权限看应用目录、日志目录、配置文件是否对运行用户可读可写特别是用非root用户跑应用的时候权限问题发生概率非常高。其次是依赖比如动态链接库是否齐全用ldd 可执行文件可以查看依赖的.so文件是否都能找到缺了哪个就装哪个。很多从源码编译的程序在CentOS上能跑换到Ubuntu上报错基本都是这个原因。依赖过了看端口确认应用要监听的端口没被其他进程占用然后看内存用free -h确认可用内存是否充足如果内存不足导致OOM系统日志里会记录内核杀进程的信息用dmesg | grep -i oom可以看到或者直接看journalctl里面的oom事件。最后才是看应用自身的日志比如Java应用就去看catalina.out或类似日志Python应用看supervisor或gunicorn的日志。按这个顺序走下来90%的“起不来”问题都能找到原因。3. 网络层排查从连通性到抓包的完整路径3.1 先分层测试连通性二层、三层、四层逐层确认网络故障排查是最容易让人血压升高的场景因为网络涉及链路、地址、路由、防火墙、应用协议等多个层面任何一个环节出了问题都会表现为“不通”。我的习惯是从下往上逐层确认不要一上来就ping不通就怀疑防火墙。第一步看链路层用ip link show确认网卡状态UP才是正常的如果显示DOWN就说明物理链路有问题检查网线、交换机端口或者用ethtool 网卡名查看协商速率和链路状态。第二步看网络层用ping测试对端IP的连通性能通说明物理链路和IP配置基本正常ping不通就查IP地址配置是否正确、网关是否可达用ip route查看路由表。第三步看传输层很多服务对ICMP不响应但TCP端口是通的所以ping不通不一定代表服务不可用用telnet 目标IP 端口号或者nc -vz 目标IP 端口号做一次端口连通性测试。这一步常常能把“网络不通”缩小为“某个服务没监听”或“防火墙拦截了特定端口”。如果前三层都通了但业务还是报错那就要上抓包工具了。tcpdump是Linux下最常用的抓包工具基本用法是tcpdump -i eth0 host 目标IP -nn -c 100抓完用Wireshark打开分析。不要被复杂的抓包参数吓到最常见的用法只需要管住网卡、主机、端口这几个筛选条件。抓包能直接看到TCP三次握手是否完成、有没有RST重置、重传率是否过高这些信息在排查“时通时不通”“连接被重置”“响应慢”这类问题时非常有用。3.2 DNS解析异常resolv.conf和systemd-resolved的拉锯战DNS问题在故障排查里占有不小的比例而且症状千奇百怪——有的域名能解析有的不行、内网域名时而生效时而失效、ping域名报错但用IP访问完全正常。这类问题首先要看系统用的DNS服务器是谁用cat /etc/resolv.conf查看但这个文件在很多系统上可能只是符号链接指向systemd-resolved或NetworkManager生成的文件所以手动改完再被覆盖是常见的事。现在的系统里常年有一个“打架”的场景/etc/resolv.conf里的配置和systemd-resolved的配置不一致。如果用了systemd-resolved推荐用resolvectl status看实际生效的DNS配置用resolvectl query 域名做解析测试。如果想手动改DNS且不想被覆盖最稳妥的办法是配置NetworkManager的连接设置而不是直接改resolv.conf。排查时还要区分是本地解析问题还是上游DNS服务器问题用dig 域名 8.8.8.8这种指定上游服务器的方式测试一下如果指定DNS服务器能解析而默认配置解析不了问题就在本地DNS配置或网络路径上。对了排查DNS还要注意一个细节域名解析结果可能被缓存了修改DNS服务器或hosts文件后要清掉缓存才能生效。systemd-resolved的缓存可以用resolvectl flush-caches清空用dnsmasq的重启dnsmasq服务Nginx、Java等应用自己也有一层DNS缓存改完hosts后服务不重启就可能一直用的是旧解析结果。这些都是实际环境中非常容易踩的隐藏坑。3.3 虚拟化与云环境的网络排查KVM、虚拟机、网桥不再黑盒现在大家生产环境里虚拟机用得很普遍不管是KVM还是其他Hypervisor虚拟机里的网络问题有时候只是“宿主机的网桥没配好”。KVM最常使用的网络模式是桥接模式宿主机上会有一个虚拟网桥设备虚拟机网卡绑定到这个网桥上。排查虚拟机网络的时候先在宿主机上用brctl show或ip link show type bridge查看网桥状态确认虚拟机网卡是不是正常挂载在桥上很多“虚拟机突然上不了网”的问题重启一下虚拟网卡或者重新添加接口就能解决。Virbr0是KVM默认安装时自动创建的一个NAT网桥用它的时候虚拟机通过宿主机访问外部网络NAT规则由iptables维护。如果虚拟机之间要互通或者要对外提供服务尽量配置成桥接模式直接把虚拟机接到物理网络里。判断当前虚拟机用的是什么模式用virsh net-list和virsh net-dumpxml 网络名称可以看到虚拟网络的详细配置。云主机和容器环境还有一类网络问题宿主机上iptables规则或conntrack表异常导致流量转发失败。外部访问TCP服务时通时不通、连接建立后立刻被重置这类问题建议查一下conntrack的状态用conntrack -L | grep 内网IP看看状态是否在变如果conntrack表满了内核会直接丢包表现为网络间歇性抽风。这时候可以临时增大net.netfilter.nf_conntrack_max参数但根治还要看是不是有连接泄漏的进程。3.4 外接显示器与桌面环境的显示问题排查这个和服务器关系不大但在使用Linux做桌面工作站的同事那里经常碰到典型症状是笔记本外接显示器后完全没有信号。首先要确认Linux内核和显卡驱动是否识别了外接显示器的热插拔事件使用dmesg -wT然后重新插拔一次HDMI/DP线看是否有新的DRM或显卡相关日志输出。如果内核没有任何反应大概率是线材、转接头或者接口本身的问题如果内核有日志但屏幕仍然不亮可能是桌面环境的显示配置问题。在GNOME桌面下可以试一下按Super键搜索Displays看系统是否检测到第二台显示器或者直接用xrandr命令查看当前的显示输出状态xrandr里会列出检测到的所有输出接口比如eDP-1、HDMI-1、DP-1等。确认系统识别到了显示器才能进一步调整分辨率、刷新率或扩展模式。还要注意有些Linux发行版默认安装的是开源驱动对NVIDIA或AMD的新卡支持不到位导致DP接口无输出换用闭源驱动或者更新内核版本往往能解决。4. 部署与软件安装的踩坑记录4.1 Linux下安装Python/JDK环境变量和多版本管理的正确姿势现在Linux发行版自带的软件源版本普遍偏旧很多同学在装Python或JDK的时候会选择从官网下载压缩包自己解压部署。这个方式本身没问题但经常败在环境变量配置上。以JDK为例解压到/opt/jdk-17后要配置JAVA_HOME和PATH记得还要把export PATH$PATH:$JAVA_HOME/bin写进/etc/profile.d/目录下的独立脚本里这样比直接改全局profile更干净卸载时直接删脚本就行。Python这里有个经典的坑系统自带的python3可能是/lib下的你手动装的新版本在/usr/local/bin两个版本同时存在pip又对不上Python版本。我建议用update-alternatives来管理先update-alternatives --install把多个版本注册进去再用update-alternatives --config python3切换默认版本。还有一点特别重要不要动系统自带的/usr/bin/python3很多系统工具依赖它如果把它的指向改成新版本整个系统的包管理器都可能挂掉。版本切换完还要确认pip指向的Python版本用pip --version看输出如果发现pip装到了别的版本里就用python3 -m pip install 包名这种模块方式调用确保装到当前正在使用的解释器里。这类“装好了但怎么都调不起来”的问题九成都是环境变量和版本对应关系没理清。4.2 解压乱码、7z压缩包处理这些压缩格式问题一次说清Linux下处理压缩包最常见的报错是解压Windows传来的zip文件时中文文件名变成乱码。原因不复杂老版本zip工具默认编码是GBK而Linux默认按UTF-8解码文件名自然就乱码了。解决办法是用unzip -O GBK 文件名.zip指定解压编码或者用7z命令7z对编码兼容性好一些。如果你的系统unzip不支持-O选项可以试试装p7zip再解压。遇到.7z格式的压缩包常规的tar和unzip都解不了需要先装p7zip然后使用7za x 文件名.7z或者7z x 文件名.7z解压。7z命令行参数不多最常用的是x解压到目录和a打包压缩解压时注意-r递归参数在7z里是默认动作不需要额外指定。另外.tar.gz、.tar.bz2、.tar.xz这一系列的区别只在于压缩算法不同使用tar -xf的统一格式就能解压tar会根据文件后缀自动选择解压方式不用背那么多带参数的命令。4.3 虚拟机安装Linux常见蓝屏/黑屏与创建向导的配置细节很多人第一次装虚拟机时就被劝退了现象是VMware里启动Linux安装镜像结果蓝屏或黑屏。这类问题最常见的有三个原因一是虚拟机固件类型选错了现在主流Linux发行版对UEFI支持很好但某些老系统镜像用UEFI启动会起不来反过来有些新镜像用传统BIOS模式也会异常创建虚拟机时务必定好镜像类型再选固件二是CPU虚拟化没开启在BIOS里要确认Intel VT-x或AMD-V已启用否则虚拟机性能极差甚至无法启动三是内存分配太少安装图形界面的Linux至少2GB以上只给512MB大概率卡死或黑屏。还有一个几乎每个新手都会踩的坑创建虚拟机时会提示“已检测到操作系统”并自动选择系统版本但这个自动检测偶尔不准。手动在虚拟机设置里改成正确的操作系统版本比如CentOS 7、Ubuntu 22.04、Kali Linux等虚拟机会自动匹配更合适的硬件配置。如果新建虚拟机后连引导都进不去先在虚拟机设置里把“启动时连接”的光驱、软驱确认一下删除不用的设备很多启动黑屏其实是固件试图从空软驱或错误的光驱引导导致的。安装完成后同样可能出现“重启后直接进入黑屏”的问题这种一般是显卡驱动没装好。文本界面安装的服务器多等等或按CtrlAltF2切到另一个tty看能不能进入字符界面能进说明系统其实已经起来了只是显示服务挂了优先排查图形界面组件。4.4 WSL删除文件后空间没释放的清理办法WSL用得多了会发现Windows的磁盘空间只涨不跌明明在WSL里删了几十G的文件Windows的磁盘可用空间却纹丝不动。这是因为WSL默认使用一个动态增长的虚拟磁盘文件删除的文件只是从文件系统层面释放了但虚拟磁盘文件本身没有自动收缩。清理的办法有几种。如果你用的是WSL 2且虚拟磁盘在ext4分区里删除文件后在Windows的PowerShell管理员模式下运行wsl --shutdown然后使用diskpart或者wsl --manage 发行版名 --set-sparse true旧版本则需要打开diskpart选择虚拟磁盘并compact它。一个更省事的方法是直接使用官方近期推出的wsl --manage命令它能自动压缩虚拟磁盘。顺手提一句WSL提示“your version of windows subsystem for linux (wsl) is too old”的话先在PowerShell里执行wsl --update把WSL组件更新到最新版很多空间释放功能在新版本里才支持。日常使用WSL还有个建议把Docker的数据目录、conda环境这类体积大的目录放到WSL外的Windows文件系统里或者定期用docker system prune清理无用镜像和容器尽量避免把WSL虚拟磁盘撑到上百G再去收拾。4.5 国产化环境与办公软件的适配排查这几年国产Linux发行版在政企办公、教育等领域越来越多相关的问题也多了起来。比如在教育场景里希沃白板有Linux版安装时要注意它依赖的一些音视频和网络组件是否齐全企业微信和豆包这类Linux客户端常见的故障点是登录界面上不来、消息通知收不到排查方向集中在系统缺少字体包、缺少桌面通知服务或者GTK/Qt依赖库版本太旧上。国产化系统还有一个共同特点很多默认是关闭了第三方软件源的软件安装会遇到依赖包缺失。遇到这种问题优先查系统自带的软件仓库里有没有兼容版本不要一上来就下载通用发行版的deb/rpm包。要做跨发行版兼容先确认软件包依赖的glibc版本、桌面环境GTK还是Qt再用dpkg -i、rpm -ivh尝试安装缺依赖时用yum/dnf/apt自动补全。很多Linux客户端装完打不开在终端里手敲命令启动就能看到具体的动态库缺失报错。5. 故障现场的黄金命令组合与冷门排查技巧5.1 故障发生后的第一分钟先用这几条命令把现场固定住故障能不能快速解决很多时候取决于第一时间有没有收集到足够的信息。我的习惯是接到故障后先把下面这几条命令的输出保存下来再做任何别的操作。第一条是uptime看系统负载和开机时长开机时长能帮你判断是重启后故障消失还是持续故障第二条是free -h别小看它内存和swap的使用情况是很多“疑难杂症”的破案线索第三条是dmesg -T | tail -50看内核有没有报硬件错误、OOM、文件系统异常第四条是journalctl -xe这条命令几乎是systemd系统下的第一排查指令直接拉出最近的系统日志和出错的服务信息。这套命令组合的意义在于故障现场的信息是“活”的它是动态变化的很多日志滚得很快稍纵即逝。如果一开始不存档等你东查西查半天再回头想看第一时间的状态可能已经被后续操作覆盖了。存下来的现场信息就算这次用不上也能作为复盘素材。5.2 排查效率翻倍的两个冷门技巧strace和lsof有些故障用系统日志怎么都看不到根因比如某个程序启动时莫名其妙卡住、配置文件明明没问题但程序就是起不来。这时候我的杀手锏是strace它可以跟踪进程的所有系统调用看到程序卡在哪个环节上是访问文件权限不足、是在等待网络socket、还是在加载某个动态库时阻塞。使用strace -f -p 附加到一个运行中的进程或者用strace -f 启动命令来观察启动过程。输出会很多但通常看最后几十行就能定位问题。另一个冷门但好用的命令是lsof它能列出打开的文件和网络连接。排查“文件无法删除”“磁盘无法卸载”“端口被神秘进程占用”这类问题lsof都比ps更能说明问题。lsof D 目录可以列出目录下被打开的文件lsof -p 能查看进程所有的文件句柄很多句柄耗尽或文件锁定问题靠它一眼就能看穿。5.3 时间同步问题一个容易误导排查方向的隐形杀手最后分享一个我踩过的大坑NTP时间不同步会导致故障排查出现完全错误的判断方向。比如你用日志时间关联两个系统的操作记录发现A系统在10点发的请求B系统在9点收到怎么都解释不通最后才发现两个系统时钟差了整整一个小时。生产环境里多个服务器的时间必须一致尤其是涉及数据库事务、消息队列、证书校验的时候。排查步骤是先用date查看本地时区和时间再用timedatectl status确认NTP同步是否启用。系统日志里明明显示服务在“未来时间”报错那就要警觉是不是时间同步失效了。日志轮转也是一个值得提前配置的事很多“磁盘突然满了”的故障根本原因是没有配置logrotate一个日积月累的日志文件占了上百G。把日志轮转策略提早在所有服务器上铺开比事后清理要省心得多。这些年处理过的故障不计其数最大的心得就是排查故障没有银弹靠的是对系统运行机制的理解、清晰的分层思路、以及熟练使用工具的习惯。《191页Linux系统运维故障排查手册》这样的资料能帮你把散落的知识串起来但真正能内化成能力的还是你自己亲手解决过一个又一个问题后的积累。遇到故障别慌按照“确认现象、采集信息、定位根因、修复验证”的流程来绝大多数问题都能在半小时内找到出路。也建议每个人维护一份自己的笔记把每次处置的命令、日志片段、根因和结论沉淀下来时间越久你会越感谢当时的自己。
