Skip to content

SKILL.md

Latest commit

 

History

History
140 lines (107 loc) · 7.4 KB

SKILL.md

File metadata and controls

140 lines (107 loc) · 7.4 KB
name moe-postmortem
description 一个混合专家事故复盘技能，对生产事故进行结构化的根因分析、影响面评估和系统性修复建议，与知识库交叉验证故障传播路径。

MoE-Postmortem 目标 (MoE-Postmortem Goal)

在生产事故发生后，通过多维度专家逆向分析故障的根因、传播路径和防御缺失，输出一份结构化的"5 Why"风格复盘报告，以及可执行的系统性修复建议。

操作指令 (Instructions)

第 1 步：路由器 — 事故信息收集 (Router — Incident Data Collection)

  1. 收集事故数据：向用户收集以下信息（部分可选）：
    • 错误日志 / 堆栈追踪 (Stack Trace)。
    • 告警信息（来自监控系统、PagerDuty、Datadog 等）。
    • 用户报告或工单描述。
    • 事故发生的时间线（何时开始、何时发现、何时恢复）。
    • 已知的临时修复措施（如果有）。
  2. 检测项目类型：识别技术栈和部署架构。
  3. 检查 KB 存在性：确定是否存在知识库。
  4. 激活专家：
    • 始终执行：第 1 层（5 个复盘专家）。
    • 有条件执行：第 2 层（KB 传播路径追踪）— 仅当 KB 存在时。

第 2 步：第 1 层 — 复盘专家组（并行执行 / Layer 1 — Postmortem Experts）

并行执行所有 5 个专家。

专家 1：根因分析 (Root Cause Analysis)

  • 关注点：从堆栈追踪和日志出发，追踪到可能的根因。区分"触发因素 (Trigger)"和"根本原因 (Root Cause)"。使用 5 Why 方法逐层追问。
  • 约束：不要提出修复建议。仅关注"为什么会发生"。

专家 2：影响面评估 (Blast Radius Assessment)

  • 关注点：受影响的用户数/请求数、数据是否损坏或丢失、是否有级联故障（如一个服务的失败导致了另一个服务的降级）、SLA 是否被违反。
  • 约束：不要分析根因。仅关注"影响有多大"。

专家 3：时间线重建 (Timeline Reconstruction)

  • 关注点：从日志和告警中重建事故的完整时间线。关键节点包括：首次异常出现时间、告警触发时间、人工介入时间、恢复时间。计算 MTTD (平均检测时间) 和 MTTR (平均恢复时间)。
  • 约束：不要分析原因或提出建议。仅关注"发生了什么，按什么顺序"。

专家 4：防御缺失分析 (Defense Gap Analysis)

  • 关注点：审视现有的防御层——为什么监控没有更早发现？为什么测试没有拦住这个 Bug？为什么代码审查没有捕获这个问题？是否缺少熔断、限流或回退机制？
  • 约束：不要分析根因或评估影响。仅关注"为什么防线失效了"。

专家 5：系统性修复建议 (Systemic Fix Recommendations)

  • 关注点：基于其他专家的发现，提出短期修复（即时止血）和长期修复（架构/流程改进）。修复建议必须可执行且附带负责人建议。按优先级排序。
  • 约束：不要重复分析。仅关注"怎么修、怎么防止再次发生"。

统一输出格式（所有专家适用）

[Dimension/维度: <专家名称>]
Finding/发现: <简明描述>
Evidence/证据: <日志片段、时间戳或事实引用>

第 3 步：第 2 层 — KB 故障传播路径追踪（按条件执行 / Layer 2 — KB Fault Propagation Tracing）

如果项目不存在 KB，请跳过此步骤。

  1. 故障入口定位：从堆栈追踪或日志中定位到故障的入口源码文件。
  2. KB 链路追踪：通过 fingerprint 找到关联的 KB 文档，沿 SSOT 链接追踪故障可能的传播路径——哪些下游模块可能被间接影响。
  3. 传播图生成：输出一份 Mermaid 图展示：故障源 → 直接影响模块 → 间接影响模块，每个节点标注影响等级。
  4. KB 盲区标记：如果故障涉及的模块在 KB 中没有文档记录，标记为知识盲区。根据情况建议：
    • 如果该模块是已有且未覆盖的，建议通过 kb-build 新建文档。
    • 如果该模块已有 KB 文档但内容过期，建议通过 kb-update 刷新。

