1、打 log，看日志
代码 log 的重要性和代码自身是一样的。在要害的逻辑和判断条件处增加日志，最好做到即便不做 debug 也能够理解代码运行逻辑。如果不晓得哪些地方应加日志，简略的形式就是所有的自定义函数的入口和进口都增加上日志。能够应用切面编程或者代理，本人封装一个 log 的框架，利用切面或代理操作就会简略很多，对原始的代码入侵也小。
日志中不仅要有流程的标记，还有有状态信息，比方：工夫、线程号或用户 id、要害的参数信息。能阐明谁在什么工夫什么条件下做了一件什么事件，把这个事件说分明就行。
这样的日志量可能会很大，日志的分级解决也很重要，trace、debug、info、warn、error 等信息别离示意。error 信息中除了异样时的运行栈信息，还须要有一些要害的内存参数信息，比方以后办法的参数或者逻辑的要害条件等。
2、用户访谈
要不要做用户访谈？打电话还是与用户见面？这个要看工程师的集体沟通能力。有的人和用户沟通亲切且业余，沟通能力强，有谈话的技巧，用户不恶感，那就能够做用户访谈，和用户理解分明过后产生问题，做了什么操作。很多奇怪的问题都是和特定的操作环境甚至操作流程有关系，做用户访谈要问分明的几件事：
- 过后的操作环境，零碎，运行环境
- 网络环境，如果是网络问题，和用户沟通一下能不能接入他们网络复现问题
- 过后的操作过程，操作程序
- 一些非凡的操作习惯
记下根本的信息，最好用脑子记，过后不要打字或用写下来，这样会给用户压迫感，感觉太正式了，说的内容就会本人提前解决一下。很多操作的细节就是在无心中提到的，所以访谈的时候能够适当随便些，然而留神凝听，如果有细节感觉有点不太一样，先记在心里，不要打断用户，让他顺畅的说完，再发问。
3、代码 review，画流程图
梳理分明代码逻辑，多看几遍代码，一边看代码，一边和需要 / 逻辑比照，发现异常的中央。如果逻辑比较复杂，档次比拟深，看一遍记不住所有逻辑，那最好画出流程图，逻辑梳理找到破绽或可疑点。运气不好，还要减少 log，测试调试。
4、用 google
这个老本最低，能够先做。把问题、异样信息贴到 google 外面，先看看其他人遇到相似的状况了吗？60% 的问题这种形式就能解决。
5、用工具剖析运行状态
如果能够复现问题了，就能够应用一些内存剖析工具，查看产生问题的状态。不同技术都有内存剖析工具，jmap, jstack 等等，多多利用，学习怎么应用这样工具会让解决问题效率晋升很多。
6、评估危害
没有不存在 bug 的程序，评估 bug 的危害和解决老本就很重要。
有没有间接影响到了用户体验，影响到领取流程，影响到了生命安全，影响到用户比例有多少。
有的问题频率尽管不高，然而很致命；有到尽管不会挫伤生命，然而规模大；有的规模不大，也不致命，但用户产生一次就被劝退了。这些都很重大。
危害的评估，次要是三个方面：规模频率、重大水平、危害是否可逆。