您的位置:首页 > 其它

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

2021-12-25 16:05 92 查看

测试奇谭,BUG不见。

大家好,我是谭叔。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: