Linux命令不是背出来的：按场景排查故障才是关键

后台经常有朋友问我Linux命令到底怎么背面试前刷了一堆命令大全看完就忘真到了服务器上又不知道该用哪条。这个问题我太有感触了。我不是计算机科班出身第一份工作是给一家小公司做运维当时的服务器是台老旧的CentOS 6交接文档上就写着十几个命令其他全靠自己碰。那会儿我理解Linux常用命令不是背下来的是一台测试服务器被我反复折腾、出问题再救回来慢慢磨出来的。这篇东西我不想写成一个标准的命令字典。网上命令大全太多了收藏了不会看看了也不会用。我想换一种讲法把常用命令拆成场景每个场景告诉你为什么用它、排查思路是什么、踩坑点在哪里。适合刚入门的同学、准备运维面试的朋友以及那些会敲cd和ls但遇到服务挂了不知道先查什么的半桶水同行。1. 先想清楚命令不是背出来的是“按场景调出来的”1.1 你记住的不该是命令而是“服务器出问题时先碰哪里”我见过太多人背了上百条命令结果真上了生产服务器第一个动作还是打开top看到CPU满了就不知道该干嘛。问题不在于命令记得少而在于脑子里没有一套排查链路。Linux常用命令从运维角度来说其实就分几大类查目录、查文件、查系统状态、查网络、查进程、查日志、装软件、改权限、配服务。每一类对应一个业务诉求。比如网站访问变慢了你需要的是按顺序看负载、看CPU、看内存、看磁盘IO、看网络连接数——这不是让你背一堆命令而是让你在“慢”这个现象出现时能有一张排查地图。所以我建议初学者不要按字母表去记命令而是按故障去记。哪怕你只掌握了top、free、df、ss、systemctl、journalctl这几条配上grep和awk百分之七八十的日常问题已经能定位了。命令多不多不重要关键是知道哪条命令能回答你当前的疑问。1.2 命令找不到、敲错字母、记不住参数——先学会怎么“求援”Linux有个好习惯每个命令都有在线帮助。敲command --help能看简短用法man command能看完整手册。刚开始我根本不看man因为全英文且又长又啰嗦但后来遇到奇怪参数发现最可靠的还是man比搜索引擎靠谱得多。另外type和which也值得养成肌肉记忆。which nginx可以确认软件装在哪个路径type -a java能看到命令是从哪里来的、有没有别名干扰。很多时候排查问题半天最后发现是自己环境里有一个旧版本的命令在作怪。这里说一个新手最容易忽略的命令找不到时报错是 “command not found”可能原因只有那么几个软件没装、路径不在PATH里、命令名记错、或者当前用户没有这条命令的执行权限。按这个顺序查比乱试快得多。我后来带新人就要求他们报错时先把完整报错贴出来别自己瞎猜因为九成问题出在环境而不是命令本身。2. 文件与目录操作干活前先把家底摸清楚2.1 ls、cd、du不只是看文件还要看大小和占用ls大概是所有人入门Linux的第一条命令。但很多人只会用ls和ls -l其实日常最实用的是ls -lht按时间排序、带大小、人类可读新改的文件一眼看到。加个-d可以只看目录本身信息加-a看隐藏文件这几个组合起来基本就够用了。再看磁盘占用我推荐du -sh *搭配du -h --max-depth1去观察某个目录下到底是什么在吃空间。这里有个教训线上日志目录经常好几个月没人清等发现的时候磁盘已经100%了但执行df -h看到的只是一个使用率根本不知道是哪个目录出了问题。这时候从根目录往下一层层du -sh *十分钟就能定位。新手最容易犯的错是用du -sh /直接扫全盘那个速度慢到怀疑人生还容易扫出大量无权限目录。rm -rf是高频命令也是最容易闯祸的。我的建议是删文件前先ls -l看一眼路径杜绝rm -rf /var /log这种因空格少打而酿成事故的手误重要目录尽量用mv到临时目录确认没问题再删真有频繁删除需求的路径可以考虑脚本里加--preserve-root之类的保护参数至少能少踩一个坑。2.2 软链接和硬链接一句话讲清楚它们的区别与用处ln -s /a /b创建软链接相当于Windows里的快捷方式指向原文件文件删除链接就失效。硬链接是文件名和文件数据之间的另一个入口删掉其中一个名字数据还在。实际服务器上我们用的最多的是软链接比如升级Java时把新版本解压到目录再用ln -s把/usr/bin/java指到新版本切换版本就是改一条链接比改全局环境变量安全得多。有一个小坑软链接路径在链接文件里是原样记录的如果你用的是相对路径换位置之后链接会断。所以写脚本、写systemd配置文件里涉及软链接时最好用绝对路径。很多服务启动时报“找不到文件”其实就是链接指错了位置。2.3 find与grep文件检索的两板斧find /data -name *.log -mtime 30能按名称和修改时间找文件清理老日志时这个命令几乎每天都要用。grep -rn 关键字 /etc/nginx/能在配置目录里直接搜内容改配置前先grep一下相关项能避免改错文件。组合起来用的时候注意find的-exec或-delete要谨慎。我见过有人写find /tmp -name *.log -exec rm -rf {} \;语法看着对但-exec里每个文件都会执行一次文件多的时候慢得厉害。更稳妥的做法是先输出看看find /tmp -name *.log | head -50确认范围没问题再执行删除。加-print也是同样思路先看清楚再动手。3. 用户与权限很多故障根本原因是权限不对3.1 新建用户、改密码、加sudo一步都不能省服务器上新建用户是高频操作完整流程一般是useradd zhangsan passwd zhangsan usermod -aG wheel zhangsan # CentOS系 # 或 usermod -aG sudo zhangsan # Debian系这里注意-aG是追加到附加组不是覆盖主组。少了-a直接-G很可能把人家的主组改掉导致权限莫名其妙缺失。给管理员加sudo权限时建议用visudo编辑/etc/sudoers别直接手改因为visudo会做语法校验语法错会导致sudo全线崩溃那是真正的生产事故。还有一点容易被忽略新建用户后要检查一下shell是否正常chsh -s /bin/bash zhangsan可以改默认shell。如果用户登录后提示符怪怪的或命令都找不到多半是shell没配对或者是HOME目录里缺了.bashrc这类配置文件。3.2 文件权限数字只是结果你得看懂设计的逻辑chmod 755和chown root:root是运维最常用的权限操作。数字权限的算法很多人背过r4w2x1加起来是owner的值group和other各自再算。但更重要的是要知道为什么用755。目录755表示owner可读写执行其他人可读可执行非常适合web站点程序目录既能读又不能改。上传类目录经常用chmod 755加chown www:www防止网站被篡改。如果是普通文件比如配置文件644就够了因为文件不需要执行。改目录权限时别忘-R递归但也要小心-R会把目录下所有子目录权限全部覆盖掉。正确做法通常是先改目录本身chmod 755再单独对已经存在的文件统一find /data/web -type f -exec chmod 644 {} \;这是生产环境里比较标准的做法。3.3 权限设计意识新手和老手的差距在这里很多初学者只关心“怎么把权限改成可读写”很少想过“为什么不能全都777”。我见过一台服务器上所有网站目录都是777结果被挂马后找不出问题因为每个目录都可以写攻击者修改任何文件都不算越权。权限管理最核心的原则是最小化能不给写就不给写能不开root就不用root。平时操作尽量用普通账号需要管理员权限时用sudo和具体命令别一上来就su - root把整台机器都暴露出来。排查问题时也多想想“这个文件到底应该属于谁、权限该是多少”这是运维习惯也是面试时“权限管理思路”这类问题背后的实质。4. 系统状态查看先看到指标再谈定位问题4.1 top、free、uptime从宏观到微观看一台机器的健康度上线跑着的服务突然卡了第一件事不是去看应用日志而是登到机器上看整体状态。uptime输出里的load average是三个数字分别代表1分钟、5分钟、15分钟平均负载。如果1分钟比15分钟高很多说明系统刚来了一波压力如果15分钟也居高不下那就是持续有问题。但注意负载高不代表CPU满还可能是在等IO。free -h看内存和交换分区。重点不是看“已用”那一栏而是看available这是真正可用的内存。很多新手看到used 90%就心慌其实Linux会尽量用空闲内存做缓存available低才是真的不够用。top里按shift p按CPU排序、按shift m按内存排序能快速找到是哪个进程在啃资源。加一个-o %MEM可以直接按内存排省去按键。还有一个细节老一点的内核或新版top输出有变化但M和P快捷键一直没变这个可以直接记。4.2 df、du与inode磁盘满没满不能只看空间磁盘满了的故障比CPU高更难缠。df -h看的是空间但它只看分区使用率有个更隐蔽的问题inode耗尽。文件数量太多把文件系统的inode用光了即使空间还有剩余也没办法创建新文件。查看方法df -i find /data -type f | wc -l要清理大量碎文件时也别用rm递归硬删推荐find /data/tmp -type f -delete或者配合-mtime 7删旧文件。有些目录里几十万个小文件直接rm -rf可能会因为文件名参数过长而报错用find的方式就没有这个问题。4.3 网络连接ss命令比netstat好用的地方老教程习惯教netstat -anpt但新版系统更推荐ss。ss -lntp可以查看监听端口和对应进程排查端口占用时比netstat快很多因为netstat在连接数多时会扫描/proc/net/tcp效率差不少。使用示例ss -lntp | grep 8080 ss -sss -s会汇总当前TCP连接状态能看到大量TIME_WAIT、SYN_RECV时基本可以判断是不是有连接异常。排查“端口起不来”的问题先看监听再看进程再看防火墙/安全组规则这一条链路基本能覆盖80%的网络问题。5. 服务管理、软件安装与常用软件快查5.1 systemctl与kill重启服务不是上来就“杀进程”现代Linux发行版普遍使用systemd天天打交道的三条命令systemctl status nginx systemctl restart nginx journalctl -u nginx -n 100 --no-pagerjournalctl -u是按服务名过滤日志比直接看/var/log/nginx/error.log更全因为systemd会把服务的标准输出和错误也收集进来。遇到服务起不来的情况先status看状态然后journalctl -u看最近日志再决定是改配置还是看依赖而不是一次次systemctl restart试运气。进程终止要看情况。服务异常了systemctl stop是正规方式某个进程占着CPU无法停止再用kill -9 PID。kill默认发的是15号SIGTERM进程还有机会做清理-9是强杀能不用就不用。排查时查看进程树pstree -ap可以看清父子关系别误杀到父进程。5.2 git与docker现在几乎每个Linux场景都躲不开Git常用命令里我推荐日常真正用得上的git clone、git pull --rebase、git status、git log --oneline -10。pull加--rebase是为了避免多出一条merge提交团队协作时保持历史干净。Docker这块最常用的是docker ps docker logs -f 容器名 docker stop 容器名 docker build -t 镜像名 . docker exec -it 容器名 /bin/bash注意区分docker ps运行中的容器和docker ps -a包括已停止的容器很多人找了一晚上容器结果发现早已被stop了。容器日志是docker logs -f和journalctl思路一致先看日志再动容器永远是排查的第一原则。5.3 mysql与redis高频命令速查MySQL基本操作mysql -uroot -p SHOW PROCESSLIST; SHOW STATUS LIKE Threads_connected;连接数满了或进程卡死先看SHOW PROCESSLIST再结合SHOW ENGINE INNODB STATUS定位一句kill id可以干掉阻塞会话。Redis常用的是redis-cli -h 127.0.0.1 -p 6379进去后info memory、keys *这些要小心线上别乱跑keys量大时会堵住。建议用scan 0 MATCH * COUNT 1000替代keys。这里想多说一句数据库命令不需要一次记住全部关键是知道去哪里找慢查询、怎么看连接数因为这些才是线上真实事故的场景。6. 日志分析与脚本化把常用命令串成组合拳6.1 查日志的正确姿势tail、less、grep配合起来日志文件的查看是一件体力活但方法对了效率翻倍。tail -f实时跟踪日志less大文件翻页比vim顺手grep过滤关键字。我常用的三段式tail -n 500 app.log /tmp/app_tail.log grep -n ERROR /tmp/app_tail.log | tail -50 less G /tmp/app_tail.logless G是打开后直接跳到末尾配合在less里按G到末尾、按?向前搜索比直接用cat然后翻屏快多了。排查问题时我习惯先看最近的报错再往回翻前几条正常日志对比异常时间点发生了什么这样能大大缩小排查范围。6.2 用cron与脚本把常用命令自动化如果每天都要查磁盘、清临时文件、备份数据库那就该写成脚本了。理论上cron定时任务crontab -e # 每天早上3点执行备份脚本 0 3 * * * /data/scripts/backup.sh /var/log/backup.log 21这里有个关键点cron环境变量很少脚本里用到mysql、python等命令时建议写全路径或用source加载环境否则会发现手动跑好好的脚本cron里一直报“command not found”。写脚本时先把set -e加上出错即停再配合日志重定向运维就省心很多。6.3 一个经典故障演练从日志到定位再到恢复的完整链路我拿一个我实际做过的例子说明。一天下午同事说某个接口特别慢我看负载不高就先看日志journalctl -u app -n 200 --no-pager | grep -i error tail -f /data/logs/app.log | grep --line-buffered slow发现日志里大量连接数据库超时接着看数据库活动SHOW PROCESSLIST;一个查询跑了十几秒几张表出现锁等待。我kill掉那个长查询顺手给相关查询加了索引重启服务后接口恢复。整个过程不到半小时用的就是上面说的那些命令的组合。类似的故障很难靠背命令解决但你心里有了“日志→连接数→锁→索引”的排查链路后就能一步步定位这种现场经验比背命令重要得多。7. 求职面试常考的命令题与学习路径建议7.1 高频面试题给你一台机器如何做体检面试里最常见的Linux问题不是“背诵命令”而是场景题。比如“服务器CPU高你怎么排查”“磁盘满但找不到大文件怎么办”“端口被占用了怎么定位”。与其背答案不如自己搭一台虚拟机把服务故意搞坏再修复。三次之后上面的问题都有了肌肉记忆。比如CPU高第一步top -c找到进程第二步top -Hp PID找到线程第三步结合日志和代码定位这个链路就是面试官想听到的排查思路。7.2 几个不算冷门但非常提升效率的命令细节有些命令平时不起眼但用对了效率翻倍history搭配!序号可以快速重跑历史命令加Ctrl R反向搜索比重新敲一遍快得多alias定义自己的快捷键比如alias llls -lh、alias gpgit pull在.bashrc里写一次节省大量时间xargs和find配合find . -name *.log -mtime 7 -print0 | xargs -0 rm -f这个写法比-exec快很多而且能应付文件名带空格的情况。写在最后的个人体会我在面试人的时候最关注的不是对方背过多少命令而是他有没有自己的排障流程。Linux常用命令就像工具箱里的扳手和螺丝刀你会用不代表你是个好机修工能快速判断该用哪把、用完怎么归位才是关键。所以学习路径上我特别建议新人在虚拟机里反复做破坏性实验把权限改错把服务停掉把磁盘塞满然后想尽办法修复。这个过程你会永远记住那些命令比看十遍命令大全都有效。另外我自己的一个小习惯所有准备执行的高风险命令先敲一遍带echo的预览版本。比如rm -rf前先echo出要删除的路径确认无误再去掉echo执行。这个习惯让我躲过了至少三次删库级别的误操作也希望你能拥有。