一、引子
多年前做的传统项目开发不像现在普遍采用敏捷开发、微服务、中台等完善的开发管理模式和敏捷开发方法；当时项目组为了增强团队年轻活力，引入了一批年轻化团队成员，其中小段同学是我们新招进来的985毕业生。在项目分工过程中，我将交易模块部分功能交给小段开发，其中包括了订单支付、充值提现两个核心关键的功能模块。在开发过程中，也经过了传统项目的几个阶段：需求分析阶段 -> 设计阶段 -> 开发阶段 -> 测试阶段，但也不是很规范，由于没有专门的测试团队，项目功能都是自测开发上线，也因而为此次故障埋下了伏笔。
为了迎接保险行业每年一度的“开门红”，客户要求提前几天发布上线，做好“开门红”前的准备。按照客户强烈要求，我们将程序进行开发打包，应用服务器部署、代理配置等一系列忙碌的操作（都懂不细说），最终将项目发布到了线上。上线后第一天有一百多万的理财产品交易额，因为客户还没有开始全面业务推广，交易少不足为怪；然而到了第二天客户过来说财务对账时发现账目不对，用户支付的钱没到公司账面上，而且还发生了少钱的情况，让赶紧查。于是本文以下从故障现象分析、问题解决、复盘总结三个方面简述这次故障发生的前后分析过程。
二、故障现象及分析
问题发生后，我们先立刻暂时停掉了线上的业务，然后自己在商城从下单（上线时也做过验证）到支付整个环节模拟操作了一遍，并没有发现问题，钱也从银行扣除了；然后再对保单进行充值（追加金额）操作，也可以成功，账户页也显示了充值后的总金额，说明从下单到支付、充值这个过程的功能和数据没有问题，能正常入库，显示也没有问题，再看服务日志也没有明显的异常信息；那问题来了，既然功能和数据都对，钱为什么没有到账呢？
三、问题排查解决过程
既然通过商城界面操作没有发现明显的问题，于是我们只能再对各业务流程环节进一步拆解分析，从各业务流程代码入手，首先从下单支付开始，从前端代码到后台代码逐行代码分析业务流程，并检查商城账户金额，检查数据入库情况，检查各业务系统交互情况，检查银行扣费接口，检查银行账户等等，都没有问题，这个环节可以排除了。
再进行下一充值环节分析，与下单支付检查思路相同，还是先走查业务代码流程，从请求入参、核心系统过程调用、数据入库等代码，再对比下单支付的逻辑时，然而发现充值缺少了调用银行接口的环节代码，由于没有实现对支付代码复用，导致最关键的处理环节流程丢失。根据这个发现进行验证，充值后依次对比商城账户、银行账户，果然发现商城中的金额增加了，而银行中的账户金额并没有减少。
既然充值没有调银行接口，那为什么公司的钱反而变少了呢，我们再对提现功能模块代码检查，发现提现功能又调用了银行接口将钱划拨到用户提现账户，至此问题大白，后续进行了一系列的修复操作，客户（保险公司）通过特珠手段挽回了部分损失，剩下的损失由我们自行承担，付出了昂贵的代价。
然而，好景不长，”屋漏偏逢连夜雨，船迟又遇打头风。“。刚解决这个问题不久，客户又来了，一进来就是：”啊啊啊，怎么又有问题了，理财产品对账结算，用户每天的利息都会少一分钱。“，做过支付的都知道：金额存储通常都是以分为计算存储单位。最不幸的是原来写这块的同事刚离职，于是只能啜啜亲自在客户一顿训斥中进行排查；首先查看数据，通过前端界面数据展示发现利息整数后的两位都是00，总金额不同也都是00，数据库中存储的数据也是00，试了几个账户都一样，就有了初步判断应该是金额转换的代码出现了问题，于是直接定位到处理利息金额的代码，发现以下问题代码：
double jine=Double.parseDouble(interest);
int sum = (int) (jine*100);
以上代码有兴趣的可以试试，看看会发生什么。
至此本次与支付有关的问题全部解决。
四、复盘总结
当时故障处理结束后，也进行了一些复盘总结：从管理方面，由于疏于管理，对于这次故障管理方面有不可推卸的重大责任；后续建立了新老员工一对一师徒制，由师父负责指导带领新人开发业务功能，并code review新人编写的每一行代码；引入了测试团队，提升业务功能测试用例覆盖等措施；从业务方面：加强业务培训，对于关键业务流程进行组织流程评审等；从技术方面：定期组织开发人员技术培训，提高个人开发能力等。
总之，最后送大家也送自己：敬畏每一行代码，敬畏每一份托付！
