bug的常见排查和分析思路以及相关的原因分类

作为开发人员，经常会收到来自用户和QA，领导反馈的各种问题。 为了快速问题，我们有时需要站在更高的角度，更全面的看待问题。才能更快锁定问题。

具体的bug还需要结合企业实际业务情况，相关的框架，依赖库，依赖api等，发布环境，发布配置，发布流程等问题 。

一、先上一些干货(bug排查中的常见原因分类)

二、排查定位的常见方法和定位思路.

 2.1一般根据异常提示或日志快速定位.

1)确定相关的异常提示是否能直接定位问题.

2)确定是否存在相关的应用日志，错误日志，操作系统日志，网络iis，apache，数据库日志，云服务日志等以便可以排查.

3)条件允许的情况下确定相同业务场景，相同用户，相同环境是否能重现.

4)确定是否有缓存问题.

浏览器缓存，cdn缓存等.

2.2无法直接定位时进行排除推理法.

1)确定版本(尤其对客户端app，api等有版本管理的地方适用).

   版本确定了则可以排查本版本的代码，配置，依赖库，发布环境，发布流程出现什么变更，然后依次排查。

2)确定问题出现的范围(用户范围，业务数据范围，新老数据范围).

    范围确定了则寻找相关的规律，从用户的角色，权限，历史数据，业务数据的状态（是否人工修改，是否因为没有事务导致不一致），是否涉及新处理不兼容老数据。

3)确定输入的业务数据本身是否有问题.

    确定输入，待处理的数据本身是否合理： 长度超过字段限制，内容被截断，tirm(), 乱码，编码，content-type,状态，过期，风控,  关联主体被禁用等.

4)查询已存在的知识库，bug管理系统，FQA等.

   借鉴历史反馈，解决方案，推测相关的处理办法。 

5)根团队确认近期公司的基础设施是否有变更( 网络环境，云服务，域名，cdn等服务商，api供应商，代理IP，安全策略等)

   会经常涉及到网络访问不通，禁止访问，缓存，重复访问,api不兼容等问题。

2.3对于莫名其妙的非正常问题.

1) 对于数据不合理，不正常，不一致，看起来无法因为代码引起的问题.

    考虑修改该数据是否有多个入口( web请求，job服务,  人工脚本修改，非事务操作导致的部分失败,sql注入，权限漏洞导致不相关的修改)

2)对于开发者那边正常，发布后不正常的问题.

    考虑环境是否一致（系统，浏览器，依赖组件，服务，硬件或云资源),  考虑是否因为混淆加壳导致代码异常或被杀毒软件拦截等。

 3)内存溢出的常见问题。

几个对象初始化形成了循环,属性形成了循环,  递归形成了循环, 线程锁死锁,同步方法内调用async方法, Task死循环， 存在只申请而不释放资源的处理, 存在释放的比较慢但申请的比较快的问题。

 4)对于微服务环境.

 k8s的老节点在Running，新节点还处于Pending状态.  加上一个负载均衡机制，会造成一个请求成功，下一个请求失败，循环交替或随机成功失败的问题。

 5)对于知道资源占用大户的进程，却不知道代码具体位置的。

   使用一些dump技术去分析观察。

 6)对于数据库访问压力大，cpu/内存占用高的问题.

   通过数据库日志，云数据库的慢sql统计，推荐办法等快速定位。  再就是要查看下相关的数据库配置是否合理。