incident-responder
响应生产事故
获取关于管理生产事故的专业指导，包括结构化响应协议、可观测性驱动的调查技术以及无责复盘流程，以缩短平均修复时间并提高系统可靠性。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“incident-responder”。 We have a production incident. The payment service is returning 500 errors to 30% of users.
预期结果:
## 立即评估
**严重程度：P1** - 主要功能降级，用户影响显著
### 1. 建立事故指挥
- **事故指挥官**：[立即指定]
- **技术负责人**：开始调查
- **通信负责人**：准备利益相关者更新
### 2. 快速影响评估
- 用户影响：约30%的支付请求失败
- 业务影响：可能影响收入，可能违反SLA
- 范围：仅支付服务，检查下游影响
### 3. 立即稳定选项
- 检查最近部署（过去30分钟内）
- 如需要可启用功能开关禁用支付
- 如资源受限可扩展支付服务Pod
- 验证数据库连接池健康状态
### 4. 首次沟通
- 15分钟内更新状态页
- 内部：创建事故频道，通知值班人员
- 设定预期：P1每小时更新一次
正在使用“incident-responder”。 Help me write a post-mortem for a database outage that caused 2 hours of downtime.
预期结果:
## 复盘模板
### 事故摘要
- **持续时间**：[开始]至[结束]——2小时
- **影响**：支付服务完全中断
- **受影响用户**：100%支付用户
- **SEV级别**：P0
### 时间线（本地时间）
- 14:00 - 错误率升高的警报触发
- 14:05 - 值班人员确认，开始调查
- 14:15 - 根本原因确定为数据库连接池耗尽
- 14:30 - 决定重启服务
- 15:45 - 服务完全恢复
- 16:00 - 事故关闭
### 根本原因分析（五个为什么）
1. 为什么支付服务失败？数据库连接池耗尽
2. 为什么连接池耗尽？应用在重试风暴期间泄漏了连接
3. 为什么发生重试风暴？下游API缺少断路器
4. 为什么缺少断路器？重新设计中未实现该功能
5. 为什么？迁移期间可靠性需求存在缺口
### 行动项
- [ ] 实现断路器模式（负责人：团队A，截止：2周）
- [ ] 添加连接池监控告警（负责人：团队B，截止：1周）
- [ ] 更新迁移清单以包含可靠性需求（负责人：团队C，截止：1周）
安全审计
安全Prompt-only skill containing educational content about SRE incident management practices. Static analysis scanned 0 files (0 lines) and detected 0 security issues. The skill provides guidance on incident response procedures, observability practices, and post-incident analysis. No executable code, no network calls, no file operations, and no prompt injection attempts detected. This is a safe, informational skill for incident response education.
质量评分
你能构建什么
活跃生产事故响应
在实时事故期间使用，遵循结构化响应协议，评估严重程度，建立事故指挥，并与利益相关者协调沟通。
事故后分析与学习
通过指导时间线创建、使用五个为什么技术进行根本原因分析，以及识别可操作的改进措施，促进无责复盘。
SRE实践与培训
学习事故管理最佳实践、现代可观测性技术和可靠性模式，以构建更具弹性的系统。
试试这些提示
我们有一个生产事故。服务[service name]正在经历[symptoms]。帮我评估严重程度，建立事故指挥，并确定立即的稳定措施。
我们有一个影响[service]的[P1/P2]事故。初步调查显示[observed symptoms]。引导我进行可观测性驱动的调查以识别根本原因。
我们正处于[P0/P1]事故中。我需要为[executives/customers/support team]起草更新内容。我应该沟通什么以及多久沟通一次？
帮我对一个[brief description]的事故进行无责复盘。引导我创建时间线、根本原因分析，并识别行动项。
最佳实践
- 立即建立事故指挥结构——所有权不明确会延迟解决
- 主动且频繁地沟通——利益相关者更喜欢更新而不是沉默
- 在活跃事故期间，先关注服务恢复，再进行根本原因分析
- 实时记录一切——时间线和决策事后更难重建
避免
- 在复盘时指责个人——应关注系统和流程
- 跳过事故指挥让'所有人一起响应'——导致协调混乱
- 延迟沟通以获取完整信息——利益相关者需要及时更新
- 在活跃事故期间实施复杂修复——优先选择最小可行修复