磨刀不误砍柴工懂点Linux命令你的工作效率会直接翻倍做技术这一行尤其是跟服务器、运维、后端打交道久了你会发现一个很扎心的现实很多人不是不会写代码而是被命令行卡住了脖子。明明一个grep加awk就能从几G的日志里揪出报错信息有人却要下载到本地用编辑器翻半天明明一条rsync就能增量同步几十G的数据有人还在用FileZilla拖拽到超时。Linux命令这东西平时觉得不就是些字母组合嘛真到关键时刻它就是你和服务器之间唯一的沟通语言。我这篇不讲那种命令大全式的罗列那种东西man手册里全都有。我想聊的是真正干活时那些高频命令的用法逻辑、组合思路以及我在实际排障中踩过的坑和沉淀下来的套路。不管你是刚接触Linux的运维新人还是写了几年业务代码想补补基本功的后端看完这篇你至少能把以前那些复制粘贴然后祈祷有效的操作变成我知道它在干嘛以及为什么这么干。1. 先聊聊我的看法命令背不完但思路可以学我刚开始接触Linux那会儿也干过拿个小本本抄命令的傻事什么tar -zcvf、chmod 777抄了满满一本。后来发现屁用没有因为命令是死的场景是活的。你背会了find / -name *.log但遇到找出最近三天修改过且大于100M的日志文件这种需求照样懵。为什么因为缺的不是命令是组合命令的思路。Linux的设计哲学特别有意思——它把每一个小工具都做到极致简单然后通过管道|、重定向、通配符*这些东西把工具串起来像乐高积木一样搭出无穷无尽的功能。你写代码讲究函数拆分、模块复用用命令其实也是一样的道理单个命令是原子操作管道和参数才是真正的业务逻辑。另外一个很重要的思路是优先掌握排查链路而不是单个命令。就好比你觉得服务器CPU飙高光是敲个top看到某个进程占300%没有用你得顺着这条线索往下摸——是哪个线程在执行什么调用是不是GC线程疯狂回收这需要top、pidstat、jstackJava场景甚至perf一路查下去。所以我下面每一部分都会尽量以真实场景为入口把一组命令串成一条完整的链路来讲。2. 文件与目录日常高频操作背后的完整逻辑2.1 批量重命名几百个文件用循环加变量别手动改有一次我需要在测试环境把一批带日期后缀的配置文件统一加上环境标识比如把app_20240101.conf改成app_20240101_dev.conf有三百多个文件。手动改手能废掉。用文件管理器处理不了那么多。这时候命令行的优势就出来了。我的做法是先进到目录看一眼规律ls -l *.conf | head -20确认所有文件名符合app_日期.conf这个格式后直接一个for循环搞定for f in app_*.conf; do mv $f ${f%.conf}_dev.conf; done这里面的关键点有两个一个是for f in app_*.confShell会先把通配符展开成所有匹配的文件名然后逐个赋值给变量f另一个是${f%.conf}这是Shell参数扩展的经典用法表示从变量f的结尾去掉.conf这个后缀。两下一组合就实现了改名并追加后缀。这种操作你要是靠人肉做一次两次还行多了准出错而且完全没办法回溯。写到这我得多说一句能用循环批量干的事千万别手搓。不只是重命名批量创建目录、批量压缩日志、批量修改权限都是一个循环一个核心命令的事。学Linux命令第一个要养的思维就是怎么让机器替我做重复劳动。2.2 删库之前问自己三次rm的安全细节rm -rf这命令江湖人称跑路命令。我见过不止一个同事在/目录下或者HOME目录下脑子一抽就敲了rm -rf *然后就是漫长的沉默。我自己的纪律是生产环境禁用裸rm -rf再怎么着急也得先把目录cd进去ls看一眼再删。这不是胆小这是对自己负责。但这不代表不能用rm而是要讲究方式方法。比如我只想删掉目录下所有.tmp文件但保留其他东西rm -i *.tmp-i参数会在删除每个文件前问一次嫌烦的话用find配合-delete更安全find ./ -name *.tmp -type f -delete用find的好处是你能先不加-delete跑一遍看看它到底会匹配到哪些文件确认无误了再把-delete加上。这个先预览后执行的思路在处理批量删除、批量修改时简直是保命符。另外真心建议个人电脑或测试机上装个trash-cli它会把删除的文件挪到回收站而不是直接抹掉。命令敲成trash file.txt哪怕手滑了还能救回来。生产环境当然不推荐但在你本地环境这层保护很有价值。在删除这件事上多一道确认、多一层回收都是值得的。2.3 找文件不只是find几个参数让你少敲一半命令find是Linux下最被低估的命令之一。很多人只会用find / -name xxx然后抱怨慢。慢就对了你从根目录全盘扫描不慢才怪。正确的打开方式是先缩小范围。举个例子我想找/home下所有属于www用户、大小超过500M的日志文件find /home -user www -type f -size 500M -name *.log这里-user www按属主过滤-size 500M过滤大小-name *.log过滤文件名。三个条件一叠加结果就非常精准了。更实用的是按时间找比如最近7天被修改过的PHP文件find /var/www -type f -name *.php -mtime -7如果想找的是7天前都没再动过的临时文件把-mtime -7换成-mtime 3030天前修改就行。再配合ls -lh或者-exec ls -lh {} \;看一眼大小和日期基本就能定位到哪些是历史遗留垃圾。我有个习惯每当服务器磁盘告警第一反应不是去du -sh *一个个看而是用find按-size 1G筛一遍。大多数情况下罪魁祸首都是几个超大的日志文件或者备份包直接逼到案发现场效率高得不是一点半点。2.4 文件对比与同步diff和rsync一对黄金搭档排查问题的时候我们经常要对比线上配置和测试配置到底差在哪。diff这时候比人眼靠谱得多diff -u nginx.conf.bak nginx.conf-u输出统一格式能直接看出哪些行被修改、新增、删除。如果你用的是IDE或者代码编辑器这格式还能直接被理解成变更视图。有时候懒得登录服务器我会先在本地把文件拉下来再diff一个道理。而说到同步rsync是当之无愧的神器。我同步代码到测试服务器常用rsync -avz --delete ./dist/ userserver:/var/www/html/解释一下-a归档模式保留权限、时间戳这些属性-v显示详情-z传输时压缩--delete让目标目录里多余的文件也删掉保证两边完全一致。最爽的是它支持断点续传和增量同步传一个大目录中断了重新跑一遍会跳过已传完的部分比干脆利落地覆盖整个目录不知道高到哪里去了。不过用--delete要格外小心它会把目标目录清成和源一模一样。我建议第一次同步的时候先加个--dry-run也就是-n参数跑一遍看看它到底打算删哪些文件、传哪些文件心里有数了再动真格。3. 文本处理三件套grep、awk、sed的实战场景3.1 grep从搜索关键词到日志里的福尔摩斯grep是每个用Linux的人最先接触的命令之一但多数人停留在grep error log.txt这个水平。我觉得真正拉开效率差距的是这几个进阶用法。第一个是上下文匹配。日志报错从来不是孤立的一行错误日志的堆栈往往在报错行前后几十行。直接grep -C 5 Exception app.log能把匹配行的前后5行都打出来完整还原现场。-A是向后取-B是向前取结合着用。第二个是多条件组合。查订单系统在支付回调里报超时的日志直接用扩展正则grep -E 支付|timeout|order_ app.log | grep 回调用管道把第一次筛选的结果再筛一遍比写一条复杂正则容易理解得多。这里-E表示用扩展正则|在正则里表示或。第三个是只输出匹配部分。有时候日志里每行都带时间戳、线程号、日志级别而我只关心里面的IP地址那就用-o参数grep -oE [0-9]\.[0-9]\.[0-9]\.[0-9] app.log | sort | uniq -c | sort -nr这一条组合命令的含义是先把每行里长得像IP的部分单独抽出来然后排序统计每个IP出现次数再按次数从高到低排。它解决的是一个特别典型的问题——到底是哪个IP在疯狂请求我们的接口一眼就能看出来。这串管道我愿称之为日志排查最常用组合拳没有之一。3.2 awk日志统计利器如果说grep是筛子那awk就是瑞士军刀。它能按列拆分、能累加统计、能做条件判断是写命令行的内联脚本语言。最常见的场景是分析Nginx访问日志。日志格式类似127.0.0.1 - - [01/Jan/2024:12:30:45 0800] GET /api/user HTTP/1.1 200 532其中第1列是客户端IP第9列是状态码第10列是响应字节数。想统计每个IP产生了多少请求平均返回多少字节awk { ip[$1]; bytes[$1]$10 } END { for (i in ip) print i, ip[i], bytes[i]/ip[i] } access.log这个脚本的逻辑很好理解每读一行以第一个字段IP为下标请求数加一同时把第10字段字节数累加进去。全部处理完后遍历打印每个IP的请求数和平均字节数。这种一行命令顶得上你写几十行Python脚本的效率。如果想筛出状态码是500的请求数占总请求数的比例awk $9500 {count500} {total} END {print count500/total*100%} access.log实际用下来awk的威力在于它把字段遍历和统计聚合揉到了一条命令里。你不需要写循环、定义变量、处理文件格式只要声明每行的第几列怎么处理剩下的它全包了。这就是命令行的魅力——简短的表达强大的能力。3.3 sed批量文本替换的好帮手sed对我来说主要干两件事一个是批量替换一个是精准打印某段内容。批量替换的经典场景是配置文件里把旧的数据库地址换成新的。sed -i s/192.168.1.100/192.168.1.200/g config.properties-i表示原地修改直接改文件备份加-i.bak更保险s是替换命令的结构g代表全局替换不写的话每行只替换第一处匹配。这个命令在改配置文件、批量替换代码里的某个变量名时能省下一大截时间。精准打印某段内容也很好用。比如一个几百兆的日志文件你想看第1000到1010行发生了什么sed -n 1000,1010p app.log-n是不自动打印p是打印匹配范围两个参数配合就是我只想看我指定的那几行。这比head -1010 | tail -11来得直观。但这里要特别提醒sed -i是危险操作因为它直接改源文件且不可逆。我的习惯是先用不带-i的替换跑一遍把输出目测一遍确认没问题再带上-i执行。如果是重要配置文件先cp一份备份再动手养成肌肉记忆。3.4 管道组合的思路先筛、再切、最后统计上文已经涉及好几次管道了但值得单独说一下设计思路。我总结的套路是先定位范围再提取字段后聚合统计最后排序展示。第一步用grep或sed缩小到感兴趣的行第二步用awk或cut把这些行里的关键字段切出来第三步用sort、uniq -c、awk做统计第四步用sort -n排出顺序。这个思路适配绝大多数文本分析需求。举个完整例子统计某个时间段内每个接口被调的次数并按次数排序grep 2024:10: access.log | awk {print $7} | sort | uniq -c | sort -nr | head -20第一段筛出上午10点的日志第二段取出URL路径字段第三段排序第四段统计去重uniq -c第五段按次数降序最后只取前20个。这一串下来就是一张现成的接口热门榜整个过程不用写脚本不用下载文件一条命令的事。平时多积累这种套路遇到具体问题时就能下意识地组合起来不用翻书。4. 性能排查Linux资源监控命令组合4.1 一上来CPU飙高我到底该看什么服务器报警CPU使用率100%我建议不要一上来就盯着top看因为top显示的是进程维度的快照信息不够纵深。更有效的路径是先用top找出嫌疑进程再用pidstat看线程最后定位到具体代码逻辑。top敲进去按P键可以按CPU使用率排序一眼扫到最上面的进程PID。这一步其实已经解决了一半问题——你知道了是哪个进程在吃CPU。然后需要看这个进程里的线程情况pidstat -t -p 12345 1 5-t显示线程维度的统计-p 12345指定进程1 5表示每1秒采样一次、共采5次。它能告诉你这个进程内部具体是哪个线程在拼命烧CPU。如果你是Java应用还可以用jstack把线程快照打出来和pidstat看到的线程号换算成十六进制去对。但如果你不是Java没关系至少排查链路是通用的进程 → 线程 → 代码层层下钻每一步都在缩小嫌疑范围。整个流程走下来一般几分钟就能从CPU飙高定位到具体某个方法或某段逻辑。vmstat也是个容易被低估的命令。它直接查看系统层面的CPU、内存、IO概况。有个参数组合特别适合复盘瓶颈vmstat 1 10每秒输出一行持续10行。重点看r列运行队列长度、us列用户态CPU、wa列I/O等待。如果r长期大于CPU核数说明任务排队严重如果wa很高说明瓶颈可能在磁盘而不是CPU。4.2 free到底该怎么看重点不是可用内存free -h命令人人会敲但很多人只会看倒数第二行available。我的经验是别被Used很高吓到也别盲目追求Available很高。Linux的内存策略是能缓存就缓存你看到的used里很大一部分其实是page cache也就是文件缓存这些内存在程序需要时是可以立刻释放的。判断内存是否真吃紧我一般看两个东西available是不是快没了这才是真正能分配给新进程的内存以及有没有明显的swap使用。swap一旦用起来说明物理内存真的不够了free -h如果发现swap用了不少还得配合看看到底是哪个进程在占用ps aux --sort-%mem | head -10按内存占用排序前10个进程名单一列谁是大头一目了然。这套组合下来内存够不够、谁吃的、要不要优化三连问就有着落了。4.3 磁盘IO才是很多性能问题的隐形凶手很多服务变慢CPU和内存看着都正常实际上瓶颈在磁盘。最简单的验证方式是用iostat看一下%utiliostat -x 1 3%util接近100%说明磁盘设备已经处于饱和状态。这段时间经常能看到iowait飙高但光看wait不够iostat -x能看到每个设备层面的读写速率和队列长度。如果确认是某个设备忙可以进一步找是哪个进程读写的iotop工具能实时显示每个进程的磁盘读写带宽iotop -o -P-o只显示正在读写I/O的进程-P只显示进程不显示线程输出清爽得多。实际排障中我遇到过几次慢查询导致大量磁盘读、从而拖垮整个数据库服务的情况都是通过这条链路定位到具体进程再去优化SQL的。4.4 网络连接排查ss和netstat怎么选排查网络连接老一点的教程会让你用netstat但新一点的系统我更推荐ss它更快、信息更全。查当前所有监听端口ss -lntp-l只看监听状态-n不反解域名直接显示IP速度快很多-t只看TCP-p显示对应进程。比如你想知道80端口上到底是哪个服务在跑它直接给你进程名和PID。如果服务器连接数异常高比如出现大量TIME_WAIT会影响新连接的建立。排查方式ss -s这条输出的是汇总统计TCP各状态的数量一目了然。如果TIME_WAIT上万说明服务端主动关闭连接太多可能需要调整内核参数或优化业务代码。这里就不展开内核调优了但排查思路是一样的从汇总里发现异常再下钻到具体连接。4.5 一次CPU飙高的完整排查实录讲个实际案例。有次某项目上线后监控不停报CPU 100%但奇怪的是业务量并没有增长。我按顺序走了这么几步第一步top按P排序看到一个Java进程占了350%。第二步pidstat -t -p看到某个线程一直在跑。第三步把线程号转十六进制jstack抓线程栈发现是在执行一个正则匹配的方法。第四步查代码发现那个正则在处理一段特殊字符串时触发了灾难性回溯。问题定位到代码层级后面的事就简单了——优化算法、上线、观察CPU降下来了。整个排查过程如果只会在某个环节敲一个命令走不到最后。但当命令串成链路每个环节都在缩小范围排查高手的价值正在于此。所以说学命令不能只学单点要学整条链路。5. 进程、会话与服务管理从裸奔到规范化5.1 查进程、杀进程ps的精髓在找ps命令参数特别多说实话我不建议全背但有两套组合必须刻进DNA里。第一个是看全量进程并排序ps -ef简明直观带父进程PID能看出进程之间的父子关系。第二个是按关键字快速找ps -ef | grep java但注意这条命令会把grep自己那一行也匹配进去看着有点碍眼。更优雅的写法是pgrep -af java直接返回进程号和完整命令行不会混入多余输出。找僵尸进程也是一项经典操作。僵尸进程就是子进程结束了但父进程没回收它这种进程杀不掉它已经死了只能处理它的父进程。排查方式ps -ef | grep defunct如果僵尸进程较多说明某个父进程没有正确处理子进程退出状态得从代码层面解决光杀是没用的。这个知识点在面试时也算个加分点实操中排查孤儿进程链也挺有用。5.2 kill不是杀掉这么简单kill命令的本质是向进程发送一个信号而不同的信号决定了进程会怎么回应。常用的三个信号得搞清楚kill -9 PID # 强制杀死不可被捕获慎用 kill -15 PID # 默认信号请求进程退出可被捕获做清理工作 kill -1 PID # 让进程重新加载配置比如nginx、sshd我见过不少新手一遇到杀不掉的进程就kill -9简单粗暴。但实际上-9相当于直接切断电源进程没机会清理临时文件、释放锁、记录状态如果是有状态服务很容易留下脏数据下次启动直接就起不来了。正确的顺序是先用-15给进程一点时间做善后过几秒还没退出再考虑-9。重载配置用-1是个特别实用的技巧比如改了Nginx配置又不想中断服务一条kill -1 $(cat /var/run/nginx.pid)或者nginx -s reload就能热加载不用重启服务。这在生产环境里是刚需操作。5.3 会话与后台运行nohup和screen的组合用SSH连到服务器跑一个长任务直接关终端会把任务一起带走这个坑我早期踩过无数次。最简单的规避方式是用nohupnohup sh long_task.sh output.log 21 拆开解释一下nohup让命令忽略挂断信号 output.log把标准输出写进文件21把错误输出也合并进同一个文件否则报错你看不到最后的把进程放到后台。这套写全了才是一个合格的后台任务启动命令。如果只写nohup command 而不重定向输出它会生成一个nohup.out文件混乱不说还可能占满磁盘。但nohup有一个天生的短板任务启动以后你就没法再回到那个会话里看了。想跟踪进度怎么办只能读日志文件。更优雅的方案是用终端复用工具我最常用的是screenscreen -S mytask # 在里面跑你的长任务 # 按 CtrlA 然后按 D 把会话脱离 screen -r mytask # 需要时重新接回这个会话这种开个虚拟终端、跑任务、关掉连接、回头再看的模式做编译、跑批处理、远程部署时都舒服得多。同类工具还有个tmux功能更强快捷键体系不一样顺手就行。5.4 systemctl现在的主流服务管理新一点的发行版都换成了systemd服务管理的标准姿势是systemctl status nginx # 看服务状态 systemctl start nginx # 启动 systemctl enable nginx # 设为开机自启 systemctl restart nginx # 重启 journalctl -u nginx -f # 实时看这个服务的日志我最常用的是journalctl -u nginx -f它直接把服务日志接上了都不用去翻/var/log目录。这在排查服务怎么又挂了时效率极高服务启动时的报错信息全都集中在一起。顺便提醒每次改完配置一定要restart或者reload不要以为改完文件就生效了——这也是新手常掉的坑。6. 网络排查命令组合拳6.1 从ping不通到定位具体环节网络问题排查是有套路的。我习惯按这个顺序来先判断是不是链路不通再判断是哪一层有问题。第一步ping一下目标地址ping -c 4 www.example.com能通就说明网络链路是通的至少ICMP通。如果ping不通可能是防火墙、路由或者对端禁ping等。下一步查路由是ip route查自己的IP是ip addr层层排查。以前大家习惯用ifconfig现在新系统更好用的是ip命令套件信息更全、输出更规范。这里要特别提一句ping通了不代表应用层就正常。有时候网络通但端口不通就需要用到下面要讲的命令。6.2 测端口和接口curl是排查应用层的好帮手端口连通性测试我一般用nc或telnetnc -vz 192.168.1.10 8080-v显示详细过程-z表示只探测端口不发送数据几秒钟就能判断端口是否开放。如果是HTTP接口的排查curl是首选。常用参数组合curl -i -X POST -H Content-Type: application/json -d {key:value} http://localhost:8080/api/test-i显示返回的响应头-X指定请求方法-H添加请求头-d附带请求体。排查接口报错时我一般先加-v看完整握手和请求发送过程。它能显示TLS握手细节、是否走了代理、响应头里有没有奇怪的跳转这些都是浏览器开发者工具很难给出的信息尤其是在服务器本机测试时curl几乎是不二之选。6.3 DNS排查解析慢或解析错时怎么办域名解析是网络访问的第一步出问题往往表现为网站打不开但IP能通。排查DNS我常用digdig www.example.com它会把完整的DNS解析过程列出来包括哪个DNS服务器响应、解析耗时、查询结果。dig trace能一步步跟踪从根域名服务器到最终结果的完整链路如果某一步超时了问题就出在那一环。老命令nslookup也可以用但其实dig输出更清晰、更适合排障。如果确定是DNS问题先检查系统的解析配置/etc/resolv.conf看看nameserver指向哪里再对比一下其他环境是否能正常解析。很多内网环境的怪问题最后都出在DNS配置指错地方。6.4 抓包分析tcpdump的简单用法有些网络问题靠ss、curl判断不出来就得抓包看了。比如接口响应慢你想确认是客户端等得久还是服务端回复得慢用tcpdump抓一下端口上的流量最直观tcpdump -i eth0 port 8080 -w /tmp/capture.pcap-i指定网卡port过滤端口-w把原始包保存下来然后用Wireshark打开分析。如果你不想装图形工具tcpdump直接输出也能看个大概tcpdump -i eth0 host 192.168.1.10 and tcp port 80在服务器端抓包能理清很多玄学问题SYN包有没有到三次握手有没有完成数据包是不是分片了应答是不是延迟了这些都是应用层看不到的底层信息。出现网络问题时抓包是最后的实锤手段有些结论光靠猜是猜不出来的。6.5 一次网站白屏的排查全流程我之前遇到过一个案例站点突然白屏但服务器负载看着不高。我这边排査的逻辑是这样——先看服务进程是否存活systemctl status nginx活着。然后看本机端口监听ss -lntp | grep :80正常。接着curl -I http://127.0.0.1看本机访问返回200。本机正常那问题可能出在外部链路上。再curl -I公网地址试试结果超时。最后抓包发现tcpdump里SYN包到了但回包没出去顺藤摸瓜发现防火墙策略把出方向某个段给挡了。这个案例想说明的是排障不是碰运气而是利用命令一点点缩小范围。每一层都有对应工具每一条链路都有该看的信息掌握这些命令等于给自己装了一副排查问题的望远镜和显微镜。7. 把命令串成脚本从敲命令到自动化运维7.1 用一条命令备份或迁移数据理解了单条命令下一步就该试试把它们串成脚本哪怕只是一行综合命令。最典型的就是数据库备份mysqldump -u root -p db_name | gzip /backup/db_$(date %Y%m%d_%H%M%S).sql.gzmysqldump导出的数据直接通过管道流给gzip压缩文件名里带时间戳。这样既省了磁盘空间又自动区分了备份时间点。顺手还能配合find做保留策略比如只保留最近7天find /backup -name *.sql.gz -mtime 7 -delete一条命令完成清理不用手动清理攒了好几个G的旧备份。7.2 日志切割与清理自动化日志膨胀是每台服务器都会遇到的问题。除了用logrotate系统自带的日志轮转机制我们也可以手写一个简单的清理脚本思路每天凌晨用find把超过30天、大于500M的日志删掉再把昨天日志压缩归档。find /var/log/nginx -name *.log.* -mtime 30 -delete find /var/log/nginx -name *.log -mtime 1 -exec gzip {} \;第一条删除超过30天的旧日志第二条把昨天的access.log压缩成access.log.gz。加个cron定时任务磁盘告警的烦恼能减少一大半。这些命令单独看不难但组合起来就形成了完整的运维策略。7.3 写一个服务器健康检查的Shell脚本我习惯把日常检查做成一个小的Shell脚本每天自动跑一遍输出结果。脚本核心逻辑无非是把前面讲过的命令串起来#!/bin/bash echo 系统负载 uptime echo 内存使用 free -h echo 磁盘占用 TOP5 df -h | sort -k5 -n | tail -5 echo 高CPU进程 TOP5 ps aux --sort-%cpu | head -6再简单点可以直接用alias把常用组合命令收成快捷键。比如我本机配了alias keysps -ef --sort-%cpu | head -20 alias myipip addr show | grep inet配置在~/.bashrc里source一下生效。这种把高频命令变成顺手快捷键的习惯长期积累下来效率差距非常可观。7.4 Shell脚本的几点提醒写Shell脚本踩过的坑我总结了几个第一变量赋值等号两边不能有空格name xxx会报错写成namexxx才对。第二引用变量尽量用双引号包起来比如echo $name否则路径里有空格时会出问题。第三判断命令返回值用$?或者直接if command; then echo success else echo fail fi这种写法比把$?存下来再判断直观得多。第四脚本开头一定加set -e表示只要某条命令返回非零就直接退出避免在错误状态下继续执行导致更严重的后果。8. 常见问题与排查技巧实录这部分我把实际运维中经常碰到的几个典型问题整理成一个速查表方便各位在处理类似状况时能快速定位方向。表格里给的是排查命令和解决思路但真正定位问题往往需要组合使用以下几个案例应该能让这个表格变得立体起来。现象一般先查什么常用命令常见原因与解决思路磁盘空间不足找出占空间的目录df -h、du -sh /* 2/dev/null | sort -hr | head -10日志文件过大、旧包未清理用上文find命令清理或调整日志策略CPU持续100%找出吃CPU的进程top按P排序、pidstat -t -p PID业务代码死循环、正则回溯、GC线程或虚拟机异常下钻线程抓栈分析命令找不到确认路径和安装情况which nginx、echo $PATH环境变量问题或软件未安装重新配置PATH或安装软件包端口被占用找出占用进程ss -lntp | grep :8080、lsof -i:8080旧服务未退出或同端口进程冲突确认后处理对应进程网络连接数异常高查连接状态分布ss -s、ss -ant | awk {print $1} | sort | uniq -cTIME_WAIT过多或连接泄漏调整内核参数或优化代码长连接管理文件无法删除确认权限和文件类型ls -l、lsattr权限不足或存在不可变属性修改权限或用chattr去掉属性这个表格只是入口。实际排查问题我始终强调的是链路思维从现象反推可能出问题的环节再用对应命令验证。比如磁盘满是现象可能的原因有日志膨胀、备份文件堆积、数据库临时文件等等。每条线索都会引导你用不同的命令去确认这就是命令行技能的真正价值。9. 写在最后的几点实在心得文章写到这核心内容已经讲得差不多了最后分享几个我用Linux命令多年攒下来的心得。第一得学会看帮助文档。别一遇到不认识的命令就百度先man 命令或命令 --help绝大多数用法参数都写清楚了。英文不好没关系看个大概结构就够了查多了自然熟悉。尤其是man里的EXAMPLES部分基本是官方给的实用案例比看网上二手教程靠谱得多。第二用一个命令前先想想可能产生什么后果。尤其是涉及删除、覆盖、批量修改的命令一定要想清楚影响范围再动手。生产环境上操作前备份永远是合格的选择。我给自己定的规矩是高危操作在回车前先停下来看一眼、确认一遍这个习惯帮我躲过了好几次灾难。第三多记录自己的组合命令。每当摸索出一条好用的命令组合我会把它记到笔记里注明应用场景。时间久了这就是你自己的命令手册比任何教程都实用。很多看起来复杂的运维操作不过是几条命令组合体记熟了就是肌肉记忆。第四别怕耗时去理解原理。比如为什么grep比编辑器搜索快因为它只做流式处理不需要把整个文件载入内存。为什么rsync适合传大文件因为它能断点续传而且只传差异部分。弄懂了这些底层机制你就知道什么场景该用什么工具而不是背参数。这一点比记住几百条命令重要太多。玩转Linux命令本质上是在学习一种用计算机的思维解决问题的方式。它让你学会组合、抽象、自动化、以及带着链路意识去排查。这条路没有终点但你会越来越顺越来越有手感。希望这篇实战分享能给你一些切实的参考。
磨刀不误砍柴工懂点Linux命令你的工作效率会直接翻倍做技术这一行尤其是跟服务器、运维、后端打交道久了你会发现一个很扎心的现实很多人不是不会写代码而是被命令行卡住了脖子。明明一个grep加awk就能从几G的日志里揪出报错信息有人却要下载到本地用编辑器翻半天明明一条rsync就能增量同步几十G的数据有人还在用FileZilla拖拽到超时。Linux命令这东西平时觉得不就是些字母组合嘛真到关键时刻它就是你和服务器之间唯一的沟通语言。我这篇不讲那种命令大全式的罗列那种东西man手册里全都有。我想聊的是真正干活时那些高频命令的用法逻辑、组合思路以及我在实际排障中踩过的坑和沉淀下来的套路。不管你是刚接触Linux的运维新人还是写了几年业务代码想补补基本功的后端看完这篇你至少能把以前那些复制粘贴然后祈祷有效的操作变成我知道它在干嘛以及为什么这么干。1. 先聊聊我的看法命令背不完但思路可以学我刚开始接触Linux那会儿也干过拿个小本本抄命令的傻事什么tar -zcvf、chmod 777抄了满满一本。后来发现屁用没有因为命令是死的场景是活的。你背会了find / -name *.log但遇到找出最近三天修改过且大于100M的日志文件这种需求照样懵。为什么因为缺的不是命令是组合命令的思路。Linux的设计哲学特别有意思——它把每一个小工具都做到极致简单然后通过管道|、重定向、通配符*这些东西把工具串起来像乐高积木一样搭出无穷无尽的功能。你写代码讲究函数拆分、模块复用用命令其实也是一样的道理单个命令是原子操作管道和参数才是真正的业务逻辑。另外一个很重要的思路是优先掌握排查链路而不是单个命令。就好比你觉得服务器CPU飙高光是敲个top看到某个进程占300%没有用你得顺着这条线索往下摸——是哪个线程在执行什么调用是不是GC线程疯狂回收这需要top、pidstat、jstackJava场景甚至perf一路查下去。所以我下面每一部分都会尽量以真实场景为入口把一组命令串成一条完整的链路来讲。2. 文件与目录日常高频操作背后的完整逻辑2.1 批量重命名几百个文件用循环加变量别手动改有一次我需要在测试环境把一批带日期后缀的配置文件统一加上环境标识比如把app_20240101.conf改成app_20240101_dev.conf有三百多个文件。手动改手能废掉。用文件管理器处理不了那么多。这时候命令行的优势就出来了。我的做法是先进到目录看一眼规律ls -l *.conf | head -20确认所有文件名符合app_日期.conf这个格式后直接一个for循环搞定for f in app_*.conf; do mv $f ${f%.conf}_dev.conf; done这里面的关键点有两个一个是for f in app_*.confShell会先把通配符展开成所有匹配的文件名然后逐个赋值给变量f另一个是${f%.conf}这是Shell参数扩展的经典用法表示从变量f的结尾去掉.conf这个后缀。两下一组合就实现了改名并追加后缀。这种操作你要是靠人肉做一次两次还行多了准出错而且完全没办法回溯。写到这我得多说一句能用循环批量干的事千万别手搓。不只是重命名批量创建目录、批量压缩日志、批量修改权限都是一个循环一个核心命令的事。学Linux命令第一个要养的思维就是怎么让机器替我做重复劳动。2.2 删库之前问自己三次rm的安全细节rm -rf这命令江湖人称跑路命令。我见过不止一个同事在/目录下或者HOME目录下脑子一抽就敲了rm -rf *然后就是漫长的沉默。我自己的纪律是生产环境禁用裸rm -rf再怎么着急也得先把目录cd进去ls看一眼再删。这不是胆小这是对自己负责。但这不代表不能用rm而是要讲究方式方法。比如我只想删掉目录下所有.tmp文件但保留其他东西rm -i *.tmp-i参数会在删除每个文件前问一次嫌烦的话用find配合-delete更安全find ./ -name *.tmp -type f -delete用find的好处是你能先不加-delete跑一遍看看它到底会匹配到哪些文件确认无误了再把-delete加上。这个先预览后执行的思路在处理批量删除、批量修改时简直是保命符。另外真心建议个人电脑或测试机上装个trash-cli它会把删除的文件挪到回收站而不是直接抹掉。命令敲成trash file.txt哪怕手滑了还能救回来。生产环境当然不推荐但在你本地环境这层保护很有价值。在删除这件事上多一道确认、多一层回收都是值得的。2.3 找文件不只是find几个参数让你少敲一半命令find是Linux下最被低估的命令之一。很多人只会用find / -name xxx然后抱怨慢。慢就对了你从根目录全盘扫描不慢才怪。正确的打开方式是先缩小范围。举个例子我想找/home下所有属于www用户、大小超过500M的日志文件find /home -user www -type f -size 500M -name *.log这里-user www按属主过滤-size 500M过滤大小-name *.log过滤文件名。三个条件一叠加结果就非常精准了。更实用的是按时间找比如最近7天被修改过的PHP文件find /var/www -type f -name *.php -mtime -7如果想找的是7天前都没再动过的临时文件把-mtime -7换成-mtime 3030天前修改就行。再配合ls -lh或者-exec ls -lh {} \;看一眼大小和日期基本就能定位到哪些是历史遗留垃圾。我有个习惯每当服务器磁盘告警第一反应不是去du -sh *一个个看而是用find按-size 1G筛一遍。大多数情况下罪魁祸首都是几个超大的日志文件或者备份包直接逼到案发现场效率高得不是一点半点。2.4 文件对比与同步diff和rsync一对黄金搭档排查问题的时候我们经常要对比线上配置和测试配置到底差在哪。diff这时候比人眼靠谱得多diff -u nginx.conf.bak nginx.conf-u输出统一格式能直接看出哪些行被修改、新增、删除。如果你用的是IDE或者代码编辑器这格式还能直接被理解成变更视图。有时候懒得登录服务器我会先在本地把文件拉下来再diff一个道理。而说到同步rsync是当之无愧的神器。我同步代码到测试服务器常用rsync -avz --delete ./dist/ userserver:/var/www/html/解释一下-a归档模式保留权限、时间戳这些属性-v显示详情-z传输时压缩--delete让目标目录里多余的文件也删掉保证两边完全一致。最爽的是它支持断点续传和增量同步传一个大目录中断了重新跑一遍会跳过已传完的部分比干脆利落地覆盖整个目录不知道高到哪里去了。不过用--delete要格外小心它会把目标目录清成和源一模一样。我建议第一次同步的时候先加个--dry-run也就是-n参数跑一遍看看它到底打算删哪些文件、传哪些文件心里有数了再动真格。3. 文本处理三件套grep、awk、sed的实战场景3.1 grep从搜索关键词到日志里的福尔摩斯grep是每个用Linux的人最先接触的命令之一但多数人停留在grep error log.txt这个水平。我觉得真正拉开效率差距的是这几个进阶用法。第一个是上下文匹配。日志报错从来不是孤立的一行错误日志的堆栈往往在报错行前后几十行。直接grep -C 5 Exception app.log能把匹配行的前后5行都打出来完整还原现场。-A是向后取-B是向前取结合着用。第二个是多条件组合。查订单系统在支付回调里报超时的日志直接用扩展正则grep -E 支付|timeout|order_ app.log | grep 回调用管道把第一次筛选的结果再筛一遍比写一条复杂正则容易理解得多。这里-E表示用扩展正则|在正则里表示或。第三个是只输出匹配部分。有时候日志里每行都带时间戳、线程号、日志级别而我只关心里面的IP地址那就用-o参数grep -oE [0-9]\.[0-9]\.[0-9]\.[0-9] app.log | sort | uniq -c | sort -nr这一条组合命令的含义是先把每行里长得像IP的部分单独抽出来然后排序统计每个IP出现次数再按次数从高到低排。它解决的是一个特别典型的问题——到底是哪个IP在疯狂请求我们的接口一眼就能看出来。这串管道我愿称之为日志排查最常用组合拳没有之一。3.2 awk日志统计利器如果说grep是筛子那awk就是瑞士军刀。它能按列拆分、能累加统计、能做条件判断是写命令行的内联脚本语言。最常见的场景是分析Nginx访问日志。日志格式类似127.0.0.1 - - [01/Jan/2024:12:30:45 0800] GET /api/user HTTP/1.1 200 532其中第1列是客户端IP第9列是状态码第10列是响应字节数。想统计每个IP产生了多少请求平均返回多少字节awk { ip[$1]; bytes[$1]$10 } END { for (i in ip) print i, ip[i], bytes[i]/ip[i] } access.log这个脚本的逻辑很好理解每读一行以第一个字段IP为下标请求数加一同时把第10字段字节数累加进去。全部处理完后遍历打印每个IP的请求数和平均字节数。这种一行命令顶得上你写几十行Python脚本的效率。如果想筛出状态码是500的请求数占总请求数的比例awk $9500 {count500} {total} END {print count500/total*100%} access.log实际用下来awk的威力在于它把字段遍历和统计聚合揉到了一条命令里。你不需要写循环、定义变量、处理文件格式只要声明每行的第几列怎么处理剩下的它全包了。这就是命令行的魅力——简短的表达强大的能力。3.3 sed批量文本替换的好帮手sed对我来说主要干两件事一个是批量替换一个是精准打印某段内容。批量替换的经典场景是配置文件里把旧的数据库地址换成新的。sed -i s/192.168.1.100/192.168.1.200/g config.properties-i表示原地修改直接改文件备份加-i.bak更保险s是替换命令的结构g代表全局替换不写的话每行只替换第一处匹配。这个命令在改配置文件、批量替换代码里的某个变量名时能省下一大截时间。精准打印某段内容也很好用。比如一个几百兆的日志文件你想看第1000到1010行发生了什么sed -n 1000,1010p app.log-n是不自动打印p是打印匹配范围两个参数配合就是我只想看我指定的那几行。这比head -1010 | tail -11来得直观。但这里要特别提醒sed -i是危险操作因为它直接改源文件且不可逆。我的习惯是先用不带-i的替换跑一遍把输出目测一遍确认没问题再带上-i执行。如果是重要配置文件先cp一份备份再动手养成肌肉记忆。3.4 管道组合的思路先筛、再切、最后统计上文已经涉及好几次管道了但值得单独说一下设计思路。我总结的套路是先定位范围再提取字段后聚合统计最后排序展示。第一步用grep或sed缩小到感兴趣的行第二步用awk或cut把这些行里的关键字段切出来第三步用sort、uniq -c、awk做统计第四步用sort -n排出顺序。这个思路适配绝大多数文本分析需求。举个完整例子统计某个时间段内每个接口被调的次数并按次数排序grep 2024:10: access.log | awk {print $7} | sort | uniq -c | sort -nr | head -20第一段筛出上午10点的日志第二段取出URL路径字段第三段排序第四段统计去重uniq -c第五段按次数降序最后只取前20个。这一串下来就是一张现成的接口热门榜整个过程不用写脚本不用下载文件一条命令的事。平时多积累这种套路遇到具体问题时就能下意识地组合起来不用翻书。4. 性能排查Linux资源监控命令组合4.1 一上来CPU飙高我到底该看什么服务器报警CPU使用率100%我建议不要一上来就盯着top看因为top显示的是进程维度的快照信息不够纵深。更有效的路径是先用top找出嫌疑进程再用pidstat看线程最后定位到具体代码逻辑。top敲进去按P键可以按CPU使用率排序一眼扫到最上面的进程PID。这一步其实已经解决了一半问题——你知道了是哪个进程在吃CPU。然后需要看这个进程里的线程情况pidstat -t -p 12345 1 5-t显示线程维度的统计-p 12345指定进程1 5表示每1秒采样一次、共采5次。它能告诉你这个进程内部具体是哪个线程在拼命烧CPU。如果你是Java应用还可以用jstack把线程快照打出来和pidstat看到的线程号换算成十六进制去对。但如果你不是Java没关系至少排查链路是通用的进程 → 线程 → 代码层层下钻每一步都在缩小嫌疑范围。整个流程走下来一般几分钟就能从CPU飙高定位到具体某个方法或某段逻辑。vmstat也是个容易被低估的命令。它直接查看系统层面的CPU、内存、IO概况。有个参数组合特别适合复盘瓶颈vmstat 1 10每秒输出一行持续10行。重点看r列运行队列长度、us列用户态CPU、wa列I/O等待。如果r长期大于CPU核数说明任务排队严重如果wa很高说明瓶颈可能在磁盘而不是CPU。4.2 free到底该怎么看重点不是可用内存free -h命令人人会敲但很多人只会看倒数第二行available。我的经验是别被Used很高吓到也别盲目追求Available很高。Linux的内存策略是能缓存就缓存你看到的used里很大一部分其实是page cache也就是文件缓存这些内存在程序需要时是可以立刻释放的。判断内存是否真吃紧我一般看两个东西available是不是快没了这才是真正能分配给新进程的内存以及有没有明显的swap使用。swap一旦用起来说明物理内存真的不够了free -h如果发现swap用了不少还得配合看看到底是哪个进程在占用ps aux --sort-%mem | head -10按内存占用排序前10个进程名单一列谁是大头一目了然。这套组合下来内存够不够、谁吃的、要不要优化三连问就有着落了。4.3 磁盘IO才是很多性能问题的隐形凶手很多服务变慢CPU和内存看着都正常实际上瓶颈在磁盘。最简单的验证方式是用iostat看一下%utiliostat -x 1 3%util接近100%说明磁盘设备已经处于饱和状态。这段时间经常能看到iowait飙高但光看wait不够iostat -x能看到每个设备层面的读写速率和队列长度。如果确认是某个设备忙可以进一步找是哪个进程读写的iotop工具能实时显示每个进程的磁盘读写带宽iotop -o -P-o只显示正在读写I/O的进程-P只显示进程不显示线程输出清爽得多。实际排障中我遇到过几次慢查询导致大量磁盘读、从而拖垮整个数据库服务的情况都是通过这条链路定位到具体进程再去优化SQL的。4.4 网络连接排查ss和netstat怎么选排查网络连接老一点的教程会让你用netstat但新一点的系统我更推荐ss它更快、信息更全。查当前所有监听端口ss -lntp-l只看监听状态-n不反解域名直接显示IP速度快很多-t只看TCP-p显示对应进程。比如你想知道80端口上到底是哪个服务在跑它直接给你进程名和PID。如果服务器连接数异常高比如出现大量TIME_WAIT会影响新连接的建立。排查方式ss -s这条输出的是汇总统计TCP各状态的数量一目了然。如果TIME_WAIT上万说明服务端主动关闭连接太多可能需要调整内核参数或优化业务代码。这里就不展开内核调优了但排查思路是一样的从汇总里发现异常再下钻到具体连接。4.5 一次CPU飙高的完整排查实录讲个实际案例。有次某项目上线后监控不停报CPU 100%但奇怪的是业务量并没有增长。我按顺序走了这么几步第一步top按P排序看到一个Java进程占了350%。第二步pidstat -t -p看到某个线程一直在跑。第三步把线程号转十六进制jstack抓线程栈发现是在执行一个正则匹配的方法。第四步查代码发现那个正则在处理一段特殊字符串时触发了灾难性回溯。问题定位到代码层级后面的事就简单了——优化算法、上线、观察CPU降下来了。整个排查过程如果只会在某个环节敲一个命令走不到最后。但当命令串成链路每个环节都在缩小范围排查高手的价值正在于此。所以说学命令不能只学单点要学整条链路。5. 进程、会话与服务管理从裸奔到规范化5.1 查进程、杀进程ps的精髓在找ps命令参数特别多说实话我不建议全背但有两套组合必须刻进DNA里。第一个是看全量进程并排序ps -ef简明直观带父进程PID能看出进程之间的父子关系。第二个是按关键字快速找ps -ef | grep java但注意这条命令会把grep自己那一行也匹配进去看着有点碍眼。更优雅的写法是pgrep -af java直接返回进程号和完整命令行不会混入多余输出。找僵尸进程也是一项经典操作。僵尸进程就是子进程结束了但父进程没回收它这种进程杀不掉它已经死了只能处理它的父进程。排查方式ps -ef | grep defunct如果僵尸进程较多说明某个父进程没有正确处理子进程退出状态得从代码层面解决光杀是没用的。这个知识点在面试时也算个加分点实操中排查孤儿进程链也挺有用。5.2 kill不是杀掉这么简单kill命令的本质是向进程发送一个信号而不同的信号决定了进程会怎么回应。常用的三个信号得搞清楚kill -9 PID # 强制杀死不可被捕获慎用 kill -15 PID # 默认信号请求进程退出可被捕获做清理工作 kill -1 PID # 让进程重新加载配置比如nginx、sshd我见过不少新手一遇到杀不掉的进程就kill -9简单粗暴。但实际上-9相当于直接切断电源进程没机会清理临时文件、释放锁、记录状态如果是有状态服务很容易留下脏数据下次启动直接就起不来了。正确的顺序是先用-15给进程一点时间做善后过几秒还没退出再考虑-9。重载配置用-1是个特别实用的技巧比如改了Nginx配置又不想中断服务一条kill -1 $(cat /var/run/nginx.pid)或者nginx -s reload就能热加载不用重启服务。这在生产环境里是刚需操作。5.3 会话与后台运行nohup和screen的组合用SSH连到服务器跑一个长任务直接关终端会把任务一起带走这个坑我早期踩过无数次。最简单的规避方式是用nohupnohup sh long_task.sh output.log 21 拆开解释一下nohup让命令忽略挂断信号 output.log把标准输出写进文件21把错误输出也合并进同一个文件否则报错你看不到最后的把进程放到后台。这套写全了才是一个合格的后台任务启动命令。如果只写nohup command 而不重定向输出它会生成一个nohup.out文件混乱不说还可能占满磁盘。但nohup有一个天生的短板任务启动以后你就没法再回到那个会话里看了。想跟踪进度怎么办只能读日志文件。更优雅的方案是用终端复用工具我最常用的是screenscreen -S mytask # 在里面跑你的长任务 # 按 CtrlA 然后按 D 把会话脱离 screen -r mytask # 需要时重新接回这个会话这种开个虚拟终端、跑任务、关掉连接、回头再看的模式做编译、跑批处理、远程部署时都舒服得多。同类工具还有个tmux功能更强快捷键体系不一样顺手就行。5.4 systemctl现在的主流服务管理新一点的发行版都换成了systemd服务管理的标准姿势是systemctl status nginx # 看服务状态 systemctl start nginx # 启动 systemctl enable nginx # 设为开机自启 systemctl restart nginx # 重启 journalctl -u nginx -f # 实时看这个服务的日志我最常用的是journalctl -u nginx -f它直接把服务日志接上了都不用去翻/var/log目录。这在排查服务怎么又挂了时效率极高服务启动时的报错信息全都集中在一起。顺便提醒每次改完配置一定要restart或者reload不要以为改完文件就生效了——这也是新手常掉的坑。6. 网络排查命令组合拳6.1 从ping不通到定位具体环节网络问题排查是有套路的。我习惯按这个顺序来先判断是不是链路不通再判断是哪一层有问题。第一步ping一下目标地址ping -c 4 www.example.com能通就说明网络链路是通的至少ICMP通。如果ping不通可能是防火墙、路由或者对端禁ping等。下一步查路由是ip route查自己的IP是ip addr层层排查。以前大家习惯用ifconfig现在新系统更好用的是ip命令套件信息更全、输出更规范。这里要特别提一句ping通了不代表应用层就正常。有时候网络通但端口不通就需要用到下面要讲的命令。6.2 测端口和接口curl是排查应用层的好帮手端口连通性测试我一般用nc或telnetnc -vz 192.168.1.10 8080-v显示详细过程-z表示只探测端口不发送数据几秒钟就能判断端口是否开放。如果是HTTP接口的排查curl是首选。常用参数组合curl -i -X POST -H Content-Type: application/json -d {key:value} http://localhost:8080/api/test-i显示返回的响应头-X指定请求方法-H添加请求头-d附带请求体。排查接口报错时我一般先加-v看完整握手和请求发送过程。它能显示TLS握手细节、是否走了代理、响应头里有没有奇怪的跳转这些都是浏览器开发者工具很难给出的信息尤其是在服务器本机测试时curl几乎是不二之选。6.3 DNS排查解析慢或解析错时怎么办域名解析是网络访问的第一步出问题往往表现为网站打不开但IP能通。排查DNS我常用digdig www.example.com它会把完整的DNS解析过程列出来包括哪个DNS服务器响应、解析耗时、查询结果。dig trace能一步步跟踪从根域名服务器到最终结果的完整链路如果某一步超时了问题就出在那一环。老命令nslookup也可以用但其实dig输出更清晰、更适合排障。如果确定是DNS问题先检查系统的解析配置/etc/resolv.conf看看nameserver指向哪里再对比一下其他环境是否能正常解析。很多内网环境的怪问题最后都出在DNS配置指错地方。6.4 抓包分析tcpdump的简单用法有些网络问题靠ss、curl判断不出来就得抓包看了。比如接口响应慢你想确认是客户端等得久还是服务端回复得慢用tcpdump抓一下端口上的流量最直观tcpdump -i eth0 port 8080 -w /tmp/capture.pcap-i指定网卡port过滤端口-w把原始包保存下来然后用Wireshark打开分析。如果你不想装图形工具tcpdump直接输出也能看个大概tcpdump -i eth0 host 192.168.1.10 and tcp port 80在服务器端抓包能理清很多玄学问题SYN包有没有到三次握手有没有完成数据包是不是分片了应答是不是延迟了这些都是应用层看不到的底层信息。出现网络问题时抓包是最后的实锤手段有些结论光靠猜是猜不出来的。6.5 一次网站白屏的排查全流程我之前遇到过一个案例站点突然白屏但服务器负载看着不高。我这边排査的逻辑是这样——先看服务进程是否存活systemctl status nginx活着。然后看本机端口监听ss -lntp | grep :80正常。接着curl -I http://127.0.0.1看本机访问返回200。本机正常那问题可能出在外部链路上。再curl -I公网地址试试结果超时。最后抓包发现tcpdump里SYN包到了但回包没出去顺藤摸瓜发现防火墙策略把出方向某个段给挡了。这个案例想说明的是排障不是碰运气而是利用命令一点点缩小范围。每一层都有对应工具每一条链路都有该看的信息掌握这些命令等于给自己装了一副排查问题的望远镜和显微镜。7. 把命令串成脚本从敲命令到自动化运维7.1 用一条命令备份或迁移数据理解了单条命令下一步就该试试把它们串成脚本哪怕只是一行综合命令。最典型的就是数据库备份mysqldump -u root -p db_name | gzip /backup/db_$(date %Y%m%d_%H%M%S).sql.gzmysqldump导出的数据直接通过管道流给gzip压缩文件名里带时间戳。这样既省了磁盘空间又自动区分了备份时间点。顺手还能配合find做保留策略比如只保留最近7天find /backup -name *.sql.gz -mtime 7 -delete一条命令完成清理不用手动清理攒了好几个G的旧备份。7.2 日志切割与清理自动化日志膨胀是每台服务器都会遇到的问题。除了用logrotate系统自带的日志轮转机制我们也可以手写一个简单的清理脚本思路每天凌晨用find把超过30天、大于500M的日志删掉再把昨天日志压缩归档。find /var/log/nginx -name *.log.* -mtime 30 -delete find /var/log/nginx -name *.log -mtime 1 -exec gzip {} \;第一条删除超过30天的旧日志第二条把昨天的access.log压缩成access.log.gz。加个cron定时任务磁盘告警的烦恼能减少一大半。这些命令单独看不难但组合起来就形成了完整的运维策略。7.3 写一个服务器健康检查的Shell脚本我习惯把日常检查做成一个小的Shell脚本每天自动跑一遍输出结果。脚本核心逻辑无非是把前面讲过的命令串起来#!/bin/bash echo 系统负载 uptime echo 内存使用 free -h echo 磁盘占用 TOP5 df -h | sort -k5 -n | tail -5 echo 高CPU进程 TOP5 ps aux --sort-%cpu | head -6再简单点可以直接用alias把常用组合命令收成快捷键。比如我本机配了alias keysps -ef --sort-%cpu | head -20 alias myipip addr show | grep inet配置在~/.bashrc里source一下生效。这种把高频命令变成顺手快捷键的习惯长期积累下来效率差距非常可观。7.4 Shell脚本的几点提醒写Shell脚本踩过的坑我总结了几个第一变量赋值等号两边不能有空格name xxx会报错写成namexxx才对。第二引用变量尽量用双引号包起来比如echo $name否则路径里有空格时会出问题。第三判断命令返回值用$?或者直接if command; then echo success else echo fail fi这种写法比把$?存下来再判断直观得多。第四脚本开头一定加set -e表示只要某条命令返回非零就直接退出避免在错误状态下继续执行导致更严重的后果。8. 常见问题与排查技巧实录这部分我把实际运维中经常碰到的几个典型问题整理成一个速查表方便各位在处理类似状况时能快速定位方向。表格里给的是排查命令和解决思路但真正定位问题往往需要组合使用以下几个案例应该能让这个表格变得立体起来。现象一般先查什么常用命令常见原因与解决思路磁盘空间不足找出占空间的目录df -h、du -sh /* 2/dev/null | sort -hr | head -10日志文件过大、旧包未清理用上文find命令清理或调整日志策略CPU持续100%找出吃CPU的进程top按P排序、pidstat -t -p PID业务代码死循环、正则回溯、GC线程或虚拟机异常下钻线程抓栈分析命令找不到确认路径和安装情况which nginx、echo $PATH环境变量问题或软件未安装重新配置PATH或安装软件包端口被占用找出占用进程ss -lntp | grep :8080、lsof -i:8080旧服务未退出或同端口进程冲突确认后处理对应进程网络连接数异常高查连接状态分布ss -s、ss -ant | awk {print $1} | sort | uniq -cTIME_WAIT过多或连接泄漏调整内核参数或优化代码长连接管理文件无法删除确认权限和文件类型ls -l、lsattr权限不足或存在不可变属性修改权限或用chattr去掉属性这个表格只是入口。实际排查问题我始终强调的是链路思维从现象反推可能出问题的环节再用对应命令验证。比如磁盘满是现象可能的原因有日志膨胀、备份文件堆积、数据库临时文件等等。每条线索都会引导你用不同的命令去确认这就是命令行技能的真正价值。9. 写在最后的几点实在心得文章写到这核心内容已经讲得差不多了最后分享几个我用Linux命令多年攒下来的心得。第一得学会看帮助文档。别一遇到不认识的命令就百度先man 命令或命令 --help绝大多数用法参数都写清楚了。英文不好没关系看个大概结构就够了查多了自然熟悉。尤其是man里的EXAMPLES部分基本是官方给的实用案例比看网上二手教程靠谱得多。第二用一个命令前先想想可能产生什么后果。尤其是涉及删除、覆盖、批量修改的命令一定要想清楚影响范围再动手。生产环境上操作前备份永远是合格的选择。我给自己定的规矩是高危操作在回车前先停下来看一眼、确认一遍这个习惯帮我躲过了好几次灾难。第三多记录自己的组合命令。每当摸索出一条好用的命令组合我会把它记到笔记里注明应用场景。时间久了这就是你自己的命令手册比任何教程都实用。很多看起来复杂的运维操作不过是几条命令组合体记熟了就是肌肉记忆。第四别怕耗时去理解原理。比如为什么grep比编辑器搜索快因为它只做流式处理不需要把整个文件载入内存。为什么rsync适合传大文件因为它能断点续传而且只传差异部分。弄懂了这些底层机制你就知道什么场景该用什么工具而不是背参数。这一点比记住几百条命令重要太多。玩转Linux命令本质上是在学习一种用计算机的思维解决问题的方式。它让你学会组合、抽象、自动化、以及带着链路意识去排查。这条路没有终点但你会越来越顺越来越有手感。希望这篇实战分享能给你一些切实的参考。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
