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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　如需了解更多测试技术信息请关注：深圳多测师软件与技术服务有限公司