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