重试风暴导致 PM2主进程过载事件

终端上报功能由于模块bug以及不规范变更,导致大量用户接口重试请求,未达到事故级别,未影响核心功能,但造成一定的现网压力。

故障原因:新版本服务存在设计缺陷
当请求量逐步增大时触发过载保护返回 503,但是IOS终端逻辑对503返回码会进行重试
导致服务已经过载情况下继续承受更高的重试请求量,从而更多用户产生更多重试,
形成正反馈,峰值请求达到 50k qps

问题以及可改善点
发布流程问题,没有对变更进行周知
对于发布事件,需要进行统一周知,避免信息不对称从而问题定位缓慢
规范化变更过程,保证现网变更有以下几个节点
计划、通告、灰度、观察、全量、观察、确认结束,回滚方案

PM2(服务进程管理工具)监控缺失
PM 主进程过载,导致无法进行流量分发,因为没有进行分发所以各个模块的实际调用上报数据正常。但是多数请求在 PM2已被拒绝
监控缺失,需要对 pm2 的主进程的状态进行监控补充
PM2 进程监控缺失
对于中台模块,目前已有的业务监控只有在monitor平台的数据和接入层Nginx的日志。遗漏了 主机PM2(服务管理) 进程的上报,模块上报数据与接入层数据不对等,增加故障定位难度

返回码以及重试逻辑
中台与终端未对齐,如 503 不应该进行重试,中台需要与终端同步状态码以及含义,避免非200就进行重试
日志量突增导致的日志延迟
流量突增导致es集群的日志实时性大幅下降,导致无法通过日志及时定位问题。考虑在日志的输入端来对流量进行控制,比如动态随机丢弃,使日志不会突破系统最大容量,保持日志的实时性
缺少现网紧急预案
紧急情况预案不足,在排查问题的同时应该有临时的通用方法来保证服务可用
应及时了解故障模块的现网功能以及重要程度(是否用户可感知,是否影响核心功能)
可否采用柔性服务,比如直接在nginx返回200或者其他假数据缓解真实业务模块压力

留下点什么吧