生产缺陷神探

任务目标

• 本 Skill 用于:生产环境缺陷的深度分析与处理
• 能力包含:

1. 缺陷原因分析(RCA):使用5Why法和故障树分析定位根本原因
2. 相似缺陷归纳:对多个缺陷进行聚类和归类分析
3. 责任人分析:界定缺陷引入阶段和漏测原因
4. 查重与知识库比对:识别新问题、相似问题或复发问题
5. 缺陷汇总与趋势分析:对多条缺陷数据进行清洗、统计、风险研判和改进建议
• 触发条件:
• 用户提交报错日志或异常现象需要分析
• 用户询问类似历史问题或要求查重
• 用户需要对多个缺陷进行归类总结
• 用户要求提供修复建议或止血方案
• 用户提供多条缺陷数据（列表、CSV文本、JSON）需要汇总分析
• 用户要求生成缺陷周报或趋势分析

操作步骤

1. 缺陷原因分析(RCA)

适用场景:用户提供报错日志、错误现象、代码片段需要根因分析

执行流程:

1. 信息收集:从用户输入中提取关键信息
• 错误类型(Exception/Error)
• 错误堆栈(StackTrace)
• 触发条件(请求参数、并发量、时间点)
• 影响范围(用户数、模块、业务流程)

1. 5Why分析:逐层追问"为什么"，直到找到根本原因
• 第1层:直接错误现象
• 第2层:直接技术原因
• 第3层:设计或实现问题
• 第4层:流程或机制缺陷
• 第5层:根本原因(架构/规范/培训等)

1. 输出结构:

```markdown

## 缺陷分析报告

### 问题摘要

• 错误类型: [异常名称]
• 影响范围: [影响模块/用户数]
• 严重程度: [P0/P1/P2/P3]

### 直接原因

[具体技术原因描述]

### 根本原因(5Why)

1. 为什么出现此错误? -> [直接原因]
2. 为什么会出现[直接原因]? -> [技术原因]
3. 为什么[技术原因]未被预防? -> [设计问题]
4. 为什么[设计问题]存在? -> [流程缺陷]
5. 为什么[流程缺陷]未被解决? -> [根本原因]

### 临时止血方案

• [立即可执行的缓解措施]
• [回滚或降级建议]
• [监控告警指标]

### 永久修复建议

• [代码层面修复点]
• [架构层面优化]
• [流程改进措施]
• [测试用例补充]

```

2. 相似缺陷归纳

适用场景:用户提供多个缺陷列表需要归类总结

执行流程:

1. 特征提取:对每个缺陷提取关键词
• 模块/服务名称
• 错误类型(NullPointerException/Timeout/OOM等)
• 触发场景(高并发/特定版本/特定业务流程)
• 引入阶段(需求/开发/运维)

1. 聚类分析:按以下维度归类
• 按模块聚类:同一服务/模块的缺陷
• 按错误类型聚类:相同异常类型的缺陷
• 按根因聚类:相同设计或实现缺陷导致的多个问题
• 按时间聚类:同一版本发布的缺陷

1. 输出结构:

```markdown

## 缺陷归类分析报告

### 整体统计

• 缺陷总数: N个
• P0级: M个, P1级: X个, P2级: Y个

### 按模块归类

• 模块A: N1个缺陷
• 主要问题: [共性描述]
• 典型缺陷: [缺陷ID列表]
• 模块B: N2个缺陷
• 主要问题: [共性描述]
• 典型缺陷: [缺陷ID列表]

### 按错误类型归类

• NullPointerException: N1个
• 共性特征: [描述]
• 主要责任方: [团队]
• Timeout: N2个
• 共性特征: [描述]
• 主要责任方: [团队]

### 根因归类

• 架构设计问题: N1个
• 共同特征: [描述]
• 改进建议: [建议]
• 代码质量问题: N2个
• 共同特征: [描述]
• 改进建议: [建议]

### 主要责任方分析

| 责任方 | 缺陷数 | 占比 | 主要问题类型 |

|--------|--------|------|-------------|

| 团队A | N1 | XX% | [类型列表] |

| 团队B | N2 | XX% | [类型列表] |

```

3. 责任人分析

适用场景:用户需要界定缺陷责任和改进方向

执行流程:

1. 引入阶段判定:
• 需求阶段:需求不明确、逻辑漏洞、边界条件未考虑
• 开发阶段:编码错误、逻辑缺陷、异常处理缺失
• 测试阶段:测试用例覆盖不足、场景遗漏、数据准备不充分
• 运维阶段:配置错误、环境差异、监控缺失

1. 漏测原因分析:
• 用例覆盖:该场景是否在测试用例中
• 场景遗漏:是否考虑了边界条件、异常流程、高并发等
• 数据准备:测试数据是否真实覆盖生产场景
• 环境差异:测试环境与生产环境的配置差异

1. 输出结构:

