同事写了一篇特别不错的文章,写了大多数公众号里不常见到的互联网一线开发的另外一面-线上事故。
老李秀,公众号:高性能API社区翻车后记之BUG李的自我检讨

大多数公众号文章都是讲面经、讲技术、付费学习,要么就是谈人生、谈理想、灌鸡汤。讲的大家激情四射、心血澎湃,恨不得赶紧去面试,入大厂,年薪百万,赢取白富美,当上CXO,从此走向人生巅峰。

然而,理想是美好的,现实是残酷的。就像手术有风险一样,互联网人的上线发,也会有各种事故伴随。端上可能会存在线上crash,服务端会存在线上接口不可用甚至服务不可用。最主要的是每天上线如喝水,再低的概率也架不住上线次数多啊。除了各种人祸,可能还会有各种天灾,今天机房网络故障,明天专线闪断 ,各种天灾人祸不断挑战着线上服务的稳定性。尤其是大公司,服务的短暂中断可能就会造成很大的损失和影响。总之,就是亚历山大。

当然天灾是不可避免的,而且也不是经常发生的,通过异地容灾的一些方案还是可以保证服务不中断的。大多数事故还是人为造成的,通过流程和制度的完善是可以避免的。

首先,大家要明白一个道理,事故是不可能零发生的,只能无限逼近于零。而且淹死的都是会水的,越是老司机,上线越会轻视,越容易出问题。新人会小心谨慎,观察仔细,反而不容易出问题。也让我想起了驾校老师的一句话,刚开车时候前三年是很少出事故的,接下来的三年是事故高峰期,然后后面就没事儿了。所以无论何时,无论是新手还是老手,对待每次上线,都要心存敬畏之心,把自己当新手。

老李公众号里描述的事故发生后临床反应还是很真实的,依稀记得我刚来滴滴时,那时候还是在做iOS乘客端,当然体量也没那么大,我也写出过累计次数上千的crash,那时候没见过世面的我也是胆战心惊,瑟瑟发抖,惶惶不可终日。也记得有一回深夜发版之后,轻松之余跟QA同学一起出去喝了一顿酒庆祝了一下,还他么喝多了。随着后来场面见多了,在公司也变成老油条了,也就没那么紧张了,但是那种小心谨慎还是要有的。做服务端后,也出过一些问题,索性现在做的业务体量不大,影响也都不大。

但是做服务端面临的压力要比端上大多了,端上只需要发版放量的前几天关注线上新增crash,没问题能过半个月的幸福时光(两周发一个版本)。服务端基本上是需要24小时不间断关注了,每天都有人在上线,流量随时都可能出现异常。有可能是网络故障,有可能是线上问题,也有可能是节假日,总要排查一下原因,确保其他人上线没影响到服务的稳定性。如果怀疑是正在上线造成的,本着“先止损,后排查”的策略,不要犹豫,不要纠结原因,立刻通知上线人员回滚,然后观察问题是否开始逐步恢复,最后还需要跑影响面,恢复线上数据及善后。平时开发时候还需要考虑对老版本是否有影响,端上当然是不用关心老版本的。

其实老李的这次翻车不算太大问题,事后总共对30多个用户造成了影响,操作上也没毛病。但是当时还不知道影响面的情况下,老李做为此次事故的主角,一个处在事故风口浪尖的人物,他惶恐的心情我还是能理解的,这也是一个开发人员出问题后的真实写照,不惶恐的要么是故作镇定,其实内心慌的一逼,要么是没心没肺,要么不是事故的始作俑者,要么是见过大世面的老油条(比这大的事故都见过了,这算个啥)。

但是无论事故大小,还是要对整个事故复盘一下的,复盘其实是对整个流程中薄弱环节的一个查漏补缺。大多数问题不是一个固定环节出的问题,而是每个环节都有一些小问题,然后到线上就成了大问题。如果每个环节都严加检查,最后问题留到线上的几率要小很多。一个问题出现到线上大概需要突破以下几个防线:

评审:(敌军出击)

这个环节产品经理提出的需求可能会有一些无法实现的,甚至比较复杂的需求,还有一些复杂状态可能产品经理本身也没罗列清楚,或是枚举不全,导致需求就有一些问题,这个环节对PM的素质要求就比较高了。一个好的PM能用简单的需求解决复杂的问题,或者把复杂的需求抽象出一个简单有序的模型,而不是简单堆砌一堆乱七八糟毫无逻辑的需求,增加用户负担,增加开发人员负担,也增加QA的负担。这个也需要开发人员从旁辅助,对于复杂的点能砍掉就砍掉,不能的话看有没有可替代方案,剩下的就要梳理清楚,罗列所有状态,对于缺失状态与各方拉齐,然后再步入开发环节。比较忌讳的是,拿到需求没梳理清楚就开始开发,这个很容易漏了逻辑,做到一半发现问题就没时间补救了,只能delay了。

开发:(敌军即将到达边境)

其实,如果评审环节,把需求梳理清楚,这个阶段反而是最简单的了,按照梳理的逻辑快速实现就行了。没梳理清楚的话,这个环节就是最痛苦的过程了,甚至是一步一个坑也不为过,线上出问题的几率会无线放大。

自测:(敌军跨过边境)

开发过后,自己一定要测试,每一行代码都要测试。按照自己的改动点,把所有逻辑都跑一遍,确保无遗漏且符合预期,这个环节做的好能扼杀99%的问题。最后到QA测试阶段,其实就是考虑你考虑不到的各种异常,对你再做一个查漏补缺。这个环节很重要,千万不要把QA环节取代自测环节。每个环节都要守好自己的防线,不要指望其他防线

QA测试:(敌军开始攻塔)

由于受自己思维的限制,有一些问题会是自己想不到的,突破自测防线来到了QA测试阶段。这就需要QA能从自己的思维角度来观察需求,两个不重合的思路才能覆盖更多逻辑。比较忌讳的是QA根据开发的diff写测试case,有可能受开发思路的影响,开发没想到的问题,QA也没想到。如果QA能根据需求写case,然后再根据开发的diff做补充,应该能覆盖更多问题。突破这个防线的问题,基本上99%会被带到线上了。

上线:(敌军到达我方大本营)

这个防线基本上问题都快到我方军营了,问题到了这个阶段还没发现就很容易就被带到线上去了。所以这个环节尤为重要,上线一定要谨慎,观察一定要仔细。如果观察不慎,那就已经造成了体验或经济上的损失,至于损失大小就要看上了多少机器,多少用户命中了逻辑。总之,一有问题立刻回滚。

所以,这里有几个重要的点,一是问题的发现要尽量前置,能前面环节就避免的,就不要留到后面,越到后面防线,危险越大。二是每个环节都要做好防守,不要依赖其他环节,否则该防线形同虚设。如果每个环节都做好防守,问题带到线上的概率会小很多。

概率再小,也怕次数多,新人的加入或者是老人的疏忽,总是会出现线上事故的,当然出现了线上事故也不要慌,不要怕。既然已经出现了,那就让我们面对疾风吧,好好总结的话,问题带来的是个人的成长,也是流程和制度的完善。但是切记要吸取教训,同一个错误尽量别犯第二次,决不允许犯第三次。

福利放送:

扫下面二维码关注公众号,回复“测试之美”,免费下载经典书籍。

本篇文章来源于微信公众号: 搞点儿啥

最后修改日期:2019年12月16日

留言

填写回复或留言