场景 一台生产 Web 服务器（RHEL 8）负载平均值过高（例如 16 核机器上达到 50+），导致响应缓慢和间歇性 503 错误。值班 SRE 需要快速定位问题进程并恢复服务，同时避免停机。
症状
- 负载平均值超过 CPU 核心数
- uptime 显示负载超过阈值
- top 显示某个进程占用超过 90% CPU 或内存
- 应用健康检查间歇性失败
- 新连接超时
诊断
1. 通过堡垒机 SSH 登录服务器。
2. 执行 uptime 确认负载。
3. 执行 top -o %CPU -n 1 找出 CPU 占用最高的进程。
4. 使用 ps aux --sort=-%cpu | head 获取详细信息。
5. 若进程未知，检查 systemctl status <服务> 或 ls -l /proc/<PID>/exe。
6. 使用 strace -p <PID> -c -S time 2>&1 | head -20 查看系统调用概况（若可用，但避免长时间运行）。
7. 检查日志：journalctl -u <服务> --since "5 分钟前"。
8. 确定进程是合法应用还是恶意程序。
命令
# 检查负载
uptime
# 排名进程
top -b -o %CPU -n 1 | head -20
# 进程详细信息
ps -p <PID> -o pid,ppid,user,%cpu,%mem,cmd,etime
# 检查打开的文件
lsof -p <PID>
# 如果进程僵死，发送 SIGTERM
kill -TERM <PID>
# 若无响应，最后手段使用 SIGKILL
kill -KILL <PID>
# 重启服务
systemctl restart <服务>
风险控制
- 切勿未识别进程就杀死。
- 优先使用 SIGTERM（15），再考虑 SIGKILL（9）。
- 若使用 strace，限制时长（如 -c 汇总模式）。
- 确保有回滚计划（如备份配置、部署工件）。
- 避免执行可能加重负载的命令（例如无限制的 find /）。
回滚
如果杀死的进程是关键服务：
1. 从备份恢复配置：cp /backup/config /etc/service/config
2. 重启服务：systemctl restart service
3. 验证：systemctl status service 并检查应用健康端点。
验证
- 再次运行 uptime，负载应下降。
- 检查 top 确认进程已终止。
- 访问应用健康端点（如 curl http://localhost:8080/health）。
- 监控 5 分钟：watch -n 1 'uptime; ps aux --sort=-%cpu | head -5'。
何时提交 OpsGlobal 工单 - 根本原因不明或问题复发。 - 怀疑内存泄漏或内核 bug。 - 进程属于复杂分布式系统，需要跨团队调查。 - 需要升级给高级 SRE 或基础设施团队。
适用场景
适合正在处理 DevOps、Linux, SRE, Runbook, Troubleshooting 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
一份逐步指南，用于诊断和解决由异常进程导致的 Linux 服务器高 CPU/内存负载问题，包含安全措施和回滚步骤。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。