本篇记录一下本人排查 bug 的大概思路及具体实践

虽然现在很多时候出现 Bug ，已经是直接丢给 GPT 先问再说~

但是这样同样消磨掉了很多经验的累积，很多时候改完只是能用了，具体发生了什么问题是一问三不知，主打一个坑是踩的，bug 是不知道的，下次是还会报相同的 Bug的😂。代码有可能越改越陌生，最后反而需要时间去熟悉代码，另外的话，很有可能 GPT 还会改错，这种情况是最糟糕的，所以结合以前排查的一些思路和角度，尽量形成一个自用向的 Bug 排查实践。

总体思路来说，keywords 为拆分-定位

摸清 bug 上下游的过程，拆分发出请求到接收响应这个过程中的全部流程，先排查现有日志的显示查看是否存在错误 log 输出.

若是定位到则继续细化缩小范围.

若是没有则最麻烦，目前想到方法为猜测+初步验证复现的方式，外加复述整体流程+AI 模型判断 (小黄鸭判别法，AI 就是我的小黄鸭)，否则只能半猜半蒙夹带打断点，一点一点缩小范围了 ~

流程 (理想状态下) 大概分为了几个方面:

  • 问题背景
  • 排查过程和思路
  • 验证及总结
  • 额外的一些补充和拓展

问题背景

Bug 的表现形式: 比如直接报错或者是给出错误信息，或者是增加服务器压力，增加运行时间，增加无用的缓存信息等等

影响了哪些范围: 包括影响的用户范围，哪些功能模块及大概的业务范围 –>由此判断这个 bug 是否属于紧急 bug 🤣, 是否需要加班紧急修改或者是添加补丁先凑合用

复现条件: 在什么条件下可以出现对应的 Bug, 是否可以稳定复现

业务背景: 熟悉包括相关的业务流程和技术栈包括使用的云基础设施服务.

初步判断和猜测: 基于上述几个方面有个初步的猜测，这是从经验出发，即使猜测错误也没关系，可以记录当时的思考, 有助于后续的复盘

排查思路

  • 日志分析: 查看错误日志，从错误日志中定位异常信息，从而尽可能缩小 bug 所在的范围
  • 环境排查: 可以查看除了生产环境外, 测试环境中是否会出现相同的 bug, 用来判断相关配置项是否正确.
  • 代码排查:
    • 检查可疑的代码逻辑
    • 关键的代码可采用断点调试，进一步明确定位问题
    • 单元测试，通过测试用例来验证猜测
  • 网络排查:

问题定位与解决

  • 定位问题存在，确定原因（待定）因为有时候不一定可以成功了解到具体的原因，或者是使用第三方库或者包的问题
  • 确认解决方案
  • 验证 Bug 是否解决

总结复盘（有时间的话）

  • 出现 Bug 的原因
  • 测试时没有考虑清楚的情况
  • 监控方面是否可以改进（如果有监控的话）
  • 拓展知识点
    • 问题设计的技术原理
    • 同类问题的其他表现形式
    • 相关 Bug 的排查和处理建议，总结形成相关 Bug 的 SOP（标准操作流程）