bug-analysis

Bug 分析

概述

此技能提供系统化的 Bug 分析方法，用于识别根本原因、评估影响、划分严重程度，并生成可执行的修复建议。它有助于高效地对 Bug 进行分类处理，并为开发团队提供结构化分析。

核心分析工作流

第 1 步：初步分类与信息收集

收集必要信息：

• Bug 描述和症状
• 复现步骤（验证步骤是否有效）
• 预期行为与实际行为
• 环境详情（操作系统、浏览器、版本、配置）
• 错误消息、堆栈跟踪、日志
• 截图或视频
• 用户影响和发生频率

快速评估：

• 严重程度：严重/高/中/低
• 类型：功能/性能/安全/UI/数据/集成/配置/回归
• 优先级：根据严重程度和业务影响确定
• 可能的重复问题：搜索现有问题

第 2 步：Bug 分类

严重程度分类（详细标准请参阅 severity-guidelines.md）：

严重（P0） - 响应时间：立即处理（<1 小时）

• 系统中断、数据丢失、安全漏洞，且没有可行的变通方案

高（P1） - 响应时间：当天处理

• 主要功能不可用、对用户影响显著（>25%）、变通方案难以实施

中（P2） - 响应时间：1 周内

• 功能部分不可用、影响中等、有可用的变通方案

低（P3） - 响应时间：待办

• 次要问题、外观问题、影响极小

Bug 类型类别：

• 功能：功能未按规范工作
• 性能：响应缓慢、超时、资源问题
• 安全：漏洞、未授权访问
• UI/UX：视觉异常、可用性问题
• 数据：损坏、丢失、处理错误
• 集成：API 故障、第三方问题
• 配置：环境或部署问题
• 回归：原本正常工作的功能出现故障

第 3 步：根本原因分析

调查流程：

1. 检查错误证据

   • 解析堆栈跟踪，确定故障点
   • 将错误代码对应到已知问题
   • 检查近期代码变更（git blame、提交历史）

2. 复现问题

   • 验证复现步骤
   • 在不同环境中测试
   • 更改输入以确定边界
   • 记录稳定的复现方法

3. 追踪执行流程

   • 沿着代码路径从入口追踪到故障点
   • 找出实际行为与预期行为的偏差
   • 检查数据转换和控制流
   • 检查相关代码段

4. 分析依赖项

   • 验证库和框架版本
   • 检查依赖项中是否存在已知问题
   • 检查集成点
   • 使用不同的依赖项版本进行测试

常见的根本原因模式：

• 逻辑错误（条件或计算错误）
• 空值/未定义引用错误
• 竞态条件和时序问题
• 内存泄漏
• 边界条件（差一错误、溢出）
• 配置问题
• 依赖项问题
• 集成故障

有关详细的分析技术，请参阅 analysis-techniques.md，内容包括：

• 五个为什么分析法
• 堆栈跟踪分析
• 差异分析
• 数据流追踪
• 假设检验
• 证据收集方法

第 4 步：影响评估

从多个维度评估影响：

用户影响：

• 受影响用户的数量/比例
• 用户工作流受到的干扰
• 受影响的用户群体

业务影响：

• 收入损失或风险
• SLA 违规
• 对客户满意度的影响
• 声誉风险

系统影响：

• 性能下降
• 资源消耗
• 连锁故障
• 数据完整性风险

安全影响（如适用）：

• 机密性：数据暴露程度
• 完整性：未经授权的修改
• 可用性：服务中断
• 可利用性

范围定义：

• 受影响的版本/发行版
• 受影响的平台/浏览器
• 受影响的功能/工作流
• 回归范围

第 5 步：修复建议

生成结构化修复策略：

1. 立即缓解（如尚未完成）：

• 为用户提供变通方案
• 调整配置以减轻影响
• 使用功能标志停用有问题的代码
• 如果近期的回归导致问题，提供回滚选项

2. 永久解决方案：

• 需要进行的具体代码更改
• 需要修改的文件及行号
• 所需的设计更改
• 所需的数据库迁移或清理
• 所需的配置更新

3. 测试要求：

• 需要添加的单元测试
• 所需的集成测试
• 用于防止问题再次发生的回归测试
• 适用时进行性能／安全测试

4. 预防措施：

• 代码审查重点
• 需要增加的验证
• 需要添加的监控／告警
• 文档更新
• 流程改进

输出格式

使用以下模板提供结构化分析：

标准 Bug 分析：使用 output-templates.md 中的模板，包括：

• Bug 摘要，含严重性和优先级
• 环境和复现步骤
• 根因分析及证据
• 影响评估
• 建议的修复方案及测试计划

专项报告（参见 output-templates.md）：

• 安全漏洞报告：CVSS 评分、攻击途径、披露计划
• 性能 Bug 报告：指标、分析结果、优化策略
• 崩溃分析报告：堆栈跟踪、内存状态、崩溃触发条件

特殊分析场景

安全漏洞

对于安全问题：

1. 使用 CVSS 评估：攻击途径、复杂度、权限、影响
2. 确定可利用性：远程利用、是否需要身份验证
3. 制定遏制计划：立即修补、访问限制、监控
4. 披露策略：时间线、通知、合规要求（CVE、GDPR、PCI-DSS）

