claude-howto 实战：用 /incident 命令构建结构化生产事件响应流程（DevOps 插件架构全解析）

在生产环境中，事故（Incident）发生时的响应质量往往决定恢复时间。claude-howto 仓库的 devops-automation 插件以 incident.md 为规范，将「救火」从依赖个人经验的临场发挥，升级为一套可由 Claude Code 执行的七步结构化流程。本文围绕 incident.md 展开，结合插件内的 subagent、MCP 配置与辅助脚本，讲解如何落地一套可复制的生产事件响应工作流。读完你将掌握：事件记录如何创建、严重度如何评估、值班团队如何被通知、诊断信息如何收集，以及如何与 /status、/rollback 等命令协同完成端到端处置。

一、事件响应命令在插件中的定位

devops-automation 是 claude-howto 提供的完整 DevOps 自动化插件，覆盖部署、监控与事件响应三大场景。根据其 README.md，插件通过 $ /plugin install devops-automation 安装，包含以下与事件响应直接相关的组件：

组件类型	名称	职责
Slash 命令	/incident	处理生产事件（本文主题）
Slash 命令	/status	检查系统整体健康状态
Slash 命令	/rollback	回滚到上一个稳定版本
Subagent	incident-commander	协调整个事件响应过程
Subagent	alert-analyzer	分析监控告警与系统指标
MCP 服务	Kubernetes 集成	提供集群内诊断能力
脚本	health-check.sh	健康检查工具

其中 /incident 是事件响应的入口命令。当收到告警或用户上报异常时，执行 $ /incident 即可启动标准化的处置流程。命令本身以 YAML frontmatter 声明元数据（name: Incident Response、description: Handle production incidents with structured response），说明这是一个被 Claude Code 识别并可按需调用的插件命令。

二、七步结构化事件响应流程

incident.md 的核心是一条七步工作流，它定义了从事件发生到复盘收尾的完整生命周期。以下对每一步进行展开解读，并补充落地时的实操要点。

1. 创建事件记录（Create incident record）

响应始于记录。第一步是建立一个事件条目，至少包含：事件发生时间、影响的服务与范围、触发源（监控告警 / 用户上报 / 部署异常）、当前状态（调查中 / 已缓解 / 已解决）。

实操要点：

• 记录统一放在团队可见的位置（如 incidents/YYYY-MM-DD-<编号>.md），保证后续步骤可追溯；
• 事件编号建议与监控平台的告警 ID 关联，便于交叉引用；
• 此时不追求信息完备，先落盘、再完善。

2. 评估严重度与影响（Assess severity and impact）

建立统一分级标准是避免「小事大动干戈、大事无人理会」的关键。可参照常见做法按两层维度评估：

严重度	判定条件示例	建议响应级别
SEV1（P0）	核心服务完全不可用、数据丢失、安全事故	立即召集全部相关方
SEV2（P1）	主要功能降级、部分用户受影响	优先响应，值班团队介入
SEV3（P2）	非关键功能异常、体验问题	常规工单处理

影响评估应明确：受影响用户量级、受影响的业务链路、是否存在绕过路径（workaround）。这一步的结论会直接决定后续是否升级响应、是否触发回滚。

3. 通知值班团队（Notify on-call team）

确认严重度后立即通知值班（on-call）人员。通知内容应自带上下文，避免团队成员二次追问：事件概述、严重度、影响范围、已执行的处置动作、当前负责人。

在 claude-howto 的插件体系中，这类通知能力可依托仓库提供的脚本化手段实现：

• 06-hooks 目录下提供了 notify-team.sh 等钩子脚本，可作为团队通知的参考实现；
• 插件本身在部署链路中使用 pre/post 钩子（见 pre-deploy.js、post-deploy.js）完成「检查-执行-校验」的编排，事件通知同样可以挂在事件被确认之后作为钩子触发。

4. 收集诊断信息（Gather diagnostic information）

信息收集决定了排查效率。结合 devops-automation 插件的组件，诊断手段包括：

• 集群视角：通过 Kubernetes MCP 服务查询 Pod 状态、事件与日志。MCP 配置见 kubernetes-config.json，它通过 npx @modelcontextprotocol/server-kubernetes 启动，并注入 KUBECONFIG 环境变量指向集群配置，因此运行前提是 export KUBECONFIG=~/.kube/config（见插件 README.md）。
• 服务视角：运行 health-check.sh 快速探测 API、数据库与 Pod 就绪情况，输出形如 API: ✅ Healthy、Kubernetes Pods: 3/3 ready 的摘要，帮助快速定位故障层。
• 告警视角：由 alert-analyzer subagent（见 alert-analyzer.md）承担告警关联、趋势分析、根因识别，它被授予 Read、Grep、Bash 三类工具，可读取日志与指标并执行排查命令。

