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

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

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

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

• 登录云平台控制台，看实例是否显示“运行中”。若为“已停止”或“异常”，直接启动或查看事件日志
• 本地执行 ping 服务器公网IP，无响应则分两路排查：
  → 本地网络是否正常（ping 8.8.8.8）
  → 云上安全组是否放行ICMP（即ping协议），以及SSH/HTTP等业务端口
• 若ping通但SSH连不上，用 telnet 公网IP 22 测试端口可达性；不通则重点查安全组、防火墙（sudo iptables -L -n）或VPC路由表

二、进系统查资源与日志

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

宝塔Linux面板11.3.0

宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。

下载

• CPU/内存/磁盘三看：
  — top -b -n1 | head -10 快速看CPU和内存占用
  — df -h 查磁盘空间，尤其/var/log和/分区是否满（满则nginx、mysql常静默失败）
  — iostat -x 1 3 看%util是否持续100%，判断I/O瓶颈
• 关键日志速筛：
  — 系统级错误：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

三、分层定位故障点

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

• 硬件层问题（突然断电、异响、指示灯报警）：
  — 电源：用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
• 系统层问题（无法启动、卡死、反复重启）：
  — 进入救援模式，用fsck -y /dev/sda1修复文件系统
  — 检查内核日志：journalctl -xb | tail -50，找panic或驱动加载失败记录
  — 尝试切换备用内核启动（修改GRUB）
• 应用层问题（网页打不开、API超时、502/504）：
  — systemctl status 服务名 看状态是否active (running)
  — curl -v http://localhost:端口/health 验证服务自检接口
  — 对Java服务抓堆栈：jstack PID > dump.log，查线程阻塞或死锁

四、恢复与验证有节奏

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

• 临时恢复优先：磁盘满就清理日志、OOM就kill异常进程、配置错就nginx -t校验后重载
• 数据安全底线：
  — 若涉及数据库或重要文件损坏，先dd if=/dev/sda of=/backup/sda.img bs=1M做原始镜像再操作
  — RAID降级或单盘故障，切勿盲目rebuild，先备份元数据
• 验证动作要闭环：
  — 网络：从外网curl -I 域名看HTTP状态码
  — 服务：模拟真实请求（如ab -n 100 -c 10 URL）
  — 监控：确认CPU、内存、延迟等指标回归基线，且无新增告警