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

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

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

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

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