背景

业务主要是通过A系统向B系统写入Kafka，然后B系统消费Kafka 将结果写到Kafka中，A进行消费最终结果。
在整个流程中，A写入Kafka会写入一张 record1表记录，然后在A消费最终结果的时候也记录一张record2表。主要改动的话 只是B系统内进行写入数据，但是没有想到用的同一个Map导致前后的一个变量值String类型转换成Integer类型。导致下游系统解析错误。由于上线后没有感觉会影响到这块，所以差不多3 4个小时后才发现，所以造成比较大的影响。

事故

补救措施：由于日志中有最终消费结果，所以从日志中拉取到最终的结果，然后在生产机器上进行重新推送这波数据。

总结

事前：对于需求 可能的难点 有问题的地方需要全方位的考虑清楚。最笨的方法就是一个案例一个案例过一遍整体的流程。
事中：上线后需要及时观察总体的数据，不能只看改动的地方，这样即使出现问题后，也可以在短时间内找到问题，然后解决，将故障时间缩小到最小范围。
事后：出现问题后，需要及时复盘，影响已经造成 可以从中吸取到一定的教训。