事故概略
直播前十分钟微信应推送相关开课提醒,至时间后未提醒,后连续收到三次开课通知,点击连接后无法进入直播系统小程序,整体504;
处理方式
检查服务器出入网带宽情况,发现入网带宽瞬时4M,出网带宽正常,mysqld服务器占用CPU 130%左右,重启mysqld后占用依旧保持,考虑跳转链接直接至保利威视平台,跳过学习系统,修改完毕后用户访问正常。
环节复盘
8:50 报未收到开课提醒
8:55 相关人员手动点击发送通知
8:56 服务器处理中未及时响应,遂相关人员再次点击两次发送通知
8:57 微信部分用户收到开课提醒,但链接无法调准
8:58 检查服务器负载,mysqld占用130%,入网4M,其余正常
9:00 重启mysqld服务,重启后依旧占用高,考虑有轮询请求一直访问未停
9:10 程序层面修改跳转链接直接至保利威视平台
9:11 用户访问正常
9:12 相关人员复盘各环节点
环节问题
测试环节
为保证直播正常,10月23日进行了服务器的带宽压力测试,出网带宽有明显瓶颈,预备临时升级50M出网,环节中并发设置为2000,按测试换算率等同在线1W左右,但无法测试mysql性能瓶颈。
通知环节
因未知因素,相关人员修改直播课程发送通知时间至10月20日,导致相关通知并未发出。
操作人员点击发送通知后因服务器处理需要时间,认为未发送成功,遂连续点击两次,导致短时间内微信服务器对学习平台服务器产生1W以上并发,且程序环节逻辑存在数据库读写环节,导致服务器mysqld占用高。
技术环节
相关人员处理问题时未及时采取有效措施,导致错过最佳时间点,造成了影响。
经验教训
测试流程应更加完善和全面。
应形成突发问题解决预案。
相关开发环节中对于突发流量的处理经验不足,要提升高并发处理能力。
硬件投入过低,2核4G单服务器,缺乏容灾多活手段。