메뉴
专业的故障诊断根因分析和报告生成 skill。当系统存在具体的故障（如服务不可用、时延飙升、进程崩溃等），且前置节点已生成1个或多个诊断文件时，用户要求基于这些诊断文件内容进行综合的根因分析（RCA）、影响评估，并生成最终的结构化故障诊断报告时，必须使用此 skill。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | fault-rca-report-generation |
| description | 专业的故障诊断根因分析和报告生成 skill。当系统存在具体的故障（如服务不可用、时延飙升、进程崩溃等），且前置节点已生成1个或多个诊断文件时，用户要求基于这些诊断文件内容进行综合的根因分析（RCA）、影响评估，并生成最终的结构化故障诊断报告时，必须使用此 skill。 |
本技能通过对前置收集到的诊断证据（如日志片段、指标异常、系统状态等）进行关联分析，推断导致系统故障的根本原因，评估业务影响范围，并最终生成标准化的故障诊断报告。
重要原则：本 skill 主要执行逻辑推理与报告生成。所有分析需基于已有的客观证据数据，严禁无中生有或臆测。
fault-rca-report-generation/
└── SKILL.md # 分析与报告生成流程文档
读取当前任务输入的1个或多个执行结果或诊断输出文件。 将零散的命令行输出、日志片段或监控指标归一化为内部证据实体。
YYYY-MM-DD HH:MM:SS。以“现象驱动”为核心，自底向上或自顶向下构建逻辑因果树：
针对提取的根因候选，列出支持证据（正向）与反对证据（反向）：
在经过上述推理后，必须严格按照以下结构输出最终报告。 报告必须同时展示在对话界面，并写入本地文件。
# 🔴 故障诊断报告
> **报告编号**：[自动生成编号]
> **故障级别**：[如：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 永久修复计划
| 修复措施 | 负责人 | 完成时间 |
|--------|------|--------|
| [如：补充正式索引并完成验证] | [待定] | [待定] |
Delegate coding tasks to Claude Code (Anthropic's CLI agent). Use for building features, refactoring, PR reviews, and iterative coding. Requires the claude CLI installed.
Delegate coding tasks to OpenAI Codex CLI agent. Use for building features, refactoring, PR reviews, and batch issue fixing. Requires the codex CLI and a git repository.
Delegate coding tasks to OpenCode CLI agent for feature implementation, refactoring, PR review, and long-running autonomous sessions. Requires the opencode CLI installed and authenticated.
Complete guide to using and extending OWLS — CLI usage, setup, configuration, spawning additional agents, gateway platforms, skills, voice, tools, profiles, and a concise contributor reference. Load this skill when helping users configure OWLS, troubleshoot issues, spawn agent instances, or make code contributions.
面向 Linux 用户态 coredump（core 文件）的结构化诊断技能。适用于进程崩溃、SIGSEGV/SIGBUS/SIGABRT/SIGFPE、空指针、栈溢出、内存破坏、总线错误、除零、Python+C 混合栈等场景；当用户提到 core、coredump、gdb 分析崩溃、段错误、总线错误、生成 core、应用转储时应触发。依赖系统已安装 GNU gdb；报告日志默认写入 /tmp/core_diag/。
Generate dark-themed SVG diagrams of software systems and cloud infrastructure as standalone HTML files with inline SVG graphics. Semantic component colors (cyan=frontend, emerald=backend, violet=database, amber=cloud/AWS, rose=security, orange=message bus), JetBrains Mono font, grid background. Best suited for software architecture, cloud/VPC topology, microservice maps, service-mesh diagrams, database + API layer diagrams, security groups, message buses — anything that fits a tech-infra deck with a dark aesthetic. If a more specialized diagramming skill exists for the subject (scientific, educational, hand-drawn, animated, etc.), prefer that — otherwise this skill can also serve as a general-purpose SVG diagram fallback. Based on Cocoon AI's architecture-diagram-generator (MIT).