一次线上服务故障应急问题总结

昨天负责的项目出了个故障，从发现故障到线上服务恢复耗时一个小时，故障应急的效率存在很大问题，这里总结一下解决故障期间存在的问题，每次故障都是技术能力进步的捷径，哈哈

。

一、故障现象：

评论列表页评论内容加载不出，一直在转小圈圈，服务端监控显示有大量NP异常。

二、故障排查：

因为故障发生在我刚上线完服务五分钟左右，第一反映是回滚代码。服务报警还在继续，怀疑是发布系统回滚有问题（因为当时恰逢公司在升级新版发布系统，我找了个历史包发布，实际发布的并不是我想要的包）。然后将master代码回滚到之前的版本（这里用了git reset和git push -f命令，不是很好，后面讲），重新打包发布，但是故障依然没有恢复。同时查看cat监控，发现并没有打印出堆栈信息。无奈登录机器查看tomcat日志，发现log量太大，即使用了grep命令依然停不下来，只能挖静态log，发现依然是只显示了空指针异常我并未打印出我需要的堆栈信息。



从所打印的堆栈信息大概可以看出，ListAbstractHandler存在问题，将整个方法进行try catch（当时怀疑堆栈信息被hystrix吞掉）:



然后灰度发布，查看log并定位问题在如下图所示处出现空指针，然后增加判空，上线，服务恢复。

三、原因分析：

经过log测试和调研，发现平台（一个服务提供方）那边在并未周知我们调用方的情况下将我这边依赖的一个接口下线，直接返回空map。由于这块逻辑没有判空，导致userReviewCount.get不到内容：feedDetailDo.setReviewCount(userReviewCount.get(reviewData.getUserId()))，而feedDetaiDo里的reviewCount类型为int型，则出现了NullPointerException。

四、存在的问题总结：

1、首先是老代码部分逻辑存在bug隐患，平时没有去仔细排查代码是否有问题。由一个字段的赋值问题影响了主流程，且这段赋值逻辑没有异常捕获存在严重问题。所以在接手一个旧项目时，必须将业务代码进行梳理，能优化的优化，能整合的整合。

2、问题发生时间恰巧是在我刚上线一段新业务需求后的五分钟左右，当时的第一反应是回滚代码，拿上一次的包重新发布，发现发布系统存在问题并未回滚成功。然后回滚master分支代码，重新打包发布，问题依然没有解决。此时怀疑底层服务出现了问题，这个过程浪费了大约二十分钟的时间。

3、线上的log以及cat的log堆栈信息不全，这个问题严重影响了排查问题的效率。经过时候分析发现，JVM为了性能考虑，当一个内建的异常被抛出一定次数后，会被重新编译，抛出不带有堆栈的异常，如果要禁用这个优化，就得使用这个参数。使用 -XX:-OmitStackTraceInFastThrow 关闭此项优化可以强制打印堆栈。优点是便于排查问题，缺点是可能会增大开销。或者是用cat app.log | grep -C5 “NullpointerException”
 | head 100查看log中某条异常的上下五行，打印前一百行，基本就可以查看前几条完整的堆栈信息了。

4、服务提供方下线相关接口并未周知接口调用方，存在严重的隐患。

5、异常log瞬间暴增，导致登录机器查看log时根本停不下来，是由于客户端在服务端返回null时一直在重试请求。

6、在回滚master代码回滚到之前的版本，这里用了git reset和git push -f命令，git reset会撤销最近几次的commit，而且不留痕迹，当有多人在开发这个master分支时会存在分支不可逆情形。最好的处理方法是用git revert命令，git revert是提交一个新的版本，将需要revert的版本内容再反向修改回去，版本递增，不影响之前提交的内容。

注：git revert 和 git reset的区别 

（1） git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。 

（2）在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。 

（3）git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。