复现-定位问题的关键步骤

背景

• 在大家测试联调的过程中,以及线上bug的排查中,有的人喜欢根据报错直接取排查代码,这样导致治标不治本,即只能定位当前问题,诶有办法确定问题的根源,导致项目中依然存在其他的隐患

排查问题的步骤

• 首先通过自测或者用户反馈,暴露出系统的问题
• 当运营或者开发收到问题反馈的时候,联系问题提出人提供参数进行复现,当可以稳定复现的时候,说明是必有缺陷,如果不能稳定复现,在下文说明
• 当可以稳定复现的时候,可以通过参数进行debug,日志,以及返回提示快速定位问题
• 确定问题之后,解决问题
• 解决问题之后联系问题提出人进行验证
• 以上就是公认的排查问题的通常步骤

不能稳定复现的场景

• 在实际生产环境中,有时会出现不能稳定复现的以下场景
• 部分用户的存在问题
• 只有某些时刻存在问题
• 刚才有问题,现在没问题
• 只有某些机器有问题,其他机器没问题

小结

• 以上的列出的场景,虽然体现出系统的缺陷性,但是对于排查成本是极高的,在实际生产中,除非是核心的业务,基本上大家是忽略的
• 接下来会针对不能稳定复现的场景进行整理和思考,提出一般性的解决方式

不能稳定复现-排查成本高的原因

• 由于分布式的服务,请求链路长,日志分散
• 由于系统的qps比较高,打的日志特别多,找起来费事
• 由于代码里没有使用try-catch异常捕获,导致被全部异常拦截器捕获,异常堆栈不全
• 问题提出人无法提供有效的复现参数,导致无法定位日志

解决方案

• elk日志系统
• 代码返回增加异常捕获

不能稳定复现-场景和可能的原因

最坏的情况-马上就要定位,来不及加日志了

• 推荐使用arhtas ,Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。  https://arthas.aliyun.com/doc/#
• 针对这种场景可以使用watch命令和throwExp参数,以及-e

watch com.xxx.web.controller.XXXXController xxxMethod {params,returnObj,throwExp} -e  -x 6

参数说明

• watch命令可以查看返回值和入参
• throwExp 等于 Exception对象
• -e 表示只有在异常的时候才会输出,减少数据量

总结

• 复现对于解决问题,相当于debug对于开发,是事半功倍的利器
• 准确的掌握复现的工具使用,可以极大的提升问题的解决质量和解决效率