服务器故障排查与恢复如何做

核心是“先稳住、再定位、后修复”，按网络→系统→服务→数据四层推进：先查实例状态与ping/telnet连通性，再用top/df/iostat看资源，结合dmesg/journalctl筛日志，分硬件/系统/应用层归因，最后验证curl/ab/监控闭环。

服务器故障排查与恢复，核心是“先稳住、再定位、后修复”。不能一上来就重启或重装，得按层推进：网络通不通、系统跑不跑、服务起不起、数据丢没丢。每一步都有明确检查项和对应命令，多数问题能在10分钟内锁定根源。

一、先确认连通性与实例状态

这是所有排查的起点。很多“宕机”其实是网络或访问路径问题，不是服务器真死了。

1. 登录云平台控制台，看实例是否显示“运行中”。若为“已停止”或“异常”，直接启动或查看事件日志
2. 本地执行 ping 服务器公网IP，无响应则分两路排查：

   → 本地网络是否正常（ping 8.8.8.8）

   → 云上安全组是否放行ICMP（即ping协议），以及SSH/HTTP等业务端口

3. 若ping通但SSH连不上，用 telnet 公网IP 22 测试端口可达性；不通则重点查安全组、防火墙（sudo iptables -L -n）或VPC路由表

二、进系统查资源与日志

能SSH登录后，别急着重启服务，先看系统有没有“撑不住”。

1. CPU/内存/磁盘三看：

   — top -b -n1 | head -10 快速看CPU和内存占用

   — df -h 查磁盘空间，尤其/var/log和/分区是否满（满则nginx、mysql常静默失败）

   — iostat -x 1 3 看%util是否持续100%，判断I/O瓶颈

2. 关键日志速筛：

   — 系统级错误：dmesg -T | grep -i "error|fail|oom"

   — 服务级报错（如Nginx）：journalctl -u nginx --since "30 minutes ago" | grep -i "error"

   — 应用崩溃痕迹：grep -A5 -B5 "segfault|killed process" /var/log/messages

三、分层定位故障点

根据现象快速归类，避免在无关环节浪费时间：

1. 硬件层问题（突然断电、异响、指示灯报警）：

   — 电源：用ipmitool sensor list | grep -i "power"查电源状态

   — 磁盘：smartctl -a /dev/sda看Reallocated_Sector_Ct、Current_Pending_Sector等关键值

   — RAID：cat /proc/mdstat或mdadm --detail /dev/md0确认是否degraded

2. 系统层问题（无法启动、卡死、反复重启）：

   — 进入救援模式，用fsck -y /dev/sda1修复文件系统

   — 检查内核日志：journalctl -xb | tail -50，找panic或驱动加载失败记录

   — 尝试切换备用内核启动（修改GRUB）

3. 应用层问题（网页打不开、API超时、502/504）：

   — systemctl status 服务名 看状态是否active (running)

   — curl -v http://localhost:端口/health 验证服务自检接口

   — 对Java服务抓堆栈：jstack PID > dump.log，查线程阻塞或死锁

四、恢复与验证有节奏

修复不是终点，验证才是闭环。改完必须测，测完才算完。

1. 临时恢复优先：磁盘满就清理日志、OOM就kill异常进程、配置错就nginx -t校验后重载
2. 数据安全底线：

   — 若涉及数据库或重要文件损坏，先dd if=/dev/sda of=/backup/sda.img bs=1M做原始镜像再操作

   — RAID降级或单盘故障，切勿盲目rebuild，先备份元数据

3. 验证动作要闭环：

   — 网络：从外网curl -I 域名看HTTP状态码

   — 服务：模拟真实请求（如ab -n 100 -c 10 URL）

   — 监控：确认CPU、内存、延迟等指标回归基线，且无新增告警