业务突发宕机是运维工作中最具挑战性的场景之一。面对“服务不可用”的警报和用户反馈，一套清晰、高效的排查思路往往比记住大量命令更为关键。本文将分享一套以“定范围、分层查”为核心的标准化排查流程，结合一线实战经验总结的命令与步骤，旨在帮助运维工程师在15分钟内完成问题初步定位与应急处理。
一、快速响应：3分钟界定问题范围
在动手敲命令前，花几分钟回答以下三个问题，能帮你迅速锁定排查方向，避免盲目操作。
- 影响范围：是单个用户、特定地域还是全体用户？地域性问题应优先排查CDN或本地运营商网络。
- 故障模块：是整站不可用，还是特定功能模块（如支付、登录）故障？模块化问题可直接聚焦对应服务集群。
- 故障特征：是持续性宕机还是间歇性波动？是否伴随流量洪峰或近期发布过变更？高峰期的故障常指向资源瓶颈，变更后的问题则可能与配置或代码相关。
示例：若仅有深圳地区的用户反馈下单失败，且一小时内曾调整过CDN配置，则应优先检查CDN在深圳区域的节点状态，从而节省大量排查时间。
二、分层排查法：10分钟逐层定位
遵循从外到内、从基础设施到应用的排查顺序，可以有效覆盖所有关键环节。建议为每个层次分配1-2分钟进行快速验证。
1. 网络层：验证基础连通性
核心目标是确认服务端网络可访问，端口已监听。
- 服务器连通性：
ping -c 4 目标IP或域名 (请求超时则网络不通)
- 路由追踪：
traceroute 目标IP (查看在哪一跳出现超时，定位故障节点)
- 端口可达性：
telnet 目标IP 端口号 (如 8080，连接被拒绝则端口未开放)
- 接口状态：
curl -I http://API地址 (返回200为正常，4xx/5xx为异常)
常见原因与处置：防火墙规则误禁、运营商网络抖动。可临时放行端口或切换备用网络线路。
2. 系统层：检查资源瓶颈
资源耗尽是导致服务宕机的常见原因，需快速检查CPU、内存、磁盘。
- CPU与负载：
top (按P键按CPU排序，%CPU持续>90%视为过载)，uptime (1/5/15分钟负载值若持续高于CPU核心数，则系统压力大)
- 内存使用：
free -h (查看available字段，若接近0则内存严重不足)
- 磁盘空间：
df -h (任何分区使用率>85%需警惕，>95%可能已影响服务)，du -sh /data/* (定位占用空间过大的目录或文件)
- 系统日志：
journalctl -n 100 或 tail -100 /var/log/messages (搜索 OOM、disk full 等关键错误)
应急操作：终止非关键进程(kill -9 PID)，清理过期日志文件(echo ““ > 日志文件)。高效的系统监控与告警能在此环节发挥巨大作用。
3. 应用层：验证服务健康度
服务异常常表现为502/503错误，重点检查进程、端口及自身日志。
- 服务状态：
systemctl status 服务名 (如 nginx，状态应为 active (running))
- 进程检查：
ps -ef | grep 服务名 (无结果则进程未运行)
- 端口监听：
ss -tulnp | grep :端口号 (无结果说明服务未监听该端口)
- 应用日志与健康检查：
tail -f /var/log/应用名.log (实时追踪ERROR级别日志)，curl http://localhost:端口/actuator/health (UP为健康)
常见原因与处置：进程崩溃、端口被占用。可尝试重启服务或释放被占用的端口。
4. 数据层：确认存储服务状态
数据库或缓存中间件故障会直接导致业务停滞。
- MySQL：
- 连通性测试：
mysql -u用户名 -p密码 -h 主机IP -e “select 1;”
- 查看进程与慢查询：
mysql -e “show full processlist;” (关注State为Locked的阻塞进程和执行时间过长的查询)
- Redis：
- 连通性测试：
redis-cli -h 主机IP ping (返回PONG为正常)
- 检查慢日志：
redis-cli -h 主机IP slowlog get 5 (获取最近5条慢命令)
应急操作：在评估影响后，可终止导致阻塞的数据库会话(kill 会话ID)，或临时调大连接数上限(set global max_connections=2000;)。
5. 外部依赖：排查第三方服务
调用第三方API、CDN或DNS解析故障常被忽略。
- 第三方接口：
curl -m 5 -I 第三方API地址 (5秒内无响应或返回5xx，可初步判断为对方服务异常)
- DNS解析：
nslookup 目标域名 (检查解析出的IP是否正确，错误IP可能指向劫持或配置错误)
- CDN缓存：
curl -v 静态资源URL 2>&1 | grep -i cache (观察缓存命中状态，节点故障时可联系CDN服务商刷新缓存)
应急方案：如有备用接口可暂时切换，或临时修改本地DNS服务器为公共DNS(如223.5.5.5)。
6. 安全设备：确认是否存在误拦截
若错误码为403，需考虑安全策略的误拦截。
- 防火墙规则：
iptables -L -n -v (查看是否有DROP规则命中)，firewall-cmd --list-ports (确认端口已放行)
- WAF/IPS：联系安全团队查看安全设备的拦截日志，临时将合法业务IP加入白名单。
三、信息收集：为事后复盘做准备
在排查过程中，应有意识地同步收集以下信息，以便后续进行根因分析：
- 用户端的完整错误截图（含错误码、时间戳）。
- 系统、应用日志中的关键错误片段。
- 故障时间点前后的服务器监控数据（CPU、内存、磁盘IO、网络流量）。
- 相关服务（数据库、缓存、依赖接口）的状态快照。
四、故障复盘与优化：避免重蹈覆辙
问题恢复后，以下三步是提升系统韧性的关键：
- 根因分析：明确是资源规划不足、配置错误、代码缺陷还是第三方问题，并明确改进责任。
- 监控加固：为核心业务指标（如接口99分位响应时间、数据库连接数、队列长度）设置更灵敏的告警（集成至钉钉/企业微信等）。
- 工具沉淀：将此次排查中验证有效的命令集，封装成自动化检查脚本，实现一键化运维诊断。
总结
应对业务宕机，关键在于保持清晰的排查逻辑：先界定范围，再按网络、系统、应用、数据、外部依赖、安全设备的顺序分层突破。遵循本指南的步骤，绝大多数常见故障都能在15分钟内得到有效定位和处理。将此流程固化为团队的标准应急响应预案，能极大提升故障恢复效率与团队协同能力。
| 
发表于 8 小时前
|
查看: 1|
回复: 0