第 4 步：聚合器 — 生成复盘报告 (Aggregator — Generate Postmortem Report)

输出一份结构化的复盘报告：

# 🚨 事故复盘报告 (Postmortem Report)

## 事故概要 (Incident Summary)
- **日期**: <事故日期>
- **持续时间**: <从首次异常到恢复的时长>
- **严重程度**: [P0|P1|P2|P3]
- **影响面**: <受影响用户数/请求数>

## ⏱️ 时间线 (Timeline)
| 时间 | 事件 |
|---|---|
| HH:MM | 首次异常出现 |
| HH:MM | 告警触发 |
| HH:MM | 人工介入 |
| HH:MM | 恢复 |

- **MTTD**: <检测用时>
- **MTTR**: <恢复用时>

## 🔍 根因分析 (Root Cause — 5 Whys)
1. **Why 1**: <第一层原因>
2. **Why 2**: <第二层原因>
3. **Why 3**: <第三层原因>
...
**根本原因 (Root Cause)**: <最终归因>
**触发因素 (Trigger)**: <直接触发事故的操作/变更>

## 💥 影响面 (Blast Radius)
<受影响的服务、用户群体、数据影响>

## 🛡️ 防御缺失 (Defense Gaps)
<为什么现有防御未能阻止>

## 🔧 故障传播路径 (Fault Propagation) (如果有 KB)
<Mermaid 图展示传播链路>

## ✅ 修复计划 (Action Items)
| 优先级 | 类型 | 行动项 | 负责人建议 |
|---|---|---|---|
| P0 | 短期 | <即时止血措施> | <建议团队> |
| P1 | 长期 | <架构/流程改进> | <建议团队> |

示例 (Examples)

示例：数据库连接池耗尽导致 API 503

  1. 数据收集：堆栈追踪显示 ConnectionPoolExhaustedError，Datadog 显示 API 延迟在 14:23 突增。
  2. 第 1 层 (Layer 1)（并行执行）：
    • Root Cause (根因)：Why 1: 连接池耗尽 → Why 2: 慢查询占用连接不释放 → Why 3: 新上线的报表查询未加索引 → 根本原因：缺少查询性能审查流程。触发因素：昨天的 PR #342 上线后引入了全表扫描。
    • Blast Radius (影响面)：30% 用户在 14:23-14:58 之间遭遇 503 错误，约 12,000 个失败请求。无数据损坏。
    • Timeline (时间线)：14:23 首次 503 → 14:31 告警触发 → 14:42 工程师开始排查 → 14:58 回滚 PR #342 恢复。MTTD = 8 min, MTTR = 35 min。
    • Defense Gaps (防御缺失)：CR 时 moe-cr 未被使用，Performance 专家本可标记全表扫描。Staging 环境数据量太小没有触发问题。
    • Fixes (修复)：短期 — 为报表查询添加索引 + 设置连接池超时。长期 — PR 合入前强制运行 moe-cr 的 Performance 专家。
  3. 第 2 层 (Layer 2)：KB 链路追踪显示 database.md → api-gateway.md → auth-flow.md。连接池耗尽影响了鉴权中间件的 DB 查询，导致 Auth 也级联失败。
  4. 聚合器：输出 P1 级事故复盘报告，含 Mermaid 传播图和 4 项 Action Items。

联动触发 (Cross-Skill Triggers)

以下建议在对应技能已安装时可选触发。调用时使用技能名称，Agent 会自动查找对应的 SKILL.md。如果技能未安装，在结果中告知用户并建议手动执行对应操作。

触发条件 建议调用技能 目的
发现 KB 盲区（故障模块无 KB 文档） kb-build 为暴露出的知识盲区新建 KB 文档
发现 KB 链路中存在过期文档 kb-update 刷新与故障相关的过期知识库文档