QuasarRyan 故障分析专家（CVE漏洞 & 互联网故障）
任务目标
- 本Skill用于：对各类故障进行深度分析，支持两种输入模式
- 能力包含：
- 自动识别输入类型（CVE编号 / 互联网故障描述）
- 获取官方故障报告作为ground truth
- 拆解故障时间线和关键事件节点
- 分析导火索、初始问题及引发的连环故障
- 识别根本原因（人员因素、组织架构因素）
- 提供技术改进建议
- 触发条件：
- CVE编号模式：用户提供CVE编号（如CVE-2021-44228）
- 通用模式：用户提供故障描述、关键词、事件名称
前置准备
- 依赖说明：
requests>=2.31.0 beautifulsoup4>=4.12.0 jinja2>=3.1.0 - 仓库根目录的
requirements.txt仅用于本地运行脚本，并与上方依赖声明保持一致；本Skill不依赖其他第三方包（Step 6 报告生成依赖 jinja2） - 无需额外文件准备
操作步骤
步骤1：识别输入类型并获取官方数据
智能体首先判断用户输入类型，选择相应的处理流程：
模式A：CVE编号（输入以"CVE-"开头）
调用 scripts/fetch_cve_data.py 获取官方数据：
- 输入：CVE编号（格式如 "CVE-2021-44228"）
- 输出：包含以下信息的结构化数据（JSON格式）：
- CVE ID
- 描述（中文和英文）
- CVSS评分（v3.1/v2.0）
- 严重性等级
- 发布日期、修改日期
- 影响产品/厂商、受影响版本
- 参考资料（官方公告、漏洞详情等URL）
- 漏洞类型（CWE）
- 利用复杂度、权限要求等元数据
- 官方公告内容（脚本自动爬取发布方官方公告的完整文本）
模式B：互联网故障描述（任意故障描述）
智能体执行以下子步骤：
步骤1.1：搜索故障报道
- 构建多个搜索查询：
- 核心关键词 + "故障报告"
- 核心关键词 + "incident report"
- 核心关键词 + "post-mortem"
- 核心关键词 + "官方声明"
- 搜索源包括：官方博客、技术博客、新闻媒体、技术社区
步骤1.2：定位并获取官方故障报告
- 识别官方来源（公司/组织官方博客、官方GitHub、技术社区公告）
- 识别报告特征（详细技术细节、时间线描述、根因分析）
- 对识别的官方报告URL，调用
scripts/extract_webpage.py提取完整文本 - 优先提取最详细、最权威的报告
步骤1.3：输出官方报告内容
- 官方报告的完整文本内容
- 报告来源和发布时间
- 报告的关键信息摘要
步骤2：基于官方报告拆解故障时间线和事件节点
以官方故障报告为主要依据，智能体将分析并输出：
时间线要素：
- 故障发现时间
- 故障首次影响用户的时间
- 问题报告和确认时间
- 故障扩散和升级过程
- 应急响应和修复时间点
- 服务完全恢复时间
- 关键决策和行动时间点
时间线格式：
时间 | 事件 | 影响 | 响应行动
分析要点：
- 识别关键转折点（从轻微到严重的变化）
- 标记响应速度（MTTD、MTTR）
- 记录影响范围变化
- 识别决策延迟点
步骤3：基于官方报告分析导火索和连环故障
以官方报告技术细节为依据，智能体将分析：
导火索识别（从官方报告提取）：
- 触发故障的初始条件（配置变更、部署发布、流量激增、外部依赖故障、特定输入等）
- 第一个出现的问题（代码bug、配置错误、资源耗尽、网络故障、设计缺陷等）
- 触发路径（谁/什么/何时/如何触发的）
连环故障分析（基于官方报告的故障传播描述）：
- 初始问题如何扩散到其他系统
- 级联故障路径（A系统故障 → B系统受影响 → C系统崩溃）
- 放大因子（缓存雪崩、重试风暴、单点故障传播、权限提升、数据泄露等）
- 雪崩效应（一个组件故障如何导致系统整体不可用）
输出结构：
- 导火索：清晰描述触发条件和触发路径（引用官方报告）
- 故障链：按顺序列出故障传播路径（引用官方报告）
- 放大因子：识别导致故障扩大的机制
步骤4：基于官方报告识别根本原因
结合官方报告的根因分析章节，从两个维度深入分析：
人员因素（从官方报告的"Root Cause"章节提取）：
- 开发/运维人员的技术盲区或认知偏差
- 代码审查过程中的疏漏
- 安全意识不足
- 测试覆盖不全
- 操作失误（误操作、配置错误）
- 沟通不畅（信息传递延误或失真）
组织架构因素（从官方报告的"Lessons Learned"推断）：
- 开发流程缺陷（缺乏自动化测试、灰度发布机制）
- 资源分配问题（监控投入不足、应急演练缺失）
- 责任划分不清（故障响应时权责不明）
- 响应机制不完善（缺乏应急预案、响应流程混乱）
- 文档和知识管理缺失（关键信息未文档化）
- 供应商依赖和管理问题（第三方SLA不足）
- 组织文化和激励问题（忽视长期稳定性、过度追求速度）
分析原则：
- 优先采用官方报告明确列出的根本原因
- 不仅分析技术层面，更要上升到管理和流程层面
- 区分直接原因和根本原因
- 识别系统性问题而非个人失误
- 所有分析都应基于官方报告提供的信息
步骤5：基于官方报告提供技术改进建议
参考官方报告的"Action Items"和"Next Steps"章节，智能体将生成具体的改进建议：
技术层面（基于官方报告的修复方案扩展）：
- 架构改进（去除单点、增加冗余、微服务解耦、输入验证）
- 代码层面（增加边界检查、异常处理、资源限制、最小权限原则）
- 配置管理（配置版本控制、灰度发布、回滚机制）
- 监控和告警（指标完善、告警分级、快速定位工具）
- 应急技术方案（熔断降级、流量限制、快速回滚、纵深防御）
- 安全检测加强（fuzzing、静态分析、渗透测试）
管理层面（基于官方报告的经验教训）：
- 开发流程优化（加强测试、Code Review、变更管理、SDLC）
- 培训和意识提升（故障案例分析、应急演练）
- 流程和文档建设（SOP更新、知识库完善）
- 资源投入（增加监控工具、自动化测试环境）
- 安全责任制和考核机制（明确权责、建立问责机制）
- 文化建设（重视稳定性、鼓励快速失败、无责复盘）
输出要求：
- 每条建议应具体可执行
- 按优先级排序（紧急/重要/长期）
- 说明预期效果和实施难度
- 尽量引用官方报告中的相关建议
步骤6：整合完整分析报告
将以上各步骤的分析结果整合成一份结构化的报告：
报告结构：
# [故障名称] 故障分析报告
## 1. 执行摘要
故障概述、影响范围、关键发现、核心结论
## 2. 故障基本信息
故障名称/编号、时间、影响范围、持续时间、严重等级
## 3. 信息来源说明
数据获取方式（CVE模式/通用模式）、官方报告来源、参考资料列表
## 4. 官方故障报告概要
基于官方报告的权威信息摘要
## 5. 时间线分析
按时间顺序排列的关键事件表格
## 6. 导火索与故障链分析
导火索说明、故障传播路径、放大因子
## 7. 根本原因分析
人员因素和组织架构因素
## 8. 改进建议
技术建议和管理建议（含优先级）
## 9. 参考资料
链接到官方报告、新闻报道、技术文档
资源索引
CVE专用脚本：见 scripts/fetch_cve_data.py 用途：从NVD API获取CVE官方数据并爬取官方公告内容 参数：cve_id - CVE编号字符串 适用场景：CVE编号输入模式
通用脚本：见 scripts/extract_webpage.py 用途：从任意URL提取网页文本内容 参数：url - 目标网页URL 适用场景：互联网故障描述输入模式
报告生成脚本：见 scripts/generate_report.py 用途：将结构化分析结果渲染为 Markdown 报告 参数：json_path - 结构化分析结果 JSON 文件路径，output_path - 可选输出路径 适用场景：Steps 2-5 完成结构化输出后，生成最终报告
结构化输出Pipeline（代码化报告生成）
本 Skill 支持将报告生成步骤自动化。AI 完成分析后，由 generate_report.py 渲染最终报告。
Pipeline 流程
用户输入
│
▼
Step 1: fetch_cve_data.py / extract_webpage.py → 原始数据（JSON / 文本）
│
▼
Steps 2-5: AI 分析 → 结构化 JSON ← 【必须输出此格式】
│
▼
generate_report.py → Markdown 报告
结构化 JSON 输出格式
Steps 2-5 完成后，AI 应将分析结果整理为以下 JSON 结构：
{
"mode": "cve | general",
"cve_id": "CVE-xxxx-xxxx（仅CVE模式）",
"basic_info": {
"incident_name": "故障名称",
"incident_id": "CVE编号或事件ID",
"start_time": "ISO8601或自然语言时间",
"end_time": "ISO8601或自然语言时间",
"duration": "如：6小时",
"impact_scope": "影响范围描述",
"severity": "critical | high | medium | low",
"cvss_score": 10.0,
"cvss_severity": "CRITICAL",
"cvss_vector": "CVSS:3.1/...",
"cwe_id": "CWE-xxx",
"cwe_name": "漏洞类型名称",
"vendors": ["厂商1", "厂商2"],
"affected_products": ["产品1", "产品2"]
},
"sources": [
{"url": "https://...", "source_type": "Vendor Advisory", "title": "标题", "collected_via": "NVD API | 网页抓取"}
],
"executive_summary": "（§1 执行摘要，AI 推理生成）",
"official_summary": "（§4 官方报告概要，AI 阅读原文后生成）",
"timeline": [
{"timestamp": "时间", "event": "事件", "impact": "影响", "response_action": "响应行动"}
],
"triggers": {
"trigger_condition": "触发条件",
"trigger_path": "触发路径",
"cascade_path": ["第一步", "第二步", "第三步"],
"amplification_factors": ["因子1", "因子2"]
},
"root_causes": {
"direct_cause": "直接原因",
"root_cause": "根本原因",
"human_factors": ["人员因素1", "人员因素2"],
"organizational_factors": ["组织因素1", "组织因素2"]
},
"recommendations": [
{
"priority": "P0 | P1 | P2",
"category": "technical | management",
"description": "建议描述",
"expected_effect": "预期效果",
"difficulty": "低 | 中 | 高"
}
],
"references": [
{"url": "https://...", "source_type": "官方博客", "title": "标题"}
]
}
使用方式
AI 完成分析后：
- 将结构化结果保存为
analysis_result.json - 调用
python scripts/generate_report.py analysis_result.json - 或直接在 Prompt 中让 AI 将 JSON 传给
generate_report.py渲染
注意事项
executive_summary（§1）和official_summary（§4）必须由 AI 推理生成，不可省略basic_info、timeline、triggers、root_causes、recommendations必须为结构化字段，不得使用自然语言段落- 报告模板见 templates/report.md.j2
- 数据模型定义见 scripts/schema.py
注意事项
- 官方故障报告是最重要的参考资料，所有技术分析应基于官方报告提供的信息
- 步骤1必须首先执行，根据输入类型选择相应脚本
- NVD API有速率限制（30请求/30秒），如遇限流错误请等待后重试
- 爬取网页时可能会遇到反爬机制，脚本会自动处理常见情况，但某些网站可能无法访问
- 如果无法找到官方报告，应基于多源新闻报道进行交叉验证，并在报告中说明数据来源和限制
- 分析过程中应保持客观中立，基于官方报告和事实，避免主观臆断
- 报告应面向技术决策者，语言应专业但不晦涩
- CVE模式和通用模式的输出报告格式保持一致，便于对比分析
使用示例
示例1：CVE漏洞分析（模式A）
功能：分析CVE-2021-44228 (Log4Shell)
输入：CVE-2021-44228
执行方式：
1. 智能体识别为CVE模式
2. 调用fetch_cve_data.py获取NVD数据并爬取官方公告
3. 智能体基于官方公告分析时间线、导火索、根因
4. 智能体生成技术改进建议
5. 智能体整合完整报告
关键点：JNDI注入、远程代码执行、CVSS 10.0
示例2：互联网故障分析（模式B）
功能：分析Facebook 2021年10月全球宕机
输入：Facebook 2021年10月4日宕机
执行方式：
1. 智能体识别为通用模式
2. 智能体搜索：Facebook outage post-mortem
3. 智能体定位官方博客的故障报告
4. 调用extract_webpage.py提取官方报告内容
5. 智能体基于官方报告分析（时间线、根因、建议）
6. 智能体整合完整报告
关键点：DNS配置错误、BGP路由问题、6小时宕机
示例3：云服务故障分析（模式B）
功能：分析阿里云某次故障
输入：阿里云2022年12月故障
执行方式：同示例2流程
关键分析点：
- 搜索阿里云官方技术博客的故障报告
- 提取官方时间线和根因分析
- 分析配置变更、系统设计等问题
- 生成针对性的改进建议
示例4：安全事件分析（模式B）
功能：分析某数据泄露事件
输入：某公司2023年数据泄露事件
执行方式：同示例2流程
关键分析点：
- 搜索官方声明和安全公告
- 提取事件时间线
- 分析漏洞类型和攻击路径
- 识别安全流程缺陷
- 生成安全改进建议
适用场景
CVE模式适用场景
- 安全漏洞分析（CVE编号）
- 软件漏洞技术分析
- 漏洞利用和影响评估
- 安全补丁分析
通用模式适用场景
- 系统宕机（服务不可用、性能严重下降）
- 安全事件（数据泄露、未授权访问、账号劫持）
- 数据丢失（误删除、数据库故障、备份失败）
- 配置错误（DNS配置、路由配置、应用配置）
- 依赖故障（第三方服务故障、云服务中断）
- 流量激增（DOS攻击、突发流量、负载均衡失效）
- 部署故障（发布失败、回滚失败、版本回退）
- 网络故障（BGP路由问题、网络分区、带宽不足）