调查 bug 的手段有哪些？（没有调查，就没有发言权，二）Jan 13, 2021

调查的 bug 的手段有哪些？

1、打 log，看日志

代码 log 的重要性和代码本身是一样的。在关键的逻辑和判断条件处添加日志，最好做到即使不做 debug 也可以了解代码运行逻辑。如果不知道哪些地方应加日志，简单的方式就是所有的自定义函数的入口和出口都添加上日志。可以使用切面编程或者代理，自己封装一个 log 的框架，利用切面或代理操作就会简单很多，对原始的代码入侵也小。

日志中不仅要有流程的标记，还有有状态信息，比如：时间、线程号或用户 id、关键的参数信息。能说明谁在什么时间什么条件下做了一件什么事情，把这个事情说清楚就行。

这样的日志量可能会很大，日志的分级处理也很重要，trace、debug、info、warn、error 等信息分别表示。error 信息中除了异常时的运行栈信息，还需要有一些关键的内存参数信息，比如当前方法的参数或者逻辑的关键条件等。

2、用户访谈

要不要做用户访谈？打电话还是与用户见面？这个要看工程师的个人沟通能力。有的人和用户沟通亲切且专业，沟通能力强，有说话的技巧，用户不反感，那就可以做用户访谈，和用户了解清楚当时发生问题，做了什么操作。很多奇怪的问题都是和特定的操作环境甚至操作流程有关系，做用户访谈要问清楚的几件事：

1. 当时的操作环境，系统，运行环境

2. 网络环境，如果是网络问题，和用户沟通一下能不能接入他们网络复现问题

3. 当时的操作过程，操作顺序

4. 一些特殊的操作习惯

记下基本的信息，最好用脑子记，当时不要打字或用写下来，这样会给用户压迫感，感觉太正式了，说的内容就会自己提前处理一下。很多操作的细节就是在无意中提到的，所以访谈的时候可以适当随意些，但是注意聆听，如果有细节感觉有点不太一样，先记在心里，不要打断用户，让他顺畅的说完，再提问。

3、代码 review，画流程图

梳理清楚代码逻辑，多看几遍代码，一边看代码，一边和需求/逻辑对比，发现异常的地方。如果逻辑比较复杂，层次比较深，看一遍记不住所有逻辑，那最好画出流程图，逻辑梳理找到漏洞或可疑点。运气不好，还要增加 log，测试调试。

4、用 google

这个成本最低，可以先做。把问题、异常信息贴到 google 里面，先看看其他人遇到类似的情况了吗？60%的问题这种方式就能解决。

5、用工具分析运行状态

如果可以复现问题了，就可以使用一些内存分析工具，检查发生问题的状态。不同技术都有内存分析工具，jmap, jstack 等等，多多利用，学习怎么使用这样工具会让解决问题效率提升很多。

6、评估危害

没有不存在 bug 的程序，评估 bug 的危害和解决成本就很重要。

有没有直接影响到了用户体验，影响到支付流程，影响到了生命安全，影响到用户比例有多少。

有的问题频率虽然不高，但是很致命；有到虽然不会伤害生命，但是规模大；有的规模不大，也不致命，但用户发生一次就被劝退了。这些都很严重。

危害的评估，主要是三个方面：规模频率、严重程度、危害是否可逆。