尧图网页设计 
简介一套面向Linux入门学习者与日常运维开发人员的实战案例合集以一百个经典应用场景为主线覆盖网络调用命令、Apache参数配置、Linux错误代码解读以及常见运行故障的排查方法适合对照练习、查阅并解决实际问题。整套资源共两百零四个文件主要以一百九十五个网页案例与说明文档为承载主体辅以三份PDF手册、两个实验压缩包、两个备用压缩包以及文档和可执行辅助程序压缩包整体约40.19MB目录结构清晰便于按主题模块检索。已有两千一百八十人学习下载。最大价值在于每个实例均呈现详细的功能调用过程与排错思路从命令行使用到服务配置层层展开既能帮助初学者理解系统运行机制也能在遇到类似报错时快速定位并对照解决。另含系统化索引、经典参考文档与辅助工具适合作为案头速查、完整练习样本及深入研读的备查材料。1. linux实战100例到底在解决什么问题如果你在搜索引擎里敲下“linux实战100例”大概率不是想再看一遍ls、cd、cp的用法解释而是已经在工位上被某个故障卡住、被某条命令的异常行为搞到怀疑人生了。这个标题代表的不是一百个孤立命令的罗列而是一百次真实场景里的问题拆解——从系统启动异常到磁盘占满从脚本定时任务不执行到进程间通信失败每一例背后都是一条完整的“现象 → 排查 → 解决”链路。它面向的是那些正在做Linux运维、嵌入式开发、系统管理工作或者准备Linux面试的人核心价值是让你在遇到同类问题时不用从零开始试错。真正的实战能力不是背出来的是踩坑踩出来的。一百个案例拆开看覆盖的是高频命令的非常规用法、故障排查的标准姿势、以及脚本编写里的边界条件和隐蔽坑点这些东西在手册和命令大全里都找不到答案。接下来的篇幅我会按实际工作中最常见的几条主线把这些案例拆开讲哪些命令最值得深挖、故障怎么定位、脚本怎么写才不容易翻车、以及面试官真正想考察的是什么。2. 命令实战里的优先级先救活系统再优化性能很多人学Linux命令是从“常用命令大全”开始的把top、df、ps背得滚瓜烂熟但真上了生产环境出了问题依然不知道从哪下手。原因很简单你背的是命令本身而不是命令适用的场景。一百个实战案例里最值钱的是按“先活着、再查因、后优化”的顺序把命令串起来用的能力。2.1 系统负载异常时先看的不该是top服务器响应变慢大多数人的第一反应是敲top看CPU占用率。这是一个典型的思维误区。CPU跑满只是表象真正的原因可能是磁盘I/O瓶颈、内存不足触发swap抖动、或者是某个进程在疯狂读写文件。正确的第一步是用uptime看负载均值再配合vmstat 1 5观察r运行队列和waI/O等待两个指标的变化趋势。# 每1秒采集一次共采集5次观察r和wa列 vmstat 1 5 # 如果wa持续偏高说明磁盘I/O是瓶颈 iostat -x 1 5逻辑说明vmstat的r列代表等待CPU的进程数wa列代表CPU花在等待磁盘I/O上的时间百分比。当r远大于CPU核心数时说明计算资源不够当wa居高不下时CPU其实在空转等磁盘这时候你换再好的CPU也没用得先处理存储。iostat -x里的%util接近100%基本可以确认磁盘阵列或单盘已经达到上限。参数说明vmstat后面第一个数字是采样间隔秒第二个是采样次数。实际排查中建议用1 5起步不要用默认的一次性输出因为负载是动态的单次快照看不出趋势。iostat需要 sysstat 包装好后-x参数会输出扩展信息1 5同样是秒数和次数。2.2 磁盘满了但df显示还有空间问题出在哪这是实战里非常经典的一类“翻车”案例应用报错说磁盘已满但你执行df -h一看根分区明明还有十几个G。真正的元凶通常是文件被进程打开后删除了但进程没退出占用的空间没有被释放。这时候df是查不出问题的要用lsof看已删除但仍被占用的文件。# 找出所有已删除但仍在被进程占用的文件 lsof | grep deleted # 定位到具体进程后确认进程PID和文件路径 lsof -p PID | grep deleted逻辑说明Linux下删除文件的本质是解除目录项的链接但如果文件已经被某个进程打开内核里的文件索引节点仍然存在磁盘空间要等进程关闭这个文件描述符才会真正释放。lsof输出里的deleted标记就是这类文件的特征。常见的处理方式有两种重启相关进程或者用 /proc/PID/fd/文件描述符号清空文件内容前者适合维护窗口内操作后者适合不能中断的服务。参数说明lsof不带参数会输出所有打开的文件量非常大生产环境建议直接管道过滤。grep deleted是关键词匹配有些老版本可能显示为(deleted)搜索时要注意。另外用/proc/PID/fd方式清空时必须先确认文件描述符号指向的是目标文件别清错了对象。2.3 查看端口占用时netstat和ss怎么选新装的系统上你可能发现netstat找不到了这不是系统变弱了而是ss已经把它替换掉了。ss直接读取内核的 socket 信息速度比netstat快一个数量级在处理大量TCP连接时尤其明显。一百个案例里如果只记一个查端口的命令我推荐ss。# 查看所有监听中的TCP端口及其对应进程 ss -lntp # 查看某个端口的连接情况比如8080 ss -tunap | grep 8080逻辑说明-l只看监听状态-n不做域名反解否则会卡在DNS查询上-t指定TCP协议-p显示进程信息。第二行的-u加上UDP-a表示所有状态。实际排查时如果某个端口连不上先看LISTEN状态是否存在再看有没有SYN_SENT堆积后者通常指向防火墙或对端服务异常。参数说明-p参数需要 root 权限普通用户执行会看不到进程名。另外ss的-a是显示所有 socket不是 older 版本netstat -a那样会同时输出路由表。这个细节踩过的人不少输出内容差很多。3. 故障排查实战像审案一样看日志和状态运维故障案例看得多会发现一个规律大部分“离奇”问题最后都能在日志里找到答案只是你没找对地方或者没找对时间点。故障排查是一场有方法的侦探工作顺序比命令更重要——先说现象再锁范围最后看日志验证而不是东敲一条命令西翻一个文件。3.1 系统启动异常时的排查路径从内核到服务服务器重启后起不来或者起来后某个服务状态异常这是生产环境里压力最大的场景之一。排查路径有一个固定顺序先确认引导阶段有没有报错再看系统日志里内核和服务的记录最后看目标服务自己的日志。很多人一上来就去翻/var/log/messages方向错了。# 查看最近一次启动的内核日志重点看硬件初始化和文件系统挂载 journalctl -b -p err # 检查关键服务的当前状态和最近几次重启记录 systemctl status sshd systemctl list-units --failed逻辑说明journalctl -b表示本次启动的日志-p err过滤出错误级别及以上的记录。如果内核层面有硬件无法识别、文件系统挂载失败这里会直接暴露。systemctl status sshd不仅显示当前状态还会列出进程的最近日志和主进程PID。list-units --failed能快速找出所有启动失败的服务比一个一个status查效率高得多。参数说明-b可以加数字比如-b -1看上一次启动的日志这个在对比“上次能起来这次起不来”时特别有用。有些系统用的是 rsyslog 而不是 journald那就要改看/var/log/messages和/var/log/syslog判断方法是执行systemctl status rsyslog确认是否在跑。3.2 服务莫名其妙被杀死先查OOM还是先看dmesg应用进程运行几天后突然消失systemctl status显示inactive (dead)重启后又恢复正常。这种情况大概率不是服务自身崩溃而是被系统的内存回收机制杀掉了专业叫法是 OOM Killer。但很多人习惯直接去调服务的超时时间这是舍本逐末。# 查看内核环形缓冲区找OOM Killer的杀进程记录 dmesg -T | grep -i killed process # 确认系统内存压力和swap使用情况 free -h cat /proc/meminfo | grep -i commit逻辑说明OOM Killer 是 Linux 内核在物理内存耗尽且 swap 不足时被迫选择牺牲进程来释放内存的机制。杀掉哪个进程由oom_score决定这个分数和进程占用内存量、运行时间、优先级都有关系。如果被杀的恰好是你的关键服务根源往往是另一个进程把内存吃光了单纯调大服务自身的内存限制治标不治本。参数说明dmesg -T里的-T是把时间戳显示成人类可读格式不加热参数显示的是开机秒数排查时对不上出事时间点很容易误判。free -h里重点看available而不是free因为 Linux 会主动把空闲内存用于缓存free很小不代表内存不足available才是真正可分配的量。3.3 网络排查的黄金命令组合ping不一定是第一步两台机器之间通信失败菜鸟先 ping老手先确认自己的网卡、IP和路由对不对。因为 ping 不通的原因太多了对端禁ping、中间防火墙策略、自身路由配置错误、DNS解析异常。把排查顺序定成“自底向上”每层验证一步才能快速缩小范围。# 第一步确认自己的网络配置 ip addr show ip route show # 第二步验证到网关的连通性 ping -c 3 网关IP # 第三步确认目标端口是否可达比ping更可靠 nc -zv 目标IP 端口逻辑说明ip addr show确认网卡有IP且状态是 UPip route show确认默认路由存在。这两步做完了本地网络基础就是健康的。接着 ping 网关能通则说明二层三层没问题。最后用nc -zv指定端口测试是因为很多故障是“能ping通但端口不通”防火墙、服务未启动都会导致这种情况。参数说明ping -c 3里的-c表示发送几个包就退出不加的话会一直ping下去脚本里跑批处理时很容易把人卡住。nc的-z是扫描模式只检测端口是否开放不发送数据-v输出详细信息有些精简系统没装 netcat可以用timeout 3 bash -c /dev/tcp/目标IP/端口替代效果一样。4. 脚本实战把重复运维变成一句话的稳妥写法一百个案例里如果有一半涉及 Shell 脚本剩下的那一半也值得你用脚本去解决重复操作。但写脚本的门槛不在语法在于你得先想清楚边界条件文件不存在怎么办、命令执行失败怎么办、传进来的参数是空值怎么办。这些没处理好的脚本就是生产环境里一颗颗定时炸弹。4.1 日志清理脚本先写保护再写删除清理日志是最常见的脚本需求也是最容易写错的脚本。很多人上来就写find /var/log -type f -mtime 7 -exec rm -f {} \;跑完才发现把正在被进程写入的日志删了或者误删了别的目录下的同名文件。正确的写法是先做保护再做清理最后留审计记录。#!/bin/bash # 日志清理脚本保留7天超过7天的压缩或删除 LOG_DIRS/var/log/nginx /var/log/app RETENTION_DAYS7 for dir in $LOG_DIRS; do if [ ! -d $dir ]; then echo $(date %F %T) WARN: $dir 不存在跳过 /var/log/cleanup.log continue fi # 只处理 .log 结尾的文件避免误删其他类型 find $dir -type f -name *.log -mtime $RETENTION_DAYS -exec rm -f {} \; echo $(date %F %T) INFO: cleaned $dir /var/log/cleanup.log done逻辑说明脚本先检查目录是否存在不存在就写告警日志并跳过避免因为路径配置错误造成后续命令全部扑空。find命令里加了-name *.log是第二层保护防止目录下出现非日志文件被误删。-mtime $RETENTION_DAYS表示修改时间超过7天的文件注意是号没有的话含义完全不同。每步操作都往审计日志里记录出了故障能追溯执行过程。参数说明$LOG_DIRS用空格分隔多目录如果要支持带空格的路径需要改成数组写法。-mtime 7和-mtime 7的区别是前者匹配超过7天的后者匹配恰好7天的少一个符号结果天差地别。-exec rm -f {} \;里的分号必须转义这是 find 语法里的固定要求。4.2 批量重命名文件让脚本自己先演练一遍用 Shell 重命名文件这个需求从热词搜索量就能看出它有多高频。mv命令本身很简单但批量重命名时一旦出同名覆盖、特殊字符截断这类问题后悔药都找不到。我一般会先让脚本输出将要执行的命令清单人工确认无误后再真正执行这个习惯帮我避免过好几次血泪教训。#!/bin/bash # 批量重命名把当前目录下的 *.txt 改为 *.bak DRY_RUN${1:-true} # 第一个参数默认只演练不实际执行 for file in *.txt; do # 文件不存在时通配符会原样输出这一步过滤掉 [ -e $file ] || continue new_name${file%.txt}.bak echo mv $file - $new_name if [ $DRY_RUN false ]; then mv $file $new_name fi done逻辑说明DRY_RUN变量控制执行模式默认只打印不执行参数传false才真正重命名。核心保护有两处第一行[ -e $file ] || continue解决了 Shell 通配符没匹配到文件时会把*.txt当字面量传进来的问题${file%.txt}是参数扩展从末尾删掉.txt后缀再拼接.bak比用sed处理更安全因为sed对文件名里的特殊字符有额外的转义负担。参数说明脚本里用到的${file%.txt}是 Shell 内置的参数扩展语法%表示从右往左匹配最短、%%是最长这里用单%就够了。[ -e $file ]里的引号不能省否则文件名带空格时整个判断会报错。DRY_RUN${1:-true}是给第一个参数设默认值传参方式类似./rename.sh false。4.3 定时任务不执行的三个隐蔽原因脚本写好了crontab 也加上了结果到点它就是不跑。这类问题在运维故障案例里出现频率极高原因翻来覆去就那么几个脚本没有可执行权限、脚本里的命令用了相对路径、环境变量和你在终端里不一样。其中环境变量不一致是最坑的因为终端里测试一切正常。# 在脚本开头显式声明所需环境 #!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # 脚本内统一使用绝对路径操作文件 LOGFILE/var/log/myscript.log echo $(date %F %T) script started $LOGFILE逻辑说明cron 执行脚本时用的 Shell 环境极其精简PATH可能只有/usr/bin:/bin你脚本里用到的命令如果装在/usr/local/bin下就会直接报 command not found。解决办法是在脚本开头显式export PATH把常用路径都加进去。LOGFILE用绝对路径是为了防止 cron 的工作目录和预期不一致它默认是用户的家目录不是脚本所在目录。参数说明export PATH的覆盖写法是按实际环境调整的生产机器装了什么路径就写什么不要照抄。cron 里执行脚本时建议用完整路径30 2 * * * /opt/scripts/cleanup.sh /var/log/cron_cleanup.out 21把标准输出和错误输出都重定向到文件排查时可查可证。21的顺序不能写反21和2含义不同。5. 避坑手册五个让我复盘一整晚的实战教训实战里踩过的坑每一条都比书上讲的更深刻。这一章不按功能分类就写那些让我熬夜排查、最后发现原因的教训希望能帮你少走同样的弯路。5.1 df显示根分区100%但du统计不到大头文件现象告警说磁盘快满了但du -sh /算出来所有文件加一起也没到90%磁盘空间“凭空消失”。原因有进程打开了一个已被删除的大文件文件占用的空间不计入任何目录的du结果但依然占据磁盘块。这种“幽灵文件”是磁盘满却找不到元凶的经典情况。解决用lsof | grep deleted找出占用进程然后根据业务决定重启进程还是用 /proc/PID/fd/N清空。我曾经因为没查这个傻乎乎地对根目录执行了du -sh *逐层排查浪费了近两个小时。5.2 端口明明在监听但外部就是连不上现象ss -lntp显示服务在0.0.0.0:8080监听本机curl localhost:8080正常从另一台机器访问就超时。原因系统防火墙firewalld 或 ufw默认挡掉了外部访问。本机能通是因为 loopback 接口通常不受防火墙入站规则限制给你造成“服务没问题”的假象。解决先systemctl status firewalld确认防火墙状态再按需放行端口firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload。如果是 ufw则ufw allow 8080/tcp。教训是排查时一定从访问发起端逐层测不要只看服务端本地状态。5.3 脚本里用sudo执行命令结果变量全是空的现象写了一个运维脚本普通用户执行时报“sudo: command not found”或者sudo后脚本里获取的用户变量变成空值。原因sudo 执行时会重置部分环境变量。更常见的是你期待的$USER、$HOME和当前用户一致但sudo后它们会被重置为 root 的对应值。还有机器上 sudo 命令本身所在路径不在默认 PATH 里。解决脚本开头直接export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。如果需要在sudo下保持环境变量用sudo -E保留当前环境或者显式在sudo命令里传参sudo VARvalue ./script.sh。现在我的习惯是脚本内不依赖用户相关环境变量需要时用id -un现场获取。5.4 定时任务脚本里有中文注释报crontab错误现象crontab -e 编辑时报错或者任务不执行系统日志里提示 crontab 文件里有非ASCII字符。原因crontab 文件对编码有要求某些系统默认按 UTF-8 处理如果你的终端编码是 GBK写进去的中文注释在 cron 服务读取时就变成了乱码导致整行解析失败。这个坑在初期机房用 Windows 终端连 Linux 时特别常见。解决crontab 文件里不写中文注释一律用英文或拼音。脚本本身可以用中文注释但文件编码必须是 UTF-8且文件首行加#!/bin/bash。我个人的处理是脚本文件里标注编码# -*- coding: utf-8 -*-虽然 Shell 不强制但对后续维护者是个明确提示。5.5 磁盘性能“看起来”正常但应用就是慢现象iostat 看 %util 只有 60%top 看 CPU 也不饱和可应用响应时间就是下不来。原因%util 是采样周期内设备有I/O请求的时间占比它不代表设备满负荷运行。比如 SSD 处理请求极快100% util 时实际吞吐还有余量而机械盘在并发随机读时%util 不高但每次寻道时间很长队列深度avgqu-sz很高这才是延迟高的真正原因。解决看iostat -x 1 5时重点看avgqu-sz平均队列长度和await平均I/O响应时间队列持续大于2、await超20ms就要警惕性能瓶颈了。不要再单看 %util 一个指标下结论那是“黑匣子”式的判断方式。6. 面试与进阶把实战案例变成你自己的方法论Linux面试题里常考的那些“实战场景题”本质是考察你有没有形成一套稳定的排查方法论。面试官抛出一个故障场景他真正想听的不是你背出的命令而是你从哪个环节开始介入、每一步依据什么判断、最终如何收敛到根因。这和我前几章讲的排查思路是一致的先看系统级状态再锁进程级对象最后验证和解决。我建议你把做过的案例整理成自己的“案例-方法”映射表。每个案例记三行第一行是现象磁盘满了、服务挂了、端口不通第二行是你用的第一条命令和判断逻辑第三行是根因和最终解法。不需要记完整命令输出记命令本身和判断逻辑就够了。这套笔记就是你面试时最有说服力的素材比任何背诵都能体现你的实战深度。# 示例整理案例的一句话模板 # 现象df -h 显示满du 找不到大文件 → 命令lsof | grep deleted → 解法清空占用进程的fd还有一个值得养成的习惯每解决一个案例就顺手把它转化成一个小脚本或者一个监控 item。比如我处理过一次“磁盘满导致服务写入失败”的故障后就写了个检测脚本在磁盘使用率超过 85% 时往告警群里发消息同时列出排名前五的大文件路径这让后续类似问题在变成故障前就被拦截了。实战能力的复利效应就是这么来的——一次踩坑变成永久的防护能力。看完这些案例希望你能找到自己的切入点从最贴近你工作的那一类问题开始练手逐步建立起属于你自己的实战方法论。希望帮到你。本文还有配套的精品资源点击获取 Linux实战100例：从故障排查到脚本自动化的核心方法论
简介一套面向Linux入门学习者与日常运维开发人员的实战案例合集以一百个经典应用场景为主线覆盖网络调用命令、Apache参数配置、Linux错误代码解读以及常见运行故障的排查方法适合对照练习、查阅并解决实际问题。整套资源共两百零四个文件主要以一百九十五个网页案例与说明文档为承载主体辅以三份PDF手册、两个实验压缩包、两个备用压缩包以及文档和可执行辅助程序压缩包整体约40.19MB目录结构清晰便于按主题模块检索。已有两千一百八十人学习下载。最大价值在于每个实例均呈现详细的功能调用过程与排错思路从命令行使用到服务配置层层展开既能帮助初学者理解系统运行机制也能在遇到类似报错时快速定位并对照解决。另含系统化索引、经典参考文档与辅助工具适合作为案头速查、完整练习样本及深入研读的备查材料。1. linux实战100例到底在解决什么问题如果你在搜索引擎里敲下“linux实战100例”大概率不是想再看一遍ls、cd、cp的用法解释而是已经在工位上被某个故障卡住、被某条命令的异常行为搞到怀疑人生了。这个标题代表的不是一百个孤立命令的罗列而是一百次真实场景里的问题拆解——从系统启动异常到磁盘占满从脚本定时任务不执行到进程间通信失败每一例背后都是一条完整的“现象 → 排查 → 解决”链路。它面向的是那些正在做Linux运维、嵌入式开发、系统管理工作或者准备Linux面试的人核心价值是让你在遇到同类问题时不用从零开始试错。真正的实战能力不是背出来的是踩坑踩出来的。一百个案例拆开看覆盖的是高频命令的非常规用法、故障排查的标准姿势、以及脚本编写里的边界条件和隐蔽坑点这些东西在手册和命令大全里都找不到答案。接下来的篇幅我会按实际工作中最常见的几条主线把这些案例拆开讲哪些命令最值得深挖、故障怎么定位、脚本怎么写才不容易翻车、以及面试官真正想考察的是什么。2. 命令实战里的优先级先救活系统再优化性能很多人学Linux命令是从“常用命令大全”开始的把top、df、ps背得滚瓜烂熟但真上了生产环境出了问题依然不知道从哪下手。原因很简单你背的是命令本身而不是命令适用的场景。一百个实战案例里最值钱的是按“先活着、再查因、后优化”的顺序把命令串起来用的能力。2.1 系统负载异常时先看的不该是top服务器响应变慢大多数人的第一反应是敲top看CPU占用率。这是一个典型的思维误区。CPU跑满只是表象真正的原因可能是磁盘I/O瓶颈、内存不足触发swap抖动、或者是某个进程在疯狂读写文件。正确的第一步是用uptime看负载均值再配合vmstat 1 5观察r运行队列和waI/O等待两个指标的变化趋势。# 每1秒采集一次共采集5次观察r和wa列 vmstat 1 5 # 如果wa持续偏高说明磁盘I/O是瓶颈 iostat -x 1 5逻辑说明vmstat的r列代表等待CPU的进程数wa列代表CPU花在等待磁盘I/O上的时间百分比。当r远大于CPU核心数时说明计算资源不够当wa居高不下时CPU其实在空转等磁盘这时候你换再好的CPU也没用得先处理存储。iostat -x里的%util接近100%基本可以确认磁盘阵列或单盘已经达到上限。参数说明vmstat后面第一个数字是采样间隔秒第二个是采样次数。实际排查中建议用1 5起步不要用默认的一次性输出因为负载是动态的单次快照看不出趋势。iostat需要 sysstat 包装好后-x参数会输出扩展信息1 5同样是秒数和次数。2.2 磁盘满了但df显示还有空间问题出在哪这是实战里非常经典的一类“翻车”案例应用报错说磁盘已满但你执行df -h一看根分区明明还有十几个G。真正的元凶通常是文件被进程打开后删除了但进程没退出占用的空间没有被释放。这时候df是查不出问题的要用lsof看已删除但仍被占用的文件。# 找出所有已删除但仍在被进程占用的文件 lsof | grep deleted # 定位到具体进程后确认进程PID和文件路径 lsof -p PID | grep deleted逻辑说明Linux下删除文件的本质是解除目录项的链接但如果文件已经被某个进程打开内核里的文件索引节点仍然存在磁盘空间要等进程关闭这个文件描述符才会真正释放。lsof输出里的deleted标记就是这类文件的特征。常见的处理方式有两种重启相关进程或者用 /proc/PID/fd/文件描述符号清空文件内容前者适合维护窗口内操作后者适合不能中断的服务。参数说明lsof不带参数会输出所有打开的文件量非常大生产环境建议直接管道过滤。grep deleted是关键词匹配有些老版本可能显示为(deleted)搜索时要注意。另外用/proc/PID/fd方式清空时必须先确认文件描述符号指向的是目标文件别清错了对象。2.3 查看端口占用时netstat和ss怎么选新装的系统上你可能发现netstat找不到了这不是系统变弱了而是ss已经把它替换掉了。ss直接读取内核的 socket 信息速度比netstat快一个数量级在处理大量TCP连接时尤其明显。一百个案例里如果只记一个查端口的命令我推荐ss。# 查看所有监听中的TCP端口及其对应进程 ss -lntp # 查看某个端口的连接情况比如8080 ss -tunap | grep 8080逻辑说明-l只看监听状态-n不做域名反解否则会卡在DNS查询上-t指定TCP协议-p显示进程信息。第二行的-u加上UDP-a表示所有状态。实际排查时如果某个端口连不上先看LISTEN状态是否存在再看有没有SYN_SENT堆积后者通常指向防火墙或对端服务异常。参数说明-p参数需要 root 权限普通用户执行会看不到进程名。另外ss的-a是显示所有 socket不是 older 版本netstat -a那样会同时输出路由表。这个细节踩过的人不少输出内容差很多。3. 故障排查实战像审案一样看日志和状态运维故障案例看得多会发现一个规律大部分“离奇”问题最后都能在日志里找到答案只是你没找对地方或者没找对时间点。故障排查是一场有方法的侦探工作顺序比命令更重要——先说现象再锁范围最后看日志验证而不是东敲一条命令西翻一个文件。3.1 系统启动异常时的排查路径从内核到服务服务器重启后起不来或者起来后某个服务状态异常这是生产环境里压力最大的场景之一。排查路径有一个固定顺序先确认引导阶段有没有报错再看系统日志里内核和服务的记录最后看目标服务自己的日志。很多人一上来就去翻/var/log/messages方向错了。# 查看最近一次启动的内核日志重点看硬件初始化和文件系统挂载 journalctl -b -p err # 检查关键服务的当前状态和最近几次重启记录 systemctl status sshd systemctl list-units --failed逻辑说明journalctl -b表示本次启动的日志-p err过滤出错误级别及以上的记录。如果内核层面有硬件无法识别、文件系统挂载失败这里会直接暴露。systemctl status sshd不仅显示当前状态还会列出进程的最近日志和主进程PID。list-units --failed能快速找出所有启动失败的服务比一个一个status查效率高得多。参数说明-b可以加数字比如-b -1看上一次启动的日志这个在对比“上次能起来这次起不来”时特别有用。有些系统用的是 rsyslog 而不是 journald那就要改看/var/log/messages和/var/log/syslog判断方法是执行systemctl status rsyslog确认是否在跑。3.2 服务莫名其妙被杀死先查OOM还是先看dmesg应用进程运行几天后突然消失systemctl status显示inactive (dead)重启后又恢复正常。这种情况大概率不是服务自身崩溃而是被系统的内存回收机制杀掉了专业叫法是 OOM Killer。但很多人习惯直接去调服务的超时时间这是舍本逐末。# 查看内核环形缓冲区找OOM Killer的杀进程记录 dmesg -T | grep -i killed process # 确认系统内存压力和swap使用情况 free -h cat /proc/meminfo | grep -i commit逻辑说明OOM Killer 是 Linux 内核在物理内存耗尽且 swap 不足时被迫选择牺牲进程来释放内存的机制。杀掉哪个进程由oom_score决定这个分数和进程占用内存量、运行时间、优先级都有关系。如果被杀的恰好是你的关键服务根源往往是另一个进程把内存吃光了单纯调大服务自身的内存限制治标不治本。参数说明dmesg -T里的-T是把时间戳显示成人类可读格式不加热参数显示的是开机秒数排查时对不上出事时间点很容易误判。free -h里重点看available而不是free因为 Linux 会主动把空闲内存用于缓存free很小不代表内存不足available才是真正可分配的量。3.3 网络排查的黄金命令组合ping不一定是第一步两台机器之间通信失败菜鸟先 ping老手先确认自己的网卡、IP和路由对不对。因为 ping 不通的原因太多了对端禁ping、中间防火墙策略、自身路由配置错误、DNS解析异常。把排查顺序定成“自底向上”每层验证一步才能快速缩小范围。# 第一步确认自己的网络配置 ip addr show ip route show # 第二步验证到网关的连通性 ping -c 3 网关IP # 第三步确认目标端口是否可达比ping更可靠 nc -zv 目标IP 端口逻辑说明ip addr show确认网卡有IP且状态是 UPip route show确认默认路由存在。这两步做完了本地网络基础就是健康的。接着 ping 网关能通则说明二层三层没问题。最后用nc -zv指定端口测试是因为很多故障是“能ping通但端口不通”防火墙、服务未启动都会导致这种情况。参数说明ping -c 3里的-c表示发送几个包就退出不加的话会一直ping下去脚本里跑批处理时很容易把人卡住。nc的-z是扫描模式只检测端口是否开放不发送数据-v输出详细信息有些精简系统没装 netcat可以用timeout 3 bash -c /dev/tcp/目标IP/端口替代效果一样。4. 脚本实战把重复运维变成一句话的稳妥写法一百个案例里如果有一半涉及 Shell 脚本剩下的那一半也值得你用脚本去解决重复操作。但写脚本的门槛不在语法在于你得先想清楚边界条件文件不存在怎么办、命令执行失败怎么办、传进来的参数是空值怎么办。这些没处理好的脚本就是生产环境里一颗颗定时炸弹。4.1 日志清理脚本先写保护再写删除清理日志是最常见的脚本需求也是最容易写错的脚本。很多人上来就写find /var/log -type f -mtime 7 -exec rm -f {} \;跑完才发现把正在被进程写入的日志删了或者误删了别的目录下的同名文件。正确的写法是先做保护再做清理最后留审计记录。#!/bin/bash # 日志清理脚本保留7天超过7天的压缩或删除 LOG_DIRS/var/log/nginx /var/log/app RETENTION_DAYS7 for dir in $LOG_DIRS; do if [ ! -d $dir ]; then echo $(date %F %T) WARN: $dir 不存在跳过 /var/log/cleanup.log continue fi # 只处理 .log 结尾的文件避免误删其他类型 find $dir -type f -name *.log -mtime $RETENTION_DAYS -exec rm -f {} \; echo $(date %F %T) INFO: cleaned $dir /var/log/cleanup.log done逻辑说明脚本先检查目录是否存在不存在就写告警日志并跳过避免因为路径配置错误造成后续命令全部扑空。find命令里加了-name *.log是第二层保护防止目录下出现非日志文件被误删。-mtime $RETENTION_DAYS表示修改时间超过7天的文件注意是号没有的话含义完全不同。每步操作都往审计日志里记录出了故障能追溯执行过程。参数说明$LOG_DIRS用空格分隔多目录如果要支持带空格的路径需要改成数组写法。-mtime 7和-mtime 7的区别是前者匹配超过7天的后者匹配恰好7天的少一个符号结果天差地别。-exec rm -f {} \;里的分号必须转义这是 find 语法里的固定要求。4.2 批量重命名文件让脚本自己先演练一遍用 Shell 重命名文件这个需求从热词搜索量就能看出它有多高频。mv命令本身很简单但批量重命名时一旦出同名覆盖、特殊字符截断这类问题后悔药都找不到。我一般会先让脚本输出将要执行的命令清单人工确认无误后再真正执行这个习惯帮我避免过好几次血泪教训。#!/bin/bash # 批量重命名把当前目录下的 *.txt 改为 *.bak DRY_RUN${1:-true} # 第一个参数默认只演练不实际执行 for file in *.txt; do # 文件不存在时通配符会原样输出这一步过滤掉 [ -e $file ] || continue new_name${file%.txt}.bak echo mv $file - $new_name if [ $DRY_RUN false ]; then mv $file $new_name fi done逻辑说明DRY_RUN变量控制执行模式默认只打印不执行参数传false才真正重命名。核心保护有两处第一行[ -e $file ] || continue解决了 Shell 通配符没匹配到文件时会把*.txt当字面量传进来的问题${file%.txt}是参数扩展从末尾删掉.txt后缀再拼接.bak比用sed处理更安全因为sed对文件名里的特殊字符有额外的转义负担。参数说明脚本里用到的${file%.txt}是 Shell 内置的参数扩展语法%表示从右往左匹配最短、%%是最长这里用单%就够了。[ -e $file ]里的引号不能省否则文件名带空格时整个判断会报错。DRY_RUN${1:-true}是给第一个参数设默认值传参方式类似./rename.sh false。4.3 定时任务不执行的三个隐蔽原因脚本写好了crontab 也加上了结果到点它就是不跑。这类问题在运维故障案例里出现频率极高原因翻来覆去就那么几个脚本没有可执行权限、脚本里的命令用了相对路径、环境变量和你在终端里不一样。其中环境变量不一致是最坑的因为终端里测试一切正常。# 在脚本开头显式声明所需环境 #!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # 脚本内统一使用绝对路径操作文件 LOGFILE/var/log/myscript.log echo $(date %F %T) script started $LOGFILE逻辑说明cron 执行脚本时用的 Shell 环境极其精简PATH可能只有/usr/bin:/bin你脚本里用到的命令如果装在/usr/local/bin下就会直接报 command not found。解决办法是在脚本开头显式export PATH把常用路径都加进去。LOGFILE用绝对路径是为了防止 cron 的工作目录和预期不一致它默认是用户的家目录不是脚本所在目录。参数说明export PATH的覆盖写法是按实际环境调整的生产机器装了什么路径就写什么不要照抄。cron 里执行脚本时建议用完整路径30 2 * * * /opt/scripts/cleanup.sh /var/log/cron_cleanup.out 21把标准输出和错误输出都重定向到文件排查时可查可证。21的顺序不能写反21和2含义不同。5. 避坑手册五个让我复盘一整晚的实战教训实战里踩过的坑每一条都比书上讲的更深刻。这一章不按功能分类就写那些让我熬夜排查、最后发现原因的教训希望能帮你少走同样的弯路。5.1 df显示根分区100%但du统计不到大头文件现象告警说磁盘快满了但du -sh /算出来所有文件加一起也没到90%磁盘空间“凭空消失”。原因有进程打开了一个已被删除的大文件文件占用的空间不计入任何目录的du结果但依然占据磁盘块。这种“幽灵文件”是磁盘满却找不到元凶的经典情况。解决用lsof | grep deleted找出占用进程然后根据业务决定重启进程还是用 /proc/PID/fd/N清空。我曾经因为没查这个傻乎乎地对根目录执行了du -sh *逐层排查浪费了近两个小时。5.2 端口明明在监听但外部就是连不上现象ss -lntp显示服务在0.0.0.0:8080监听本机curl localhost:8080正常从另一台机器访问就超时。原因系统防火墙firewalld 或 ufw默认挡掉了外部访问。本机能通是因为 loopback 接口通常不受防火墙入站规则限制给你造成“服务没问题”的假象。解决先systemctl status firewalld确认防火墙状态再按需放行端口firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload。如果是 ufw则ufw allow 8080/tcp。教训是排查时一定从访问发起端逐层测不要只看服务端本地状态。5.3 脚本里用sudo执行命令结果变量全是空的现象写了一个运维脚本普通用户执行时报“sudo: command not found”或者sudo后脚本里获取的用户变量变成空值。原因sudo 执行时会重置部分环境变量。更常见的是你期待的$USER、$HOME和当前用户一致但sudo后它们会被重置为 root 的对应值。还有机器上 sudo 命令本身所在路径不在默认 PATH 里。解决脚本开头直接export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。如果需要在sudo下保持环境变量用sudo -E保留当前环境或者显式在sudo命令里传参sudo VARvalue ./script.sh。现在我的习惯是脚本内不依赖用户相关环境变量需要时用id -un现场获取。5.4 定时任务脚本里有中文注释报crontab错误现象crontab -e 编辑时报错或者任务不执行系统日志里提示 crontab 文件里有非ASCII字符。原因crontab 文件对编码有要求某些系统默认按 UTF-8 处理如果你的终端编码是 GBK写进去的中文注释在 cron 服务读取时就变成了乱码导致整行解析失败。这个坑在初期机房用 Windows 终端连 Linux 时特别常见。解决crontab 文件里不写中文注释一律用英文或拼音。脚本本身可以用中文注释但文件编码必须是 UTF-8且文件首行加#!/bin/bash。我个人的处理是脚本文件里标注编码# -*- coding: utf-8 -*-虽然 Shell 不强制但对后续维护者是个明确提示。5.5 磁盘性能“看起来”正常但应用就是慢现象iostat 看 %util 只有 60%top 看 CPU 也不饱和可应用响应时间就是下不来。原因%util 是采样周期内设备有I/O请求的时间占比它不代表设备满负荷运行。比如 SSD 处理请求极快100% util 时实际吞吐还有余量而机械盘在并发随机读时%util 不高但每次寻道时间很长队列深度avgqu-sz很高这才是延迟高的真正原因。解决看iostat -x 1 5时重点看avgqu-sz平均队列长度和await平均I/O响应时间队列持续大于2、await超20ms就要警惕性能瓶颈了。不要再单看 %util 一个指标下结论那是“黑匣子”式的判断方式。6. 面试与进阶把实战案例变成你自己的方法论Linux面试题里常考的那些“实战场景题”本质是考察你有没有形成一套稳定的排查方法论。面试官抛出一个故障场景他真正想听的不是你背出的命令而是你从哪个环节开始介入、每一步依据什么判断、最终如何收敛到根因。这和我前几章讲的排查思路是一致的先看系统级状态再锁进程级对象最后验证和解决。我建议你把做过的案例整理成自己的“案例-方法”映射表。每个案例记三行第一行是现象磁盘满了、服务挂了、端口不通第二行是你用的第一条命令和判断逻辑第三行是根因和最终解法。不需要记完整命令输出记命令本身和判断逻辑就够了。这套笔记就是你面试时最有说服力的素材比任何背诵都能体现你的实战深度。# 示例整理案例的一句话模板 # 现象df -h 显示满du 找不到大文件 → 命令lsof | grep deleted → 解法清空占用进程的fd还有一个值得养成的习惯每解决一个案例就顺手把它转化成一个小脚本或者一个监控 item。比如我处理过一次“磁盘满导致服务写入失败”的故障后就写了个检测脚本在磁盘使用率超过 85% 时往告警群里发消息同时列出排名前五的大文件路径这让后续类似问题在变成故障前就被拦截了。实战能力的复利效应就是这么来的——一次踩坑变成永久的防护能力。看完这些案例希望你能找到自己的切入点从最贴近你工作的那一类问题开始练手逐步建立起属于你自己的实战方法论。希望帮到你。本文还有配套的精品资源点击获取