“业务崩了！”“用户全在投诉！”——作为运维人，宕机应急就像家常便饭，但每延迟 1 分钟恢复，都可能造成损失。其实不用慌，掌握 “定范围 + 分层查” 的核心逻辑，15 分钟就能定位问题、恢复业务！

本文整理一线实战精华，聚焦最实用的排查步骤、命令和案例，新手能直接套用，老手可快速参考。

一、3 分钟应急：先圈范围，不做无用功

排查前别盲目敲命令，先花 3 分钟明确 3 个问题，快速缩小排查半径：

1.   影响谁？：单个用户 / 特定地区 / 全量用户？（地区性问题优先查 CDN / 运营商）

2.   哪块崩？：全站 / 特定模块（支付 / 登录）/ 前端 / 后端？（模块问题聚焦对应服务）

3.   怎么崩？：持续宕机 / 间歇性波动？是否发生在流量高峰 / 版本更新后？（高峰优先查资源，更新后查配置）

举例：仅深圳用户无法下单，1 小时前调整过 CDN → 直接锁定 CDN 区域节点，省一半时间！

二、10 分钟分层排查：6 大维度，逐一突破

按 “网络→系统→应用→数据→外部依赖→安全设备” 顺序排查，不遗漏关键节点，每个维度控制 1-2 分钟实操。

（一）网络层：1 分钟判 “通不通”

核心验证链路和端口，命令直接复制用：

·          服务器连通性：ping -c 4 服务器IP/域名（Request timeout = 不通）

·          路由定位：traceroute 服务器IP（某一跳超时 = 故障节点）

·          端口测试：telnet 服务器IP 端口（如 8080，Connection refused = 端口未开）

·          接口验证：curl -I 接口地址（200 = 正常，4xx/5xx = 异常）

常见问题：防火墙封禁端口、运营商波动 → 临时放行端口或切换备用线路。

（二）系统层：2 分钟查 “够不够”

资源耗尽是宕机头号原因，重点看 CPU / 内存 / 磁盘：

·          CPU / 负载：top（按 P 排序，%CPU>90%= 过载）、uptime（负载值 > CPU 核心数 = 压力大）

·          内存：free -h（available 接近 0 = 内存不足）

·          磁盘：df -h（分区使用率 > 85%= 预警，>95%= 满了）、du -sh /data/*（定位大文件）

·          日志：journalctl -n 100 /var/log/messages（搜 OOM/disk full = 关键报错）

应急处理：杀无用进程（kill -9 进程ID）、清理旧日志（echo "" > 日志文件）。

（三）应用层：2 分钟验 “活不活”

服务异常常报 503，重点查进程 / 端口 / 日志：

·          服务状态：systemctl status 服务名（如 nginx，active = 正常）

·          进程检查：ps -ef | grep 服务名（无结果 = 进程未启动）

·          端口监听：ss -tulnp | grep 端口（无结果 = 端口未监听）

·          日志 / 健康检查：tail -f /var/log/应用.log（搜 ERROR）、curl -v http://localhost:端口/health（UP = 正常）

常见问题：进程崩溃、端口冲突 → 重启服务、释放端口。

（四）数据层：2 分钟看 “撑不撑”

数据库 / Redis 故障直接卡业务，重点查连通性和性能：

·          MySQL：

·          登录测试：mysql -u用户名 -p -hIP（登录失败 = 服务停 / 密码错）

·          阻塞 / 慢查询：mysql -e "show full processlist;"（Locked = 阻塞，时间 > 60s = 慢查询）

·          Redis：

·          连通性：redis-cli -h IP ping（PONG = 正常）

·          慢日志：redis-cli -h IP slowlog get 5（定位慢命令）

应急处理：杀阻塞进程（kill 数据库进程ID）、临时扩容 数据库连接 数（set global max_connections=2000）。

（五）外部依赖：1 分钟核 “联不联”

第三方接口 / CDN/DNS 故障易被忽略：

·          第三方 API：curl -I 接口地址（响应超时 / 5xx = 第三方故障）

·          DNS 解析：nslookup 域名（解析错误 IP = 劫持 / 配置错）

·          CDN：curl -v 域名 | grep cache（HIT = 命中，节点故障则刷新缓存）

应急方案：切换备用接口、临时换 DNS（如 223.5.5.5）。

（六）安全设备：1 分钟查 “拦不拦”

报 403 大概率是误拦：

·          防火墙：iptables -L -n（查 DROP 规则）、firewall-cmd --list-ports（确认端口放行）

·          WAF/IPS：联系安全团队查拦截日志 → 临时加白合法 IP / 请求。

三、2 分钟 信息 收集：为复盘留依据

排查时同步收集这些信息，后续复盘更高效：

1.   用户报错截图（含错误码、时间）

2.   系统 / 应用日志关键片段

3.   CPU / 内存 / 磁盘 / 网络监控数据

4.   服务 / 数据库 / 第三方接口状态记录

四、事后关键：3 步避免重复踩坑

1.   根源复盘：明确是资源 / 配置 / 代码 / 第三方问题，划分责任；

2.   监控优化：核心指标（CPU / 连接数 / 接口响应时间）设告警（短信 / 钉钉）；

3.   脚本沉淀：常用排查命令写成脚本（如系统资源检查脚本），一键执行。

总结

宕机排查的核心不是记多少命令，而是 “先定范围，再分层突破”。按本文流程，15 分钟内就能定位 80% 以上的故障。收藏这份指南，下次宕机直接套用，从容解决问题！