简介这是一份面向运维新手与初级工程师的Linux命令速成手册系统梳理了文件目录操作、文本处理、系统监控、权限管理、网络调试、压缩打包等高频场景并配有日志分析实战、故障排查流程与学习路线图帮助读者从零到一搭建运维技能框架。资源为PDF文档共1个文件压缩包约821KB内容结构清晰可作为随身速查手册。目前已有737人学习下载。文档不仅罗列cat、grep、awk、sed、top、netstat等命令的用法与参数还通过“统计Nginx IP排名”“定位高负载进程”等实战示例展示如何用组合命令解决真实问题并特别提醒rm -rf、chmod -R 777等避坑要点与备份习惯能够切实提升日常运维效率。适合具备基础计算机知识、希望快速上手Linux命令行并逐步走向Shell自动化运维的技术人员。1. 为什么每个运维人都该有一套自己的命令手册干运维这行你会发现一个特别真实的现象Linux基础命令就是你的饭碗。不管你是刚入行准备转运维的小白还是已经在服务器堆里摸爬滚打一阵子的初中级工程师每天打交道最多的不是花里胡哨的监控平台不是自动化的运维工具而是那一行行敲进终端里的命令。你连grep、awk、sed都玩不溜连df -h看磁盘、top看负载都要现场想半天那别说处理线上故障了连面试那关都过不去。我见过太多人一上来就啃《鸟哥的Linux私房菜》啃了一个月还在文件权限那块打转越看越没信心。也见过一些人张口闭口“高可用”“容器化”结果让他去排查一台CPU飙高的服务器他连top进去按P排序都忘了。这就是典型的基础不牢地动山摇。所以我一直建议新手入行第一件事别贪多别求全先搞一份覆盖日常高频场景的命令清单像速查手册一样带在身边边用边查查着查着就熟了。这份“运维工程师必备Linux基础命令完全指南新手速成版”要解决的就是这个问题。它不跟你扯太多内核原理也不追求把 man 手册搬过来而是直接告诉你遇到这个场景你用哪条命令为什么要用这条常见的坑在哪里。本文就把这本手册的核心思路和关键内容展开聊聊从一个老运维的视角把这些命令背后的逻辑、使用场景和实战经验都给你掰扯清楚。不管是刚接触 Linux 的新手还是准备跳槽面试的准运维这份内容都能帮你把基础打扎实。注意本文面向的读者是“新手速成”所以刻意省略了部分极其冷门的参数和进阶玩法。先把 80% 高频场景拿下剩下 20% 的进阶技巧在工作中遇到再查再补这才是新手上路最高效的路径。2. 目录就是一张运维地图2.1 别急着敲命令先把环境“拉起来”说实话很多新手在一开始就被卡住了——不是命令不会敲而是根本没有一台 Linux 环境可以练手。这就好比你学游泳理论知识背了一堆结果连水池都没下过。所以无论你手里拿的是哪一份命令指南我建议你的第一步永远是先把环境搞定。本地没有任何 Linux 机器的情况下最常见的做法有这几种你根据自己的电脑配置挑一个就行方案适合人群优点缺点虚拟机VMware / VirtualBox电脑内存 16G 以上完全隔离随便折腾资源占用较高WSLWindows Subsystem for LinuxWindows 10/11 用户轻量启动快与Windows文件互通与真实服务器环境略有差异云服务器阿里云/腾讯云轻量服务器能花一点小钱学生机很便宜和真实生产环境一致随时 SSH 练手需要网络且不能随便折腾系统我个人最推荐新手用云服务器。原因很简单你将来工作就是要 SSH 连服务器而不是坐在服务器前敲键盘。提前适应这种方式后面会很顺。而且像阿里云的“飞天加速计划”、腾讯云的“轻量应用服务器”都有针对新人的优惠一个月几块钱到十几块钱比自己组一台旧电脑当服务器要省心得多。Windows 用户的话WSL 是体验最丝滑的安装也简单。以 Windows 11 为例管理员身份打开 PowerShell执行一句wsl --install重启后就自动装好 Ubuntu直接进终端开练。唯一要提醒的是WSL 的 systemd 默认不启动所以像systemctl start nginx这类服务管理命令在里面用不了需要在/etc/wsl.conf里加一段配置才会生效。这个坑我后面在服务管理章节还会具体说新手不用急。2.2 本篇命令手册按什么逻辑组织拿到一份命令指南先别急着从头背到尾。你要明白它怎么组织的才能知道以后遇到问题该去哪一章找答案。这篇手册的编排逻辑很清晰完全按运维日常的工作流来划分大致是这么个路线文件与目录操作每天的增删改查最基础也最常用。文本处理三剑客grep、sed、awk处理日志和配置文件的利器。权限与用户管理服务器不是你家电脑权限搞错是要出事故的。进程与服务管理线上程序活着没挂了怎么拉起来网络相关命令排查网络不通、端口被占用全靠它们。磁盘与系统状态磁盘满了、内存不够、系统负载高是运维最常见的告警。常用服务与日志排查nginx、MySQL、定时任务的日常维护。每一章都配了对应的场景说明、命令示例、输出解读和避坑提醒。这种按“运维工作场景”而不是“命令字典排序”来组织的方式对你建立自己的知识框架非常有帮助。你脑子里记的不再是孤零零的命令而是遇到什么问题应该用什么工具去哪一章查。3. 核心命令拆解每一条背后都有讲究3.1 文件与目录你每天都在用但真的用对了吗ls、cd、pwd这三个命令大概是你敲得最多的但正因为太基础很多人反而没注意到一些细节。比如ls -l输出的第一列是文件权限一共 10 位第一位是文件类型-代表普通文件d代表目录l代表软链接后面每三位一组分别是**属主u、属组g、其他人o**的读r、写w、执行x权限。这玩意儿面试必考也是你排查“为什么明明有权限却访问不了”这个问题的入口。还有一个我非常推荐的ls参数组合ls -lh。h参数能把文件大小显示成人类可读的格式K、M、G比如你去排查日志目录的时候一眼就能看出哪个日志文件占了几百 M 甚至几个 G心里先有个数。不加h的话显示纯字节数一大串数字看半天还要心算纯属浪费时间。目录操作方面mkdir -p这个组合要重点记一下。-p代表递归创建多级目录。比如你要一次性创建/data/logs/nginx这种层级直接mkdir -p /data/logs/nginx不需要一层层先建/data再建/data/logs省事不少。对应地删除目录用rm -rf但这三个字母组合也是运维事故的高发区。网上流传的那些“删库跑路”段子很多都是手滑在错误目录下执行了rm -rf *。我的习惯是生产环境强制禁用rm -rf要么用一个mv到临时回收站目录的别名替代要么至少在执行前先pwd和ls确认一遍当前路径这个习惯能救命。文件复制和移动就两个关键参数cp -r递归复制目录cp -p保留文件属性属主、时间戳等。日常备份配置时我总会加-p不然复制出来的文件属主变了服务重启后可能因为没有权限读配置而报错这种问题排查起来很绕。移动或重命名用mv没啥好说的记住mv在同一文件系统内是原子操作速度极快。3.2 文本处理三剑客grep、sed、awk 实战这三条命令是运维面试里绕不开的硬骨头也是工作中处理日志、批量修改配置的顶梁柱。先说grep它的核心能力就是在文件或输出流中按模式过滤文本。比如你排查 Nginx 日志里的 500 报错grep 500 /var/log/nginx/access.log注意我建议在 500 前后加了空格避免误匹配到时间戳里包含 500 的行。这就是经验新手经常会因为匹配太宽而把无关行筛进来然后对着输出一头雾水。grep常用的参数还有-E支持扩展正则、-v反向匹配比如过滤掉包含 “health” 的监控探针请求、-c统计匹配行数、-A 2 -B 2前后各显示两行上下文。尤其是-A/-B你在日志里找到一个报错关键字后往往需要看看它前后的日志才能完整还原现场这个参数能帮你快速定位上下文。sed最经典的场景是批量替换文本。比如你有一批配置文件里把旧的 IP 地址192.168.1.10全换成新的192.168.1.20sed -i s#192.168.1.10#192.168.1.20#g /opt/app/config/*.conf这里面有几个要点-i表示直接修改原文件不加的话只输出到屏幕文件本身不变s是替换命令g是全局替换不加只替换每行第一处匹配分隔符我用的是#而不是常规的/因为 IP 地址里本身带斜杠用#能避免转义的麻烦。新手第一次用sed -i前我强烈建议先不加-i跑一遍看看输出是否正确确认无误再加-i执行。这个习惯能帮你避开很多“改完文件全乱了”的惨案。awk在三者里学习曲线最陡但同时也是最能体现运维水平的一条命令。它的本质是一种按列处理文本的编程语言。最简单的用法比如从df -h的输出里提取磁盘使用率df -h | awk NR1 {print $5}NR1表示跳过第一行表头$5是第五列使用率那一列。熟练掌握awk的字段分割默认按空格和内置变量NR行号、NF字段数你就能写出很多像这样一行命令搞定一个报表需求的骚操作。比如统计 access.log 中每个 IP 的访问次数awk {print $1} access.log | sort | uniq -c | sort -nr | head -20这行命令虽然短但把awk、sort、uniq三个命令串起来了能帮你快速看出哪些 IP 在疯狂请求你的服务器是排查 CC 攻击和爬虫骚扰的利器。3.3 权限与用户运维事故的高发区权限管理这块新手最常见的问题就是图省事直接chmod 777。给你个忠告在任何一台正经的服务器上777都是被安全扫描和同行鄙视的。正确的做法是先分析这个文件/目录需要给什么人什么权限然后精确设置。比如 web 目录通常需要属主可读写执行属组可读执行其他人只读chmod -R 755 /var/www/html chown -R www:www /var/www/html第一行是给目录设置权限7是属主读写执行5是属组读执行5是其他人读执行。第二行是修改属主和属组为www用户和www组Nginx 默认运行用户。这两个命令往往是配合使用的只改权限不改属主很容易出“权限给了但程序没权限读”的怪问题。这里用-R递归的时候也要谨慎如果是符号链接目录操作不当可能会影响链接指向的真实目录。用户管理方面创建新用户 设置密码 加入 sudo 组是每个运维都该闭着眼睛敲的命令组合useradd -m -s /bin/bash zhangsan passwd zhangsan usermod -aG wheel zhangsan # CentOS/RHEL 系列 usermod -aG sudo zhangsan # Ubuntu/Debian 系列useradd的-m自动创建家目录-s指定登录 shell。很多新手建完用户发现登录后连ls都不能用大概率就是忘了加-s /bin/bash系统默认给了个 nologin 的 shell。还有一个细节不同发行版的 sudo 组名不一样CentOS 是wheelUbuntu 是sudo记混了会提示用户不存在这个也经常坑到人。还有一个高频排查场景是文件权限正常但服务依然提示 Permission denied。这时候优先看 SELinux 和 AppArmor 是不是在捣乱。查看 SELinux 状态用getenforce临时关闭用setenforce 0永久关闭要编辑/etc/selinux/config。不过我不建议你无脑关闭 SELinux虽然关闭后很多权限问题都消失了但这相当于给服务器卸了一层安全防护。更好的做法是学会用audit2why去解析 SELinux 的拒绝日志知道它到底拦了什么再针对性地放行。3.4 进程与服务管理线上程序活没活就看这几条排查进程状态ps和top是两大主力。ps -ef和ps aux是两种最常见用法前者看进程的父进程 IDPPID后者看 CPU 和内存占用率。以 nginx 为例你会发现ps aux输出里会有一行 master 进程和多行 worker 进程这是 nginx 的架构决定的master 负责管理worker 负责干活。理解这个模型对于你后面做服务调优和故障排查都有帮助。top进入交互界面后几个快捷键要记住P按 CPU 使用率排序M按内存排序1查看每个 CPU 核心的负载q退出。线上 CPU 飙高时我习惯先按P找到最耗 CPU 的进程号 PID然后用下面的命令顺着查它到底是什么top -H -p 12345 # 查看某个进程内所有线程的 CPU 占用-H 开启线程模式 ps -Lp 12345 -o pid,tid,pcpu,comm # 更详细地按线程查看如果你发现某个进程 CPU 占用率高得离谱而且 CPU 占比加起来超过 100%说明它开了多线程在并行计算。如果是 Java 应用还可以用jstack导出线程快照对照线程 ID 的十六进制值找到具体是哪段代码在疯狂抢占资源。这一套组合拳在线排查问题非常管用。服务管理这块现在的系统基本都是 systemd 的天下了核心命令其实就几个systemctl start/stop/restart/status/enable xxx。新手最容易绕晕的是enable和start的区别start是现在启动enable是下次开机自启。所以一条完整的服务上线流程通常是systemctl enable nginx systemctl start nginx systemctl status nginxstatus命令输出里重点看两行一行是Active: active (running)另一行是Main PID。如果服务起不来status输出末尾通常会自带一小段日志这是你排查问题的第一现场。日志不够看的话再执行journalctl -u nginx -n 50 --no-pager-n 50表示只看最后 50 行--no-pager避免输出卡在分页器里。这是排查 systemd 服务的标准姿势。3.5 网络排查从 ping 到 tcpdump 的进阶路径网络排障是运维面试里最容易挂人的环节但也是最吃经验的。你需要一个清晰的排查路径从外到内逐层打怪我先用ping验证目标主机通不通、延迟高不高。通了就继续往上走不通先查自己的网卡和默认网关。然后telnet ip 端口或nc -vz ip 端口看端口通不通这一步能快速判断是不是防火墙或安全组拦截了。再之后ss -lntp或netstat -lntp看本地端口有没有进程在监听。ss是netstat的现代替代品输出更快信息也更全我建议直接学ss。我这里有一个真实的排查案例对你理解这套路径会很有帮助。有次开发说“连接 MySQL 超时”我先telnet 数据库IP 3306发现端口不通。然后用ss -lntp | grep 3306检查数据库服务器本机端口发现 MySQL 进程根本没在监听查了systemctl status mysqld服务是 active (running) 的这就很反常。后来才想到用ss -lntp | grep 3306看到的输出里监听地址是127.0.0.1:3306而不是0.0.0.0:3306所以外部连不上——是 MySQL 配置里的bind-address写错了改成0.0.0.0后重启搞定。排查思路逐层递进才能不慌不乱地快速定位。再补充一个查看实时网络连接的利器ss -s可以打印当前系统的网络连接统计摘要能一眼看到 TIME_WAIT、ESTABLISHED 等状态的连接数。当线上出现大量 TIME_WAIT 连接时往往是短连接请求太频繁、连接复用没做好这时候调整应用连接池、开启 keepalive 通常能明显缓解。如果你要抓包看实际传输内容tcpdump当仁不让tcpdump -i eth0 -nn port 8080 -c 100 -w /tmp/capture.pcap解释一下参数-i指定网卡-nn不解析域名和端口提升性能-c 100抓 100 个包后自动停止-w把原始数据包写入文件。抓完的 pcap 文件拖到 Windows 上用 Wireshark 打开分析那图形界面比纯命令行友好太多。学会这一套你排查网络问题的效率会有一个质的飞跃。3.6 磁盘与系统状态告警来了不要慌磁盘告警是运维收到最多的告警之一处理流程也相对固定。第一步永远是用df -h看整体使用情况找出哪个分区快满了。第二步用du -sh逐级查看目录大小定位到底是谁在吃磁盘。比如查出/根分区快满了就一层层往下看du -sh /home/* du -sh /var/* du -sh /var/log/*一层一层缩小范围直到找到那个占用大头的目录或文件。这里有个非常常见的陷阱用df -h看磁盘已经用了 100%但du找来找去发现目录加起来没有那么多。这种“空间神秘消失”的案子八成是有进程删除了文件但没有释放句柄。用lsof | grep deleted就能把这些“幽灵文件”揪出来通常是某个日志文件被rm了但进程还开着它空间一直被占着。确认是哪个进程占用后重启那个进程即可释放空间。内存和负载方面free -h是看内存情况的首选命令。注意看的是available这一列而不是free这一列因为 Linux 会尽量把空闲内存用作 page cache缓存free显示很小并不代表内存不足available才是实际可用的内存估值。新手经常看着free显示 0 就大喊内存爆了纯属自己吓自己。uptime会告诉你系统的 1 分钟、5 分钟、15 分钟平均负载load average。判断负载是否过高需要结合 CPU 核心数来看如果你的机器是 4 核那么 load average 长期高于 4 说明 CPU 已经饱和。不过负载高不一定都是 CPU 问题也可能是大量进程在 D 状态不可中断睡眠通常是磁盘 I/O 阻塞这时候要用top看waCPU 等待 I/O 的时间占比来确认是不是磁盘有瓶颈。理解这些指标之间的关系比死记硬背阈值有用得多。4. 运维特别关注的部分从命令到场景的串联4.1 定时任务crontab 的正确姿势运维日常里定时备份、日志切割、健康检查脚本都离不开crontab。新手用crontab最容易踩的坑主要有两个。第一个坑是环境变量问题。crontab 执行环境非常精简不会加载你在终端里的.bash_profile环境变量。所以你在终端里跑得好好的脚本放进 crontab 里却报“command not found”。解决方案是脚本里要么写清楚命令的绝对路径比如/usr/bin/python3而不是python3要么在脚本开头显式 source 环境变量#!/bin/bash source /etc/profile source ~/.bash_profile # 脚本正文...第二个坑是 crontab 的日志和输出。默认情况下crontab 任务的标准输出会用邮件发给 root 邮箱而你大概率不会去看这个邮箱。所以我建议每个定时任务都标准地重定向日志0 2 * * * /opt/scripts/backup.sh /var/log/backup.log 21以追加方式写入日志21把标准错误合并到标准输出这样任务执行的输出和报错都记录在同一个日志文件里排查问题方便得多。如果某个任务一直没执行先用systemctl status crond确认 crond 服务正常再用grep CRON /var/log/cronCentOS或journalctl -u cronUbuntu看调度日志多半能发现端倪。4.2 日志排查三板斧找、滤、切日志是运维的宝藏但这个宝藏的挖掘工作如果纯靠肉眼去翻会累死人。我处理日志通常就三板斧。第一板斧找关键信息。用grep在日志里定位错误关键字比如ERROR、Exception、timeout。如果需要按时间范围找可以用sed -n /2024-01-15 10:00:00/,/2024-01-15 10:30:00/p app.log截取某段时间的日志这个技巧在做故障复盘时特别好用。第二板斧统计归纳。比如你想要知道日志里一分钟平均有多少条请求可以结合awk和sort/uniq处理。把日志按分钟字段做聚合统计 QPS 趋势异常峰值一下就暴露了。第三板斧切割归档。日志文件如果不定期切割长年累月能把磁盘写满。系统自带的logrotate是管理日志轮转的好帮手它的配置通常在/etc/logrotate.d/下一个典型的 Nginx 日志轮转配置长这样/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }daily按天轮转rotate 14保留 14 天compress压缩历史日志delaycompress让上一次的日志先不压缩给仍在写入的进程留余地postrotate里执行kill -USR1是通知 Nginx 重新打开日志文件这是一种平滑重载的方式不需要重启服务。如果你负责的应用没有接入日志采集系统给自己配一份 logrotate 是最省心的日志维护方案。4.3 软件包管理装个软件也能出花活装机软件这块不同发行派系的命令不一样。CentOS/RHEL 系用yum/dnfUbuntu/Debian 系用apt。命令本身很简单yum install xxx/apt install xxx但有几条进阶技巧能帮你省不少事。第一条是查看一个软件包是由哪个文件提供的。比如你想用ifconfig却发现系统提示 command not found那你需要先装上 net-tools 包可问题是你不记得包含ifconfig的包叫什么。这就能用上yum provides ifconfigCentOS或apt-file search ifconfigUbuntu它会直接告诉你该装哪个包。第二条技巧是锁定软件版本避免yum update时一不小心把核心软件升级坏了。可以在/etc/yum.conf或使用yum versionlock插件锁定指定包版本。生产环境最忌讳的就是“顺手升了个级”导致依赖崩掉、服务起不来能锁定版本就锁定。关于 Docker 有个额外的建议现在大多数新服务部署都会优先考虑容器方式但你依然要掌握原生软件包管理。因为排查容器内问题、编写 Dockerfile、处理宿主机基础环境时底层还是这些命令逻辑。4.4 LVM 与磁盘扩容让经典“翻车”场景变简单面试题的高频考点和线上事故的重灾区一定有磁盘扩容这一号。这里重点提一下 LVM逻辑卷管理在无需新增物理磁盘的情况下你可以从卷组里划出空闲空间给某个逻辑卷扩容。排查流程大概是这样的。先用df -h确认哪个挂载点满了比如/home。再用vgs看卷组还有没有空闲空间。有的话直接一条命令扩展逻辑卷并同步文件系统lvextend -L 20G /dev/mapper/centos-home xfs_growfs /home # XFS 文件系统用这个 resize2fs /dev/mapper/centos-home # ext4 文件系统用这个关键坑点在于lvextend 之后必须执行文件系统扩容命令很多新手扩完逻辑卷发现df -h没变化就开始怀疑人生。原因就是少了xfs_growfs或resize2fs这一步。另外注意文件系统类型对应不同的扩容命令xfs用xfs_growfsext4用resize2fs用反了会直接报错甚至损坏文件系统。如果卷组没空间了需要先加新物理磁盘创建 PV 再vgextend那就属于另一个更进阶的场景了这里先不展开。5. 常见问题速查那些我踩过的坑给新手整理一张“避坑速查表”其实比讲任何大道理都有用。下面这 8 个场景是我带人或者自己工作中反复遇到过的问题每一条都值一顿饭钱症状排查命令/思路大概率原因磁盘满了但 du 找不到大文件lsof | grep deleted进程占用已删除文件句柄未释放服务 active 但端口不通ss -lntp | grep 端口监听地址是 127.0.0.1外部无法访问crontab 脚本执行报 command not found脚本中是否有绝对路径环境变量未加载明明 chmod 777 了还是 Permission deniedgetenforce查 SELinuxSELinux/AppArmor 拦截kill 进程后过会儿又出现ps -ef | grep 进程名看 PPID有守护进程如 supervisor/systemd自动拉起命令显示 buffer/cache 占满内存看free -h的 available 列正常现象Linux 缓存机制rm -rf 删了大文件但 df 没变化lsof | grep deleted同第一行update 之后服务起不来journalctl -xe查看报错依赖库版本冲突这里再贴一个实际排查案例。有次测试环境 MySQL 突然无法登录服务显示active (running)但应用侧疯狂报“Too many connections”。我第一反应是连接数真的被打满了但ss -s一看连接数并不高。后来tail -100 /var/log/mysql/error.log才发现错误日志里写的是Cant create thread to handle new connection——是操作系统的max user processes(ulimit) 限制导致线程创建失败。最后在/etc/security/limits.conf里提高了nproc限制并重启 MySQL 解决。这类“服务正常但实际拒绝连接”的问题最考察排查思路也是面试官最爱出的场景题。6. 给新手的最后几个实操建议先说一个学习顺序的问题。很多人喜欢把命令大全从头背到尾这个思路我真心不建议。命令是查出来的不是背出来的。我更推荐的做法是今天我要完成一个什么任务比如“把 nginx 的日志按天切割”然后带着目标去翻手册把完成任务需要的命令一条条试出来、查出来标注到自己的笔记里。这样学的命令每个都带着场景记忆记得牢、用得上。用一个月时间每天解决一个小任务你的命令积累量会比死记硬背强十倍。最后分享一个小习惯给自己维护一个“命令速查笔记”。我早期的笔记就是一个纯文本文件按主题分类记录所有用过的命令每一条附一行注释说明它是干嘛的、有什么坑。坚持一两年后这份笔记就成了我的“私人运维手册”。你现在看到的这份“Linux基础命令完全指南”在很大程度上就是这类笔记的系统化整理。所以不要光看找个环境打开终端亲手敲它几十条比什么都强。本文还有配套的精品资源点击获取