这个面试题我在两年社招的时分遇到过，前几天面试也遇到了。我觉得我每一次都答得中规中矩，今日来梳理复盘下，下次又被问到的时分希望能够答得更好。
下一次我应该会依照这个思路去答：
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
本文正在参与「金石计划 . 瓜分6万现金大奖」
