关于 incident-response
这是一套与技术栈和工具无关的技能，用于协调生产事故从发现到解决的全过程。它为响应人员提供分阶段流程、角色职责、缓解措施和沟通规范。
主要功能
- 01五阶段事故响应流程
- 02严重级别评估与升级
- 03事故角色与决策权限
- 04缓解措施与验证指引
- 05内部及客户沟通规范
适用场景
- 01响应正在发生的生产事故
- 02制定严重级别和响应流程
- 03设置值班轮换与事故角色
- 04培训团队开展事故协调
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/incident-response确认已加载。
附带文件README.mdreferences/incident-playbook.md
详细介绍
事件响应
管理从发现到解决的生产环境活动事件。与技术栈无关，与工具无关。
此技能适用于活动事件和事件处理流程。对于事后分析，请使用 after-action-report。对于计划中的发布，请使用 launch-runbook。
适用场景
- 正在发生活动事件
- 制定事件响应流程
- 定义严重级别
- 设置值班轮班
- 为团队开展事件响应培训
不适用场景
- 事件后的回顾（使用
after-action-report） - 计划中的发布（使用
launch-runbook） - 发布前的问题分类（使用
qa-testing）
必要输入
- 了解事件情况（告警、客户报告、内部观察）
- 可访问生产系统和监控
- 明确定义角色和权限
- 通信渠道正常运行
框架：5 个阶段
1. 发现
了解事件是如何被发现的。
发现来源：
- 自动告警（监控、SLO 违规、错误率飙升）
- 客户报告（支持工单、社交媒体、状态页订阅者）
- 内部观察（工程师发现异常）
- 第三方（安全研究人员、合作伙伴）
发现后：
- 在目标时间内确认（严重事件通常为 5 到 15 分钟）
- 评估严重程度（见下方严重级别标准）
- 如果尚未通知值班人员，则通知值班人员
- 创建事件频道
2. 分类
确定严重程度和影响范围。
严重级别标准：
| 严重级别 | 定义 | 响应 |
|---|---|---|
| SEV-1（严重） | 面向客户的主要功能无法使用。数据完整性面临风险。发生安全漏洞。 | 全员响应。指定事件指挥官。启动实时战情室。必须对外沟通。 |
| SEV-2（重大） | 服务明显降级。部分客户受到影响。收入受到影响。 | 指定事件指挥官。启动主动响应。进行内部沟通。视情况决定是否需要对外沟通。 |
| SEV-3（轻微） | 影响有限。有可用的变通方案。影响少数用户。 | 按标准值班流程响应。指定单一负责人。 |
| SEV-4（低） | 外观问题、边缘情况或低频问题。无需紧急处理。 | 作为缺陷跟踪。在常规队列中处理。 |
严重级别可能会变化。随着更多信息出现，重新评估。
3. 缓解
在修复原因之前，先止住问题影响。
缓解方法（比完整修复更快）：
- 回滚（撤销最近的部署）
- 关闭功能标志（无需部署即可禁用故障功能）
- 故障切换（将流量路由到健康副本或区域）
- 扩容（增加容量以承载负载）
- 限流（拒绝部分流量，以保护其余服务）
- 优雅降级（关闭非必要功能，保持核心功能可用）
- 维护模式（最后手段，会阻止所有用户访问）
**缓解原则：**先停止对用户的影响，再分析原因。
4. 沟通
事件期间需要沟通的三类对象：
内部团队：
- 在事件频道中实时更新
- 频率：活动事件期间至少每 15 分钟一次
- 格式：带时间戳的状态更新，说明已知情况、正在采取的措施和预计完成时间
内部利益相关方：
- 向更广泛的组织提供较高层级的更新
- 频率：每 30 到 60 分钟一次
- 格式：围绕业务影响说明，而非技术细节
外部人员／客户：
- 更新状态页
- 频率：活动事件期间至少每 30 分钟一次
- 格式：使用浅显语言，不推卸责任，说明用户遇到的问题以及后续预期
沟通原则：
- 在有答案之前先确认已知悉（“我们已知悉此问题，正在调查”）
- 按计划更新，即使没有进展也要更新（“仍在调查中，暂无新信息”）
- 绝不在公开场合猜测原因
- 恢复后明确确认问题已解决
5. 解决
已验证修复方案，客户服务恢复，事件已关闭。
解决标准：
- 已采取缓解措施并完成验证
- 已确定根本原因（或明确推迟到 AAR 中分析）
- 所有受影响系统均已恢复正常
- 客户可以恢复正常使用
- 已发布最终状态更新（内部和外部）
- 可以关闭事件频道（或归档以供 AAR 使用）
关闭后：
- 在 1 至 2 周内安排 AAR
- 趁记忆犹新时记录初始时间线
- 跟踪后续待办事项
事件期间的角色
| 角色 | 职责 |
|---|---|
| 事件指挥官（IC） | 负责响应工作。作出决策。分配任务。不一定是技术能力最强的人，但需要负责协调。 |
| 沟通负责人 | 负责内部和外部沟通，减轻 IC 的沟通负担。 |
| 运维负责人 | 推动技术调查和缓解工作，通常由资历最深的值班工程师担任。 |
| 记录员 | 随事件进展记录时间线，对 AAR 至关重要。 |
| 主题专家 | 根据需要召集，包括服务负责人、数据库专家和安全专家。 |
对于小型团队或严重程度较低的事件，一人可以担任多个角色。但每个角色的职责仍应明确。
事件期间的决策
IC 的权限：
- 决定回滚或采取其他缓解措施
- 召集更多人员
- 提升事件严重程度
- 在选项不明朗时作出决定
应避免的不作为：
- 有可用缓解措施且影响仍在持续时说“先等等看”
- 用户仍在受到影响时讨论根本原因（先缓解）
- 未完成验证就过早宣布问题已解决
- 陷入委员会式决策（召集很多人，却无人作出决定）
拿不准时：采取行动。与用户持续受影响时什么都不做相比，可回滚的错误操作更好。
状态页沟通范例
初始：
“我们正在调查有关 [问题] 的报告。后续将发布更新。”
已确认：
“我们已确认影响 [范围] 的问题。工程师正在处理修复。下次更新时间为 [时间]。”
监控中：
“已应用修复方案。我们正在监控以确认问题已解决。下次更新时间为 [时间]。”
已解决：
“此事件已解决。服务已恢复。我们将在 [时间范围] 内发布完整的事件报告。”
应避免的表达：
- 表述含糊（“出现了一些问题”——具体是什么问题？）
- 未说明受影响范围（“登录服务不可用”——是所有地区，还是仅一个地区？）
- 未承诺更新时间
- 未经验证就说“应该很快就能解决”
- 未经验证就说“已恢复”
工作流
- 确认。 首位响应人员在目标时间内确认收到事件。
- 评估严重程度。 使用评估标准，并开启相应的响应频道。
- 分配角色。 至少指定 IC、沟通负责人和运维负责人。
- 沟通。 发布初始状态更新，并启用内部频道。
- 调查。 检查日志、指标和近期变更。最常见的四种原因是：近期部署、配置变更、第三方依赖项变更、负载激增。
- 缓解。 先止住问题。不要等到完全查明根本原因。
- 验证缓解措施。 不要只相信仪表板；测试用户操作流程。
- 通报解决情况。 对内和对外沟通。
- 关闭事件。 记录最终时间线，并跟踪待办事项。
- 安排 AAR。 在 1 至 2 周内进行。
失败模式
- 没有明确的 IC。 多人并行调试，却缺乏协调。缓解问题的速度更慢，也更容易出现相互冲突的更改。
- 跳过缓解措施，直接查找根因。 工程师调试期间，用户仍在持续受到影响。
- 过早宣布「一切正常」。 尚未验证就宣布问题已解决。
- 沟通中断。 用户不知道是否有人正在处理。
- 状态更新过于含糊。 只说「我们正在处理」，却没有具体信息。
- 公开猜测原因。 猜测往往不正确，而且总会损害信任。
- 拉入过多人员。 协调成本超过了带来的价值。
- 没有记录员。 时间线会丢失。AAR 不得不从聊天记录中重建经过。
- 以「小问题」为由跳过 AAR。 问题模式会被忽略，经验也会被反复重新摸索。
- 责备文化。 人们会隐瞒错误，导致事件处理时间更长。
输出格式
事件进行期间：按照上述框架更新事件频道和状态页面。
事件关闭后：撰写简要的事件摘要，供 AAR 使用。
# Incident: [Brief title]
**Date:** [YYYY-MM-DD]
**Severity:** [SEV-1 / 2 / 3 / 4]
**Duration:** [Detection to resolution]
**Customer impact:** [Who, how many, how, or state the gap per the data-availability rule]
## Summary
[1 to 2 paragraphs]
## Timeline
[Timestamped events]
## Mitigation
[What was done]
## Action items
[Follow-ups, with owners]
## AAR scheduled for
[Date]
如果所需数据不可用
此技能的输出依赖其无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时，获准的输出方式是交付成果并说明缺口：需要什么、实际获取或验证了什么，以及输出中的哪些部分受到影响。绝不允许为了完成交付成果而捏造、估算或插补所需数值。说明缺口即为完整答复。
参考文件
references/incident-playbook.md- 严重程度定义、角色、状态页面模板和决策准则。