这个面试题我在两年社招的时候遇到过，前几天面试也遇到了。我觉得我每一次都答得中规中矩，今天来梳理复盘下，下次又被问到的时候希望可以答得更好。下一次我应该会按照这个思路去答：
如何发现问题 –》 如何解决问题
- 观察问题的现象，如果你对业务比较熟的话能够根据问题很快定位出问题所在。当然有时候没那么简单。
- 思考下是否最近有发过版，线上大多数的问题都来源于系统的变更(迭代)，可能我们只是变更了很少的代码，但只要有一丝的逻辑没留意到，就真的很可能会导致出现问题。或者是说只改了一个功能，其他功能也可能影响到，测试不够全面。
- 如果不能短时间发现不了问题，或者解决不了向上问题，可以考虑回滚，最快的恢复线上正常运行。
- 要建立一个监控告警机制，我们希望通过监控告警来自动提醒我们bug所在，而不是要等到业务或者用户来反馈。等到那时候就是线上事故了，严重的就是扣绩效、最终可能会影响到你个人或者团队甚至是公司的形象。
- 监控告警怎么做。监控主要分为业务监控和资源监控，业务监控需要我们手动埋点，我们需要对核心接口做好监控告警的。资源监控，监控服务器和应用的的CPU,内存。使用开源的Prometheus监控和告警足够了。
如何解决问题
bug主要分为 业务逻辑bug，代码异常bug，应用，资源瓶颈
- 查日志，一个系统日志是必须的，分布式环境下一般会集成ELK，根据ELK日志可以很快的定位出异常代码bug，至于业务问题需要我手动埋好点。
- 如果是业务代码层面的监控报警，那我们应该是可以很快地定位出是哪儿的问题，毕竟告警逻辑都是我们写的嘛。如果是服务器资源/所依赖的中间件告警，那我们可能就要花点时间去排查啦。
- 不管怎么样，无论是系统告警还是是业务侧反馈系统或者接口出了问题。我们要想想在近期有没有发布过系统，如果近期发布过系统，判断能不能立马回滚到上一个版本，恢复系统平稳正常运行（在线上环境下，可用性是相当重要的）。回滚的时候要考虑接口有无依赖性，是否需要跟业务侧同步此次的回滚以及做相关的配合。
- 如果近期都没发布过系统，是系统告的警，那追踪下告警和报错日志，应该是可以很快地就能定位出问题。
- 如果不是系统告的警，是业务侧反馈出了问题，那这时候需要业务侧明确是哪个具体的功能/接口出了问题，有没有保留请求入参，有没有返回错误的信息，有何现象
- 知道了问题的现象之后，就需要根据经验排查可能是哪块出了问题了。我的经验一般是：先查存储侧有没有瓶颈(MySQL 的CPU有没有飙高，主从同步延迟是否很大，有没有慢SQL。Redis是不是内存满了，走了淘汰策略。搜索引擎有没有慢Query)，把该服务所依赖的中间件的指标看一遍，这个过程中也要去看看服务接口的QPS/RT相关的监控。如果有某项指标不对劲，那顺着写入逻辑也应该很快能看出来
- 一般到这里，大多数的问题都能查出来。可能是逻辑本身的问题，可能是请求入参导致慢查询，可能是中间件的网络抖动，可能是突发或者异常请求的问题。
- 如果都不是，回归到应用和机器本身的监控：应用GC的表现、机器本身的网络/磁盘/内存/CPU 各种的指标有没有发现异常的情况。这里可能是需要运维侧一起配合看看有没有做过改动。
- 要是还定位不出来，看能不能复现，能复现都好说，肯定是能解决的。
- 要是不能复现，只能在怀疑的地方打上详细的日志再好好观察(下次触发可以加个告警)（问题定位不出来，很多时候就是日志不够详细，而日志在正常情况下也不应该打太多）
这个我估摸想要考察的是看看你平时是怎么去定位问题的，定位问题的思路是什么，自己有没有方法论之类的。话虽如此，这也只是我这几年的定位问题的模式，也未必对，也不知道有没有缺少了哪一个重要的环节。面小公司总体下来会问些方法论的多，不会很专研某项技术的问题。