用户群里面有个别用户反馈系统卡主了,一直在刷新,但就是出不来,但是我们本地又是好好的。让用户清空一下缓存,再次刷新就又好了。这个问题乍一看是系统不行的样子,但是查看监控又发现指标一切正常,并没有异常的情况发生。
因为是偶发性问题,用户的bug场景已经消失,没办法远程查看用户的电脑,所以只能根据现有问题,将bug复现出来。
首先我们可以确定,这个问题是个别用户+特殊场景下产生的,所以可以排除是系统架构问题。然后有一个很明显的点,用户清空缓存之后,就恢复正常,我们服务对外提供接口,是没有缓存之分的,所以问题大概率出现在客户浏览器上面。
还有一个很明显的问题是:前端页面一直在刷新出不来,跟前端沟通发现,如果getUser接口请求没有得到正确的响应,就会一直等待。所以问题再次缩小为:getUser接口没有返回200的正确请求。通过后端api调用日志,可以确定用户出问题的这段时间,没有错误请求进来。
getUser为用户基本信息接口,前端会根据用户信息来判断各种权限。
api的日志没进来,我们可以确定这个接口在nginx端就被拦截了,通过查看nginx端的日志,发现了很多getUser请求报Http 400 Bad Request问题。分析到这一步,我们基本可以把思路放在,什么错误场景下才会产生Http 400错误。
Http 400异常场景参考博客: https://blog.csdn.net/zhuyiquan/article/details/78707577
通过对能够产生Http 400的场景进行分析,最终确定是:Http请求头的cookie超过最大限制导致nginx返回400的错误,跟我们的问题场景最符合。跟前端确认产生cookie的页面操作后,最终定位到是登录/退出的页面操作,然后本地不断进行登录然后退出,发现getUser的cookie会越来越大,数据量达到4KB的时候,就返回400错误,复现出用户的问题了。
cookie是什么,最大限制是多少,可以参考: https://juejin.cn/post/6844904100035821575
找到问题后,问题的解决方案就简单很多了,既然是cookie太大从而导致的Http 400错误,那就在退出登陆的时候清空历史cookie即可,但是有一点需要注意的是,如果用户处于已登录状态下,访问系统的登录接口,要强制性重定向到登陆后的控制台页面,不能在已登录情况下,重复登录。
所以对应的处理方案为:
虽然找到问题并解决,但同时也暴露出更多的问题来,解决这一个问题并非我们的最终目的,最终目的应该是避免或者更快的找到问题,解决一类的问题。
不仅仅是对系统各个环节进行监控,还要对用户的客户端进行监控,比如console控制台错误,兼容性问题等。设置各类异常点的报警,将报警推送到开发可以看得到的地方(邮件、短信、电话等)。
前后端对接严格遵循规范,对请求参数、返回值、错误信息等的处理进行明确的要求。对于方案的设计要按照要求:先出设计文档,技术研讨确定,最后再实施测试,让每一次方案设计都能够尽可能的完善,减少出错的概率。
对每次发生的bug进行复盘总结,形成文档沉淀到公司的bug问题库中,后续不管是遇到问题还是方案设计,都可以借鉴参考,让已经发生的问题,不再重复发生。