运维实战：Linux命令、故障排查与自动化脚本技巧解析

1. 写在前面

干了这么多年运维，我最大的感受就是：这行看起来是“修电脑的”，实际上拼的是快速定位问题的能力和日复一日积累下来的小套路。无论是服务器崩了、办公网卡了、还是业务上线前要巡检，真正拉开效率差距的，往往不是哪些高深的架构设计，而是那些随时能拿出来用的命令技巧、工作习惯和判断逻辑。

这一次我不打算讲什么大而全的运维体系，就专门把平时在 Linux 环境、桌面支持、机房巡检和日常自动化处理里踩过的坑、用顺手的技巧整理一遍。这篇内容适合刚入行的运维新人、负责公司内部 IT 支持的桌面运维，以及想优化自己日常工作流的工程师。每一条我都尽量说清楚为什么这么做、在什么场景下用，顺便附上我自己的实测经验，希望能给你一些可以拿过去直接用的参考。

2. 服务器运维中的实操技巧与高频命令

2.1 命令技巧：别再敲完整路径和重复命令了

服务器运维最怕两件事：一是敲错命令，二是浪费时间敲重复的命令。先说让人“真香”的几个技巧。

善用 alias 固化高频操作

我习惯在自己管理的每台服务器上，把常用的命令简化成一串短别名，写在 ~/.bashrc 里：

bash复制alias ll='ls -alF'
alias vi='vim'
alias grep='grep --color=auto'
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias netstat='netstat -tunlp'
alias df='df -h'

别小看加 -i 参数这件事。服务器上误删文件、误覆盖配置的案例，百分之八十发生在深夜变更和紧急排障的时候，这时候一个默认的交互确认提示能救回半条命。改完 ~/.bashrc 记得执行 source ~/.bashrc，让它立刻生效。

历史命令搜索与调用

很多运维同事还在用上下方向键翻历史命令，翻得眼花缭乱。实际上用 Ctrl + R 可以反向搜索历史命令，输入几个关键字母就能快速调出之前执行过的完整命令，效率提升非常明显。

如果想看到历史上所有执行过的命令，直接敲：

bash复制history

但要真正发挥价值，还得配合 ! 符号。比如 !ps 会重新执行最近一条以 “ps” 开头的命令；!! 表示执行上一条命令。日常改配置文件时我经常用 !! 反复调试命令，省去重复输入的麻烦。

多条命令组合执行

一个是用 && 连接，前一条成功后才会执行后一条。另一个是用 ; 分隔，无论前一条是否成功都会继续往后执行。做服务发布时我一般写成这样：

bash复制cd /app/deploy && tar -zxvf app.tar.gz && systemctl restart app && systemctl status app

这样的好处是，哪一步失败了就立刻停下来，不会在解压失败后还傻傻地去重启服务。

2.2 排查三板斧：CPU、内存、磁盘的快速体检

系统出问题，先看什么？绝大多数情况下，一台服务器表现异常，无非是 CPU 飙升、内存不足、磁盘写满、IO 卡顿这几类问题。我的习惯是先用 top 和 free 摸个底，再用 df 和 iostat 做精细定位。

定位 CPU 占用高的进程

top 进入后按 P 键可以让进程按 CPU 使用率排序，这是最快把“罪魁祸首”揪出来的办法。如果发现某个进程 CPU 占用率长时间在 100% 以上，先别急着 kill，先用 ps 看一下它到底是什么：

bash复制ps -ef | grep 进程名

如果确定是需要重启的业务进程，先重启再观察；如果是可疑进程，结合启动时间和执行路径判断是否为异常程序。另外，多核 CPU 环境下看 CPU 使用率要留意数值可能超过 100%，因为 top 显示的是所有核的累计占用率。

释放内存前先搞清楚谁在占用

当 free -h 看到内存不足时，很多人第一反应是“清理缓存”。但其实 Linux 的内存管理机制中，buff/cache 占用的内存是可以在需要时自动释放的，不需要手动干预。真正的问题是进程占用的内存异常增长。

此时我会用：

bash复制ps aux --sort=-%mem | head -20

从高到低列出内存占用最高的 20 个进程，看看是哪个业务在吃内存。如果是 Java 应用，再用 jmap 或 jstat 进一步查看堆内存使用情况；如果是数据库，检查慢查询和连接数。

磁盘写满后别忽略 inode

df -h 查看磁盘剩余空间是大家都会做的事，但还有一类经典问题：磁盘明明还有空间，却提示“No space left on device”。这种时候十有八九是 inode 耗尽了。

bash复制df -i

用 df -i 查看 inode 使用率，如果 IUse% 接近 100%，说明磁盘上小文件太多，需要找出这些文件并清理。常见的位置包括 /tmp 目录、邮件队列目录、容器日志目录等。我曾处理过一台被大量 0 字节临时文件塞满 inode 的服务器，最后是用 find /tmp -type f | wc -l 确认数量后批量清理解决的。

2.3 日志查看与实时追踪：别只会 tail -f

看日志是运维的基本功，但怎么看得快、看得准，还是有技巧的。

多文件实时追踪

一次部署多个服务时，我常需要同时看多个日志的输出。简单做法是开多个终端窗口，但更优雅的方式是用 tail -f 同时跟踪多个文件，并且用 --pid 参数让它跟随某个进程退出：

bash复制tail -f /var/log/nginx/access.log /var/log/nginx/error.log

如果担心日志文件被 logrotate 切割后 tail -f 失效，推荐用 tail -F（大写 F），它会自动重试打开被轮转的文件。这个细节在跑长期任务时特别重要，否则日志一切割，终端就再也不输出新内容了，你以为是应用停了，其实只是跟踪断开了。

按关键字抓上下文

排查报错时，只知道“有 ERROR”是不够的，得看到报错前后的日志内容。用 grep -C 可以同时打印匹配行的前几行和后几行：

bash复制grep -C 5 "ERRO