fault-rca-report-generation

name	fault-rca-report-generation
description	专业的故障诊断根因分析和报告生成 skill。当系统存在具体的故障（如服务不可用、时延飙升、进程崩溃等），且前置节点已生成1个或多个诊断文件时，用户要求基于这些诊断文件内容进行综合的根因分析（RCA）、影响评估，并生成最终的结构化故障诊断报告时，必须使用此 skill。

故障诊断根因分析和报告生成 Skill

本技能通过对前置收集到的诊断证据（如日志片段、指标异常、系统状态等）进行关联分析，推断导致系统故障的根本原因，评估业务影响范围，并最终生成标准化的故障诊断报告。

重要原则：本 skill 主要执行逻辑推理与报告生成。所有分析需基于已有的客观证据数据，严禁无中生有或臆测。

---

文件结构

fault-rca-report-generation/
└── SKILL.md                    # 分析与报告生成流程文档

---

诊断流程

阶段一：证据收集与关联 (Evidence Collection)

步骤 1：输入数据解析

读取当前任务输入的1个或多个执行结果或诊断输出文件。 将零散的命令行输出、日志片段或监控指标归一化为内部证据实体。

步骤 2：时间线重建 (Timeline Reconstruction)

• 提取各证据中包含的时间戳，统一时区。
• 构建包含：首次异常发生、告警触发、故障蔓延、尝试恢复等关键节点的事件时间轴。
• 强制约束：时间必须格式化为绝对时间，如 YYYY-MM-DD HH:MM:SS。

---

阶段二：根因推断与影响评估 (Root Cause Inference & Impact)

步骤 1：构建故障传导链路

以“现象驱动”为核心，自底向上或自顶向下构建逻辑因果树：

• 起点：故障表象（如：支付接口 500 报错）
• 中间链路：性能瓶颈 / 资源耗尽（如：DB连接池满）
• 根因候选：引发瓶颈的最底层技术原因（如：某表缺少索引导致全表扫描）

步骤 2：假设验证与置信度评估

针对提取的根因候选，列出支持证据（正向）与反对证据（反向）：

• 若有决定性证据且能解释所有现象：高置信度 (🟢)
• 仅有间接证据，无明显反证：中置信度 (🟡)
• 存在相互矛盾的现象或证据不足：低置信度 (🟠)

步骤 3：业务影响评估

• 影响范围：受影响的具体微服务、数据库节点或物理机。
• 故障时段：故障开始时间至结束时间（或当前时间）。
• 严重程度：根据受损面定级（如 P1 / P2 / P3 / Critical / Major 等）。

---

阶段三：输出标准故障诊断报告

在经过上述推理后，必须严格按照以下结构输出最终报告。 报告必须同时展示在对话界面，并写入本地文件。

# 🔴 故障诊断报告

> **报告编号**：[自动生成编号]
> **故障级别**：[如：P1 / Critical]
> **报告时间**：[YYYY-MM-DD HH:MM:SS]
> **当前状态**：🔴 处理中 / 🟡 观察中 / 🟢 已恢复

---

## 一、故障概览

| 项目 | 内容 |
|------|------|
| 故障标题 | [准确描述发生的问题] |
| 影响范围 | [具体的服务/模块/用户范围] |
| 故障时段 | [YYYY-MM-DD HH:MM:SS ～ YYYY-MM-DD HH:MM:SS] |
| 根本原因 | [一句话概括根因] |
| 是否恢复 | [✅ 已恢复 / ❌ 未恢复] |
| 根因置信度 | [🟢 高置信 / 🟡 中置信 / 🟠 低置信] |

### 置信度说明（此表固定展示作为参考）

| 等级 | 标识 | 含义 | 示例场景 |
|------|------|------|--------|
| 高置信 | 🟢 | 根因已明确，可复现，单一原因可解释所有现象 | SQL 无索引 → 复现后加索引立即恢复 |
| 中置信 | 🟡 | 根因基本确认，但存在 1～2 个无法完全解释的现象 | 定位到慢查询，但流量突增原因待查 |
| 低置信 | 🟠 | 有多个可疑原因，尚未排除竞争，结论为推断 | 多个组件同时异常，无法判断触发顺序 |
| 未知 | 🔴 | 现象无法解释，根因未定位，仍在排查中 | 服务偶发崩溃，日志无异常，无法复现 |

---

## 二、根因速览

> 用一张图说清楚：**什么事件触发了什么连锁反应，最终导致故障**。

### 事故时间线 & 故障传导链路

