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 等）。

步骤 4：领域扩展证据处理 (Domain-Specific Extensions)

• 分层解析与标题提取：
  • 元数据提取：解析 DOMAIN_EXT_START 与 DOMAIN_DATA_START 之间的 ## 标题：[内容]。该标题将作为报告第四章节的正式标题（前缀“四、”）。
  • 负载提取：解析 DOMAIN_DATA_START 与 DOMAIN_DATA_END 之间的内容。
• 透传与剥离策略：
  • 标签剥离：协议标签（DOMAIN_EXT / DOMAIN_DATA）仅用于内部解析识别。在输出最终报告时，必须剥离所有协议标签，严禁将其渲染在用户可见的报告中。
  • 去重渲染：使用提取的元数据标题填充章节头。严禁在正文中再次出现“## 标题：xxx”行，以避免标题冗余。
  • 核心透传与可视化：对 DOMAIN_DATA 内部的诊断结论、证据出处执行最高优先级透传。对于符合 Step 3 §3.4 规范的标准化 JSON 对象，严禁直接展示源码，必须将其关键要素转化为适合用户观看的 Markdown 表格。
• 动态挂载逻辑：
  • 多实例处理：若存在多块故障盘（多个领域块），应在报告“第四章节”下按序循环挂载。
  • 空保护：若输入中完全不存在领域扩展块，则在最终报告中彻底移除"第四章节"及其标题，同时将原"第五章节（修复方案）"及其内部子节重新编号为第四章（## 四、修复方案，子节改为 ### 4.1 / ### 4.2），确保最终报告章节编号连续，不出现跳号。

---

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

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

# 🔴 故障诊断报告

> **报告编号**：[自动生成编号]
> **故障级别**：[如：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）
                        └─► 🎯 根因确认：缺少索引 
\`\`\` 

---

## 四、[由领域扩展块提取的标题]

[按序挂载各领域扩展块中 `DOMAIN_DATA` 层的核心负载。
**渲染约束：**
1. **剥离标签**：移除所有 `DOMAIN_EXT` 和 `DOMAIN_DATA` 协议标签。
2. **标题去重**：严禁出现重复的 `## 标题：` 行。
3. **内容透传与可视化**：完整保留 ### 卷_id、故障结论。对于**标准化 JSON 对象，必须转化为表格显示**（含：物理槽位、型号、通电时间、存活概率、可修复性、分析原因等），严禁输出 JSON 源码块。
4. **多盘处理**：确保多块磁盘的信息被完整、独立地呈现。**注意：若输入中无此扩展块，则本章节应整体移除。**]

---

## 五、修复方案

> ⚠️ **编号说明**：若本报告中存在第四章（领域扩展块），本章编号为"五"，子节为 `5.1` / `5.2`；若第四章已因无领域扩展块而移除，本章应改编号为"四"，子节改为 `4.1` / `4.2`。

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

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

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

### 5.2 永久修复计划 

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

---

## 诊断质量自查

- [ ] **领域透传**：是否通过剥离协议标签，洁净地展示了 `DOMAIN_DATA` 内部的深度诊断内容（含原始 JSON）？
- [ ] **标题对齐**：章节标题是否准确提取自 `DOMAIN_EXT` 层级的“标题：xxx”？
- [ ] **路径溯源**：所有核心结论是否均附带了 `[完整绝对路径 : 行号]`？
- [ ] **逻辑闭环**：故障传导链路是否能逻辑自洽地解释所有观测到的证据？