快速定位和修复问题是程序员的一项基本功，而只有把问题定位准确，才能有针对性的修复。在程序的世界里，神马都是数据。当数据没有按照预期从源头到达目的地，那一定是中间的某个环节出了问题。搞清楚整个链路的模型（包括各个环节对数据的处理逻辑及它们之间的衔接方式），然后用二分法的思想去不断确认和缩小问题范围，这是通用的方法论。
C系统为何没有收到mq消息呢?
上图是我们系统间数据的流转链路。
前几天有C系统的研发反馈没有收到mq消息（其实也有B系统的运营反馈有数据对不上），此为背景。
这里插一句，任何事物都是有因果关系的。变化的“因”会导致变化的“果”，而变化的“果”一定是变化的“因”导致的。比如, 某块功能一直没有问题, 但最近开始出现问题了, 这就是【变化的“果”】，它一定是【变化的“因”】导致的。但凡有点经验，都会琢磨“是不是最近上线了什么或者调整了什么导致的”。
那么问题该如何排查呢？
显然，C没有收到消息,是不是因为B没有发消息?
如果B发了，问题可能出在MQ2上。
而如果B没发，那么要确认B是否收到了A的消息。
如果B收到了A的消息，那么问题很可能就在B上
如果B没有收到A的消息，那么问题可能出在了A或MQ1上
事实上, 问题就出在了MQ1上，B最近没有收到A的消息。原因是最近MQ1做了机房的迁移，B修改了mq的配置，而A的mq配置忘改了。这也正好印证了【变化的果是由变化的因导致的】这个朴素的道理。
对问题的复盘总结
-
变化的果是由变化的因导致的，在遇到问题时，应该首先基于这种思维去大胆猜测问题发生的原因。
-
刻画的传播链模型要准确。比如图中B有落库操作，开始时以为落库了就证明AB之间的消息传递是正常的，一直在对B的消费逻辑进行debug。但实际上发现A也有落库操作，这个时候应该重新考量MQ1是否正常工作，结果大脑可能有思维惯性，还停留在之前的观念里，误以为问题肯定出在了B系统。都有好记性不如烂笔头，其实不仅仅是记忆可以借助笔，分析问题时如果能多动动笔，也不容易走进思维的误区。
-
强化对二分法思想在定位问题上的运用。它其实也是一种先粗后细的思想。我们走上了一条小路，是因为它所在的大路是正确的。但如果大路都走错了，在小路上徘徊良久，你也找不到答案。
