你遇到过的测试难题（6）记一次xxl-job的故障失败没有重试机制

你遇到过的测试难题（6）记一次xxl-job的故障失败没有重试机制

业务背景

次日凌晨零点开始，获取前一天符合条件的用户，然后将这一部分的用户筛选出来并做好记录
一般都是参加了某活动并达标了的用户；或者是参加某活动送送什么东西之类的

线上故障表现

查询订单记录发现符合条件的用户有1W个，实际记录里面只有100个用户

故障结论

由于其他发版导致失败、延时影响到原有xxl-job的定时器，xxl-job我这就都管他叫定时器吧。

因为定时器在0点的时候就触发，但因为某些原因，业务层面，服务层面，硬件层面，到时失败没有办法正常处理。

因为硬件坏那服务就只一个坏；
业务坏那一定影响客服端，有报错日志，有客户端会反馈。
所有剩下的就是服务端的问题了呀，显然这一次应该就是服务层面，就其他服务的定时器都正常，唯独这一个就挂了。

定时器挂了之后，也没有执行重试，也没有告警

测试过程

只做了功能，点点点，而且在有限的时间里面，根本缺很多边界、异常的思考，确实没有有容灾，容错的考虑。
因为业务为先，功能优先，往往坑就这样来了，挂在活动结束的最后一天。OMG!!!

总结

1.需要在错误中吸收经验
2.了解一下业务的中间件，比如mq，xxl-job的机制
3.测试、开发如何规划容错，容灾，兼容等灾难机制的响应（通常紧急需求，必踩坑）
4.关于告警的设置，如何定义，业务有没有给出一个数来定义，什么时候该告警
5.开发有没有考虑重试的机制，日后有必要对所使用的中间件特性说明清楚

对bug要有敬畏之心，从错误当中积累好经验，提高风险意识！正因如此才有跟多的动力去推动自己学习，虽然功能上面没有问题，但锅还是要背，bug还得修啊，给大家收集了一个难忘的bug