incident-response-incident-response

使用此技能的场景

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

不要在以下场景使用此技能

• 任务与事件响应无关时
• 需要使用此范围之外的其他领域或工具时

说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可执行的步骤和验证方法。

运用现代 SRE 实践协调多 Agent 进行事件响应，以便快速解决问题并总结经验：

[扩展思考：此工作流依据现代 SRE 原则实现了一套全面的事件指挥系统（ICS）。多个专业 Agent 通过明确定义的阶段协作：检测／分诊、调查／缓解、沟通／协调以及解决／事后复盘。该工作流强调速度，同时不牺牲准确性，保持清晰的沟通渠道，并通过无责复盘和系统性改进，确保每起事件都成为学习机会。]

配置

将响应绑定到现有事件指挥官、严重性策略、已授权服务和变更权限。以下 Task／子 Agent 名称是特定宿主环境中的示例，不保证已安装。仅在获得用户／项目授权后进行委派；否则按顺序执行各角色。先起草状态更新和外联材料；只有在明确获得沟通权限时，才发送／发布。只要可行，就在缓解前保留证据，记录时间戳和不确定性；对生产环境写入操作，必须要求经过批准的回滚标准。紧急情况不代表获得部署或删除数据的权限。

严重性级别

• 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）CDN 性能，6）自动扩缩容触发条件。识别瓶颈和容量问题。"
• 输出：性能瓶颈、资源建议、优化机会
• 上下文：调试发现、当前缓解状态

阶段 3：解决与恢复

7. 修复实施

• 使用 Task 工具，设置 subagent_type="backend-development::backend-architect"
• 提示词："根据根因，为事件 $ARGUMENTS 设计并实施生产环境修复。要求：1）适用于快速部署的最小可行修复，2）风险评估和回滚能力，3）包含监控的分阶段发布计划，4）验证标准和健康检查。兼顾即时修复和长期解决方案。"
• 输出：修复实施、部署策略、验证计划、回滚流程
• 上下文：根因分析、性能发现、安全评估

8. 部署与验证

• 使用 Task 工具，设置 subagent_type="deployment-strategies::deployment-engineer"
• 提示词："执行事件修复的紧急部署：$ARGUMENTS。流程：1）蓝绿部署或金丝雀部署，2）通过监控进行渐进式发布，3）在每个阶段验证健康检查，4）配置回滚触发条件，5）部署期间进行实时监控。与事件指挥协同。"
• 输出：部署状态、验证结果、监控仪表板、回滚准备情况
• 上下文：修复实施、当前系统状态

阶段 4：沟通与协调

9. 利益相关方沟通

• 使用 Task 工具，设置 subagent_type="content-marketing::content-marketer"
• 提示词："管理事件 $ARGUMENTS 的沟通工作。创建：1）状态页更新（面向公众），2）内部工程更新（技术细节），3）高管摘要（业务影响／预计解决时间），4）客户支持简报（沟通要点），5）记录关键决策的时间线文档。根据严重程度，每 15-30 分钟更新一次。"
• 输出：沟通材料、状态更新、利益相关方简报、时间线日志
• 上下文：前序所有阶段、当前解决状态

10. 客户影响评估

• 使用 Task 工具，设置 subagent_type="incident-responder"
• 提示词："评估并记录事件 $ARGUMENTS 对客户的影响。分析：1）受影响的用户群体和地区，2）失败的交易或数据丢失，3）SLA 违约和合同影响，4）客户支持工单量，5）收入影响估算。准备主动联系客户的名单。"
• 输出：客户影响报告、SLA 分析、联系建议
• 上下文：解决进展、沟通状态

阶段 5：复盘与预防

11. 无责复盘

• 使用 Task 工具，设置 subagent_type="documentation-generation::docs-architect"
• 提示词："针对事件开展无责复盘：$ARGUMENTS。记录：1）完整的事件时间线及决策，2）根本原因和促成因素（聚焦系统），3）响应过程中做得好的方面，4）可改进之处，5）包含负责人和截止日期的行动项，6）供团队学习的经验教训。遵循 SRE 复盘最佳实践。"
• 输出：复盘文档、行动项列表、流程改进、培训需求
• 上下文：完整的事件历史、所有 Agent 输出

12. 监控与告警增强

• 使用 Task 工具，设置 subagent_type="observability-monitoring::observability-engineer"
• 提示词："增强监控，以防止以下事件再次发生：$ARGUMENTS。实施：1）用于早期检测的新告警，2）必要时调整 SLI/SLO，3）改进仪表板以提升可见性，4）运行手册自动化机会，5）用于测试的混沌工程场景。确保告警可执行且减少噪声。"
• 输出：新的监控配置、告警规则、仪表板更新、运行手册自动化
• 上下文：复盘发现、根本原因分析

13. 系统加固

• 使用 Task 工具，设置 subagent_type="backend-development::backend-architect"
• 提示词："设计系统改进方案，以防止事件再次发生：$ARGUMENTS。提出：1）增强弹性的架构变更（断路器、舱壁），2）优雅降级策略，3）容量规划调整，4）技术债优先级排序，5）减少依赖的机会。制定实施路线图。"
• 输出：架构改进、弹性模式、技术债事项、路线图
• 上下文：复盘行动项、性能分析

成功标准

即时成功（事件期间）

• 在 SLA 目标时间内恢复服务
• 在 5 分钟内准确判定严重程度
• 每 15-30 分钟向利益相关方通报一次
• 无级联故障或事件升级
• 维持清晰的事件指挥架构

长期成功（事件后）

• 在 48 小时内完成全面复盘
• 为所有行动项指定负责人和截止日期
• 在 1 周内部署监控改进
• 完成运行手册更新
• 根据经验教训开展团队培训
• 评估并通报错误预算影响

协作协议

事件指挥架构

• 事件指挥官：决策权限、协调
• 技术负责人：技术调查与解决
• 沟通负责人：向利益相关方通报进展
• 领域专家：特定系统方面的专业知识

沟通渠道

• 战情室（Slack/Teams 频道或 Zoom）
• 状态页更新（StatusPage、Statusly）
• 使用 PagerDuty/Opsgenie 发送告警
• 使用 Confluence/Notion 编写文档

交接要求

• 每个阶段都向下一阶段提供清晰的上下文
• 在共享事件文档中记录所有发现
• 记录决策依据，以供复盘
• 为所有重要事件标注时间戳

需要立即响应的生产事件：$ARGUMENTS

示例

用户请求：

在此任务中使用 @incident-response-incident-response：用于处理事件响应任务。

限制

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