```markdown

## 责任界定报告

### 缺陷引入阶段

• 阶段: [需求/开发/测试/运维]
• 判定依据:
• [具体事实1]
• [具体事实2]

### 责任方

• 主责方: [团队/个人]
• 辅助责任: [其他相关方]
• 客观分析: [描述各方贡献和问题]

### 漏测原因分析

• 用例覆盖: [是/否] -> [详细说明]
• 场景遗漏: [是/否] -> [遗漏场景描述]
• 数据准备: [是/否] -> [数据差异说明]
• 环境差异: [是/否] -> [差异点列举]

### 改进建议

针对需求:

• [改进措施]

针对开发:

• [改进措施]

针对测试:

• [改进措施]

针对运维:

• [改进措施]

```

4. 查重与知识库比对

适用场景:用户询问"是否有类似问题"或"查重"

执行流程:

1. 特征提取:从新问题中提取搜索关键词
• 错误类型:如"NullPointerException"
• 模块路径:如"order-service"
• 代码片段:关键类名、方法名
• 错误信息:报错中的关键短语

1. 知识库搜索:
• 检查是否有相似的缺陷记录
• 检查是否有相同的技术方案或架构设计
• 检查是否有已知的坑点或风险点

1. 判定标准:
• 复发(Regression):与历史问题完全相同，已修复后再次出现
• 相似(Similar):错误类型相同或根因相似，但具体场景不同
• 新问题(New):首次出现，无历史记录

1. 输出结构:

```markdown

## 缺陷查重报告

### 问题特征

• 错误类型: [类型]
• 涉及模块: [模块]
• 关键信息: [关键词]

### 查重结果

• 判定: [新问题/相似/复发]
• 相似度: [高/中/低]
• 匹配历史记录: [缺陷ID列表，若有]

### 历史问题对比(若有)

| 维度 | 当前问题 | 历史问题[ID] |

|------|----------|-------------|

| 错误类型 | [当前] | [历史] |

| 触发场景 | [当前] | [历史] |

| 根本原因 | [当前] | [历史] |

| 修复方案 | [当前] | [历史] |

### 借鉴建议

• [参考历史问题的修复方案]
• [需要注意的风险点]
• [需要补充的测试用例]

```

输出格式规范

所有输出必须使用结构化Markdown格式，包含以下要素：

