记一次报表问题排查

2024年12月份某一天，接到财务用户报障，说关税分摊报表数据不对，11月份有一个报关单分摊到明细的金额汇总，超过了报关单的总金额。

由于刚接手这一块业务，对业务不是很熟，就试图找到之前的交接文档。看了看大数据后台任务，发现有10多个，每个任务的代码量非常大。第一天就在看代码、了解业务逻辑中度过，感觉时间过得很快。虽然了解了一些业务，但是问题还是没有解决。只发现了一个问题线索，但是具体原因还是没有定位到。

第二天继续排查问题。找之前交接的同事一起研究，他也发现了一个问题，不过，经过几个小时的思索、重现，发现问题的根源不在此。后用户提醒说，10月份数据没有问题，11月份突然有问题，一共4个单。如果代码层面没有问题，是不是数据的问题？难道数据被人篡改过？带着疑问，我拿出11月份的数据和10月份的数据做对比，果然发现了问题：在单据已经没有业务的情况下，竟然多出了收货数量，而收货数量就是分摊金额的分母。本以为找到问题的根源，结果发现收退货业务表，并没有这些异常数据，那数据从哪里来？

带着疑问，找到之前交接的同事，他经过排查，很快定位到问题根源，是他11月份改了代码逻辑，将PO的父PO的收退货数据合并到子PO来。这个逻辑是一段case when逻辑，隐藏的比较深。

经过这次的问题处理，我总结到一些经验。首先，如果以前一直没有问题，是突然出现的，要先看看代码是否有变更。其次，如果从代码层面找不到问题，要分析一下数据，将异常的数据和以前的正常数据做比较，找到异常的数据，仔细分析。最后，找到问题根源后，及时修复代码。异常数据修复比较危险，如果下次能自动更正过来最好，不要贸然去修复数据，否则会越修复越乱。