背景
最近发现团队中一些同学对如何排查一个bug，思路不够清晰。本文随笔整理：常规情况下，我们是如何排查一个bug的。
1. 弄清楚问题
有些人看到“弄清楚问题”，可能会觉得好笑，这不是废话吗？
实际上，我遇到很多同学连问题都没搞清楚，就开始在排查问题，继续追问是如何排查的，回答更是模糊。
我们首先要弄清楚问题是什么，最起码的是“复现步骤”、“预期结果”、“实际结果”、“是否必现”。
当然问题描述越细致，越有助于问题的排查。
《【效能提升】测试人员提bug，应该提供哪些信息以便排查问题？》描述了理想情况下，我们想知道问题的哪些信息。
2. 复现问题
用户反馈的问题一般都发生在生产环境，我们需要在测试环境复现此问题，有助于我们排查问题，也有助于测试人员验证问题是否修复到位。
复现问题这个步骤一般由测试人员完成。
3. 排查问题
排查问题有许多排查手段，排查手段没有先后之分，我们会针对不同的问题优先选择某些手段以便快速解决问题。
3.1. 通过“日志”、“审计日志”、“堆栈”、“错误收集”等信息定位问题
如果系统有打印日志、记录审计日志、打印异常信息、异常收集，可以通过这些信息快速的定位问题发生在哪里，再结合对应的代码实现，很容易就能定位到问题。
（这看似理所当然的一个步骤为什么要列出来？实际我遇到太多同学连异常日志都不看，就匆匆跑去看代码实现了）
- 日志：应用日志、Web服务器日志
- 审计日志：关键操作审计日志、请求响应报文日志
- 异常信息：日志中应该包含异常信息（包括堆栈信息）
- 异常收集：如Sentry
- 等等
3.2. 阅读源码排查问题点
1、阅读发生问题的相关代码实现，理解功能的实现逻辑，分析问题有可能发生在实现的哪几个点。
2、然后，按照怀疑的这几个点，按照优先级排查验证。这个排查验证有很多种方式，最老实的可以通过“添加日志打印，然后查看日志”来验证你的怀疑点。
3.3. 经验主义
某些系统，经常出现某些问题（而此问题至今仍未修复），基于经验，你可以消除你怀疑的问题，观察问题是否还能复现。
比如，A系统，常出现消息队列阻塞，至今仍未修复，现在出现某个问题，你可观察该消息队列的消息都完成消费了，再观察问题是否还能复现。
后记
有些经验的小伙伴看到此文，可能会觉得很多步骤是理所当然的，不用特别说就应该这么做，实际上，我见过挺多入行不久的小伙伴还没掌握。
小弟不才，暂时只回忆起这些点，后续根据实战迭代起来哦！！