凌晨 3 点，服务器报警响了：20 个救命命令
运维打怪日记 · 第 001 期
这是每个运维都经历过的场景：凌晨 3 点，手机突然响起，监控群@所有人：CPU 100%。你抓起电脑，手还在抖，发现只会 3 个命令...
一、那个让我终生难忘的夜晚
时间: 2023 年冬天，凌晨 3:17 地点: 出租屋，被窝里 事件: 入职新公司第 3 天，第一次 on-call
电话响的时候，我脑子一片空白。
"喂？"
"服务器崩了，你赶紧看一下！"
（电话挂断）
我手忙脚乱打开电脑，登录服务器，输入：
top
然后...就没有然后了。
我只知道 CPU 红了，但不知道哪个进程在作妖。想查日志，不知道在哪。想重启，怕背锅。
那一夜，我在机房打了地铺。
二、血泪换来的 20 个命令
那次之后，我逼自己把这 20 个命令刻进 DNA。
现在，我把它们整理给你。希望你永远用不到，但用到的时候能救命。
三、文件操作类（5 个）
1️⃣ ls - 列出文件
真实场景: 领导问"昨天谁改了配置文件？"
ls -lt # 按时间排序，最新的在前
ls -lt | head -5 # 看最近改的 5 个文件
ls -l *.conf # 只看配置文件
💡 老运维的血泪: 有一次，生产环境配置被改错，领导问谁干的。我用 ls -lt 找到最近修改的文件，又用 stat 查到修改时间，最后发现是测试同事手滑...
2️⃣ cd - 切换目录
真实场景: 日志报错了，但不知道日志在哪
cd /var/log # 日志默认在这
cd - # 回到上一个目录（这个超实用！）
pwd # 我在哪？（别笑，紧张时真会忘）
⚠️ 老运维的血泪: 有次排查故障，紧张到忘了自己在哪目录，直接 rm -rf *... 还好及时发现，但手心全是汗。
记住: 执行删除前，先 pwd 确认位置！
3️⃣ cp - 复制文件
真实场景: 要改配置文件，但不敢直接改
cp nginx.conf nginx.conf.bak.20250314 # 备份！备份！备份！
cp -a old.conf new.conf # 保留权限复制
⚠️ 血泪教训: 有次同事直接改配置文件，改完服务起不来了... 原文件还没备份。
记住: 改任何配置前，先 cp 备份！这是保命习惯！
4️⃣ mv - 移动/重命名文件
真实场景: 日志文件太大，要挪走
mv access.log access.log.bak # 重命名备份
mv bigfile.tar /data/archive/ # 移走大文件
💡 老运维的血泪: 有次磁盘满了，我用 mv 把大文件移到备份盘，结果... 两个盘是同一个挂载点。文件没动，时间浪费了。
记住: mv 前先 df -h 确认挂载点！
5️⃣ rm - 删除文件
真实场景: 磁盘满了，要清理日志
rm -f *.log.2024* # 删除旧日志
find /var/log -name "*.log" -mtime +30 -delete # 删除 30 天前的日志
⚠️ 血泪教训（这个真的要命）: 我见过 3 个同事误操作过这个命令：
保命建议:
四、文件查看类（4 个）
6️⃣ tail - 实时看日志
真实场景: 服务报错了，要看实时日志
tail -f /var/log/messages # 实时查看
tail -f access.log | grep "500" # 只看 500 错误
tail -100 error.log # 看最后 100 行
💡 老运维的血泪: 有次服务报错，我用 cat 看日志，结果日志 2 个 G，终端直接卡死...
记住: 大日志用 tail 或 less，别用 cat！
7️⃣ grep - 搜索关键字
真实场景: 日志太多，要找错误信息
grep "error" /var/log/messages # 找错误
grep -i "error" file # 忽略大小写
grep -v "info" file # 排除 info
tail -f log | grep "error" # 实时监控错误（黄金组合！）
💡 老运维的血泪: 有次排查故障，我用 grep 搜"error"，没找到。后来发现日志里写的是"ERROR"...
记住: 加 -i 忽略大小写，别跟自己过不去！
8️⃣ less - 分页查看
真实场景: 日志太大，要慢慢看
less bigfile.log
交互命令:
💡 老运维的血泪: 有次用 vim 打开 5G 日志，编辑器卡死，服务器也卡了... 被领导骂了一下午。
记住: 大文件用 less，别用 vim 或 cat！
9️⃣ head - 查看文件开头
真实场景: 要看日志格式，确认字段
head -20 access.log # 看前 20 行
head -n 1 config.yaml # 只看第一行（看配置格式）
五、文件查找类（2 个）
🔟 find - 查找文件
真实场景: 磁盘满了，找大文件
# 找大于 500M 的文件
find / -type f -size +500M -exec ls -lh {} \;
# 找 7 天前的日志
find /var/log -name "*.log" -mtime +7
# 找 7 天前的日志并删除
find /var/log -name "*.log" -mtime +30 -delete
💡 老运维的血泪: 有次磁盘满了，我用 du -sh * 一层层找，找了 2 小时... 后来才知道 find 可以直接找大文件。
记住: 磁盘满了，先用这个命令：
cd /
du -sh * | sort -rh | head -10
1️⃣1️⃣ grep - 文本搜索（再次出现，因为太重要）
真实场景: 要查某个订单的日志
grep "order_id_12345" *.log # 找订单日志
grep -r "keyword" /var/log/ # 递归搜索
grep -C 5 "error" log # 显示错误前后 5 行
六、系统信息类（4 个）
1️⃣2️⃣ ps - 查看进程
真实场景: 服务卡了，看进程还在不在
ps aux | grep nginx # 找 nginx 进程
ps aux --sort=-%cpu | head # 看 CPU 最高的进程
ps aux --sort=-%mem | head # 看内存最高的进程
💡 老运维的血泪: 有次服务挂了，我 ps aux | grep java，发现进程还在，但实际已经死了（僵尸进程）。后来学会用 jps 看 Java 进程更准。
1️⃣3️⃣ top - 实时监控系统
真实场景: 服务器卡了，看什么在占用资源
top
交互命令:
💡 老运维的血泪: 有次 CPU 100%，我用 top 看到是一个 Java 进程。后来用 top -H -p 看线程，才发现是某个线程死循环。
记住: top 是排查故障的第一步！
1️⃣4️⃣ df - 查看磁盘空间
真实场景: 服务报错"no space left on device"
df -h # 人类可读格式（最常用）
df -i # 看 inode（空间够但无法写入时用）
⚠️ 血泪教训: 有次磁盘空间够，但服务就是写不进去。查了半天，发现是 inode 满了（大量小文件）。
记住: 磁盘报错，先 df -h，再 df -i！
1️⃣5️⃣ du - 查看目录大小
真实场景: 磁盘满了，找哪个目录占空间
du -sh * | sort -rh | head -10 # 找最大的 10 个目录
💡 老运维的血泪: 有次磁盘满了，我用 ls -lh 看文件大小，结果... 隐藏文件没显示。真正占空间的是 .m2 目录。
记住: du -sh * 比 ls -lh 更准！
七、网络类（3 个）
1️⃣6️⃣ ss / netstat - 查看网络连接
真实场景: 服务访问不了，看端口有没有监听
ss -tunlp | grep 80 # 看 80 端口
ss -tunlp | grep java # 看 Java 进程端口
netstat -tunlp # 老命令，逐渐被 ss 替代
💡 老运维的血泪: 有次服务起不来，报"address already in use"。我用 ss -tunlp | grep 8080 发现端口被占用了... 是昨天测试的进程没关。
1️⃣7️⃣ curl - 测试接口
真实场景: 服务起来了，但不知道能不能用
curl http://localhost:8080/health # 健康检查
curl -I http://localhost:8080 # 只看响应头
curl -X POST -d "json" http://api/test # 测试 POST
💡 老运维的血泪: 有次部署完，我以为服务好了，结果用户说访问不了。后来学会用 curl 先测试，再告诉领导"可以了"。
1️⃣8️⃣ ping - 测试连通性
真实场景: 服务器连不上了
ping baidu.com # 测试外网
ping 192.168.1.1 # 测试内网
ping -c 4 baidu.com # 只 ping 4 次
八、权限类（2 个）
1️⃣9️⃣ chmod - 修改权限
真实场景: 脚本执行不了，报"permission denied"
chmod +x script.sh # 添加执行权限
chmod 755 directory # 目录权限
chmod 644 file # 文件权限
⚠️ 血泪教训: 有次服务启动失败，查了 3 小时，最后是配置文件权限不对（600，服务读取不了）。
记住: 服务启动失败，先查权限！
2️⃣0️⃣ chown - 修改所有者
真实场景: 服务说"permission denied"，但权限是对的
chown nginx:nginx /var/log/nginx # 修改所有者
chown -R www:www /var/www # 递归修改
💡 老运维的血泪: 有次 Nginx 报错，我查了半天，发现日志目录的所有者是 root，Nginx 用户写不进去...
记住: 权限对了但还报错，查所有者！
九、组合拳实战（这才是真功夫）
🎯 场景 1: 凌晨 3 点，服务器报警
# 1. 先看什么占用资源
top
# 2. 发现 CPU 高，看哪个进程
ps aux --sort=-%cpu | head
# 3. 看进程日志
tail -f /var/log/app.log | grep "error"
# 4. 磁盘也满了？找大文件
du -sh * | sort -rh | head -10
# 5. 清理日志
find /var/log -name "*.log" -mtime +30 -delete
🎯 场景 2: 服务访问不了
# 1. 服务进程在不在
ps aux | grep nginx
# 2. 端口有没有监听
ss -tunlp | grep 80
# 3. 防火墙有没有开放
firewall-cmd --list-ports
# 4. 测试本地访问
curl http://localhost:80
# 5. 看日志
tail -f /var/log/nginx/error.log
🎯 场景 3: 磁盘满了，紧急清理
# 1. 看哪个分区满
df -h
# 2. 找大目录
cd /
du -sh * | sort -rh | head -10
# 3. 找大文件
find / -type f -size +500M -exec ls -lh {} \;
# 4. 清理日志
find /var/log -name "*.log" -mtime +30 -delete
# 5. 清理缓存
rm -rf /tmp/*
十、我的学习建议
1. 别死记硬背
我第一次学的时候，把命令抄在小本子上，天天背... 然并卵。
正确方法:
2. 建立自己的命令库
我现在有个笔记软件，里面全是命令：
## 磁盘满了
du -sh * | sort -rh | head -10
find / -type f -size +500M
## CPU 高了
top
ps aux --sort=-%cpu | head
## 日志报错
tail -f log | grep error
用的时候直接复制，省时省力。
3. 善用 Tab 键
别硬打命令，用 Tab 自动补全：
4. 学会看帮助
man ls # 详细手册
ls --help # 快速帮助
tldr ls # 简化版（推荐！）
强烈推荐安装 tldr:
# CentOS
yum install tldr
# 使用
tldr tar # 比 man 简洁太多
十一、写在最后
回到开头那个夜晚。
那一夜之后，我逼自己学了这 20 个命令。
后来，我还是会接到凌晨 3 点的电话。
但现在，我能在 5 分钟内定位问题，30 分钟内解决。
因为我知道，这 20 个命令，能救我的命。
📌 关注公众号【运维打怪日记】
- - 回复【加群】加入运维技术交流群（500+ 运维同行）
下期预告: 《凌晨 4 点，CPU 100%：一次真实的故障排查》
作者：运维老兵 | 10 年运维经验 | 踩过所有坑 本文首发自公众号【运维打怪日记】转载请注明出处
