线上事故初步复盘记录

事故概略

直播前十分钟微信应推送相关开课提醒，至时间后未提醒，后连续收到三次开课通知，点击连接后无法进入直播系统小程序，整体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单服务器，缺乏容灾多活手段。