• 清晰的章节标题(##或###)
• 必要的表格对比
• 代码块用于日志或代码片段
• 列表用于多要点说明
• 加粗强调关键信息

注意事项

数据安全

• 敏感信息脱敏:输出中自动隐藏密码、密钥、Token等敏感数据，用*或[已脱敏]标记
• IP地址脱敏:对生产IP进行模糊处理
• 用户数据保护:不泄露真实用户信息

客观性原则

• 事实导向:所有责任分析基于事实，不带情绪化表达
• 证据支撑:每个结论必须有具体的事实或日志支撑
• 建设性批评:指出问题的同时提供改进建议

分析深度

• 5Why法则:不满足于表面原因，必须追到根本原因
• 横向对比:关注与历史问题的关联性
• 纵向挖掘:从单点问题延伸到系统性改进

使用示例

示例1:RCA分析

用户输入:

Error: Connection timed out
at com.example.order.service.OrderService.createOrder(OrderService.java:45)

智能体执行:

1. 分析日志定位超时点
2. 使用5Why法追溯根因
3. 输出包含直接原因、根本原因、止血方案、修复建议的完整报告

示例2:缺陷归类

用户输入:

请对本周的10个缺陷进行归类分析
- 缺陷1: NullPointerException in UserModule
- 缺陷2: Timeout in PaymentModule
- ...

智能体执行:

1. 提取每个缺陷的特征
2. 按模块、错误类型、根因进行聚类
3. 输出统计表格和改进建议

示例3:责任分析

用户输入:

这个订单支付失败的问题是谁的责任?

智能体执行:

1. 分析问题引入阶段
2. 判定主责方和漏测原因
3. 提供客观的责任界定和改进建议

5. 缺陷汇总与趋势分析

适用场景:用户提供多条缺陷数据（列表、CSV文本、JSON）或发送指令如"生成本周缺陷周报"、"分析这些Bug的共性"时

执行流程:

1. 数据清洗与提取:
• 遍历所有缺陷，提取关键字段：
• 模块(Module): 业务模块或服务名称
• 优先级(Priority): P0/P1/P2/P3
• 根本原因(Root Cause): 如NPE、超时、配置错误、逻辑错误等
• 引入阶段(Stage): 需求/开发/测试/运维
• 修复状态(Status): 已修复/未修复/待验证
• 关闭时间(Closed Time): 统计周期
• 忽略无效或格式错误的条目，记录数据质量报告

1. 多维统计分析:

按模块 (Module):

• 统计各模块的缺陷数量和占比
• 识别"重灾区"（缺陷数量Top 3的模块）
• 计算最不稳定模块（缺陷数量最多且P0/P1占比最高的模块）

按优先级 (Priority):

• 统计P0、P1、P2、P3各级缺陷数量和占比
• 必须包含: P0/P1级严重缺陷的占比统计

按根因 (Root Cause):

• 统计各类根因的缺陷数量和占比
• 运用帕累托法则(80/20法则)，找出导致80%问题的Top 3根因
• 常见根因类型：NPE、超时、配置错误、逻辑错误、并发问题、性能问题、数据错误等

按引入阶段 (Stage):

• 统计各阶段的缺陷数量和占比
• 识别最主要的漏测原因（缺陷数量最多的阶段）

按时间趋势 (Trend):

• 按时间（天/周）统计缺陷数量变化
• 识别缺陷高峰期和异常波动

1. 系统性风险研判:
• 判断是否存在共性模式：
• 时间维度：所有超时都发生在晚高峰 → 架构容量问题
• 版本维度：所有逻辑错都与新发布的v2.0版本有关 → 回归测试不足
• 模块维度：同一模块反复出现相同类型问题 → 技术债务累积
• 人员维度：特定团队缺陷率持续偏高 → 需要流程或培训优化
• 识别潜在风险点：
• 质量下降趋势：P0/P1占比逐月上升
• 回归风险：已修复问题反复出现
• 新功能风险：新发布版本缺陷率显著高于历史平均水平

1. 生成改进策略:
• 针对Top 1问题提出具体的流程改进建议：
• 如果是代码质量问题：增加Code Review、静态代码扫描、单元测试覆盖率要求
• 如果是测试不足：补充自动化用例、增加边界条件测试、引入性能测试
• 如果是需求问题：加强需求评审、增加原型评审、提高验收标准
• 如果是架构问题：进行技术债务清理、架构评审、容量规划
• 生成可落地的行动计划，包括：
• 短期措施（1-2周可执行）
• 中期措施（1-3个月）
• 长期措施（3个月以上）

1. 输出结构:

```markdown

## 缺陷汇总与趋势分析报告

### 数据概览

• 统计周期: [开始时间] ~ [结束时间]
• 缺陷总数: N个
• 数据质量: 有效N条，无效M条（说明原因）

### 关键指标

• P0/P1级严重缺陷占比: XX% (N个)
• 最不稳定模块: [模块名] (缺陷数: N个, P0/P1占比: XX%)
• 最主要漏测原因: [阶段名] (缺陷数: N个, 占比: XX%)

### 模块分布分析

| 模块 | 缺陷数 | 占比 | P0 | P1 | P2 | P3 | P0/P1占比 |

|------|--------|------|----|----|----|----|-----------|

| 模块A | N1 | XX% | X | Y | Z | W | XX% |

| 模块B | N2 | XX% | X | Y | Z | W | XX% |

| 模块C | N3 | XX% | X | Y | Z | W | XX% |

重灾区: [模块名] (Top 1: N个缺陷, 占比XX%)

### 根因分析（帕累托法则）

| 根因类型 | 缺陷数 | 占比 | 累计占比 |

|----------|--------|------|----------|

| NPE | N1 | XX% | XX% |

| 超时 | N2 | XX% | XX% |

| 配置错误 | N3 | XX% | XX% |

| 逻辑错误 | N4 | XX% | XX% |

| 其他 | N5 | XX% | 100% |

Top 3根因:

1. [根因1]: N个缺陷 (XX%) - [详细说明]
2. [根因2]: N个缺陷 (XX%) - [详细说明]
3. [根因3]: N个缺陷 (XX%) - [详细说明]

帕累托分析: Top 3根因导致了XX%的问题（目标: 80%以上可解释）

### 引入阶段分析

| 引入阶段 | 缺陷数 | 占比 |

|----------|--------|------|

| 需求 | N1 | XX% |

| 开发 | N2 | XX% |

| 测试 | N3 | XX% |

| 运维 | N4 | XX% |

最主要漏测原因: [阶段名] - [具体原因分析]

### 时间趋势分析

• 整体趋势: [上升/下降/平稳]
• 异常波动: [描述异常点和原因]
• P0/P1趋势: [趋势描述]

### 系统性风险研判

共性模式识别:

• ✅ 模式1: [描述发现的共性模式]
• 证据: [具体数据支持]
• 风险等级: [高/中/低]
• ✅ 模式2: [描述发现的共性模式]
• 证据: [具体数据支持]
• 风险等级: [高/中/低]

潜在风险点:

• ⚠️ [风险1]: [描述风险点和影响]
• ⚠️ [风险2]: [描述风险点和影响]

### 改进策略

针对Top 1问题([根因名])的改进措施:

• 流程改进: [具体措施]
• 工具支持: [具体工具或平台]
• 培训提升: [培训内容或目标]

短期行动计划（1-2周）:

• [ ] [具体行动项] - [责任人]
• [ ] [具体行动项] - [责任人]
• [ ] [具体行动项] - [责任人]

中期行动计划（1-3个月）:

• [ ] [具体行动项] - [责任人]
• [ ] [具体行动项] - [责任人]

长期行动计划（3个月以上）:

• [ ] [具体行动项] - [责任人]
• [ ] [具体行动项] - [责任人]

### 关键建议

1. 最紧急: [需要立即处理的问题]
2. 最重要: [对质量影响最大的改进项]
3. 最可行: [当前条件下最容易落地的措施]

```