场景：一台运行Java应用（例如Kubernetes工作节点）的生产Linux服务器突然出现高CPU负载（平均负载超过CPU核心数的4倍）。用户报告响应缓慢和超时。监控系统（如Prometheus + Alertmanager）触发告警。
症状： - 平均负载高：uptime显示负载 > 8（4核机器） - CPU使用率高：top显示us或sy超过90% - 应用响应延迟飙升 - 上下文切换可能增加：vmstat显示cs > 10000
诊断：
1. 检查整体系统状况：top（按CPU排序），htop查看每个核心视图。
2. 识别问题进程：ps aux --sort=-%cpu | head -5
3. 深入分析：strace -c -p <PID>查看系统调用计数，或strace -T -p <PID>查看耗时。
4. 使用perf top查看热点函数。
5. 检查是否内核相关：vmstat 1关注高sy；mpstat -P ALL 1查看每个CPU的分解。
6. 对于Java应用，使用jstack或jcmd抓取线程转储，并用FastThread等工具分析。
命令：
# 快速评估
uptime
top -b -n1 | head -20
# 查找CPU消耗最高的进程
ps aux --sort=-%cpu | head -10
# 监控系统统计
vmstat 1 5
mpstat -P ALL 1 5
# 分析特定进程
sudo strace -c -p <PID> # 运行10秒后Ctrl+C
sudo perf top -p <PID> # 实时分析
# Java线程转储
jstack <PID> > threaddump.txt
风险控制：
- 切勿在未了解进程角色时杀死进程。如果关键服务，考虑优雅重启。
- 谨慎使用strace：可能会减慢进程。限制持续时间（例如strace -c -p <PID> & sleep 10; kill %1）。
- 确保使用sudo运行perf，注意性能影响。
- 对于Java，在强制重启前确保有适当的日志和堆转储设置。
回滚：
- 如果问题始于最近的部署或配置更改，回滚该更改。
- 重启服务：systemctl restart <service> 或 kubectl rollout restart deployment/<name>。
- 必要时临时增加副本以分散负载。
- 如果系统或内核层面问题，考虑重启到已知良好的内核版本。
验证： - 修复后，检查uptime和top确认负载降低。 - 通过端点或监控仪表板验证应用健康。 - 运行一些测试事务确保响应时间正常。 - 监控15-30分钟以防复发。
何时提交OpsGlobal工单： - 尽管彻底诊断但根因不明确。 - 应用标准回滚后问题仍然存在。 - 需要内核级调优（如调度器、IRQ平衡）。 - 怀疑内存泄漏或硬件问题。 - 任何时候需要第二双眼睛或24/7覆盖。
适用场景
适合正在处理 DevOps、Linux, SRE, 故障排除 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
本文通过一个实际场景，详细介绍了 Linux 生产服务器出现高 CPU 负载时的排查步骤，包括症状识别、诊断命令、风险控制、回滚策略以及何时升级到 OpsGlobal。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。