反思

这周任务有些紧，也没有找到合适的书来看。大家可以推荐推荐。就简单描述下解决一个问题的心路历程。

大概两个礼拜前，系统上了一次版本。目的为了解决同一个公司采用不同code系统能够支持接单的问题。具体的改动主要在一个无比巨大的sql里面，系统每15分钟会去跑下这句sql，将相关的单子的ata信息反馈到sap中。上线前也做了code review,sql也进行了性能的评估测试，自己也在测试环境用测试工具模拟发单等。因为这个改动的影响比较严重，所以也担心上到生产环境会有影响，所以周末上线的时候也把sql拉下来再检查，周一的时候也登到b2b网站上看单子有没有发出去……一切貌似成功了，检查了两三天，ssc那边也没有新的异常反馈，就不再检查了……

本周一下午，接到邮件大概400多单子反馈的ata被sap reject回来，你可能会问为什么都这么长时间了才收到这个问题，这也与流程有关，客户公司会在每周四的时候给到我们缺失ata的文件，时间上及时性没有那么好。言归正传reject的理由是yt818等一串编码，这个编码很少见几乎没遇到过，又把问题抛给了客户公司，猜测是不是他们那边系统有所调整。

周二中午的时候，客户IT回复了缺失航班船只信息，同时csv也发来了一堆缺失信息的单子，这才认识到问题的严重性。

定位问题

随机挑了一个单子，查看单子是否有那些信息，确认有，再到b2b上拉下发出去的报文，查找信息，发现没有。范围缩小，应该在发送给b2b的邮件中丢失了，然后想到了那个巨长sql中有一处是获取航班船只信息的。

分析问题

拉取sql，在测试环境构建单子，运行。在返回的字段中确实没有值，重现了问题。再定位那句sql：

select translate(field_value，cha(9)||cha(13)||cha(10),'');

看到了最后一个‘’，感觉问题出现在了这个‘’这边，因为当时打patch的时候特地把sql format了一下，然后出现了一个情况是：比如我sql中有个字符串的值=‘yyyy-mm-dd’，格式化之后变成‘    yyyy-mm-dd  ’，字符串前后都出现了空格，这显然是不对的。于是手动将这些空格删除，其中也包含了上述tranlate函数的部分。想到这，尝试着将空格补上，然后运行，发现船只航班信息有了......紧接着回复了BPM的人，承担责任，并把事情起末以及影响面告知领导，准备patch，找人review，紧急上prd，（patch到prd的时候也出现了由于sql过长不让update，只能将sql拆解成10几个小的语句的插曲），最后将影响的单子重新resend edi，怕一次性回复过多，每个15分钟回复一批（15分钟有个定时任务在跑）。

事后总结

上次正好看了黑匣子思维，归纳了一下：事情的反馈周期比较长（2个礼拜），所呈现的表象具有迷惑性（YT818...）自己一度认为是对方系统的问题，黑匣子思维也要求发现问题，然后将其逐步拆解，任务原子化，逐步排除受影响的点，思想上一定要高度认知这是个严重问题，不能躲避。

当然这是事情发生之后了，想了下事情发生前的情景。也存在着以下需要改进的因素:

情绪占了一部分，改那句超长的sql心里是有抵触情绪的，特别是在测试的时候测试工具不会使用，由此引发了一系列的故事。测试的点局限了，或许多个人分享下，就能知道那个隐藏的隐患。这让我想起了一句，往往越是担心的事情越有可能发生。或许这其中也存在了一丝丝侥幸心理。

虽然问题很严重，还好最终解决了，心里也有一丝不合时宜的高兴，毕竟分析到解决的那一刻还是令人激动的。因为不是每一次的试探都有好的结局。比如上次同事做版本后验证系统发现后台出错，报了db字段找不到的问题。作为做这块的人义不容辞的参与定位问题，但是却事倍功半，还是A大牛一针见血说版本错了……这种速战速决的思维令人惊叹！

时常也在想思维这种东西真的可以锻炼吗？就像R同学跟我说脑袋不够用了，要洗洗……仔细想想，是的啊，洗洗该多好！