前言

对于工程师来说,开发系统的BUG是不可避免的,有时候即使在测试版本把新上的功能反复测试,当新功能到了线上难免会出现BUG。工作两年,我不断的总结出一套适合自己处理线上问题的一套方案。
目前整套应急方案通过不断的演练,修改和总结,大概分成了 发现问题-定位问题-提出方案-实施方案 几个基本的步骤。

发现问题

发现问题是开始的第一步,只有发现了问题才能解决问题。发现问题有几种途径。
1、用户反馈
当新功能上线之后,用户在用的过程中,发现了流程不能走通,肯定会发起反馈。然后工程师才能根据用户反馈去重现问题,最终发现这是一个BUG。然后去下一步解决问题。但是这样的途径对用户来说是不友好的,尤其是对于ToC的产品,可能用户并不会去反馈,而是觉得你的产品难用,直接放弃了使用。即使有对你的产品抱有兴趣的用户进行了反馈,但是从用户 -> 客服 -> 研发这个流程之长,效率之低,使得问题很容易被跟丢,很容易跟掉。这个体验对于用户来说是很不好的。
2、监控反馈
工程师通过对系统进行监控,让系统对错误的信息进行上报,通过邮件的方式直接发给相应的工程师。这样当用户在使用过程中出现任何系统问题,工程师可以第一时间收到相应的错误信息。

定位问题(BUG)

当发现了问题之后,工程师肯定得重现问题,当问题重现之后才能对应的知道问题的原因。主要根据发现问题那步骤我们可以根据以下两种方式进行重现问题。
一、通过模拟用户行为重现问题
最基础的是根据用户提供的信息来重现问题,这里定位问题的速度主要取决于用户提供信息的全面性决定。如果用户提供得不全,那么多少需要工程师连猜带蒙的来重现问题,这样定位问题的速度太慢。基本定位问题的时间快慢多少取决于工程师运气,有时候一个问题可能要好几个工作日才能定位到。
二、通过监控重现定位问题
如果是有做相应的监控反馈时,工程师可以通过监控邮件中收集的代码栈和输入的变量来定位问题。然后根据人脑来模拟步骤来快速的定位到问题出现的原因。
在整个定位问题的过程中,我发现很多刚入职场的同事在定位问题时,大多数指定为到问题的表面,如果说可能某个变量的类型应该是List,而这里则出现了None。那么他们就认为问题出在了这里。大多数加一个类型判断解决问题。其实并不是,我认为在定位问题的时候,应该对出现问题的地方向回看,一定要发现为什么这里出现None,是哪里出现了问题?只有找到最最根本的原因才能从根本上解决这个问题。看问题应该全面,不应该“头痛医头,脚痛医脚”。

提出解决方案

当我们定位到问题的原因之后,不应该立刻对问题进行简单的修复。应该对问题进行分析,这是个怎样的问题?是某个条件没有考虑到,还是设计上的缺陷。
我认为大多数问题的出现原因不应该只考虑到当前,只有不断的深入去探究问题出现的原因,才能下次避免类似的问题出现。
因为这个阶段我觉得应该提出两个解决方案

临时方案

提出临时方案是为了快速的修复BUG,然后让系统能正常运行,减少用户损失。一般临时方案指定要根据这个问题的严重程度来决定,如果这是一个不影响整体功能的问题,那么则通过一些临时代码加判断进行处理;如果这是一个BUG导致整个功能都不能使用,那么应该马上回滚版本,使系统回滚到上次那个可用的状态。

最终方案

临时方案只是能让系统处于一个可用的状态。每一个问题的出现不应该单纯的怪罪为工程师不细心写了BUG,测试人员没有仔细测试 这样的结论,然后把相关工作人员大骂一顿,扣罚款,或者降低绩效这样的处罚草草结案。我认为作为相关的领导乃至于工作人员应该思考的整个流程是不是哪里出了错?我们应该怎样来杜绝相关的问题继续发生。
软件工程在整个历史的场合中不断演练,从传统的开发流程到现在的敏捷开发,从SVN到GIT多个分支,从系统测试到现在的单元测试,从人工测试到集成测试。软件工程师做了太多的工具,太多的工作,制定了太多的流程来规范开发流程就是为了避免这类似的问题发生 。
而现在太多的工程师乃至于他们的领导,都不太关注最终的解决方案的制定。这样随着系统的复杂度不断提升,问题越来越多。工程师每天修BUG占了太多工作时间,每天都处于救火的状态。
因此,我认为最终方案的制定应该从以下几个方面为准
一、流程
我认为大部分的问题都是因为流程问题才会导致的。作为相关人员应该从流程方面思考。是否确定系统集成测试?是否缺少必要的单元测试?是否再开发-测试到发布整个流程中哪一个部分没有做好?有没有必要的Code Review?
二、系统架构问题
对于大型的系统来说,一般有多个工程师进行开发,而对系统进行架构的工程师只有少数一两个。架构工程师应该思考是否系统架构会出现问题?系统抽象还不够具体?系统模块之间的开发是否对业务开发人员来说太多余复杂?系统模块之间耦合度怎么样?

实施解决方案

在提出解决方案那个步骤,提到了两个方案:临时方案和最终方案。
临时方案要求的是快速解决问题,分配任务给负责相关业务开发的工程师。不断的PUSH工程师快速实施临时解决方案。工程师修复问题之后,多找几个同事进行集中测试,然后上线。
最终方案是在临时方案已经完成时候,所有工程师在一起探讨最终方案的优缺点,是否合理?对最终方案进行再次的确认。最终方案的实施应该让所有相关的工程师都参与进来,这样不会导致工程师之间出现消息不对称的情况。最终方案确认之后,要严格按照要求完成。千万不要因为实施不到位导致问题再次出现。

结论

解决线上问题是一个亡羊补牢的过程。说了那么多,归纳来说应该做好相关的系统监控,在问题出现之后,马上对问题进行定位评级。快速提出临时的解决方案,实施临时解决方案。临时方案完成之后,要召集大家商量最终解决方案,通过不断优化开发流程,调整系统架构。最终达到同一个问题不会再出现第二次。

发表评论

电子邮件地址不会被公开。 必填项已用*标注