企业官网建设流程全解析

简介：这是一份面向运维新手与初级工程师的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 机器的情况下，最常见的做法有这几种，你根据自己的电脑配置挑一个就行：

我个人最推荐新手用云服务器。原因很简单：你将来工作就是要 SSH 连服务器，而不是坐在服务器前敲键盘。提前适应这种方式，后面会很顺。而且像阿里云的“飞天加速计划”、腾讯云的“轻量应用服务器”都有针对新人的优惠，一个月几块钱到十几块钱，比自己组一台旧电脑当服务器要省心得多。

Windows 用户的话，WSL 是体验最丝滑的，安装也简单。以 Windows 11 为例，管理员身份打开 PowerShell，执行一句wsl --install，重启后就自动装好 Ubuntu，直接进终端开练。唯一要提醒的是，WSL 的 systemd 默认不启动，所以像systemctl start nginx这类服务管理命令在里面用不了，需要在/etc/wsl.conf里加一段配置才会生效。这个坑我后面在服务管理章节还会具体说，新手不用急。

2.2 本篇命令手册按什么逻辑组织

拿到一份命令指南，先别急着从头背到尾。你要明白它怎么组织的，才能知道以后遇到问题该去哪一章找答案。这篇手册的编排逻辑很清晰，完全按运维日常的工作流来划分，大致是这么个路线：

1. 文件与目录操作：每天的增删改查，最基础也最常用。
2. 文本处理三剑客：grep、sed、awk，处理日志和配置文件的利器。
3. 权限与用户管理：服务器不是你家电脑，权限搞错是要出事故的。
4. 进程与服务管理：线上程序活着没？挂了怎么拉起来？
5. 网络相关命令：排查网络不通、端口被占用，全靠它们。
6. 磁盘与系统状态：磁盘满了、内存不够、系统负载高，是运维最常见的告警。
7. 常用服务与日志排查：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.20：

sed -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 'NR>1 {print $5}'

NR>1表示跳过第一行表头，$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 是wheel，Ubuntu 是sudo，记混了会提示用户不存在，这个也经常坑到人。

还有一个高频排查场景是文件权限正常但服务依然提示 Permission denied。这时候优先看 SELinux 和 AppArmor 是不是在捣乱。查看 SELinux 状态用getenforce，临时关闭用setenforce 0，永久关闭要编辑/etc/selinux/config。不过我不建议你无脑关闭 SELinux，虽然关闭后很多权限问题都消失了，但这相当于给服务器卸了一层安全防护。更好的做法是学会用audit2why去解析 SELinux 的拒绝日志，知道它到底拦了什么，再针对性地放行。

3.4 进程与服务管理：线上程序活没活，就看这几条

排查进程状态，ps和top是两大主力。ps -ef和ps aux是两种最常见用法，前者看进程的父进程 ID（PPID），后者看 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 nginx

status命令输出里重点看两行：一行是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看wa（CPU 等待 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 2>&1

>>以追加方式写入日志，2>&1把标准错误合并到标准输出，这样任务执行的输出和报错都记录在同一个日志文件里，排查问题方便得多。如果某个任务一直没执行，先用systemctl status crond确认 crond 服务正常，再用grep CRON /var/log/cron（CentOS）或journalctl -u cron（Ubuntu）看调度日志，多半能发现端倪。

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/dnf，Ubuntu/Debian 系用apt。命令本身很简单，yum install xxx/apt install xxx，但有几条进阶技巧能帮你省不少事。

第一条是查看一个软件包是由哪个文件提供的。比如你想用ifconfig，却发现系统提示 command not found，那你需要先装上 net-tools 包，可问题是你不记得包含ifconfig的包叫什么。这就能用上yum provides ifconfig（CentOS）或apt-file search ifconfig（Ubuntu），它会直接告诉你该装哪个包。第二条技巧是锁定软件版本，避免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_growfs，ext4用resize2fs，用反了会直接报错甚至损坏文件系统。如果卷组没空间了，需要先加新物理磁盘创建 PV 再vgextend，那就属于另一个更进阶的场景了，这里先不展开。

5. 常见问题速查：那些我踩过的坑

给新手整理一张“避坑速查表”其实比讲任何大道理都有用。下面这 8 个场景，是我带人或者自己工作中反复遇到过的问题，每一条都值一顿饭钱：

这里再贴一个实际排查案例。有次测试环境 MySQL 突然无法登录，服务显示active (running)，但应用侧疯狂报“Too many connections”。我第一反应是连接数真的被打满了，但ss -s一看连接数并不高。后来tail -100 /var/log/mysql/error.log才发现，错误日志里写的是Can't create thread to handle new connection——是操作系统的max user processes(ulimit) 限制导致线程创建失败。最后在/etc/security/limits.conf里提高了nproc限制并重启 MySQL 解决。这类“服务正常但实际拒绝连接”的问题，最考察排查思路，也是面试官最爱出的场景题。

6. 给新手的最后几个实操建议

先说一个学习顺序的问题。很多人喜欢把命令大全从头背到尾，这个思路我真心不建议。命令是查出来的，不是背出来的。我更推荐的做法是：今天我要完成一个什么任务（比如“把 nginx 的日志按天切割”），然后带着目标去翻手册，把完成任务需要的命令一条条试出来、查出来，标注到自己的笔记里。这样学的命令，每个都带着场景记忆，记得牢、用得上。用一个月时间每天解决一个小任务，你的命令积累量会比死记硬背强十倍。

最后分享一个小习惯：给自己维护一个“命令速查笔记”。我早期的笔记就是一个纯文本文件，按主题分类记录所有用过的命令，每一条附一行注释说明它是干嘛的、有什么坑。坚持一两年后，这份笔记就成了我的“私人运维手册”。你现在看到的这份“Linux基础命令完全指南”在很大程度上就是这类笔记的系统化整理。所以，不要光看，找个环境，打开终端，亲手敲它几十条，比什么都强。

本文还有配套的精品资源，点击获取