用途
Incident Response 用于系统化地处理生产环境事故，覆盖从发现到复盘的完整流程，帮助团队在压力下保持有序响应。
严重级别
技能定义了四个严重级别及对应响应时间：
- SEV1：服务宕机，影响全部用户，需立即响应。示例包括数据库崩溃、DNS 故障、认证失效。
- SEV2：主要功能损坏，影响大量用户，需 30 分钟内响应。示例包括支付失败、搜索不可用。
- SEV3：次要功能损坏，存在替代方案，需 4 小时内响应。示例包括导出按钮损坏、仪表盘变慢。
- SEV4：外观或低影响问题，下一个工作日处理。示例包括 UI 错别字、轻微样式问题。
事故工作流
1. 检测与分诊（前 5 分钟）
确认收到事故，回复“我正在排查”；确定严重级别；检查监控仪表盘（错误率、延迟、状态页）；检查近期部署，例如运行 git log --oneline -10 查看最近是否部署过内容。
2. 缓解（接下来 15-30 分钟）
目标是止血，而非找到根因。快速缓解手段包括：
- 回滚：
git revert <commit> && deploy，若由部署引起则是最快选项。 - 功能开关：禁用损坏的功能。
- 扩容：若为容量问题则增加实例。
- 故障转移：主节点宕机时切换到备份或从节点。
- 阻断流量：对特定滥用流量进行限流或封禁。
3. 沟通
内部沟通：建立事故频道（如 #incident-2026-04-10）；每 15-30 分钟发布状态更新；分配角色，包括事故指挥官、沟通负责人、工程师。
外部沟通：更新状态页；若中断时间较长，向受影响用户发送邮件或通知；保持诚实，例如“我们正在经历 X 问题，已定位原因并正在修复”。
4. 解决
部署修复；在生产环境验证修复有效（检查指标，而不仅是错误消失）；以总结关闭事故频道。
5. 事后复盘（48 小时内）
撰写无指责的事后复盘，包含以下部分：
- 标题与元信息：事故名称、日期、持续时间、严重级别、影响范围。
- 时间线：按时间记录告警、确认、定位、根因、修复、恢复、关闭等节点。
- 根因：说明导致事故的具体技术原因。
- 做得好之处：列出响应中值得肯定的环节。
- 不足之处：列出暴露的问题。
- 行动项：带负责人与截止日期的改进任务。
资料中提供了一个示例：支付因 Stripe webhook 失败，持续 45 分钟，SEV2，约 200 名用户无法完成购买；根因是数据库迁移 #47 添加了 NOT NULL 的 currency 列但没有 DEFAULT 值，新 webhook 事件插入时未包含该列而失败。
提示
- 先回滚，后调查——速度比优雅更重要。
- 最近的部署最可能是原因。
- 事后复盘不要归咎于人，聚焦流程改进。
- 为常见故障模式维护运行手册。
- 在真实事故前通过演练日练习事故响应。
适用场景与限制
该技能适用于运维与开发团队处理线上故障，帮助快速止血、协调沟通并沉淀改进。资料未提供具体平台、收费、价格或效果数据，这些信息暂未提供。