安全专项分流请参阅 severity-guidelines.md。

性能问题

对于性能 Bug：

1. 建立基线：预期指标、SLA 阈值
2. 找出瓶颈：CPU 分析、内存模式、I/O、数据库查询
3. 量化性能下降：响应时间增加、吞吐量降低
4. 优化策略：代码优化、缓存、索引、架构更改

崩溃分析

对于应用程序崩溃：

1. 分析崩溃转储：异常类型、堆栈跟踪、线程状态
2. 确定触发条件：用户操作、系统状态、数据输入、时序
3. 评估稳定性影响：发生频率、受影响场景、数据丢失风险
4. 恢复策略：崩溃处理、优雅降级、监控

调查工具和命令

详细的命令参考请参阅 investigation-commands.md：

版本控制：

• git bisect - 找出引入 Bug 的提交
• git blame - 查看最近修改代码的人
• git log -S "text" - 查找代码变更的时间

日志分析：

• grep -A 5 -B 5 "error" app.log - 查找错误及其上下文
• tail -f app.log | grep ERROR - 实时监控错误
• 使用 awk 和分析脚本解析日志

数据库调查：

• PostgreSQL：慢查询分析、索引使用情况
• MySQL：进程列表、死锁检测
• MongoDB：操作分析、集合统计信息

系统监控：

• 进程监控：top、ps、htop
• 内存分析：free、pmap、valgrind
• 网络分析：netstat、tcpdump、curl -v

应用程序调试：

• Node.js：node --inspect、性能分析、堆快照
• Python：pdb、cProfile、内存分析
• Java：jmap、jstack、飞行记录器
• Docker/Kubernetes：容器日志、exec、调试

最佳实践

调查原则

• 以证据为依据：基于具体数据得出结论，而非依赖假设
• 系统化：遵循合乎逻辑的调查流程
• 以假设为导向：提出假设、进行测试并验证结果
• 记录一切：记录发现、推理过程和决策
• 考虑多种原因：不要只盯着最初的猜测

有效沟通

• 使用清晰的语言：与非技术相关方沟通时避免使用术语
• 提供背景信息：解释 Bug 为何重要
• 设定预期：给出切合实际的时间安排和复杂度预估
• 提供临时解决方案：尽可能立即帮助用户
• 跟进进展：向相关方更新进展

注重预防

修复 Bug 后：

• 找出规律：识别多个 Bug 之间的常见原因
• 改进测试：为 Bug 场景增加测试覆盖
• 加强监控：为类似问题添加告警
• 更新流程：更新代码审查清单和部署流程
• 记录经验教训：更新知识库

快速参考

常见根本原因检查清单

• Null/undefined 引用
• 差一错误或边界条件
• 竞态条件或时序问题
• 内存泄漏
• 缺少验证或错误处理
• 配置问题
• 依赖版本不匹配
• API 契约变更
• 数据库架构不匹配
• 权限配置错误
• 资源耗尽
• 缓存问题
• 时区/日期处理问题
• 字符编码问题

快速诊断命令

# Service status
systemctl status service_name

# Resource usage
top -bn1 | head -20                    # CPU
ps aux --sort=-%mem | head -10         # Memory
du -sh /* | sort -rh | head -10        # Disk

# Recent changes
git log --since="1 day ago" --oneline

# Error analysis
tail -100 /var/log/app.log | grep -i error
grep ERROR /var/log/app.log | wc -l

与开发工作流集成

Bug 生命周期：

1. 新建 → 收到报告
2. 初步评估 → 分析并确定优先级（使用此技能）
3. 已确认 → 已复现并找出根本原因
4. 已分配 → 已分配开发人员
5. 进行中 → 正在实施修复
6. 代码审查 → 正在审查修复
7. 测试 → QA 验证
8. 已修复 → 已部署
9. 已关闭 → 已验证问题解决

文档要求：

• 代码链接：文件及行号
• 测试链接：验证修复的测试用例
• 监控链接：仪表板或告警
• 相关问题链接：重复问题及相关 Bug
• 更新文档：如有面向用户的变更

参考文件

根据分析需要加载参考文件：

• 严重性指南：遇到以下情况时，参见 severity-guidelines.md：

  • 确定 Bug 的严重性和优先级
  • 了解初步评估标准
  • 需要严重性/优先级矩阵
  • 对安全漏洞进行分类

• 分析技术：遇到以下情况时，参见 analysis-techniques.md：

  • 需要详细的根本原因分析（RCA）方法
  • 使用五个为什么或其他技术
  • 进行假设测试
  • 收集证据
  • 使用特定的调试策略

• 输出模板：遇到以下情况时，参见 output-templates.md：

  • 创建 Bug 报告
  • 编写根本原因分析文档
  • 记录安全漏洞
  • 报告性能问题
  • 分析崩溃
  • 标记重复问题

• 调查命令：遇到以下情况时，参见 investigation-commands.md：

  • 需要特定的命令语法
  • 使用版本控制（git）
  • 分析日志和数据库
  • 监控系统资源
  • 调试应用程序
  • 使用容器工具（Docker、Kubernetes）