背景
业务主要是通过A系统向B系统写入Kafka,然后B系统消费Kafka 将结果写到Kafka中,A进行消费最终结果。
在整个流程中,A写入Kafka会写入一张 record1表记录,然后在A消费最终结果的时候也记录一张record2表。主要改动的话 只是B系统内进行写入数据,但是没有想到用的同一个Map导致前后的一个变量值String类型转换成Integer类型。导致下游系统解析错误。由于上线后没有感觉会影响到这块,所以差不多3 4个小时后才发现,所以造成比较大的影响。
事故
补救措施:由于日志中有最终消费结果,所以从日志中拉取到最终的结果,然后在生产机器上进行重新推送这波数据。
总结
事前:对于需求 可能的难点 有问题的地方需要全方位的考虑清楚。最笨的方法就是一个案例一个案例过一遍整体的流程。
事中:上线后需要及时观察总体的数据,不能只看改动的地方,这样即使出现问题后,也可以在短时间内找到问题,然后解决,将故障时间缩小到最小范围。
事后:出现问题后,需要及时复盘,影响已经造成 可以从中吸取到一定的教训。
版权归原作者 qxlxi 所有, 如有侵权,请联系我们删除。