面试官：“你是怎么定位线上问题的？”这道面试题我在社招的两年里遇到过，前几天面试的时候也遇到过。我觉得我每次的回答都相当令人满意。今天整理一下审稿，希望下次再被问到的时候能回答的更好。下次我应该按照这个思路来回答：1、如果线上出现问题，我们希望通过监控告警发现我们线上有问题，而不是等待业务方的反馈。因此，我们需要做好核心接口的监控和告警工作。2、如果是业务代码层面的监控告警，那么我们应该可以快速定位问题。毕竟，我们写了告警逻辑。如果是服务器资源/依赖中间件告警，那我们可能要花点时间排查。3、不管怎样，不管是系统告警还是业务方反馈系统或接口有问题。我们不得不考虑系统是否最近发布了。如果系统是最近发布的，我们可以判断是否可以立即回滚到之前的版本，让系统恢复流畅运行（在线环境下，可用性很重要）。回滚时需要考虑接口是否依赖，是否需要与业务方同步回滚并进行相关配合。4.因为线上的问题大部分来自于系统改动，可能我们只改了几个代码，但是只要有一丝不被注意的逻辑，就真的很可能出问题，回滚的可能性很大在线恢复正常操作的最快方法。5.如果系统最近没有发布，是系统警告，那么跟踪警告和错误日志应该可以快速定位问题。6、如果不是系统告警，而是业务方上报的问题，那么此时业务方需要明确具体是哪个功能/接口出现了问题，是否保留请求入参，是否保留返回错误信息，以及什么现象7.知道问题现象后，需要根据经验排查可能是哪个部分有问题。我的经验一般是：首先检查存储端是否有瓶颈（MySQL的CPU是否飙升，主从同步延迟是否过大，SQL是否慢。Redis是否内存满，有采用了淘汰策略，搜索引擎没有慢查询），检查服务依赖的中间件的指标，同时检查这个过程中服务接口的QPS/RT相关监控。如果某个指标有问题，应该顺着写的逻辑快速看出来。8.一般大部分问题都可以在这里找到。可能是逻辑本身的问题，可能是请求的入参导致的查询慢，可能是中间件的网络抖动，也可能是突发或异常请求的问题。9.如果没有，回到应用和机器本身的监控：应用GC的性能，机器本身的网络/磁盘/内存/CPU的各项指标，有没有发现异常。这里可能需要配合运维方看看有没有改动。10.如果还是找不到，看看能不能重现。能不能复现好说，肯定能解决。11、如果无法重现，只能在怀疑的地方写详细的日志，仔细观察（如果不能定位问题，往往是因为日志不够详细，下面的日志不要打的太多）正常情况）。最后推荐一下我的开源项目，我对如何实现在线消息推送感兴趣，可以看看：austin消息推送平台项目源码Gitee链接：gitee.com/austinaustin消息推送平台项目源码GitHub链接：github.com/austin
