故障处理的价值不在"修好"，而在"下次更快修好、甚至不再发生"。这篇复盘三个高频故障的定位思路。
通用排查方法论
确认现象 → 看日志 → 提假设 → 验证 → 定位根因 → 修复 → 预防
别一上来就重启（重启会抹掉现场，根因没找到下次还会复发）。
案例一：磁盘 100%
现象
写入报 “No space left on device”，df -h 显示 100%。
定位
df -h # 确认哪个分区满了
sudo du -sh /* 2>/dev/null | sort -rh | head -20 # 根目录谁占最多
# 逐层下钻，直到找到元凶目录
sudo du -sh /var/log/* | sort -rh | head
三个经典原因
- 日志疯涨：
/var/log下某个日志没切割，无限增长 →logrotate或清空。 - 大文件：备份、临时文件、上传文件堆积。
- 文件删了但没释放空间（最常见陷阱）：
sudo lsof +L1 | grep deleted # 找到"已删除但仍被进程占用"的文件
# 重启对应进程即可释放
磁盘满了，
df和du对不上，基本都是第 3 种情况。
案例二：CPU / 内存飙高
定位 CPU
top # 按 P 排序，看哪个进程占 CPU
ps aux --sort=-%cpu | head
# 定位到进程后，看它是不是死循环/被攻击
sudo strace -p <PID> -c # 概览该进程系统调用（进阶）
定位内存
free -h # 总量/已用/swap
top # 按 M 排序
# 是否 OOM 过（内核日志）
journalctl -k | grep -i oom
内存爆了通常两种结果：OOM 杀进程（journalctl -k 能看到）或 swap 疯狂换页卡死。找到吃内存的进程后，判断是内存泄漏（要修程序/重启）还是业务本身吃得多（要加内存/限流）。
案例三：SSH 连不上
按从外到内排查：
# 1. 网络通不通
ping <服务器IP>
nc -vz <服务器IP> 22
# 2. 本地有没有在监听（在服务器上，或通过 VNC 登录看）
ss -tlnp | grep :22
# 3. 服务起没起
systemctl status sshd
sudo tail -50 /var/log/auth.log
# 4. 是不是被 fail2ban/防火墙封了自己的 IP
sudo fail2ban-client status sshd
sudo ufw status
sudo fail2ban-client set sshd unbanip <你的IP> # 误封时解封
常见原因：安全组没放行 22、改了 sshd_config 语法错/端口错、AllowUsers 没包含自己、fail2ban 误封、密码登录被禁但密钥没配好。
改 SSH 配置前一定保留一个已登录的会话，或先验证新配置能登录，防止把自己锁外面。
复盘模板
每个故障处理完，用一段话记录：
时间 / 现象 / 影响范围
根因
排查过程（关键命令与输出）
修复动作
预防措施（加监控？加备份？改配置？）
坚持写，半年后这就是你最值钱的经验库。
小结
| 故障 | 第一命令 |
|---|---|
| 磁盘满 | df -h + du -sh /* + lsof +L1 |
| CPU 飙高 | top（按 P）+ ps aux --sort=-%cpu |
| 内存爆 | free -h + journalctl -k | grep oom |
| SSH 连不上 | nc -vz + ss -tlnp + systemctl status sshd + 安全组 |
记住：先看现象和日志，再动手；修好只是及格，找到根因并预防才算到位。