LinuxSRE故障排除
场景
生产 Linux 服务器突然响应缓慢，监控告警显示 CPU 使用率持续超过 90%。
症状
- SSH 连接缓慢或超时
- 应用程序响应时间增加
top或uptime显示高负载平均值
诊断
- 通过 SSH 连接到服务器，使用备用管理 IP 或带外管理（如 iDRAC）。
- 运行
top -b -n1查看实时进程，按P按 CPU 排序，找出最占用 CPU 的进程。 - 使用
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head确认。 - 检查进程详情：
ls -l /proc/<PID>/exe以及strace -p <PID> -c -S time 2>&1追踪系统调用。 - 使用
perf top进行性能分析（如果已安装）。 - 检查系统日志：
journalctl -u <service> --since "5 minutes ago"。
命令
- 收集进程信息：
ps -p <PID> -o pid,ppid,user,start,etime,%cpu,%mem,cmd - 分析线程：
top -H -p <PID>或ps -L -p <PID> - 获取内存映射：
pmap -x <PID> - 堆栈跟踪：
pstack <PID>或gdb -batch -ex "thread apply all bt" -p <PID> - 使用
nice调整优先级：renice +10 <PID>（降低 CPU 竞争）
风险控制
- 在杀死进程前，确认其是否属于关键业务服务。
- 使用
kill -STOP <PID>暂停进程而非直接终止。 - 如果进程是孤儿或僵尸，检查父进程；必要时重启父服务。
- 对非核心进程使用
systemctl restart <service>而不是直接 kill。 - 避免在高峰时段运行
perf或strace，它们本身会增加开销。
回滚
- 如果误杀了进程，立即重启服务：
systemctl start <service>或手动启动命令。 - 如果调整了优先级却导致其他问题，使用
renice 0 <PID>恢复默认。 - 如果故障转移对集群有影响，切换到备用节点。
验证
- 运行
top确认 CPU 使用率降至正常水平（例如 <50%）。 - 检查应用健康端点：
curl -I http://localhost:8080/health。 - 监控日志确认无新错误：
tail -f /var/log/syslog | grep -i error。 - 在负载测试工具中检查响应时间。
何时提交 OpsGlobal 工单
- 无法确定进程来源或归属。
- 进程反复重启或无法被杀掉（如处于不可中断睡眠 D 状态）。
- 需要回顾代码或内核级别的根本原因分析。
- 补丁或配置更改需要变更管理。
适用场景
适合正在处理 DevOps、Linux, SRE, 故障排除 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
为 SRE 提供的逐步指南，用于诊断和解决生产 Linux 环境中的高 CPU 负载问题，包含安全控制和升级标准。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。