问题记录

昨天又有线上问题，而且这次的坑很深，差点爬出不来。
下午三点四十运维群里消息说有个业务客户做的时候一直失败，然后查日志，发现调CA认证的方法返回状态不对，然后咨询CA系统同事，说是方法参数“工单号”，前台传的跟后台传的不一致。然后就让前端同事协助查下那个工单号传的是否为保单号，同时我在确定CA方法的保单号是哪里的，最后确定在调业务第一个页面时，后端会把客户输的保单号存入缓存，此后几个方法使用的都是客户输的保单号。然后跟前端同事确定，前端在调CA加密方法时传的保单号变量值是否改变过，前端同事再三认定，传的保单号没有变过。这时跟CA系统确定是否仅在“工单号”不一致时才返回那个状态码，CA同事确定是的，只有这种情况才是那个状态码。
这时问题就有点棘手了，我们这边确定前后端传的是一致的，CA说不一致。查生产日志，这个业务失败次数不多，日志里有20个左右返回这个状态。然后跟有经验同事求助，同事说让CA系统把加密串解密，看下前端传的是否跟后端一致，然后CA同事等了半小时才回复可以，是他可以查日志了，我们给他的报文，他用不上，只能根据他查出来的日志来分析。而且这个CA同事，问题截图把保单号框出来，但不对截图进行说明，搞得我们一时理解不了他发的什么意思，回过头看他发的信息依然晦涩难懂。这里提一句沟通时的信息一定要简洁明了，把要表示的信息清晰表达出来，不作过多说明，对图片、文件及其中的标注要做必要说明。我们其实也应该早点问他他发的图片之间有什么关系。项目经理怕问了把问题带跑偏就没问。
后续我们分析了数据库里的数据，分析的时候有点跑偏了，还看了其他错。分析结果只分析出有小部分的交易会返回那个状态，而且报运维的那个保单号在做了10多次后交易成功了。同事把焦点放在时间点上，分析那个时间点之间有没有上线，而昨天前端在下午4点多时有过一次上线，从数据库记录里查看，交易是在下午5点17做成功的，那说明跟4点的上线没关系。
最后还是那个有经验的同事通过分析CA同事给的最后一个截图，查那个截图里的两个保单号是否为同一个人名下保单号，结论是同一个人名下，然后他怀疑是小程序缓存导致同一个人用第一个保单号做业务后，继续做第二个保单便会使用缓存中的第一个保单号，进而报错。然后我们确定了下是同一个人的。这时前端同事检查程序发现正如所料，是小程序缓存造成的bug。其实我们在确定是同一个人保单号后，其实应该再查数据库看另一个保单号是否成功。
最后总结下在处理这个问题时可以优化的地方。一是，跟其他系统沟通时要思考他们给的信息，并得出要表达的结论，不确定的要跟他们确定，引导他们表达出他们要表达的信息。二是，数据库语句次缺太多。三是，解决问题时要紧紧围着问题来分析思考，不要跑偏去分析与问题没有直接关联的问题。四是，今天发现对maven高级功能的使用完全没了解要尽快了解下。