5. 协调响应行动（Coordinate response efforts）

这是事件处置的执行阶段，核心原则是「明确单一指挥、任务并行推进」：

• incident-commander subagent（见 incident-commander.md）是整个响应过程的协调者，它负责严重度评估、团队协调、状态更新、解决跟踪与 post-mortem 促成，被授予 Read、Write、Bash、Grep 四类工具，具备读写事件记录、执行命令、检索日志的完整能力；
• 响应行动应与恢复手段联动。例如确认是部署引入的回归时，可执行 /rollback 回滚（流程见 rollback.md）：识别上一个部署 → 验证回滚目标健康 → 执行回滚 → 运行健康检查 → 通知团队；底层由 rollback.sh 实现，包括 kubectl rollout undo 与回滚后的健康校验；
• 排查期间应持续通过 /status（见 status.md）跟踪 Pod 状态、数据库连接、API 响应时间、错误率与资源利用率的变化，作为缓解措施是否生效的量化依据。

6. 记录解决方案（Document resolution）

事件缓解后，须把「什么时间、由谁、做了什么、效果如何」完整写入事件记录。这一步经常被跳过，但它直接决定复盘质量与知识沉淀水平。记录应包含：时间线、根因、修复动作、验证方式、残留风险。

7. 规划事后复盘（Schedule post-mortem）

最后一步是安排 post-mortem（事后复盘）。复盘不追责、只追因，围绕五个问题展开：发生了什么、影响是什么、为什么发生、为什么没有被及时发现、如何防止再次发生。输出应落到可执行项：改进监控告警、补充自动化测试、修改部署流程或更新 runbook。

三、从命令到体系：事件响应在插件架构中的协作关系

/incident 之所以是「工作流」而非「一条命令」，在于它与插件内其他组件形成了完整协作链：

事件触发（告警 / 上报）
      │
      ▼
/incident 启动七步流程
      │
      ├──► incident-commander（协调：严重度、分工、状态、跟踪）
      ├──► alert-analyzer（诊断：告警关联、根因分析）
      ├──► kubernetes MCP（查询集群状态与日志）
      ├──► health-check.sh（服务级健康探测）
      ├──► /status（持续监控量化指标）
      └──► /rollback（必要时回滚恢复）

从仓库结构看（可对比 07-plugins/devops-automation 目录），这种「命令（commands）+ 子代理（agents）+ MCP + 脚本（scripts）+ 钩子（hooks）」的分层设计，让每个环节都有独立可替换的组件承载：命令负责定义用户入口与流程骨架，subagent 负责需要推理的专业判断，脚本负责确定性的操作执行，钩子负责流程前后的校验与收尾。事件响应因此具备了可观测、可审计、可演练的特质。

四、部署前置条件与使用限制

要将上述流程真正跑通，需满足插件 README.md 中列出的前提：

1. Claude Code 2.1+：插件面向 Claude Code 2.1 及以上版本设计（incident.md 元数据标注的 Claude Code 版本为 2.1.220）；
2. Kubernetes CLI（kubectl）：pre-deploy.js 钩子中通过 which kubectl 与 kubectl cluster-info 校验 kubectl 是否安装、是否已连接集群，事件响应中依赖集群诊断时同样需要该前提；
3. 集群访问已配置：设置 export KUBECONFIG=~/.kube/config 后，Kubernetes MCP 服务才能通过环境变量注入配置并正常访问集群。

限制说明：仓库中的示例命令（如 curl http://api.production.example.com/health、kubectl wait ... -l app=myapp）均为占位性质的演示，实际使用时需替换为自身环境的服务域名与应用标签；health-check.sh、rollback.sh 等脚本输出的时间、版本、Pod 数等数据是脚本运行结果，不代表任何特定环境的真实指标。

五、落地建议

• 先演练后实战：在 staging 环境用 health-check.sh 模拟故障注入，走一遍七步流程，验证通知链路与记录模板是否顺手；
• 沉淀 runbook：把每次 post-mortem 的根因与处置步骤回写为新的检查清单，让 /incident 越用越「聪明」；
• 保持记录即文档：事件记录本身就是最好的复盘材料，坚持第 6、7 步不省略，团队的事件处理能力才能持续迭代。

claude-howto 将这套事件响应流程以插件形式开源，配合 commands 定义、subagent 编排 与 健康检查脚本，为生产环境事件处置提供了一个结构清晰、可直接借鉴的参考实现。