出现线上bug,测试人能做些什么?

  一提到线上问题,很多测试小白要么”原则性“恐惧,要么憨憨如也,不知如何下手。

  本篇文章,我再细化下这道常见的面试题,跟大家捋捋发生在线上问题,作为测试人,该有的思路。

  首先,直接给出万金油三步公式:

  第一步,初步排查,快速恢复业务;

  第二步,查找问题的根本原因,彻底解决;

  第三步,团队分享,避免出现类似问题。

  这三步中的措辞,十分重要。特别是第一点——初步排查,快速恢复业务。

  出现问题,不要一来就盲目定位,本着找不到根本原因不罢休的思想去处理突发问题,是不可取的。

  线上有问题,最重要的是快速恢复业务。

  你可以先检查CPU、内存、网络IO、磁盘IO等,看看有无明显的抖动。比如CPU过高,可以尝试重启。

  接着查看调用情况,判定是依赖系统的问题,还是自身系统的问题。如果是依赖系统的问题,有降级方案的优先做降级处理,无降级方案的马上联系依赖系统负责人协同解决。

  

出现线上bug,测试人能做些什么?

  如果是自身系统问题,优先判断数据库类问题。若有慢查询,就先kill掉,重启数据库;若访问量不足,就先做扩容或者限流。再查查Full GC,如果Full GC过多,先重启服务,再通过DUMP内存找对象,修复并上线。

  前面所述,都提到了重启服务——人人都说重启大法好,因为它是真的香。

  有时候,重启是快速恢复业务的一种方式。但这种方式,治标不治本。

  治本是在快速恢复业务之后,定位问题,去彻底解决它;去做总结分析,避免出现类似的问题。

  比如,刚刚提到,若是数据库慢查询,想要快速恢复业务,可以kill掉慢查询,重启数据库。此时,业务虽然恢复,但它是短暂的恢复,你还得继续定位。你定位到问题原因是新加的表索引不够,那你得马上加索引,并在事后开个会或者做个组内总结,聊聊库表设计的问题,聊聊上线方案的问题等等,避免再出现类似问题。

  其实,在生产环境,引起大面积故障,导致系统不可用的问题一般有三大类:依赖系统故障、数据库故障、程序问题导致内存不足引发Full GC。

  请牢记并背诵这三大类,绝对实用!!!

  再细分点讲,数据库慢查、死锁、连接数不够,redis有大key,Full GC过多,线程DUMP,内存DUMP,MQ消费积压,都是常见的线上问题,也可以说,是绝大部分问题。

  这些内容,每个都可以开一篇专题聊聊,故此文不再拓展。

  在中大型公司,以上这些都是通用的知识点。出现线上问题,体验并实操几次,自然而然就懂了。

  作为测试,你可以不深入它们,但你一定得了解它们,或者说,你可以把他们作为你进阶提升的课程表,挨个去学习。

  最后,愿天下测试人都不会遇到线上BUG。

发表评论

相关文章