关于线上的bug何时修复的思考

 

 

这里系统专门指的是那种用户量大的系统，好比有几百万或者上千万的注册会员。由于小系统由于用户量少，不存在这种思考，考虑有时候是多余的。另外还有内部系统，给本身公司内部人员使用的，即使是出现了问题，也不会形成很大的问题，内部协调一下便可。

 

而针对客户的系统，公司的收入和价值来源于给客户提供稳定的服务。这是关系到公司命脉的。若是系统不稳定，在客户心中形成的印象就会很差。

 

 

 

快速修复与稳定测试之间的权衡

 

若是线上系统出现了bug，用户反馈问题。做为开发人员，确定要修复bug。是马修复代码后上传到生产环境，仍是在灰度或测试环境把修复的代码测一遍后，再上传到生产环境呢？

 

有时候为了快速解决线上问题，因此修改代码后，就想发布上去。大一点的网站，都要走发布流程，填写发布单的。不能随便ftp上传代码的。都是业务系统，一点问题会存在影响。

 

看《淘宝技术这10年》里面也出现过相似问题，改改，编译(java语言要编译)好后发布上去，发现仍是有问题，又得从新找，一天过去了。

 

我本身也有相似的体会：有时候发现bug，想快速修复bug，就懒得在灰度测试了。因而发布到线上。可是会出现其余问题来。

有的时候还会犯低级错误。

 

好比我本身亲身经历过好几回了。一次是邮箱的激活状态。发现有这个bug，去修复，想快速修复，在测试环境测验了后，程序是没问题，可是发布到线上，就出现问题。

此次不是程序出现问题。是没沟通好，不该该改成激活状态。这种办法只是一个临时办法，没有从总体角度考虑，即其余系统也会用到数据库的状态，根据这个状态来拦截发广告行为。这样改掉就形成数据错误了。

 

不少人都有相似的习惯，干脆懒得测了，本身以为有信心，就发布到生产环境去(身边一些开发人员改好代码，本身不测试，直接发到灰度去给测试人员测试，实际上仍是要打回来。这样来回折腾的耗费的精力和时间其实还更多)

 

表面觉得快，实际上并无快。有时候，咱们修改简单的功能，发布上去，没有出现问题，因而就养成这样的习惯了。几回没有出现问题，可是某次就会出现意外，形成了系统的不稳定，也让开发人员处处救火的行为，好比这里修复好后，出现新的问题，继续修复，处处救火弄得精疲力竭的。

 

我现在愈来愈有以下感悟：追求快速能够，但若是追求快速，质量得不到保证，这种快速有多大意义呢？为了保证质量，宁愿慢一点，放到测试环境和灰度环境把问题还原出来，测验没问题再发布。

 

 

靠人的经验和能力来控制是否靠谱

 

开发人员出于自信和经验考虑，以为本身修改的东西不用通过测验，反正就修改那么一点点代码，我有信心保证不出错。

 

我如今发现，靠人的经验来保证质量，不太靠谱了。由于任何人再厉害，都有犯错的时候，都会有疏忽。好比今天恰好由于家庭有事，情绪比较低落。修改代码就忽略掉一些部分了。眼睛看失误了。或者今天睡眠不充足，或者今天心情很差。就会形成相似的事故出来。一我的的大脑负担多的时候，就更加容易失误了。

 

靠一我的的智力终究有限，怎么防火才能从源头上来解决问题。若是可以设计一种办法，哪怕是人会犯错，可是能够纠错，就会好不少。

 

 

不少时候之因此那么赶，是由于以为本身再去测验浪费时间，还有上面也不给你时间来测验？

 

这方面的投入时间相比后续出现问题再去救火处处的成本，是很是值得的。

 

古代人说，慢工出细活，的确很是有道理。编程就是一个慢共出细活的工种。心理越乱月容易出错。

 

 

线上的bug怎么处理？

 

分清楚优先级，重要程度。若是影响的面不是很广，只是一部分用户。能够放在测试环境把这个问题还原出来。这样确保找到了缘由，再去修复问题。

 

避免越修越乱的局面！

没有找到确切的缘由，像苍蝇同样，各个去尝试，这样会形成更多的问题出来。之前只是影响一部分用户，后来影响更多的用户了。获得反馈回来，这个时候会惊动更多人(好比产品、老板)，开发人员获得的内心压力会更大。这样干的也不愉快。产品对系统频繁出问题也内心不爽，反馈到老板那里，老板也以为是这样，开发人员也由于受到压力干的不愉快。最后是一个双输的局面。

 

总结：不要由于线上出了问题，为了快速修复bug，而忽略掉了节奏。开发人员可以作到面临外界压力，不乱实际上是一种内心素质。

若是乱，心智不稳定的状态下，还会形成更多的问题出来，之前的修改代码就白劳动一场。有时候要庆幸如今本身冷静，没有去乱动，尚未由于乱动而形成更多问题(到时候吃不了兜着走)。

 

之前个人思想是，既然是面对用户的系统出现了bug，那么就要快速修复，我或多或少是出于假设某天个人公司遇到相似问题我应该如何办的思惟模式来作事。

面对用户的bug，会引发个人特别重视。可是后来我发现，彻底这样子也不行的。要权衡一下质量。若是没有质量保证的修复，那就会形成其余问题的出现。其实有些用户是能够缓一缓的，没想象那么紧急。好比线上程序就的确有这个bug：在app注册后，跑到pc版本去登陆，须要邮箱激活。我仔细跟产品沟通会发现，没有想象的那么重要。周五原本想发布修复bug，可是能够缓到周一去发布的(这样有足够的时间来测验修改代码后形成的影响)。我没有抓住里面的关键点，目前只有这一个用户反馈这个问题。没有出现大面积的用户反馈。

由于经过手机app注册的用户，并不像咱们想象那样，会去pc端页面进行登陆。因此用户没有遇到这样的问题。

 

因为一个瓶子放在桌面上，每一个人观察到的面是不一样的。咱们会忽略掉一些看不到的面。

 

咱们内部开发人员观察到的永远是bug，由于产品反馈给咱们了，咱们看到的就是这个bug这一面。可是咱们没有从总体角度来考虑。咱们只是关注这是一个影响用户登陆的bug。

 

咱们觉得改掉能够颇有成就感，但多是杨白劳，周五去发布，若是没法确保本身的代码不会形成其余影响。就少干。原地不动，反而风险更低。

 

顶着错误前进，错误次数多了后，就会是经验。有人宣扬，人生没有后退的路子。但我在想，若是一我的没法从错误的经历中吸收教训，避免下一次犯错，那么仍是同样的浪费折腾。好比修复bug的事情，如何权衡，这样的错误继续再犯，老是处处救火。仍是没有造成稳定的局面。