共计 1194 个字符，预计需要花费 3 分钟才能阅读完成。
面试官：「你是怎么定位线上问题的？」
这个面试题我在两年社招的时候遇到过，前几天面试也遇到了。我感觉我每一次都答得中规中矩，明天来梳理复盘下，下次又被问到的时候心愿能够答得更好。
下一次我应该会依照这个思路去答：
1、如果线上呈现了问题，咱们更多的是心愿由监控告警发现咱们出了线上问题，而不是等到业务侧反馈。所以，咱们须要对外围接口做好监控告警的性能。
2、如果是业务代码层面的监控报警，那咱们应该是能够很快地定位出是哪儿的问题，毕竟告警逻辑都是咱们写的嘛。如果是服务器资源 / 所依赖的中间件告警，那咱们可能就要花点工夫去排查啦。
3、不论怎么样，无论是零碎告警还是是业务侧反馈系统或者接口出了问题。咱们要想想在近期有没有公布过零碎，如果近期公布过零碎，判断能不能立马回滚到上一个版本，复原零碎安稳失常运行（在线上环境下，可用性是相当重要的）。回滚的时候要思考接口有无依赖性，是否须要跟业务侧同步此次的回滚以及做相干的配合。
4、因为线上大多数的问题都来源于零碎的变更，可能咱们只是变更了很少的代码，但只有有一丝的逻辑没留意到，就真的很可能会导致呈现问题，回滚很可能是最快能复原线上失常运行的方法。
5、如果近期都没公布过零碎，是零碎告的警，那追踪下告警和报错日志，应该是能够很快地就能定位出问题。
6、如果不是零碎告的警，是业务侧反馈出了问题，那这时候须要业务侧明确是哪个具体的性能 / 接口出了问题，有没有保留申请入参，有没有返回谬误的信息，有何景象
7、晓得了问题的景象之后，就须要依据教训排查可能是哪块出了问题了。我的教训个别是：先查存储侧有没有瓶颈(MySQL 的 CPU 有没有飙高，主从同步提早是否很大，有没有慢 SQL。Redis 是不是内存满了，走了淘汰策略。搜索引擎有没有慢 Query)，把该服务所依赖的中间件的指标看一遍，这个过程中也要去看看服务接口的 QPS/RT 相干的监控。如果有某项指标不对劲，那顺着写入逻辑也应该很快能看进去
8、个别到这里，大多数的问题都能查出来。可能是逻辑自身的问题，可能是申请入参导致慢查问，可能是中间件的网络抖动，可能是突发或者异样申请的问题。
9、如果都不是，回归到利用和机器自身的监控：利用 GC 的体现、机器自身的网络 / 磁盘 / 内存 /CPU 各种的指标有没有发现异常的状况。这里可能是须要运维侧一起配合看看有没有做过改变。
10、要是还定位不进去，看能不能复现，能复现都好说，必定是能解决的。
11、要是不能复现，只能在狐疑的中央打上具体的日志再好好察看（问题定位不进去，很多时候就是日志不够具体，而日志在失常状况下也不应该打太多）
最初再举荐下我的开源我的项目，对线上音讯推送是怎么实现而感兴趣的，能够看看：
austin 音讯推送平台 我的项目源码Gitee 链接：gitee.com/austin
austin 音讯推送平台 我的项目源码GitHub 链接：github.com/austin