```text
[此处根据实际故障绘制时间线与性质，示例：]
时间                   事件                                          性质         溯源路径 [完整绝对路径 : 行号]
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
2024-01-01 09:05:00   用户请求量突增（大促活动开始）                    📈 外部触发   [/var/log/nginx/access.log:1200]
  │
  ▼
2024-01-01 09:08:00   orders 表慢查询开始堆积（status 字段全表扫描）     ⚠️  隐患激活   [/var/log/mysql/slow.log:45-50]
  │                   SQL 执行时间 > 30s，连接长期不释放
  ▼
2024-01-01 09:10:00   DB 连接池使用率飙升 60% → 90%                    🟡 压力积累   [/var/log/app/monitor.log:88]
  │
  ▼
2024-01-01 09:12:00   连接池耗尽（100/100），新请求排队超时              🔴 故障爆发   [/var/log/app/error.log:102-105]
  │                   ↳ 监控告警触发，成功率跌至 0%
  ▼
[...依次向下直到故障恢复...]

故障因果链

[此处根据实际故障绘制因果树，示例：]
用户请求量突增
    └─► orders.status 无索引 → 全表扫描（500万行，耗时 >30s）
            └─► 数据库连接长期不释放，连接池线程被持续占用
                    └─► 连接池耗尽（max=100，used=100）
                            └─► 新请求等待超时（30s timeout）
                                    └─► 支付接口批量返回 500
                                            └─► 🔴 支付业务全量中断
\`\`\`

---

## 三、排查过程

> 排查逻辑：**提出假设 → 收集证据 → 验证或排除 → 逐步收敛到根因**

### 3.1 初始现象

- [如：监控告警：支付成功率 99.8% → 0%，接口 RT 从 200ms → 超时]
- [如：日志关键报错片段]
- [如：用户侧表现]

---

### 3.2 假设驱动排查

> ⚠️ **反思与自检**：在撰写本节前，**必须严格自查**：
> 1. 此处的假设是否在**真实的排查上下文**中发生过？
> 2. 操作命令和验证数据是否来源于真实的日志、命令输出或历史记录？
> 3. **绝对禁止凭空捏造未执行过的排查动作**。若某条路径并未排查，不应强行构造“虚假排除”，请直接呈现基于真实数据的分析路径。

[针对每一个**曾被真实排查过**的假设，记录验证过程。此处为示例：]

#### 假设 A：网络层故障（基于当时网络告警日志的推断）

> 🧪 假设：机房网络抖动或 DNS 异常，导致请求无法到达服务

| 检查项 | 操作（基于真实历史记录） | 结论 |
|--------|------|------|
| 网络连通性 | \`ping db-host\` / \`curl payment-api\` | ✅ 正常（延时 < 2ms） |
| DNS 解析 | \`nslookup payment.internal\` | ✅ 正常（解析到预期 IP） |

**❌ 排除**：基于上述验证数据，网络层正常，非网络问题。

---

#### 假设 C：数据库连接池耗尽 ✅ 确认根因

> 🧪 假设：基于应用日志中的 \`ConnectionTimeoutException\`，推测 DB 连接池已满

**Step 1 — 确认连接池状态**
\`\`\`sql
SHOW STATUS LIKE 'Threads_connected';
-- 实际获取结果：100 / 100（已满）
\`\`\`

**Step 3 — 定位问题 SQL**
\`\`\`sql
EXPLAIN SELECT * FROM orders WHERE status = 1;
-- 实际执行计划：type=ALL → 全表扫描，rows=500万 → 慢日志显示单次耗时 >30s
\`\`\`

**✅ 结论：\`orders.status\` 字段缺失索引，导致全表扫描，连接长期占用，最终连接池耗尽。**

---

### 3.3 排查结论与逻辑树

> ⚠️ **反思与自检**：排查树必须与 \`3.2\` 节中**真实执行过的**假设驱动排查路径严格对应。

\`\`\`text
[绘制排查树，示例：]
支付接口 500
├─► 网络层                → ✅ 正常，排除（基于 ping/nslookup）
├─► 应用服务              → ✅ 进程存活，排除崩溃（基于 ps/日志）
│       └─► 日志发现连接池超时 → 🔍 深入 DB 层
└─► 数据库层              → ❌ 连接池 100/100 已满（基于 SHOW STATUS）
        └─► 慢查询堆积      → ❌ 80+ 线程卡住
                └─► 定位 SQL → ❌ orders.status 全表扫描（基于 EXPLAIN）
                        └─► 🎯 根因确认：缺少索引
\`\`\`

---

## 四、修复方案

### 4.1 应急处置（如有）

| 步骤 | 操作 | 执行人 | 时间 | 效果 |
|------|------|--------|------|------|
| [如: 1] | [如: Kill 慢查询] | [系统/人工] | [时间] | [如: 连接池释放] |

[可以附带具体的恢复脚本或命令片段]

### 4.2 永久修复计划

| 修复措施 | 负责人 | 完成时间 |
|--------|------|--------|
| [如：补充正式索引并完成验证] | [待定] | [待定] |