关于线上的bug什么时候修复的思考

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

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

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

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

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

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

我自己也有类似的体会：有时候发现bug，想快速修复bug，就懒得在灰度测试了。于是发布到线上。但是会出现其他问题来。

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

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

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

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

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

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

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

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

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

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

很多时候之所以那么赶，是因为觉得自己再去测验浪费时间，还有上面也不给你时间来测验？

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

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

线上的bug怎么处理？

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

避免越修越乱的局面！

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

总结：不要因为线上出了问题，为了快速修复bug，而忽略掉了节奏。开发人员能够做到面临外界压力，不乱其实是一种心里素质。

如果乱，心智不稳定的状态下，还会造成更多的问题出来，以前的修改代码就白劳动一场。有时候要庆幸现在自己冷静，没有去乱动，还没有因为乱动而造成更多问题(到时候吃不了兜着走)。

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

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

因为通过手机app注册的用户，并不像我们想象那样，会去pc端页面进行登录。所以用户没有遇到这样的问题。

由于一个瓶子放在桌面上，每个人观察到的面是不同的。我们会忽略掉一些看不到的面。

我们内部开发人员观察到的永远是bug，因为产品反馈给我们了，我们看到的就是这个bug这一面。但是我们没有从整体角度来考虑。我们只是关注这是一个影响用户登录的bug。

我们以为改掉可以很有成就感，但可能是杨白劳，周五去发布，如果无法确保自己的代码不会造成其他影响。就少干。原地不动，反而风险更低。

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