一、线上数据状况
卡管空白卡、库存卡、主题卡余额、面值卡余额由于前期系统不稳定、业务流程遗漏等原因造成数据不准确；
业务方诉求：要求每一天卡在各个阶段在每一个人手里面的数量，还有每一天的余额是多少，还要跟订单、
支付、凭证各个系统去核对数据（所有的金额以凭证为主，对不上的数据需要各个系统去分析原因、确认问题）；
需要对齐的数据：
空白卡：期初数量、入库数量、调拨数量、建卡数量、作废数量、盘点数量、期末数量
库存卡：期初数量、调拨数量、建卡数量、作废数量、领入数量、领出数量、换卡数量、发售数量、退售数量、期末数量
主题卡余额：期初余额、消费额、退款金额、清零金额、期末余额
面值卡余额：期初余额、消费额、退款金额、清零金额、期末余额
具体原因和需要解决的问题如下：
1.卡管上线前，将之前老系统的卡移动了新系统，同步初始化了库存卡保管账的初始值，由于数据组在同步数据时业务方还在继续产生售卡、消费等业务，造成了初始化数据不准确；
2.调拨业务数据量大，由于保管账都是异步线程执行，事务未回滚重复点击，导致数据重复累加；
3.主题卡换卡、退领、作废、POS过卡激活、调拨卡业务是新建的卡类型、并拆卡券、赠券、补赠券、面值卡发售等业务逻辑疏漏和相应的BUG造成数据异常；
4.餐饮卡前期修数错误、业务方要求手动改数据库，这种手动修复的数据很难追溯；
5.定时任务不稳定，或是手动触发了多次，造成了数据的重复；
6.管理类型的卡，在其它系统操作，未产生相应的记录；
7.面值卡发售时银行业务异常、硬件异常造成跟支付和订单的数据同步异常；
8.POS卡消费业务BUG产生的数据异常，或数据未同步至卡管；
二、问题的解决思路
1.跟数据组同学确认期初数量和期初金额、根据当日的流水去修复当天的期初数据和期末数据；
2.根据每个业务段的流水去查询保管账的流水，查看流水是否缺失或者流水是否重复，以此已经来修复每个阶段的数据；
3.调拨业务根据流水和错误日志分析定位出问题，修复代码堵住了漏洞；
4.在SQL修复记录中找出餐饮卡修复异常的数据，排查相应的数量和金额；
5.POS过卡激活没有任何记录，且在激活后清空了保管人和保管地点，根据生成日志追溯出每一张卡的参数；
6.零面值的卡用于卡券的赠送和退售等相关业务，没有相关记录，根据单卡追踪和数据库日志分析了每一张卡的流程，确认每一张卡在发售前属于哪一个人手上；
7.删除重复的记录，手动脚本查找前一天期末数据不等于后一天期初的数据，查询每一组异常数据；
8.业务方要求手动修改数据的在remark中有记录数据，查询remark这个字段的记录修复相应的卡；
9.POS端由于用的老接口导致数据未记录，要求POS修复了此问题，然后根据流水和日志分析每一张卡的归属；
10.主题卡余额跟订单和支付跨库查询出了每一笔差异的数据，根据差异数据分析数据同步的问题；
11.面值卡问题根据相应的流水和各系统的数据稽核查询差异数据，并修复漏洞；
三、第一次月结出现的问题和解决思路
1.新开店铺某些业务异常，造成空白卡保管账数据不准确；
解决思路：根据卡类型分析发现是新创建的卡类型，然后查找数据库发现卡类型ID为空，基本就找到了问题；
2.餐饮卡数量异常，原因：前期手动调数修复数据异常导致；
解决思路：根据脚本录分析记每张卡的流向同步修复数据；
3.业务方手动改了数据库的卡类型，造成某些卡数据对不上；
解决思路：根据移动的数据和数据库中每条数据的备注同步修复每个账目下的流水和保管账数据；
4.主题卡余额跟凭证对数遇到了很多异常数据；
解决思路：某些数据是卡余额统计的方式不一致，有些是系统BUG，还有一些是数据同步的问题，
根据每种场景调整对数的逻辑并修复异常数据的BUG；
5.面值卡余额保管账遇到的问题主要是库存卡保管账售卡数据异常导致，同步修复完库存卡保管账后问题解决；
6.信息部提供的报表跟各个系统数据不一致，经分析发现两边数据SQL统计口径不一致导致；
四、第二次月结出现的问题和解决思路
1.库存卡保管账每天有手动去核对数据，异常数据主要是业务逻辑漏洞导致，后续修复了代码基本解决了此问题；
2.主题卡余额跟凭证的核对依旧问题很多，两笔的数据很多对不上，经查发现第二个月期初不等于上一次的结存数据，后续发现是定时任务每天统计的数据覆盖了，且统计口径与报表中的数据不一致，后面修复了定时任务的逻辑，并同步修复了前一天的期末不等于后一天的期初的数据；
3.面值卡余额数据差了很多，跟核算、凭证好几条数据不一致，后续发现是跨店消费的原因，同步修复了代码BUG和异常数据；
4.一次性盘点数据好几十万，导致系统超时又重复点击，导致数据差异很大，后续将盘点改成了异步执行操作；
五、两次月结后续ACTION
1.总结了跟每个系统对接的和数据推送的SQL（包括：消费记录、退款记录、清零记录等），然后将比对SQL放入ADB数据库，每天定时核对，避免了月底大范围修复数据，减少月结的时间和工作量；
2.卡管内部自查，每一个报表和卡金额数据都整理好相应的脚本放入ADB数据库，每天定时跑脚本核对，将不一致的数据导出然后分析原因，查找系统BUG并修复数据，减少月结的时间和工作量；
3.核查各个影响数据的业务场景（前期测试不充分，业务场景考虑不全），修复代码中错误逻辑和遗漏的逻辑；
4.实时关注慢SQL，修复可能影响数据的业务逻辑并优化SQL；
六、总结
主要总结以下几点：
1.线上问题复盘，分析每次出问题的原因，以及如何避免再次发生；
2.设计测试用例非常关键，要覆盖所有的场景，卡管第一次月结就是由于测试场景不全导致遗漏了很多数据；
3.测试力度不够，未考虑数据量及异常情况，正常情况下没问题，生产往往是操作大批量的数据；
4.修数前要分析产生问题的原因，代码可以延期修复，不然同类问题还会重复出现
5.研发人员需求理解不到位，需要跟BA多沟通，不理解的业务要及时问，这样能发现很多对业务理解的盲点
6.线上日志的查看对定位排查问题帮助很大，本次数据修复查询了近一个月的日志，分析卡的流向；
