解决一个线上bug的全过程

先说下最近的求职历程吧，年初由于疫情爆发，公司经营困难，然后裁员，到现在也过去了2二个月，我也是最近才入职的，这个时间段求职相比以前是很难，给一句忠告，这个时期能不换工作就千万变换了；
这段时间总结来说：没有要求随遇而安的话，也好找；但是想要精挑细选，有点要求那么就比较难了；
那么接下来废话不多说，来说说新公司的新bug吧

bug描述

1.运营描述：已退款的订单确认退款后又产生了一笔新的待发货订单。。。。以下省略一些图片文字等

看到这个描述，我第一下就觉的实际情况不应该是这样，所以就沟通，查询，了解，经过分析，这个bug的最终描述是：
2.这个bug是因为支付宝回调接口没有处理好退款的回调，导致将原来的订单状态改为了待发货状态，并且修改了支付时间等参数，导致让运营误以为产生了两笔订单，实际上还是原来的那笔订单；

解决步骤

1.1 查看订单相关参数

这一步主要是确认订单是否跟运营描述的一样，是否产生了新的订单

1.2 查看日志

这一步主要是查看线上服务日志，这笔订单的相关日志，主要是这笔订单，在这个修改时间范围的订单日志
基本上这一步就可以知道是哪个方法导致的，但是由于我这边日志里面没有打印哪个方法，所以我又去链路追踪服务里面（skywalking）去找到这个调用链，然后确认相关方法；

1.3 继续查询日志

这一步跟上一步的差不多，但是查询的主要是该方法内的日志，由此确定是该方法导致该问题的产生；

1.4 复现这种情况

等到了这一步基本上也知道该bug产生的原因，以及解决办法了。

bug解决

我这里是通过相关参数判断该回调是退款回调，所以不做处理，直接告诉第三方success；

注意

支付宝的回调接口不仅会通知支付成功的回调，同时也会通知退款的回调，我们在处理的时候需要对退款回调也做处理，否则很可能造成其他bug的产生，并且这种问题，一时半会儿不一定能马上找到；但是如果是B2C方式支付的订单，不管是支付还是退款都是不会回调的；