服务器负载异常处理全流程：看完就能上手救急

你是不是碰到过这种糟心情况？ 正跟朋友吃火锅呢，或者半夜睡得正香。 公司运维的电话直接炸过来。 说APP/网站崩了，用户已经在评论区骂疯了。 你爬起来登后台一看，服务器负载直接飘红。 满屏的报错信息，你脑子一片空白，不知道先干啥。 别慌，今天给你说的这套流程。 不管你是刚入行的运维，还是要兼管服务器的开发。 看完照着做，10分钟就能稳住局面，还能找到根因。

第一步：先应急止损，保住业务再说

别一上来就死磕找原因，用户等不起。 先把业务恢复了才是第一位。

1. 先摘故障节点，切走流量

要是你有多台服务器扛业务。 哪台负载爆了就先摘哪台。 把上面的流量全部转到正常的服务器上。

举个例子，你有3台服务做负载均衡。 其中1台CPU占满了，直接在负载均衡后台。 把这台的权重改成0就行，10秒就能操作完。

避坑提醒：绝对不要一上来就重启服务器

重启之后所有运行日志、进程信息全没了。 后面想找故障根因根本找不到，下次还会炸。

2. 临时扩容先顶住流量

要是所有服务器负载都爆了。 赶紧去云厂商后台开弹性实例。 按当前流量的1.5倍来扩容，先把流量接住。

哪怕后面峰值过了再释放就行，多花不了几块钱。 总比用户全跑了强得多。

第二步：定位根因，从根源解决问题

业务稳住了，再慢慢找为啥会出问题。 按下面的顺序查，90%的问题半小时内就能找到。

1. 先查三大核心指标

登服务器输个top命令就行：

```top```

按P键，看哪个进程占CPU最高。 按M键，看哪个进程占内存最高。 再输入df -h看磁盘是不是满了。

说白了就是三个点：人脑（CPU）有没有被占满。 办公桌（内存）有没有被堆爆。 找文件的速度（磁盘IO）是不是太慢。

之前我碰到过一次CPU占100%。 查出来是运营偷偷上的抽奖脚本。 写了个死循环，直接把服务器拖垮了。

2. 再查访问日志，看流量是不是正常

如果指标没问题，就去看nginx或者业务的访问日志。 看短时间内的请求量是不是突然涨了。

要是请求全是同一个活动页面的。 那大概率是运营搞活动没提前打招呼，流量突增。 要是请求全是乱七八糟的陌生路径，那就是被CC攻击了，直接封IP就行。

3. 查最近24小时的上线记录

90%的服务器故障，都是新上线的代码搞的。 要是最近有上线新功能、改了配置。 直接回滚到上一个稳定版本，大概率马上就好。

比如之前有个开发写的接口没加缓存。 每次请求都查数据库，直接把数据库拖垮。 连带所有服务器负载都飘红，回滚之后1分钟就恢复了。

第三步：做好防护，下次别再踩坑

故障解决了不算完，要是不做防护。 下次碰到同样的问题，还得半夜爬起来救火。

1. 提前设好告警阈值

别等服务器崩了才知道有问题。 把CPU、内存、磁盘的告警阈值都设好。 比如CPU到70%就发消息告警，到80%直接打电话提醒。

避坑提醒：阈值别设太高

要是你设成CPU到95%才告警。 等你看到消息的时候，服务器已经崩了，根本来不及反应。

2. 核心接口加限流降级

像秒杀、抽奖、下单这种容易爆的接口。 提前设好最大请求数，超过阈值就直接返回“稍后再试”。

宁愿少部分用户用不了，也比所有用户全崩了强。 这个配置开发10分钟就能加上，性价比极高。

3. 定期清理服务器垃圾

很多人容易忽略这点，日志、临时文件堆一年都不删。 哪天磁盘占满了，服务器直接挂，连日志都写不进去。

设个定时脚本，每周自动清理7天前的日志。 每次上线前清一遍临时缓存，省得后面出幺蛾子。

下次再碰到服务器负载异常的情况。 别慌，就按这个顺序来：先切流量扩容稳住业务。 再按步骤查指标、日志、上线记录找原因。 最后把告警、限流、清理的防护措施补上。

现在就打开你家服务器的监控后台。 看看告警阈值有没有设对，最近的日志有没有清理。 别等半夜睡得正香的时候，被运维的电话叫起来救火。