Linux SRE生产故障排查实战手册

场景

某电商平台生产环境中的Web服务器（运行Nginx和PHP-FPM）突然出现高CPU负载，用户响应时间从200ms飙升到5秒以上，部分请求超时。

症状

• top显示CPU使用率持续在95%以上，用户态占80%。
• uptime负载平均值超过CPU核心数（16核）的2倍。
• nginx日志出现大量504 Gateway Timeout。
• 应用监控显示PHP-FPM进程数达到最大限制。

诊断步骤

1. 确认资源瓶颈：运行top，按P按CPU排序，发现多个PHP-FPM进程占用CPU高。
2. 抓取进程调用栈：使用strace -p <PID> -c -S time统计系统调用耗时，发现大量epoll_wait和recvfrom。
3. 性能采样分析：perf top -p <PID>查看热点函数，定位到php:--中的execute_ex和Zend引擎函数。
4. 查看慢日志：检查PHP-FPM慢日志slowlog，发现多个请求执行时间超过30秒，均调用外部API。
5. 网络排查：netstat -anp | grep :80统计连接数，发现大量TIME_WAIT，但未达到上限。

使用的命令

# 查看CPU负载
watch -n 1 'ps aux --sort=-%cpu | head -20'

# 追踪进程系统调用
strace -fp $(pgrep -d',' php-fpm) -c -S time 2>&1 | head -30

# 性能热点采样
perf top -p $(pgrep -d',' php-fpm)

# 检查慢日志
tail -f /var/log/php-fpm/slow.log

# 网络连接统计
ss -tan | awk '{print $1}' | sort | uniq -c

风险控制

• 执行诊断前，确认有监控告警以及回滚能力（例如有蓝绿部署或快速重启脚本）。
• 在低峰期进行strace以避免对生产产生额外开销。
• 使用timeout命令限制潜在危险命令的执行时间：timeout 10 strace ...。
• 勿在生产环境直接kill -9进程，优先使用kill -TERM或通过systemd停止服务。

回滚操作

1. 如果问题是由新代码版本引起，立即回滚到上一个稳定版本：git revert <commit> && systemctl restart php-fpm nginx。
2. 如果是外部API超时，临时配置Nginx的proxy_read_timeout从30秒降为5秒，并启用熔断机制。
3. 如果PHP-FPM进程失控，手动杀死所有子进程并重启： bash systemctl stop php-fpm killall -9 php-fpm # 仅在无法正常停止时使用 systemctl start php-fpm

验证

• 使用ab或wrk模拟请求：wrk -t4 -c100 -d30s http://localhost/，观察响应时间和错误率。
• 监控CPU使用率恢复至正常水平（<60%）。
• 检查日志是否不再出现504错误。
• 确认用户反馈延迟回归正常。

何时提交OpsGlobal工单

• 当问题持续超过30分钟且你无法定位根因。
• 当需要跨团队协调（如数据库或网络团队）时。
• 当需要执行高风险操作（如内核参数调整、系统调优）且信心不足时。
• 当生产环境出现数据丢失或服务完全不可用时（立即提交紧急工单）。
• 当你需要事后复盘或需要第二意见来优化runbook时。