故障分析专家（CVE漏洞 & 互联网故障）

任务目标

• - 本Skill用于：对各类故障进行深度分析，支持两种输入模式
• 能力包含：

• - 触发条件：

前置准备

• - 依赖说明：

  requests>=2.31.0
  beautifulsoup4>=4.12.0
  

• - 仓库根目录的 requirements.txt 仅用于本地运行脚本，并与上方依赖声明保持一致；本Skill不依赖其他第三方包
• 无需额外文件准备

操作步骤

步骤1：识别输入类型并获取官方数据

智能体首先判断用户输入类型，选择相应的处理流程：

模式A：CVE编号（输入以"CVE-"开头）

• - 输入：CVE编号（格式如 "CVE-2021-44228"）
• 输出：包含以下信息的结构化数据（JSON格式）：

模式B：互联网故障描述（任意故障描述）

步骤1.1：搜索故障报道

• - 构建多个搜索查询：

• - 搜索源包括：官方博客、技术博客、新闻媒体、技术社区

步骤1.2：定位并获取官方故障报告

• - 识别官方来源（公司/组织官方博客、官方GitHub、技术社区公告）
• 识别报告特征（详细技术细节、时间线描述、根因分析）
• 对识别的官方报告URL，调用 scripts/extract_webpage.py 提取完整文本
• 优先提取最详细、最权威的报告

步骤1.3：输出官方报告内容

• - 官方报告的完整文本内容
• 报告来源和发布时间
• 报告的关键信息摘要

步骤2：基于官方报告拆解故障时间线和事件节点

时间线要素：

• - 故障发现时间
• 故障首次影响用户的时间
• 问题报告和确认时间
• 故障扩散和升级过程
• 应急响应和修复时间点
• 服务完全恢复时间
• 关键决策和行动时间点

时间线格式：
CODEBLOCK1

分析要点：

• - 识别关键转折点（从轻微到严重的变化）
• 标记响应速度（MTTD、MTTR）
• 记录影响范围变化
• 识别决策延迟点

步骤3：基于官方报告分析导火索和连环故障

导火索识别（从官方报告提取）：

• - 触发故障的初始条件（配置变更、部署发布、流量激增、外部依赖故障、特定输入等）
• 第一个出现的问题（代码bug、配置错误、资源耗尽、网络故障、设计缺陷等）
• 触发路径（谁/什么/何时/如何触发的）

连环故障分析（基于官方报告的故障传播描述）：

• - 初始问题如何扩散到其他系统
• 级联故障路径（A系统故障 → B系统受影响 → C系统崩溃）
• 放大因子（缓存雪崩、重试风暴、单点故障传播、权限提升、数据泄露等）
• 雪崩效应（一个组件故障如何导致系统整体不可用）

输出结构：

• - 导火索：清晰描述触发条件和触发路径（引用官方报告）
• 故障链：按顺序列出故障传播路径（引用官方报告）
• 放大因子：识别导致故障扩大的机制

步骤4：基于官方报告识别根本原因

人员因素（从官方报告的"Root Cause"章节提取）：

• - 开发/运维人员的技术盲区或认知偏差
• 代码审查过程中的疏漏
• 安全意识不足
• 测试覆盖不全
• 操作失误（误操作、配置错误）
• 沟通不畅（信息传递延误或失真）

组织架构因素（从官方报告的"Lessons Learned"推断）：

• - 开发流程缺陷（缺乏自动化测试、灰度发布机制）
• 资源分配问题（监控投入不足、应急演练缺失）
• 责任划分不清（故障响应时权责不明）
• 响应机制不完善（缺乏应急预案、响应流程混乱）
• 文档和知识管理缺失（关键信息未文档化）
• 供应商依赖和管理问题（第三方SLA不足）
• 组织文化和激励问题（忽视长期稳定性、过度追求速度）

分析原则：

• - 优先采用官方报告明确列出的根本原因
• 不仅分析技术层面，更要上升到管理和流程层面
• 区分直接原因和根本原因
• 识别系统性问题而非个人失误
• 所有分析都应基于官方报告提供的信息

步骤5：基于官方报告提供技术改进建议

技术层面（基于官方报告的修复方案扩展）：

• - 架构改进（去除单点、增加冗余、微服务解耦、输入验证）
• 代码层面（增加边界检查、异常处理、资源限制、最小权限原则）
• 配置管理（配置版本控制、灰度发布、回滚机制）
• 监控和告警（指标完善、告警分级、快速定位工具）
• 应急技术方案（熔断降级、流量限制、快速回滚、纵深防御）
• 安全检测加强（fuzzing、静态分析、渗透测试）

管理层面（基于官方报告的经验教训）：

• - 开发流程优化（加强测试、Code Review、变更管理、SDLC）
• 培训和意识提升（故障案例分析、应急演练）
• 流程和文档建设（SOP更新、知识库完善）
• 资源投入（增加监控工具、自动化测试环境）
• 安全责任制和考核机制（明确权责、建立问责机制）
• 文化建设（重视稳定性、鼓励快速失败、无责复盘）

输出要求：

• - 每条建议应具体可执行
• 按优先级排序（紧急/重要/长期）
• 说明预期效果和实施难度
• 尽量引用官方报告中的相关建议

步骤6：整合完整分析报告

报告结构：
CODEBLOCK2

资源索引

• - CVE专用脚本：见 scripts/fetchcve_data.py

• - 通用脚本：见 scripts/extract_webpage.py

注意事项

• - 官方故障报告是最重要的参考资料，所有技术分析应基于官方报告提供的信息
• 步骤1必须首先执行，根据输入类型选择相应脚本
• NVD API有速率限制（30请求/30秒），如遇限流错误请等待后重试
• 爬取网页时可能会遇到反爬机制，脚本会自动处理常见情况，但某些网站可能无法访问
• 如果无法找到官方报告，应基于多源新闻报道进行交叉验证，并在报告中说明数据来源和限制
• 分析过程中应保持客观中立，基于官方报告和事实，避免主观臆断
• 报告应面向技术决策者，语言应专业但不晦涩
• CVE模式和通用模式的输出报告格式保持一致，便于对比分析

使用示例

示例1：CVE漏洞分析（模式A）

示例2：互联网故障分析（模式B）

示例3：云服务故障分析（模式B）

示例4：安全事件分析（模式B）

适用场景

CVE模式适用场景

• - 安全漏洞分析（CVE编号）
• 软件漏洞技术分析
• 漏洞利用和影响评估
• 安全补丁分析

通用模式适用场景

• - 系统宕机（服务不可用、性能严重下降）
• 安全事件（数据泄露、未授权访问、账号劫持）
• 数据丢失（误删除、数据库故障、备份失败）
• 配置错误（DNS配置、路由配置、应用配置）
• 依赖故障（第三方服务故障、云服务中断）
• 流量激增（DOS攻击、突发流量、负载均衡失效）
• 部署故障（发布失败、回滚失败、版本回退）
• 网络故障（BGP路由问题、网络分区、带宽不足）