原创

找到根因,才能从根本上解决问题

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://elastic.blog.csdn.net/article/details/39449391

找到根因,才能从根本上解决问题

       源自我参与的一个项目在用户那里出了bug,当然非我的改动引发,是之前处理数据未考虑到异常。

      一、Bug描述

      公式即:优化数据=出口1flow1-出口2flow2,优化比例=优化数据/出口1flow1

      正如上表黄色标注所示,bug表象是优化数据为负值,优化比例为负值。用户一看还了得,还不如不去优化?

      二、Bug临时补救方案

      分析发现,不是所有应用识别都会出错,只有极其个别的情况。并且这种逻辑,近几年就跑出一回。所以,我们的方案是,当出口2flow2>出口1flow1的时候,就置出口2flow2 =出口1flow1。这样就绝对不会出现优化数和优化比例为负数的情况。

      三、Bug补救后仍存在隐患

       隐患1:所有上面的出口1、出口2的数据是从mysql数据库中读取的,包含合计数据。合计和应用1-9共用一套逻辑,所以导致纠错时,如果出现出口2比出口1大的情况,置出口2=出口1的数据。这样就会出现出口2列的应用1-应用9的求和与出口2合计不等的隐患。

      补救隐患1:只有出口2列对应的合计行出错,真正的和应该等于应用1+…+应用9。想到的方案是不是从数据库中读取,而是进行应用1到应用9求和

      补救隐患1后的隐患:我们保证了不出现异常数据,保证求和正确,用户看着没有问题,但作为工程师,就要扒一扒为什么会出现上面的异常数据

     四、找到根因

     讨论分析发现,是我们的应用识别驱动问题出了问题,导致讲大量出口1的数据识别为出口2的数据。即是下图的分类识别数据出了错。

 

     五、总结

      很小很小的bug,但是带来很大很大的灾难性不可饶恕的问题,这种我们自身验证和测试是几年也跑不出这种异常数据的。但是,我们对异常的把控是做的远远不够的,其实除了常用的除数为0的情况,对于这种优化数据良不能为负数的情况也必须敲响警钟!

      程序设计中要做出异常处理机制,或者跑出异常、或者打印错误日志,或者其他方法,但是一定要去做,要去处理,异常的场景考虑的越全面越好,异常的处理机制对应的越多越好。

      谨记!

      2014-9-21am10:30思于家中床前

 

作者:铭毅天下

转载请标明出处,原文地址:http://blog.csdn.net/laoyang360/article/details/39449391

如果感觉本文对您有帮助,请点击支持一下,您的支持是我坚持写作最大的动力,谢谢!

 

0 个人打赏
文章最后发布于: 2014-09-21 10:20:16
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503

打赏

铭毅天下

“你的鼓励将是我创作的最大动力”

5C币 10C币 20C币 50C币 100C币 200C币

分享到微信朋友圈

×

扫一扫,手机浏览