线上 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，下次就能少踩一次坑。
