一直有线上问题不可怕,可怕的是一直有同一类型的线上问题。遇到线上问题时,你是讳莫如深,还是直言不讳呢,相信大部分人还是很担心翻车的,认为翻车是自己能力不足的体现。
但是线上问题并不是一无是处的,他们是一个宝贵的学习机会。首先可以反映出我们流程中哪一步做的不足,需要改进;其次可以将这些问题记录下来,补充到wiki中分享给其他同学,下次测试相似功能的同学可以在测试用例中补充该测试点。
线上问题的来源可能是客服反馈的问题、线上灰度时发现的问题、业务团队通过数据分析发现的问题或者是技术团队监控报警的问题。
当我们从各方收到疑似线上问题时,就要分析是bug导致、操作问题、外部原因、还是需求如此。如果是bug导致,就要立即成立临时小组,包括相关的业务、产品、开发、测试和运维人员。开发同学需要及时在群里同步定位情况和解决进度。如果需要发布hotfix版本,需要和测试沟通,提前协调测试环境和准备测试数据。同时,需要找上一级开发领导审查改动的代码,确认可以解决该问题并且影响范围可控(或者在改动前多方一起设计改动方案)。上线后,技术人员从监控中验证和观察服务状态,业务人员从业务数据中观察线上情况。如果是由于最近一个版本导致的P0级别的问题,但是一时半会儿无法想到解决方案,或者解决方案可能需要比较长时间的验证,那评估是否需要通过回滚代码解决。如果需要回滚代码,需要同步该版本的业务和产品,需要同步上下游系统该版本的功能撤销,可能导致新功能下线等。
到这里就完了吗,并没有。线上问题解决后,相关的人员需要尽快再开个小会,复盘整个问题的经过、解决方式和改进措施,以及总结各方是否有应对不及时的情况。针对改进措施最好建立任务追踪并分配到人。如果严重级别较大,还需要拉上项目组人员一起参与。复盘的结果文档需要同步到项目组群里,并且最好保存在一个线上问题文件夹中。大家时不时回顾一下这些问题,加深印象,降低之后出现类似问题的概率。这才是线上问题的价值。
出现线上问题之后,第一时间修复问题很重要,同时也需要做好总结复盘,否则下次还是有可能掉进同一个坑。
网友评论