20171024灰度服务器负载超过预警值的故障

事件描述及现象

10月24号在灰度上测试版本功能出现测试环境没有出现的问题；为了排查没有数据的问题，在灰度上部署了打印日志的代码。

本来灰度的机器不上线，抛日志的代码是不会出现负载超越的问题，因为灰度之后不对外网开放，只有内部人员能使用，用户量非常少。

但是在我19：54分的灰度部署之后，

另外一名同事进行了正式发布的操作；

在他操作前我询问过他什么时候是用户高峰期？

他说现在就是。

我说那你还发布？

他没说话。

由于我是第一次上正式环境部署项目，而这位同事在公司也比较久，于是我选择相信有经验同事的选择，一起发布正式环境。

然后在线上看日志。

发布之后20：01分系统发送了机器负载超过预警值的消息；因为发布正式是同事，他和项目组长收到了邮件和短信。大概过了10分钟后，同事说明了收到报警，通知我赶紧回滚项目，有报警。

于是20：12分对项目进行了回滚。警告解除。

事件持续时间

• 从上线10月24号19：54分的灰度部署之后几分钟，到10.24号 20：12号回滚项目解除警报。

事件处理过程

19：54分的灰度部署几分钟以后的正式部署,使得线上出现log很多与用户高峰的流量重叠,造成超负载均衡预警的故障 20：12分回滚旧版本，没有了大量的日志 

处理流程：[编辑]

上线10几分钟之后回滚到原来的版本

事件原因：

1. 问题排查方向换了好几个：开始是缓存，后来是ip，在对应的代码调用中加入了比较多的logger输出，而输出一个module的内容原本就很多。而排查问题的接口正是访问量居高的首页。

　　 2.这时候转正式环境，且没有考察过服务器的流量承载能力，就轻易上线是非常需要反省的态度，上线项目必须谨慎小心。

　　 3.当天的日志流量多是有证可循的，事后下载了24号前后几天的日志进行对比，发现24号的error级别(因为排查问题输出直接用了error)日志输出是平时的将近150倍

正常的日志输出也是平时的5倍，如下图：

影响业务

影响业务：海外应用中心

影响用户数:暂无数据

事件结论

1. 输出日志过多造成服务器流量高峰与用户高峰重叠，回滚没有日志输出的项目版本，削除日志数出的流量，负载超过预警的故障得到解决。
2. 好在在这转正式的十分钟内查到了异常报错的地方，是正式环境与测试环境数据结构不一致造成，后来删除多余的表字段，线上问题得到解决。
3. 这是一次试错，反过来想也是幸运，是一个提醒，最后正式环境多增加了一台服务器，以防止再次出现负载过量的问题。
4. 先找好解决办法再动手。尤其是线上问题在线下不出现的情况, 尤其在项目已经延期的情况下,更加应该保持冷静和镇定,积极查找解决的办法,询问有经验的同事,补充相关的知识盲点,而不是动手就是线上日志,这样非常盲目且效率极差,不是解决问题的最好办法.这次恶劣的影响便是教训.
5. 附上应用商店一天PV峰谷图

发布准备工作可以放在上午，下午 14：00 开始进行灰度验证，16：00左右完成验证就比较完美，最迟不得超过18：00

优化整改措施

1. 从源头上找解决办法, 避免在线上加日志排查问题，三思而后行，上正式环境更是要禁止
2. 优化自己解决问题的方式,切忌盲目而动