今天的一次线上事故产生了一些反思，在此记录一下。

事情是这样的，今天线上服务突然 redis 挂了，然后服务各种报警，这里说下我们对服务异常是有监控报警机制的，然后抓紧时间排查问题，发现 redis 内存满了，然后自动主从切换了，但是这个中间切换是需要一个过程的，而且从节点被选为主节点也是经历一个时间过程的，切换的这个时间间隔就开始疯狂报警，赶紧跟运维同事沟通解决问题，从发现问题到解决中间的这段时间，系统对外提供服务访问都有问题，各个合作服务方都找来了，处理完然后通知各调用方服务已正常，然后持续观察后续还有没有问题。

风平浪静之后，本以为这么就完事了，可观察了一会之后发现虽然没有报警了，可线上业务数据量没了，数据监控图明显下降直逼近0，这可是一个很恐怖的事情，然后赶紧抓服务日志，发现有一个 job 的 key 没有释放导致 job 没有正常退出，被卡之后当然就不能继续进行业务，所以导致数据都卡了，赶紧手动操作删除被锁的 key ，持续观察业务数据量回归正常状态，到此算是松了一口气。

刚放松了一会以后，发现对接的一个渠道又开始疯狂报警，加紧联系对方技术，接着我们把渠道方加入黑暗期，然后等对方紧急修复，他们修复完反馈已正常，我们放开黑暗期试了几单正常，然后开始放量，到此才算是真正的松口气，真是一波三折的一天。

事故反思，数据监控真的太重要了，各种问题都离不开数据监控，由此进一步说明数据太重要了，没有数据就没有对比就无法暴露问题，还有就是数据埋点，埋点埋的好，问题就能直观明了的被发现。

我们目前做的好的点，监控比较完善，redis 满了之后服务监控立即监控到了状态异常，问题及时得到了解决。后面 job 卡数据也是监控图直观体现出来的，明显数据量曲线图陡降，问题直接暴露了出来。

做的不好的点，job 被卡之后需要手动删除数据，这个是有风险点的，比如，如果在上下班路上手边没有电脑就做不了这个操作，也就是说要一直卡主业务，后果还挺严重，这也是暴露出的一个很重要的需要优化的点。发现问题，后面就想办法优化解决，不断优化不断完善。

然后还想再说一句，其实人和系统一样，不对外暴露问题，就没有明确的需要优化的方向，希望我们多自省，向上生长。