qq建设网站首页,网站悬浮窗口,成都房地产政策,门户网站建设公司这个面试题我在两年社招的时候遇到过#xff0c;前几天面试也遇到了。我觉得我每一次都答得中规中矩#xff0c;今天来梳理复盘下#xff0c;下次又被问到的时候希望可以答得更好。 下一次我应该会按照这个思路去答#xff1a;
1、如果线上出现了问题#xff0c;我们更多…这个面试题我在两年社招的时候遇到过前几天面试也遇到了。我觉得我每一次都答得中规中矩今天来梳理复盘下下次又被问到的时候希望可以答得更好。 下一次我应该会按照这个思路去答
1、如果线上出现了问题我们更多的是希望由监控告警发现我们出了线上问题而不是等到业务侧反馈。所以我们需要对核心接口做好监控告警的功能。
2、如果是业务代码层面的监控报警那我们应该是可以很快地定位出是哪儿的问题毕竟告警逻辑都是我们写的嘛。如果是服务器资源/所依赖的中间件告警那我们可能就要花点时间去排查啦。
3、不管怎么样无论是系统告警还是是业务侧反馈系统或者接口出了问题。我们要想想在近期有没有发布过系统如果近期发布过系统判断能不能立马回滚到上一个版本恢复系统平稳正常运行在线上环境下可用性是相当重要的。回滚的时候要考虑接口有无依赖性是否需要跟业务侧同步此次的回滚以及做相关的配合。
4、因为线上大多数的问题都来源于系统的变更可能我们只是变更了很少的代码但只要有一丝的逻辑没留意到就真的很可能会导致出现问题回滚很可能是最快能恢复线上正常运行的办法。
5、如果近期都没发布过系统是系统告的警那追踪下告警和报错日志应该是可以很快地就能定位出问题。
6、如果不是系统告的警是业务侧反馈出了问题那这时候需要业务侧明确是哪个具体的功能/接口出了问题有没有保留请求入参有没有返回错误的信息有何现象
7、知道了问题的现象之后就需要根据经验排查可能是哪块出了问题了。我的经验一般是先查存储侧有没有瓶颈(MySQL 的CPU有没有飙高主从同步延迟是否很大有没有慢SQL。Redis是不是内存满了走了淘汰策略。搜索引擎有没有慢Query)把该服务所依赖的中间件的指标看一遍这个过程中也要去看看服务接口的QPS/RT相关的监控。如果有某项指标不对劲那顺着写入逻辑也应该很快能看出来
8、一般到这里大多数的问题都能查出来。可能是逻辑本身的问题可能是请求入参导致慢查询可能是中间件的网络抖动可能是突发或者异常请求的问题。
9、如果都不是回归到应用和机器本身的监控应用GC的表现、机器本身的网络/磁盘/内存/CPU 各种的指标有没有发现异常的情况。这里可能是需要运维侧一起配合看看有没有做过改动。
10、要是还定位不出来看能不能复现能复现都好说肯定是能解决的。
11、要是不能复现只能在怀疑的地方打上详细的日志再好好观察问题定位不出来很多时候就是日志不够详细而日志在正常情况下也不应该打太多。
