应急响应处理

---

name: incident-response-incident-response description: "用于处理事件响应工作流" risk: unknown source: community date_added: "2026-02-27"

何时使用此技能

• 处理事件响应任务或工作流
• 需要事件响应的指导、最佳实践或检查清单

不要在以下情况使用此技能

• 任务与事件响应无关
• 你需要此范围之外的不同领域或工具

说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可操作的步骤和验证。
• 如果需要详细示例，打开 resources/implementation-playbook.md。

使用现代 SRE 实践编排多代理事件响应，实现快速解决和学习：

[扩展思考：此工作流实现了遵循现代 SRE 原则的综合事件指挥系统（ICS）。多个专业代理通过定义的阶段协作：检测/分类、调查/缓解、沟通/协调和解决/事后分析。工作流强调速度而不牺牲准确性，维护清晰的沟通渠道，并确保每个事件通过无责事后分析和系统改进成为学习机会。]

配置

严重级别

• P0/SEV-1：完全中断、安全漏洞、数据丢失 - 立即全员响应
• P1/SEV-2：重大降级、显著用户影响 - 需要快速响应
• P2/SEV-3：轻微降级、有限影响 - 标准响应
• P3/SEV-4：外观问题、无用户影响 - 计划解决

事件类型

• 性能降级
• 服务中断
• 安全事件
• 数据完整性问题
• 基础设施故障
• 第三方服务中断

阶段 1：检测与分类

1. 事件检测和分类

• 使用 Task 工具，subagent_type="incident-responder"
• 提示："紧急：检测并分类事件：$ARGUMENTS。分析来自 PagerDuty/Opsgenie/监控的告警。确定：1）事件严重性（P0-P3），2）受影响的服务和依赖，3）用户影响和业务风险，4）所需的初始事件指挥结构。检查错误预算和 SLO 违规。"
• 输出：严重性分类、影响评估、事件指挥分配、SLO 状态
• 上下文：初始告警、监控仪表板、最近变更

2. 可观测性分析

• 使用 Task 工具，subagent_type="observability-monitoring::observability-engineer"
• 提示："对事件执行快速可观测性扫描：$ARGUMENTS。查询：1）分布式追踪（OpenTelemetry/Jaeger），2）指标关联（Prometheus/Grafana/DataDog），3）日志聚合（ELK/Splunk），4）APM 数据，5）真实用户监控。识别异常、错误模式和服务降级点。"
• 输出：可观测性发现、异常检测、服务健康矩阵、追踪分析
• 上下文：步骤 1 的严重级别、受影响的服务

3. 初始缓解

• 使用 Task 工具，subagent_type="incident-responder"
• 提示："对 P$SEVERITY 事件实施立即缓解：$ARGUMENTS。操作：1）必要时进行流量限制/重路由，2）禁用受影响功能的功能标志，3）激活断路器，4）评估最近部署的回滚，5）如果与容量相关则扩展资源。优先恢复用户体验。"
• 输出：已采取的缓解措施、已应用的临时修复、回滚决策
• 上下文：可观测性发现、严重性分类

阶段 2：调查与根因分析

4. 深度系统调试

• 使用 Task 工具，subagent_type="error-debugging::debugger"
• 提示："使用可观测性数据对事件进行深度调试：$ARGUMENTS。调查：1）堆栈追踪和错误日志，2）数据库查询性能和锁，3）网络延迟和超时，4）内存泄漏和 CPU 峰值，5）依赖故障和级联错误。应用五个为什么分析。"
• 输出：根因识别、贡献因素、依赖影响图
• 上下文：可观测性分析、缓解状态

5. 安全评估

• 使用 Task 工具，subagent_type="security-scanning::security-auditor"
• 提示："评估事件的安全影响：$ARGUMENTS。检查：1）DDoS 攻击指标，2）认证/授权失败，3）数据暴露风险，4）证书问题，5）可疑访问模式。审查 WAF 日志、安全组和审计追踪。"
• 输出：安全评估、漏洞分析、漏洞识别
• 上下文：根因发现、系统日志

6. 性能工程分析

• 使用 Task 工具，subagent_type="application-performance::performance-engineer"
• 提示："分析事件的性能方面：$ARGUMENTS。检查：1）资源利用模式，2）查询优化机会，3）缓存效率和命中率，4）连接池状态，5）自动扩展行为。提供性能基线比较。"
• 输出：性能分析、瓶颈识别、优化建议
• 上下文：调试发现、系统指标

阶段 3：沟通与协调

7. 利益相关者沟通

• 使用 Task 工具，subagent_type="incident-responder"
• 提示："管理事件沟通：$ARGUMENTS。创建：1）内部状态更新（Slack/Teams），2）客户通知（状态页面），3）管理层简报，4）时间线文档。遵循 ICS 沟通协议。保持更新简洁、事实性和可操作。"
• 输出：沟通模板、状态更新、时间线
• 上下文：当前事件状态、缓解进展

8. 变更管理

• 使用 Task 工具，subagent_type="incident-responder"
• 提示："协调事件的变更管理：$ARGUMENTS。管理：1）紧急变更审批，2）回滚程序，3）部署冻结决策，4）依赖协调，5）变更影响评估。确保所有变更都被追踪和可逆。"
• 输出：变更记录、审批状态、回滚计划
• 上下文：根因分析、缓解措施

阶段 4：解决与事后分析

9. 永久修复实施

• 使用 Task 工具，subagent_type="error-debugging::debugger"
• 提示："实施事件的永久修复：$ARGUMENTS。确保：1）根因已解决（不仅仅是症状），2）修复经过测试和验证，3）监控确认恢复，4）SLO 恢复正常，5）相关系统已检查类似问题。"
• 输出：修复实施、验证结果、恢复确认
• 上下文：根因分析、临时缓解措施

10. 无责事后分析

• 使用 Task 工具，subagent_type="incident-responder"
• 提示："进行无责事后分析：$ARGUMENTS。记录：1）事件时间线（检测到解决），2）根因和贡献因素，3）有效的措施和无效的措施，4）行动项目（带负责人和截止日期），5）流程改进建议，6）SLO/SLA 影响分析。"
• 输出：事后分析文档、行动项目、改进建议
• 上下文：完整事件时间线、所有阶段发现

限制

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需的输入、权限、安全边界或成功标准，请停下来要求澄清。