| 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 永久修复计划
| 修复措施 | 负责人 | 完成时间 |
|--------|------|--------|
| [如：补充正式索引并完成验证] | [待定] | [待定] |
