嘿，朋友。此刻你大概正盯着监控屏幕发呆，或者手机不停地震动，心里只有一个念头：“完了，服务挂了。”
别急，深呼吸。我是你的老伙计，一个在服务器机房里摸爬滚打多年的“老中医”。今天我不跟你讲那些晦涩难懂的运维理论，我们就当成是在修一辆抛锚的车，一步步来。AlmaLinux 作为目前最稳得住、最像 RHEL 兄弟的发行版之一，它的排查逻辑其实非常有迹可循。只要掌握了这套流程，90% 的故障你都能自己救回来。
第一阶段：急诊室——确认现场，别乱动
当警报响起，第一反应往往是冲向键盘疯狂敲命令。停！先看看“病人”还有没有气息。
1.1 远程连接还能通吗？
如果这是你的生产服务器，首先尝试 SSH 登录。
- 能登录：太好了，系统内核没崩，只是某个服务（比如 Nginx、MySQL 或 SSH 本身）挂掉了。这时候你是安全的，可以继续排查。
- 不能登录，但 IP 能 ping 通：可能是 SSH 服务挂了，或者网络配置有问题。这时候试试带外管理（BMC/iDRAC/ILO）。如果你用的是云服务商（如阿里云、AWS、腾讯云），控制台通常有个“VNC 远程连接”或者“实例连接”功能。
- 完全无响应：内核 panic、硬件故障、或者资源耗尽（CPU/MEM 100% 且无法分配）。这时候可能需要重启，但在那之前，看看云控制台的截图，有没有任何错误信息？
1.2 检查资源“生命体征”
登录成功后，别急着查日志，先看资源。很多时候，服务中断是因为资源被挤爆了。
# 一眼看清 CPU 负载和内存使用情况
top
# 或者用更友好的 htop（如果装了的话）
htop
# 查看磁盘空间，特别是 / 和 /var 分区
df -h
# 查看 inode 使用率，有时候文件没满，但小文件太多撑爆 inode 也会导致写入失败
df -i
# 查看内存交换分区压力
free -h
真实案例：有一次客户找我，说网站打不开。我上去一看，磁盘空间 100%，/var/log 下面有个日志文件因为程序 bug 一路写到了 50GB。这时候重启服务没用，得先删日志腾出空间，服务才能起来。
第二阶段：刑侦科——挖掘日志，寻找真相
AlmaLinux 使用 journald 作为主要的日志管理系统，所有的系统日志、服务日志都可以通过 journalctl 命令查询。这是你最强大的武器。
2.1 先看最近的错误
# 查看系统启动以来的所有日志，重点看红色的错误
journalctl -p err --no-pager
# 只看今天的日志
journalctl --since today --no-pager
# 查看内核消息，这里会有硬件报错、OOM（内存溢出） killer 等信息
dmesg | grep -i error
dmesg | grep -i fail
dmesg | grep -i oom
重点观察：
- OOM Killer：如果你看到
Out of memory: Killed process，说明某个进程吃光了内存，系统被迫杀掉了它。这可能是你的应用有内存泄漏，也可能是内存太小。 - Hardware Error：看到
mce: [Hardware Error]，那可能是内存条坏了，或者 CPU 有问题。 - Disk I/O Error：看到
I/O error，硬盘可能快挂了。
2.2 针对性查看具体服务日志
如果你知道是哪个服务挂了（比如 Nginx），那就单独看它的日志。
# 查看 Nginx 服务的所有日志
journalctl -u nginx --no-pager
# 查看 MySQL/MariaDB 的错误日志（通常不在 journald 里，而是在文件里）
cat /var/log/mariadb/mariadb.log | tail -n 50
# 或者
cat /var/log/mysql/error.log | tail -n 50
# 查看 SSH 服务日志
journalctl -u sshd --no-pager
2.3 历史日志回溯
有时候问题发生在几个小时甚至昨天，但服务是现在才挂的。
# 查看上一次启动的日志（如果系统重启过）
journalctl -b -1 --no-pager
# 查看指定时间段的日志
journalctl --since "2023-10-27 10:00:00" --until "2023-10-27 11:00:00" --no-pager
第三阶段：病理分析——常见故障类型及对策
日志看完了，你大概能猜出个所以然了。下面我列举几种最常见的“病症”及“药方”。
3.1 服务无法启动：依赖缺失或配置错误
症状：systemctl start nginx 报错，或者启动后立即退出。
排查：
# 查看服务状态详情，包括失败的返回值
systemctl status nginx
# 尝试手动运行服务，看看具体报什么错（以 nginx 为例）
nginx -t
# 这会直接告诉你配置文件哪一行错了
真实案例：有一次客户升级了 SSL 证书，结果 Nginx 启动失败。nginx -t 显示 SSL: error:02001002:system library:fopen:No such file or directory。原来是他把证书文件路径改错了，而且没重启 Nginx 后重新加载配置。
3.2 系统卡顿：负载过高
症状：top 显示 load average 远高于 CPU 核数，top 里某个进程 CPU 占用 100%。
排查：
# 找出占用 CPU 最高的进程
ps aux --sort=-%cpu | head -n 10
# 找出占用内存最高的进程
ps aux --sort=-%mem | head -n 10
# 如果是 I/O 等待高，用 iostat 查看
iostat -xz 1 5
对策：
- 如果是正常业务峰值，考虑扩容或优化代码。
- 如果是异常进程（如死循环的脚本），
kill掉它。 - 警惕
stress、cryptominer等未知进程，可能是中了挖矿病毒。
3.3 磁盘问题：空间满或坏道
症状：写入失败，服务报错 No space left on device。
排查：
# 查找大文件
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null
# 查找占用空间最多的目录（从根目录开始）
du -sh /* | sort -hr
对策：
- 清理日志文件：
journalctl --vacuum-time=3d（只保留最近3天的日志） - 清理 yum 缓存：
yum clean all - 如果有旧的内核没用到，可以清理：
package-cleanup --oldkernels --count=2
3.4 网络连接问题
症状：服务启动了，但外部连不上，或者内部服务间调用失败。
排查：
# 查看端口监听情况
ss -tlnp
netstat -tlnp
# 测试本地端口是否通畅
curl -I http://127.0.0.1:80
curl -I http://127.0.0.1:3306
# 查看防火墙状态
firewall-cmd --state
iptables -L -n -v
# 查看网络连接数，有没有大量 TIME_WAIT 或 ESTABLISHED
ss -s
真实案例：有一次客户的网站打不开，curl 本地通，外部不通。查 firewall-cmd 发现端口 80 和 443 没有开放。原因是之前的运维修改了防火墙规则后忘记重新开放。
第四阶段：急救措施——重启与恢复
如果排查后发现服务确实救不活，或者系统处于不稳定状态，重启是最后的救命稻草。
4.1 优雅重启服务
# 重启单个服务
systemctl restart nginx
systemctl restart mysql
# 重启后检查状态
systemctl status nginx
4.2 系统重启
注意：在生产环境重启前，务必确认是否有重要数据未同步，或者是否有用户在操作。如果可以，先发个公告。
# 立即重启
reboot
# 或者更温和一点，给5分钟警告
shutdown -r +5 "System rebooting for maintenance"
4.3 重启后验证
系统起来后，别急着走。
# 检查所有关键服务是否自动启动
systemctl list-units --type=service --state=running | grep -E 'nginx|mysql|ssh|docker'
# 再次检查资源使用情况
top
df -h
第五阶段：预防复发——建立监控与备份机制
修好了一次，下次怎么办？真正的专家不会只当“消防员”，更要当“建筑师”。
5.1 启用监控告警
- Zabbix / Prometheus + Grafana：搭建专业的监控平台，监控 CPU、内存、磁盘、网络、服务状态。
- 简单方案：使用
checkmk或者云厂商自带的云监控，设置阈值告警（比如 CPU > 80% 持续5分钟告警）。
5.2 定期日志轮转与清理
确保你的日志轮转（logrotate）配置正常，避免日志文件无限增长。
# 检查 logrotate 状态
cat /etc/logrotate.conf
ls -l /etc/logrotate.d/
5.3 备份！备份！备份！
- 配置文件备份：每次修改配置前，先备份。可以用
git管理配置文件。 - 系统备份：使用
rsync或tar定期打包重要目录，或者使用专业的备份工具如BorgBackup、Restic。 - 快照：如果是云服务器，定期创建系统盘快照。
5.4 编写故障排查手册
把这次排查的过程，整理成一篇文档，放进团队的 Wiki 里。下次再遇到类似问题，新人也能按图索骥。
写在最后
服务器故障并不可怕，可怕的是慌乱和无序。AlmaLinux 作为一个稳定、安全的操作系统，只要掌握了正确的排查思路，你完全可以从容应对。
记住这个流程：
- 看状态（资源、连接）
- 查日志（journald、dmesg、服务日志）
- 定问题（配置、资源、依赖、硬件）
- 做急救（重启服务、系统）
- 防复发（监控、备份、文档）
希望这份指南能帮到你。如果在排查过程中遇到具体的报错信息，欢迎把日志贴出来，我们一起分析。服务器是你的战场，保护好它，就是保护你的业务。
加油，运维人！