服务器宕机后应先确认是否真宕机，再依次检查系统日志、资源耗尽情况及服务配置变更，最后建立监控预警机制。
服务器宕机后，先别急着重启，关键是要快速定位原因，避免重复发生。以下步骤按优先级和实操性整理，覆盖常见硬件、系统、服务层面问题。
一、确认是否真宕机，还是仅服务不可达
很多“宕机”其实是网络或服务中断，而非系统崩溃：
- 用另一台机器 ping 服务器 IP，看是否响应；不响应再尝试 telnet 或 nc 检查 SSH 端口（如
nc -zv 192.168.1.100 22） - 检查路由器、交换机、防火墙策略，确认没误封 IP 或关闭端口
- 如果是云服务器，登录控制台查看实例状态（如 AWS EC2 的“Instance Status Checks”，阿里云的“系统/实例健康状态”）
- 物理服务器需现场确认：电源指示灯、硬盘灯是否闪烁，是否有异常蜂鸣声
二、检查系统日志（需能登录或挂载磁盘）
若可 SSH 登录或通过救援模式挂载根分区，日志是核心线索：
-
/var/log/messages（CentOS/RHEL）或 /var/log/syslog（Ubuntu/Debian）：搜索关键词
panic、oom-killer、hardware error、segfault - dmesg -T | tail -100：查看内核环缓冲区，重点关注内存不足（OOM）、磁盘 I/O 错误、驱动崩溃、CPU 温度告警
- journalctl -b -1：如果上次启动失败，查上一次 boot 的完整日志（适用于 systemd 系统）
- 特别注意时间戳——宕机前 2~5 分钟的日志往往包含直接诱因
三、排查资源耗尽类问题
内存、CPU、磁盘满是高频原因，尤其在无监控场景下易被忽略：
- 内存：执行
free -h和cat /proc/meminfo | grep -E "MemAvailable|SwapFree"；若 MemAvailable 接近 0 且 OOM Killer 被触发，dmesg通常会打印被 kill 的进程 - CPU：用
top或htop查看负载（load average > CPU 核数 × 3 需警惕），注意%si（软中断）过高可能指向网卡或存储驱动异常 - 磁盘：运行
df -h和df -i（inode 耗尽也会导致服务异常）；lsblk && smartctl -a /dev/sda检查磁盘健康（需安装 smartmontools）
四、检查关键服务与配置变更
人为操作或自动更新常引发连锁故障：
- 确认最近是否执行过
yum update、apt upgrade或内核升级——新内核启动失败会导致黑屏式宕机 - 检查定时任务：
crontab -l和/etc/cron.d/下脚本，是否有清日志、rsync 同步等高 IO 操作 - 验证关键服务状态：
systemctl list-units --state=failed，重点看 sshd、network、systemd-journald 是否异常退出 - 检查 /etc/fstab：新增挂载项配置错误（如 NFS 不可达却设置 _netdev 缺失）可能导致开机卡住
不复杂但容易忽略——每次处理完，建议补上基础监控（如 Prometheus + Node Exporter）和日志轮转策略，把“事后救火”变成“事前预警”。
