1. 为什么Linux基础运维命令仍然是硬通货这几年容器化、K8s、云原生铺天盖地很多新入行的朋友一上来就学Docker、学编排、学各种自动化平台。但说实话不管是虚拟机、物理机还是云主机最后你总要落到一台Linux系统上。你可以在图形界面里点点点但服务器上没有那个条件生产环境里也没人给你装桌面。我面试过不少年轻人简历写得花团锦簇提到排障就是看看监控、重启服务但真给他一台干净的CentOS或者Ubuntu让他查一下磁盘为什么满、某个进程为什么CPU飙高、网络端口为什么连不上很多人会愣住。这不是个别现象。基础运维命令就像是内功你容器玩得再花、平台搭得再炫底层还是那套进程、文件、网络、权限模型。搞懂了这些命令你不仅能在没有图形界面的机器上干活还能在这些工具之上理解更复杂的系统问题。本文不搞从入门到放弃的大而全就挑运维日常工作里命中率最高的一批命令按场景拆开讲透告诉你每个命令解决什么问题、为什么这么用、实际踩坑时怎么组合出击。适合谁看刚入行的运维新人、被各种自动化工具包围但Linux基本功不扎实的开发同学以及准备面试想系统梳理一遍基础命令的求职者。老手也可以当查漏补缺看看有没有哪个细节是你平时忽略的。2. 上手前的关键认知命令是死的场景是活的2.1 先想清楚你要解决什么问题再想敲什么命令很多人学命令喜欢死记今天记一个ls明天记一个ps后天记一个netstat背完就忘。我自己的经验是命令从来不是靠背的是靠场景-命令的对应关系记住的。你真正要练的是这个转化过程磁盘告警了我需要先看分区使用率再定位大文件再决定是清理还是扩容进程卡住了我需要先找到PID再看它为什么卡是CPU、内存还是IO瓶颈。所以整篇文章我打算按运维场景来组织而不是按命令字母顺序。每个场景背后你会接触到一组高度相关的命令它们组合起来才能解决实际问题。先建立这个认知后面学起来就不会觉得命令是零散的碎片了。2.2 环境差异先说清楚CentOS系和Ubuntu系的命令差别很多命令在两个系统上是通用的比如ls、cd、grep、awk这些不用纠结。但包管理、服务管理、一些系统工具的默认行为会有区别。常见的情况是操作场景CentOS / RHEL / RockyUbuntu / Debian包管理yum install xxx/dnf install xxxapt install xxx查看系统版本cat /etc/redhat-releaselsb_release -a服务管理systemctl start xxx/service xxx start基本一样就是以systemd为主默认Shellbashbash防火墙firewall-cmd/iptablesufw/iptables安装网络工具yum install net-toolsapt install net-tools还有一点很重要新装的最小化系统很可能没有ifconfig、没有netstat、没有telnet因为很多发行版默认不再集成这些老旧工具了。遇到command not found不要慌用包管理装一下就好。运维里最尴尬的不是不会命令而是以为命令不存在。3. 文件与目录管理再简单的命令也有讲究3.1 ls和cd的进阶用法别停留在看列表阶段ls是入门第一课但实际运维里我经常看到有人只用ls和ls -l。对于排查问题来说这远远不够。ls -laha显示隐藏文件h把字节数转成人类可读的K、M、G。排查磁盘占用时这个命令能一眼看出日志目录里哪个文件已经涨到几个G了。ls -lt按时间倒序排列配合head -20查看最近修改过的文件。日志切分、临时文件清理、发布后确认新产物是否生成都靠它。ls -l /path/后看第一列文件类型是d目录、-普通文件、l软链接还是ssocket。判断一个服务是否监听了Unix Socket、某个路径是不是软链这个字段很有用。cd也一样别只知道cd /xxx。cd -可以在最近两个目录之间跳转这个在长路径之间来回切换时非常好用。我经常在/etc/nginx/conf.d和/var/log/nginx之间切来切去如果每次都用全路径会疯掉。cd ~回家目录、cd ..回上级目录这些是基本功但cd -好多人真不知道。3.2 文件查找三兄弟find、locate、which文件找不到了大部分人第一反应是find / -name xxx。这个命令确实万能但它是全盘扫描慢而且负载高。生产环境高峰时段慎用。find 的正确姿势限制查找范围能精确到目录就精确到目录。比如find /var/log -name *.log -mtime 30查找30天前修改过的日志文件find /data -type f -size 500M找出超过500M的文件。这两条命令在磁盘清理时效率极高。locate 的坑它靠系统定期生成的数据库来查速度快但新文件可能查不到。所以在刚发布新包后想立刻找它locate会给你不存在的假象。心态上要明白它只能用于找老文件。which 的用途查命令的可执行文件路径。which python3、which nginx一方面确认命令装没装另一方面排查是不是用了非预期的版本。比如系统里装了两个Pythonwhich能告诉你当前默认的是哪个。3.3 磁盘占用的组合拳du、df和sort磁盘告警是运维里最常遇到的事件之一。告警来了你被拉进群第一件事是什么df -h看整体使用率。df -h输出里/dev/vda1挂载在根目录、使用了90%下一步肯定是找到底是哪个目录在吃磁盘。这时候用du -sh /看根目录总大小不合适因为会扫全盘。正确做法是层层递进du -h --max-depth1 / | sort -rh | head -10du -h --max-depth1 /只看一级目录的大小sort -rh按人类可读数字反向排序head -10取最大的前十个。然后进到最大的那个目录再来一轮。这样定位大文件通常几分钟就能搞定。日常巡检我还习惯用du -sh /var/log/* | sort -rh | head -20看看有没有某个服务的日志在偷偷膨胀。很多存量报警都是日志文件无限增长导致的不是业务数据的问题。4. 进程管理从ps到排查CPU飙高的完整链路4.1 ps的三种组合全格式、全进程、指定进程ps大概是运维里使用频率最高的命令之一了但我见过太多人只会ps -ef然后一顿翻。这条命令本身没问题问题在于你不会从里面筛出你要的信息。ps -ef查看所有进程输出里有UID、PID、PPID、CPU、MEM、启动时间和命令。它是全量视图适合我知道有个进程在跑但我想确认它在不在。ps aux和-ef类似但输出格式稍有区别a包含所有终端进程、u显示用户、x包括没有终端的进程。排查僵尸进程时用ps aux能看到STAT一栏的Z状态而ps -ef不直观。ps aux | grep nginx过滤出和nginx相关的进程。这里有个小知识grep本身也会出现在结果里所以很多人会写grep -v grep过滤掉自己。不过更推荐用pgrep -l nginx直接输出PID和进程名干净利落。查PID是后续所有排查的前提。你要kill进程、要看进程的启动参数、要进/proc/PID/目录看它的运行时状态第一步都是拿到准确的PID。4.2 top的读法与top -c的实战价值top是排查性能问题的主战场但很多人进去以后不知道看什么。我建议按这个顺序读load average三个数分别是1分钟、5分钟、15分钟的负载。如果三个数都很高说明系统持续繁忙如果只有1分钟高可能只是临时的脉冲。%Cpu(s)这一行重点看us用户态CPU和sy内核态CPU再配合waIO等待。wa很高说明磁盘或网络IO可能有问题光加CPU没用。进程列表按P键按CPU排序、按M键按内存排序。哪个进程冒头了问题大概率就是它。top里还有个很多人忽略的小技巧进程列表可能不会显示完整命令行按c键可以切换显示完整命令路径和参数。这样你看到一个python进程能知道它跑的是哪个脚本看到java进程能知道它的启动参数是什么。对于怎么有个奇怪进程占满CPU这类问题top -c几乎是定位第一步。4.3 一次完整的CPU飙高排查链路这里分享一个我处理过的典型案例帮助你把ps、top、strace、kill这些命令串起来。现象应用监控报警某台机器的CPU使用率持续接近100%。第一步top -c进去按P排序看到一个java进程PID是23456CPU占了800%。注意top里CPU可能超过100%因为多核机器上top显示的是所有核的累加。第二步top -Hp 23456按线程维度看这个进程里的哪条线程在消耗CPU。发现有个线程TID是67890CPU接近100%。第三步printf %x\n 67890把线程号转成十六进制得到10932。为什么转因为Java线程dump里的线程号是十六进制的你要到dump文件里找对应线程就必须转。第四步jstack 23456 | grep -A 30 10932拿到这条线程的堆栈看到它在循环调用某个方法代码定位到是正则匹配导致CPU空转。到这里问题的根源才算真正浮出水面。如果不用Java一般的C/C进程可以用perf top或者strace -p 23456看看它在打什么系统调用也能辅助判断是IO卡住还是死循环。整个链路走下来你会发现核心就是从进程到线程、从线程到代码栈逐层缩小范围。这个思路比单记命令重要得多。4.4 关进程的正确打开方式kill的层级从宽容到强制很多人一上来就是kill -9 PID这是非常不好的习惯。kill -9是强制杀死进程没有机会做清理工作可能导致数据损坏、文件锁残留、服务状态不一致。正确的流程是kill PID # 先发SIGTERM让进程自己优雅退出 sleep 3 # 等几秒给它清理时间 ps -p PID # 看看还在不在 kill -9 PID # 还活着再动粗这条链路里kill -9是最后手段不是第一选择。我自己运维时也见过有同事对MySQL直接kill -9结果表损坏、恢复花了半天典型的省事变费事。信号级别的知识不仅运维面试常考实际排障中理解为什么有时候kill不生效也很关键。比如进程处于不可中断睡眠D状态时连kill -9都没用此时往往是内核IO出问题要解决根源而不是一个劲儿地kill。5. 网络排查从端口到连接状态的定位思路5.1 端口占用ss替代netstat的时代已到以前查端口都是netstat -tlnp但新版系统里netstat经常没装而且它还是过时的工具。现在推荐用ss它直接从内核socket信息里读取数据速度快、输出更清晰。ss -tlnp这个命令列出所有监听中的TCP端口和对应的进程。ss -tlnp | grep 8080就能看到8080端口被哪个PID占用。排查端口被占用服务起不来端口冲突这类问题时第一步永远是它。如果要看所有连接而不只是监听中的加个ass -tanp输出里你会看到ESTAB已建立、LISTEN监听、TIME-WAIT、CLOSE-WAIT这些状态。其中CLOSE-WAIT特别值得关注它通常意味着对端关闭了连接但本机应用没有正确关闭自己的socket大量CLOSE-WAIT往往是应用层代码有连接泄漏。5.2 连通性与路径排查ping、telnet、nc、traceroute刚入职的运维有个典型问题用户说连不上我先ping一下。ping通了只能说明网络通、主机在但端口是否可达、服务是否正常ping根本测不了。ping验证目标IP/域名是否可达网络层ICMP层面通了仅此而已。telnet IP PORT很多系统没装telnet客户端但它就是个简易的端口连通性测试工具。telnet 192.168.1.10 80如果端口能通会进入一个黑屏或显示连接成功的提示不通则报错。现在更推荐用nc -vz IP PORTz不发送数据v输出详细信息连完就退干净。traceroute IP看数据包经过哪些路由节点定位是哪一跳丢包或延迟高。但要注意很多云环境运营商ban了ICMP/UDP的traceroute包结果不一定准。我实际排障时最常用的组合是先ping看主机通不通再nc -vz看端口通不通最后ss -tlnp到目标机器上看服务到底监听了哪个地址。有一种很经典的坑服务明明在跑但只监听了127.0.0.1外部IP根本访问不到。用ss -tlnp一看127.0.0.1:8080问题马上浮出水面。5.3 DNS排查nslookup与digDNS问题是网络故障里比较隐蔽的一类。表现是明明能ping通IP但用域名访问不了服务。这时候要查域名解析。nslookup www.example.com dig www.example.comdig的输出更详细可以看到用的是哪个DNS服务器、返回的A记录是什么、TTL多少。排查解析到了旧IP这类问题dig比nslookup直观。我遇到过一个真实案例应用配置里写了一个域名连接时一直报超时但ping域名又是通的。后来用dig一看解析到的IP是一个已经被回收的旧机房地址而DNS缓存里还有这条过期的A记录。清掉缓存、更新内网DNS记录问题才解决。排查DNS有个实用技巧直接指定外部DNS测试绕过本地配置。比如dig www.baidu.com 8.8.8.8能确认是本地DNS服务器的问题还是全球解析的问题。它也能在/etc/hosts改乱了之后快速确认是不是hosts的问题。5.4 抓包三板斧tcpdump的简易上手很多运维看到抓包就害怕觉得那是网络工程师的活儿。但排查一些疑难问题比如连接建立后立刻断掉协议对不上不抓包你永远只能猜。tcpdump的基本用法并不难tcpdump -i eth0 port 8080 -w /tmp/capture.pcap-i eth0指定网卡先ip addr看一下网卡名新系统里常见的有eth0、ens33。port 8080只抓8080端口的包。-w /tmp/capture.pcap保存到文件然后用Wireshark慢慢分析。生产环境建议先-w保存文件再分析不要直接-c打到屏幕上。屏幕输出会丢包你事后啥也看不出来。还有一个组合tcpdump -i any port 80 -nn。-nn的意思是端口和IP都不做反解全是数字速度快、输出清爽。抓完看一眼有SYN包没回ACK包基本就能判断是防火墙拦了还是应用没响应。6. 用户与权限运维里最容易出事故的领域6.1 用户管理useradd到新建用户的完整步骤用户管理看起来简单但涉及系统安全时细节很多。最常见的新建用户场景是这样的新同事入职需要给他一个账号。useradd -m -s /bin/bash zhangsan passwd zhangsan-m自动创建家目录/home/zhangsan不写可能连登录后的目录都没有。-s /bin/bash指定登录Shell不写可能落到/bin/sh虽然能用但体验很差有些功能也不兼容。如果公司要求用户只能访问特定目录可以用setfacl做细粒度权限控制。但作为基础运维更重要的是理解为什么不能随便给普通用户sudo权。很多人图省事直接把新同事加到wheel组或者改了sudoers后面自己给自己埋雷。用户权限和线上系统安全是强相关的事给权限前先想清楚他真的需要root吗查看一个用户的信息id zhangsan输出里有uid、gid和用户所属的组。修改用户所属组可以用usermod -aG docker zhangsan注意-a参数没有它会把用户从其他组里拽出来。6.2 文件权限符号模式和数字模式的本质chmod 755 file里的755怎么来的74214是读、2是写、1是执行。三个数字分别对应owner、group、other。所以755的意思是属主可读可写可执行属组可读可执行其他人可读可执行。用符号模式更直观chmod ux script.sh # 给属主加执行权限 chmod g-w file # 去掉属组的写权限 chmod o-r file # 去掉其他人的读权限执行权限在脚本上的意义特别容易被忽视。你写了一个deploy.shbash deploy.sh能跑但直接./deploy.sh报Permission denied原因是文件没有x权限。对这个问题的理解是脚本没有执行权限而不是脚本内容有错对新手来说是个常见的认知坎。修改属主和属组chown zhangsan:devops /data/app这条命令把/data/app的属主设为zhangsan、属组设为devops。发布代码时经常要批量处理chown -R www:www /var/www/html-R是递归会作用到目录下所有文件。但这个参数要格外小心用错了可能会把整个系统的属主关系搞乱到时找回都很麻烦。6.3 修改sudoers一次草率操作引发的教训sudoers文件是个见了就想跑的东西。它语法严格改错了可能导致所有用户都无法sudo连root都救不回来其实root还是能救但过程很惨。正确做法从来不是直接编辑/etc/sudoers而是把新规则放到/etc/sudoers.d/目录下一个单独的文件里echo zhangsan ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx /etc/sudoers.d/zhangsan-nginx chmod 440 /etc/sudoers.d/zhangsan-nginx这个配置的意思是只允许zhangsan免密执行systemctl restart nginx这一条命令。既满足业务需要又不给全量root权限。chmod 440必须设置因为sudoers的安全检查要求文件不能是组和其他用户可写的否则会拒绝加载。改完文件后一定用visudo -c检查语法。visudo这个命令本身就是为安全设计的它会在保存时做语法校验有问题会提示而不是直接写入。我强烈建议任何动sudoers的操作都要先visudo -c校验再在另一个终端开着root会话确认好了才关掉。7. 日志分析与文本处理三剑客的日常组合7.1 grep的优化思路别把日志整个cat出来日志分析第一原则能不让屏幕刷屏就不刷屏。生产日志文件动辄几个Gcat app.log直接把终端卡死这是很多新人的血泪教训。grep的基本用法是grep ERROR app.log但实际使用需要更细腻的策略grep 2025-06-11 10: app.log # 只看某个时间段的日志 grep -i error app.log # 忽略大小写 grep -r keyword /var/log/ # 递归搜索整个目录 grep -A 10 Exception app.log # 匹配后打印后面10行 grep -B 5 Exception app.log # 匹配前打印前面5行排查线上报错时-A和-B几乎必用。单独一个Exception行看不到上下文你根本不知道是哪个方法、哪个参数触发的异常。还有一个组合拳grep ... | head -50查看前50条就收工避免一次输出几万行把终端搞崩。配合tail -f实时跟踪日志排查正在发生的问题也很有用。7.2 awk从按列切到按条件统计awk的本质是按行读、按分隔符切列、按条件处理。运维里面最常用的场景是日志分析和统计。awk {print $1} access.log # 打印第一列通常是IP awk {print $1, $4} access.log # 打印IP和时间 awk -F: {print $1} /etc/passwd # 按冒号切分取用户名更实用的场景是统计IP访问次数awk {print $1} access.log | sort | uniq -c | sort -nr | head -10这条命令的链路是取出IP列 - 排序 - 去重并统计次数 - 按次数降序 - 取前10名。它能告诉你是谁在频繁请求你的接口通常用于排查疑似扫描或刷量。如果awk的语法太复杂记不住先掌握print和$1、$2、$NF这几个基本操作就够用了。$NF表示最后一列在日志分析里很有用。7.3 sed原地编辑的威力与风险sed最常见的用途是批量替换文件内容。sed -i s/old_string/new_string/g config.conf不加-i只是在屏幕输出替换结果文件本身不变加上-i才是原地修改。新手最容易犯的错就是以为不加-i也能改文件结果改了个寂寞。生产环境更新配置时sed配合备份很实用cp config.conf config.conf.bak sed -i s/192.168.1.10/192.168.1.20/g config.conf先备份再原地替换万一改坏了能立刻回滚。这个习惯在操作任何关键文件时都适用。8. 系统状态与性能一条命令定位瓶颈8.1 uptime、free、vmstat负载与内存的快速体检系统卡了用户反馈很慢你怎么量化这个慢uptime输出里有load average前面讲top时提过。它能告诉你系统当前的负载水平但光看负载不够还要看内存。free -hfree -h会显示总内存、已用、可用。有一个细节很多人误解available列才是真正可用的内存不是free列。因为Linux会把空闲内存用作缓存free列看着很低但available其实还有很多这种假性内存不足在加过缓存读写的机器上非常常见。要看更细的内存和CPU行为用vmstatvmstat 1 5这个命令每秒采样一次共采样5次。重点看si和soswap in/out。这两列数值长期不为0说明物理内存不够系统在频繁交换内存页性能会急剧下降。处理办法通常是加内存、优化应用的内存占用或者调整swap策略而不是一遍遍重启服务。8.2 iostat与iotop磁盘IO瓶颈的定位CPU看着不高、内存也够服务还是慢这时候大概率是磁盘IO出问题了。iostat -x 1-x显示扩展信息1是每秒刷新。重点看util列接近100%说明磁盘已经满负荷运转。再看await和svctmawait如果明显高于svctm说明请求在排队磁盘确实是瓶颈。iotop类似top但按IO占用排序能直接看到哪个进程在大量读盘。这个工具需要root权限。排查为什么数据库慢为什么日志写入卡顿时iotop能给你直接的答案是不是某个备份进程在疯狂读盘、是不是日志切分在瞬时大量写盘。8.3 systemctl服务管理的统一入口systemd已经全面普及service chkconfig那套旧命令基本可以不学了。systemctl是统一入口systemctl start nginx # 启动 systemctl stop nginx # 停止 systemctl restart nginx # 重启 systemctl status nginx # 查看状态 systemctl enable nginx # 设置开机自启 systemctl disable nginx # 取消开机自启查看服务状态时systemctl status nginx是一个非常高效的诊断起点。它不仅告诉你服务是active还是failed还会输出最近几条日志。如果服务起不来下面通常直接有Process: 1234 ExecStart...和错误信息不用再去翻日志文件。排查服务起不来的问题时journalctl -u nginx是systemd环境下的日志神器。它把所有服务的日志集中管理不用挨个找/var/log下有没有对应文件。对新手来说这个命令能省很多找日志的功夫。9. 一个从零到一的实战给一台新Linux服务器做初始化讲了这么多零散命令我用一个实际场景把它们串起来新拿到一台虚拟机或云主机需要做基础配置和安全加固。9.1 环境信息确认cat /etc/os-release uptime free -h df -h ip addr这五条命令告诉你系统是什么发行版、负载多少、内存多大、磁盘多大、IP是多少。服务器长什么样先有个全局认知后面所有操作都有底了。9.2 建用户、改SSH配置useradd -m -s /bin/bash admin passwd admin usermod -aG wheel admin把管理员用户加到wheel组后面的操作都不用root直接登录了。然后修改SSH配置vim /etc/ssh/sshd_config把PermitRootLogin改成no禁用root直接SSH登录。这个动作很多新手不理解总觉得自己机器无所谓。但安全运维的基本常识是不要让root账号暴露在网络入口。即使要远程管理也应该先登录普通用户再通过sudo提权。改完配置systemctl restart sshd重启SSH服务前请确认你已经打开了另一个终端保持连接否则配置写错可能把自己锁在门外。这条改SSH先保底的经验几乎每个运维都会被教育几次。9.3 安装基础工具yum install -y vim net-tools lsof tcpdump telnet # CentOS apt install -y vim net-tools lsof tcpdump telnet # Ubuntu这些工具是排障的入门装备。lsof尤其好用lsof -i:8080可以列出占用8080端口的进程lsof /var/log/messages能看出哪个进程在写这个日志文件。9.4 配置防火墙firewall-cmd --permanent --add-port80/tcp firewall-cmd --permanent --add-port443/tcp firewall-cmd --reload firewall-cmd --list-all只开放必要端口其他一律关掉。很多被入侵的机器就是开了个不知道干什么用的端口被人扫到后直接打穿了。9.5 确认服务自启与基础巡检systemctl enable nginx systemctl list-units --typeservice --staterunningsystemctl list-units --typeservice --staterunning会列出所有正在运行的服务看一眼有没有不该出现的服务在跑。这一步是安全巡检里很基础的动作防止被装了后门。整个初始化链路走完你实际上已经把前面讲的命令都用了一遍。当你理解了每个步骤背后的意图而不是机械地敲命令Linux基础运维的大门才算真正推开。我在实际工作中还发现一个规律很多排查经验不是学来的是摔出来的。但基础命令扎实的人摔了之后能更快爬起来因为他知道往哪个方向看。希望这篇整理能帮你少走一些弯路至少在面对一台陌生的Linux服务器时心里有底手上不慌。