凌晨两点，监控面板跳出一条CPU使用率突破九成的告警。不少运维同行的第一冲动是直接重启机器，觉得这样最省事。但这个动作背后藏着不小的隐患：重启会把现场一并抹掉，进程清单、连接状态、临时日志统统归零，真正的原因还没浮出水面就被掩盖了。更棘手的是，如果这台机器正处在业务高峰前的预热阶段，重启反而会打乱原有的节奏。更稳妥的路径是先连上去看一眼，把吃CPU的进程归归类，再判断该不该动手。
别只盯一个百分比，先看整体负载
告警里的CPU数字只是敲门砖，不是最终答案。先用top或uptime读取三个时间维度的平均负载：1分钟、5分钟、15分钟。如果三个值齐刷刷偏高，说明压力是持续性的；如果只有1分钟飙高，5分钟和15分钟都正常，那更可能是一次短时脉冲，比如某个定时任务刚刚跑完。接下来要分辨是单个进程占满了一个核心，还是多个进程在互相争抢。单进程跑满通常指向某个程序的内部逻辑，多进程争抢则更可能是并发量上涨或资源分配不合理。
按四类进程逐一过筛
第一类是业务进程。网站主程序、接口服务、数据库连接池都在这个范围。看进程名、启动用户、运行时长，判断最近是否发过新版本。如果某个业务进程的CPU占用明显高于平日，先去翻它的日志，看有没有报错循环或死循环。
第二类是计划任务。备份、日志切割、数据同步、缓存刷新都容易在固定时间点集中消耗CPU。用crontab列表对照当前时间，确认是否有任务正在跑。这类占用往往有规律，过了时间点会自行回落。
第三类是外部请求。爬虫、恶意扫描、突发流量都会让Web服务进程的CPU升高。查看当前连接数和请求来源，如果某个IP或某个接口的请求量异常集中，可以先在防火墙或反向代理层做限流。
第四类是系统服务。数据库、缓存、消息队列、监控代理都属于这一类。它们通常比较稳定，但如果配置不当或数据量增长，也会逐渐吃满CPU。看它们的慢查询日志和连接数，比直接重启更有用。
常见误判：正常任务被当成异常
不少CPU告警其实来自正常操作。比如凌晨的数据库全量备份，压缩过程会短暂占满CPU；日志切割时如果单个文件很大，切割和压缩也会拉高占用。这类任务的特点是时间固定、持续时间可预期、结束后自动恢复。遇到这种情况，不需要处理进程，而是应该调整任务时间或限制任务使用的CPU核数，避免它和业务高峰重叠。
处理顺序与临时降级
确认是异常占用后，处理顺序建议是：先限流，再降级，最后才考虑重启单个进程。限流可以在反向代理层做，把异常来源挡在外面；降级可以暂时关闭非核心功能，比如推荐模块或统计上报，把CPU让给主流程。如果必须重启某个进程，优先重启单个业务进程，不要重启整台服务器。重启前先记录进程ID、启动参数和当前连接数，方便事后对比。
事后复盘补什么
问题解决后，复盘重点不是写一份报告，而是补两个东西。一是监控阈值，把CPU告警从单一百分比改成结合负载和进程数的复合条件，减少误报。二是进程白名单，把已知的正常高CPU任务标记出来，告警时自动排除或降低优先级。这样下次再收到告警，就能更快判断是正常波动还是真实故障。
it数运在网站维护服务中通常会把这类排查步骤整理成检查清单，让值班人员按顺序执行，避免一上来就重启。技术有章法，服务有回应，处理CPU告警也一样，先分清进程类型，再决定动作，线上访问才能稳得住。
