测试奇谭，BUG不见。

大家好，我是谭叔。

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

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

首先，直接给出万金油三步公式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

请牢记并背诵这三大类，绝对实用！！！

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

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

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

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

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