监控面板忽然报警，CPU占用率飙到九成以上，不少运维人员下意识就想重启服务。可CPU升高并不代表系统立刻会崩，先分清它是长时间高负载还是短暂冲高，通常比马上动手更关键。短时峰值也许只是备份任务或日志轮转引起的，持续高负载才更需要留意。
登录服务器之后，别急着翻应用日志。先用系统自带工具查看整体状况，例如top或uptime，确认负载均值是一分钟偏高还是十五分钟也偏高。如果十五分钟均值同样很高，说明压力已经持续了一段时间。接着在top里按CPU排序，找出占用最高的进程，记下它的PID、用户和启动命令。很多情况下，问题就集中在最上面那一两个进程里。
锁定高占用进程后，再区分常见原因。第一类是定时任务集中执行，比如多个备份、同步、统计脚本撞在同一时间段。第二类是日志写入异常，程序报错后疯狂写日志，磁盘和CPU都会被拖累。第三类是访问量突增，可能是推广活动或爬虫集中抓取。第四类是程序死循环或频繁重试，比如连接数据库失败后不断重连。这几类原因的处理方式完全不同，不能一概而论。
排查时建议按顺序来，避免一上来就重启。先看进程列表，确认高占用的是业务进程、数据库进程还是系统进程。再看该进程的线程情况，用top -H或ps确认是哪个线程在消耗。然后看日志，找最近几分钟有没有大量报错或重复请求。接着看网络连接，确认是否有异常来源在频繁访问。最后看定时任务列表，确认是否有任务刚好在这个时间点执行。这套顺序能帮你缩小范围，而不是盲目重启。
有些情况需要先保留现场再处理。比如进程反复崩溃又重启，或者怀疑被入侵、被植入挖矿程序，这时候直接重启会丢掉关键线索。可以先保存进程信息、网络连接和日志片段，再做隔离或限流。日常监控阈值也不要设得太敏感，CPU短时冲到百分之八十可以只记录不告警，持续五分钟超过百分之九十再通知，能减少大量无效打扰。it数运在运维服务中通常会把这类检查步骤整理成固定流程，让值班人员按顺序执行，减少重复沟通。
