线上问题三原则

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

本篇，通过一道常见的面试题，跟大家捋捋发生线上问题，作为测试人，该有的思路。

首先，出现线上问题怎么办？

万金油三步走：

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

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

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

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

切忌，不要一来就盲目定位问题，本着不找到根本原因，不彻底解决誓不罢休的思想去处理突发的线上问题，是不可取的。

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

你可以先检查检查CPU、内存、网络IO、磁盘IO等，看看有无明显的抖动，比如CPU过高，可以尝试重启。接着查看调用情况，判定是依赖系统的问题，还是自身系统的问题。如果是依赖系统的问题，有降级方案的优先做降级处理，无降级方案的马上联系依赖系统负责人协同解决。如果是自身系统问题，优先判断数据库类问题，有慢查询，就先kill掉，重启数据库，访问量不足，就先做扩容或者限流。再查查fullGC，如果fullFC过多，先重启服务，再通过DUMP内存找对象，修复并上线。

你可以看到，重启大法真的香，是快速恢复业务的一种方式。但这种方式，治标不治本。

治本是在快速恢复业务之后，定位问题彻底解决和经验总结。

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

其实，在生产环境，引起大面积故障，导致系统不可用的问题一般是依赖系统故障、数据库故障、程序问题导致内存不足引发fullGC，这三大类。再细分点讲，数据库慢查、死锁、连接数不够，redis有大key，fullGC过多，线程DUMP，内存DUMP，MQ消费积压，这些是常见的线上问题，也可以说，是绝大部分问题。

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

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

一如既往，做个总结

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

发现问题、定位问题、解决问题。有一道目标准则，1分钟内发现问题，5分钟内定位问题，10分钟内解决问题。