线上Linux服务故障应按“先止血再查因”流程处理：先确认影响范围并紧急止血，再锁定异常进程与资源瓶颈，接着精准采集现场证据，最后针对常见故障模式速查验证。

线上Linux服务出问题，别慌，按流程快速定位、止损、恢复。核心是“先止血再查因”，优先保障业务可用，再深入分析根因。

一、快速确认影响范围与紧急止血

事故刚发生时，第一反应不是查日志，而是判断“现在谁在受影响”：

• 用 curl -I 或 telnet 测试关键端口（如80、443、数据库端口）是否可连通；
• 检查负载：uptime 看1/5/15分钟load，top 或 htop 观察CPU、内存是否飙高；
• 确认服务状态：systemctl is-active nginx、ss -tlnp | grep :3306 看进程和端口是否存活；
• 若服务已挂，立即尝试重启：systemctl restart nginx（注意：仅限有把握的场景，避免二次震荡）。

二、锁定异常进程与资源瓶颈

服务假死、响应慢、OOM等问题，往往藏在进程或资源层面：

• CPU过高：用 top → Shift+P 排序，记下PID，再执行 ps aux --sort=-%cpu | head -10；
• 内存耗尽：看 free -h 和 dmesg -T | grep -i "killed process" 是否触发OOM killer；
• 磁盘打满：运行 df -h 和 du -sh /var/log/* | sort -hr | head -5 找大日志目录；
• 文件句柄/连接数爆满：lsof -n | wc -l 查总数，lsof -p PID | wc -l 查单进程打开数，对比 cat /proc/sys/fs/file-max。

三、精准采集现场证据，避免误操作覆盖

排查中务必保留原始线索，禁止直接清日志、删临时文件：

• 拷贝关键日志前先打时间戳：cp /var/log/nginx/error.log error.log.$(date +%s)；
• 抓取当前网络连接快照：ss -tulnp > ss_snapshot_$(date +%s).txt；
• 保存进程树和环境：ps auxf > ps_tree_$(date +%s).txt，env > env_snapshot.txt；
• 如怀疑内核或硬件问题，记录 dmesg -T 和 journalctl -b -p 3（错误级别以上）。

四、常见故障模式与速查建议

多数线上问题集中在几类高频场景，可针对性验证：

• DNS解析失败：nslookup api.example.com + cat /etc/resolv.conf，检查是否误配了不可达DNS；
• 证书过期或不匹配：openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates；
• SELinux/AppArmor拦截：临时设为permissive模式测试（setenforce 0），确认后再调整策略；
• 配置热加载失败：Nginx重载后用 nginx -t 验证语法，再 systemctl reload nginx，避免配置错误导致全站宕机。

应急响应不是拼手速，而是靠结构化动作降低决策噪音。每次处理完，把关键命令和判断逻辑记进团队Runbook，下次就能少踩一次坑。

# linux  # sort  # NULL  # dns解析失败  # dns  # curl  # ssl  # 端口  # app  # nginx  # date