痛点：突发事件中的资源定位困境
当企业内部运维系统收到一条突发事件告警时，运维人员面临的第一个难题往往是：这个事件可能是哪些云资源异常引起的？
典型的场景是这样的：
- 内部监控系统检测到「订单服务接口超时率飙升」
- 需要快速找到对应的腾讯云 CVM、CLB、数据库等资源
- 但云资源分布在多个项目、多个地域，标签也可能不完整
- 关联资源（同 VPC、同安全组、同标签）同样需要排查
- 人工逐个登录控制台查询，耗时且容易遗漏
CloudQ 本身具备云资源查询和诊断能力，但如果能让它「理解」你的排障方法论，就能大幅提升效率——这就是自定义 Skill 的价值。
什么是自定义 Skill？
CloudQ 的自定义 Skill 是一种可扩展的能力包，它定义了特定场景下 CloudQ 应该遵循的工作流程、分析规则和输出格式。你可以把它理解为「给 CloudQ 写一份 SOP」。
一个 Skill 包通常包含：
references/ — 存放详细规则、模板等参考文档
当用户的问题匹配到 Skill 的触发条件时，CloudQ 会自动加载 Skill 定义的工作流程，按照预设的步骤和规则进行分析，而不是仅凭通用能力「自由发挥」。
突发事件排障 Skill 包详解
我们设计了一个「突发事件排障 Skill 包」，专门用于「突发事件 → 云资源排障」场景。它将排障流程标准化为 7 个步骤：
Step 1：解析突发事件
从用户提供的突发事件信息中提取关键要素：
项目名称：{腾讯云控制台项目名}
资源标签：{key:value 格式，如 env:prod, app:order-service}
故障现象补充：{可选，如"接口超时"、"5xx 比例升高"}
如果信息不完整，CloudQ 会主动追问，确保排障有足够输入。
Step 2：资源定位
通过三种方式定位受影响的云资源：
- 项目匹配：查询指定项目下所有腾讯云资源
- 标签匹配：按 key:value 标签对进一步筛选
- 资源组匹配：按资源组筛选，适用于用资源组做权限隔离的客户
如果标签缺失，自动回退到项目+地域全量列举，并标注无标签资源占比。
Step 3：关联资源扩展
直接匹配的资源可能不完整。Skill 包定义了 6 个关联维度来扩展排查范围：
| 维度 | 关联逻辑 |
|---|---|
| 网络关联 | VPC、子网、安全组下的其他资源 |
| 依赖关联 | CLB 后端、数据库、Redis 依赖 |
| 上下游关联 | API Gateway、SCF、消息队列 |
| 同标签关联 | 相同 app/env 标签的资源实例 |
| 同项目关联 | 同项目下有网络/依赖关系的资源 |
| 网络出口关联 | NAT Gateway、EIP、对等连接、专线网关、DNS 解析 |
扩展深度默认 1 跳，网络类故障自动延伸到 2 跳，但总资源数不超过 50 个以保证报告聚焦。
Step 4：异常分析（8 项检查清单）
对定位到的所有资源执行标准化检查：
- 实例健康状态 — 运行状态是否异常
- 监控指标 — CPU/内存/磁盘/网络波动（对比基线窗口）
- 告警记录 — 异常窗口内是否有相关告警
- 最近变更 — 配置变更、扩缩容、版本发布
- 安全组变更 — 安全组规则变更（高频故障源）
- 限流/封禁变更 — CLB/API Gateway 限流策略变更
- 日志异常 — ERROR 或异常堆栈
- 容量水位 — 带宽、连接数、磁盘容量是否接近上限
时间窗口定义明确：异常窗口 ±30min，基线窗口故障前 1h，变更窗口故障前 24h。指标异常同时报告绝对值和相对偏差百分比，避免小流量资源误报。
Step 5：根因推断
输出 Top 3 最可能根因，每个根因附带：
- 置信度评分：80-100%（多项证据交叉验证）、60-79%（2 项证据）、40-59%（1 项间接证据）、<40%（仅推测）
- 证据链：指标 + 告警 + 日志 + 变更记录
- 缺失证据：告知运维人员「还有什么没查到」，而不是只从已有证据下结论
Step 6：生成排障报告
输出结构化排障报告，以 3 行 TL;DR 开头：
报告包含完整的故障概要、资源定位结果、关联拓扑、异常发现、根因分析、修复建议和风险提示。
Step 7：修复建议
按优先级分级：
| 优先级 | 定义 | 示例 |
|---|---|---|
| P0 立即 | 紧急止血 | 降级/限流/回滚/隔离故障节点 |
| P1 24h内 | 根本修复 | 修复配置、扩容、调整安全组 |
| P2 下周期 | 预防改进 | 完善监控、补充标签、优化阈值 |
每条建议都包含具体操作步骤、预期效果和回滚方案（P0 项）。
降级策略：不完美也能用
实际环境中，并非所有检查项都能执行。Skill 包内置了降级策略：
• CloudQ API 不支持 → 标注"该检查项未执行：API 暂不支持"
• 权限不足 → 标注"该检查项未执行：权限不足（需要 XXX 权限）"
• 数据源未配置 → 标注"该检查项未执行：数据源未配置"，并建议开通
• 资源过多（>50） → 按优先级裁剪并标注裁剪说明
这种「不猜测、不跳过」的策略，确保运维人员对报告的可信度有清晰认知。
如何使用这个 Skill 包
1. 获取 Skill 包
下载 incident-troubleshoot-skill.zip
解压后包含：
incident-troubleshoot-skill/
├── SKILL.md # Skill 定义文件
└── references/
└── troubleshoot-rules.md # 排障规则详细定义
2. 上传到 CloudQ
在 CloudQ 的自定义 Skill 管理界面上传 Skill 包。上传后，当用户的问题包含「突发事件」「排障」「故障排查」等关键词时，CloudQ 会自动加载此 Skill。
3. 使用示例
当发生突发事件时，直接告诉 CloudQ：
TL;DR: 最可能根因为 CLB 安全组规则变更导致流量拦截 | 影响 ap-shanghai 地域 3 台 CVM + 1 个 CLB | 建议立即检查安全组规则并回滚
[完整排障报告生成中……]
适配你的环境
Skill 包的设计遵循通用化原则，适用于任何使用腾讯云的企业。你可以根据自身情况微调：
- 自定义关联维度：如果你们的架构有特殊的关联方式（如微服务注册中心），可以在 references 中补充
- 调整时间窗口：默认异常窗口 ±30min，可根据业务特点调整
- 增减检查项：8 项检查清单可根据实际需求增减
- 对接内部系统：如果已有 CMDB 或事件平台，可将突发事件信息格式对齐
总结
自定义 Skill 让 CloudQ 从「通用的云助手」进化为「懂你排障方法论的专业运维」。突发事件排障 Skill 包的核心价值：
- 标准化流程：7 步排障法，不遗漏关键环节
- 6 维关联扩展：超越直接匹配，发现隐藏关联
- 置信度量化：根因不再靠猜，证据链透明可审计
- 降级不跳过：能力不足时明确告知，不误导
- 即开即用：上传 Skill 包，无需开发，立刻生效