用 Claude Code 的 /incident 命令建立结构化事故响应：devops-automation 插件实战指南

用 Claude Code 的 /incident 命令建立结构化事故响应devops-automation 插件实战指南【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto在生产环境里事故Incident不可避免真正拉开差距的是响应方式是临场慌乱地翻日志、靠记忆拼凑排查步骤还是让 AI 助手按照一套固定、可复现、可审计的流程来推进claude-howto 仓库中devops-automation插件提供的/incident斜杠命令正是为后者而生。它以 incident.md 中定义的七步结构化响应流程为核心骨架配合incident-commander、alert-analyzer两个子代理以及健康检查脚本、Kubernetes MCP 等配套资源让 Claude Code 在故障发生时能够按部就班地完成从建单、定级、通知、诊断、协调到复盘的全链路处置。读完本文你将掌握/incident命令的完整工作流、每一步的落地方式以及如何利用仓库内已有的子代理与脚本把响应过程固化成可复用的工程能力。一、/incident命令在插件中的定位devops-automation是 claude-howto 仓库中面向部署、监控与事故响应的完整插件其安装方式为/plugin install devops-automation根据插件的 README.md它共提供四个斜杠命令/incident与其余三个形成完整闭环命令用途/deploy部署到生产或预发环境/rollback回滚到上一个稳定版本/status检查系统整体健康状态/incident处理生产环境事故可以看到/incident是这套自动化体系中专门负责出事之后怎么办的兜底环节当/status或监控告警发现异常、部署引发故障时/incident负责接管接下来的所有处置动作。这正是 incident.md 定义的核心职责——以结构化响应流程处理生产事故。二、七步事故响应工作流详解incident.md 将整个事故处置抽象为七步结构化流程。每一步都是独立、可执行的环节下面结合仓库内配套资源逐一展开。1. 创建事故记录Create incident record事故处置的第一步不是先修而是先建档。只有先把事故记录下来后续的处置过程、影响范围、时间线才能被追溯和复盘。这一步在工程实践中通常对应生成唯一的事故编号、记录事故发生时间、记录首次发现来源告警、用户反馈还是/status巡检发现。在 Claude Code 的语境下可以理解为让 AI 打开一个事故跟踪文档如 README、Changelog 或团队协作平台中的事故单作为后续所有步骤的信息汇聚点。2. 评估严重级别与影响范围Assess severity and impact确定这个事故有多严重、影响了谁直接决定响应投入的资源。这一步正是incident-commander子代理的核心职责之一。查看 incident-commander.md 的定义name: incident-commander description: Coordinates incident response tools: Read, Write, Bash, Grep其能力清单第一项就是Severity assessment严重级别评估。该子代理被授予 Read、Write、Bash、Grep 四类工具意味着它可以读取系统状态、写入事故记录、执行诊断命令并在代码与日志中检索线索。从源码结构看严重级别评估需要结合实际的业务定义如 P0/P1/P2 分级仓库内health-check.sh、status.md提供的基础健康数据可以作为分级依据——例如 API 完全不可用、数据库连接失败可判为最高级别而单 Pod 抖动则级别较低。3. 通知值班团队Notify on-call team定级之后需要第一时间把事故推送给值班人员。插件 README 中列出了notify-team.sh类通知能力在 06-hooks 目录下还提供了 notify-team.sh 等钩子脚本用于在事件发生时通知团队。在实际流程中这一步与第 5 步协调响应紧密配合通知内容应包含事故级别、影响范围、已收集到的初步诊断信息和事故记录链接让接警的人能在最短时间内进入状态。4. 收集诊断信息Gather diagnostic information这是技术上最重的一步。仓库为这一步提供了两条能力路径路径一alert-analyzer子代理做告警与指标分析。查看 alert-analyzer.mdname: alert-analyzer description: Analyzes monitoring alerts and system metrics tools: Read, Grep, Bash其能力覆盖 Alert correlation告警关联、Trend analysis趋势分析、Root cause identification根因识别、Metric visualization指标可视化和 Proactive issue detection主动问题检测。也就是说Claude 可以把多个告警拼在一起找关联、看趋势定位异常起点从而把症状收敛到根因假设。路径二health-check.sh脚本做分层健康探测。仓库中的 health-check.sh 展示了典型的诊断采集手段# Check API echo -n API: if curl -sf http://api.$ENV.example.com/health /dev/null; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Database echo -n Database: if pg_isready -h db.$ENV.example.com /dev/null 21; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Pods echo -n Kubernetes Pods: PODS_READY$(kubectl get pods -n $ENV --no-headers | grep Running | wc -l) PODS_TOTAL$(kubectl get pods -n $ENV --no-headers | wc -l) echo $PODS_READY/$PODS_TOTAL ready脚本接受$1作为环境参数默认production依次探测 API 健康端点、数据库连通性pg_isready和 Kubernetes Pod 就绪数量输出一目了然的 ✅/❌ 与就绪比例。这类脚本可以在/incident的第 4 步中被 Claude 直接调用快速判断故障是落在应用层、数据库层还是容器编排层。此外status.md 中/status命令的六项检查Pod 状态、数据库连接、API 响应时间、错误率、资源利用率、整体健康报告也是第 4 步的标准信息源。5. 协调响应工作Coordinate response efforts诊断收敛后进入多角色协同处置阶段。incident-commander子代理的能力清单中Team coordination团队协调、Status updates状态更新、Resolution tracking解决跟踪三项都服务于这一步团队协调在多个修复方向之间做取舍与分工例如谁处理数据库连接池谁查 API 网关状态更新同步当前处置进度与最新影响面避免重复劳动解决跟踪记录已尝试的方案与结果确保修复动作可审计。从部署侧看处置手段通常有两种一是修复后通过 deploy.sh 重新部署该脚本内部包含 lint、test、build、kubectl apply -f k8s/$ENV/、健康检查的完整链路二是快速止血通过 rollback.sh 回滚脚本先读取kubectl rollout history确认前序版本再kubectl rollout undo回退并等待kubectl rollout status最后做健康检查。二者配合incident-commander的协调即可形成边回滚止血、边定位根因的标准打法。6. 记录解决方案Document resolution事故解决不等于工作完成必须把最终怎么解决的沉淀下来。这一步要求将根因、修复动作、验证方式、恢复时间点写入事故记录为后续复盘和知识库沉淀提供素材。incident-commander拥有 Write 工具权限正是为了支持这类文档写入动作。7. 安排事后复盘Schedule post-mortem最后一步是安排 Post-mortem事后复盘。incident-commander的职责清单最后一项正是Post-mortem facilitation复盘引导。复盘的核心目标不是追责而是回答三个问题为什么会发生为什么没有被更早发现如何防止再次发生复盘的输出通常包括改进项清单补充监控告警、增加健康检查项、调整部署策略等这些改进项又反过来反哺/status、/deploy、/rollback等命令的配置形成正循环。三、支撑架构子代理、脚本与 MCP 的协作方式/incident命令之所以是结构化的在于它并非孤立运行而是依托整个插件生态协同工作子代理层incident-commander协调、定级、复盘与alert-analyzer告警关联、根因分析分别承担指挥官与分析师角色两者权限工具见上文定义。脚本层health-check.sh 提供分层健康探测deploy.sh 与 rollback.sh 提供处置手段三者均以set -e保证失败即中断避免在错误状态下继续操作。MCP 层kubernetes-config.json 配置了 Kubernetes MCP 服务器使 Claude 能直接查询集群状态{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }该配置通过npx启动modelcontextprotocol/server-kubernetes并把KUBECONFIG环境变量透传给 MCP 服务器让 Claude 在事故响应中可以直接读取 Pod、Deployment、Rollout 等集群资源信息与health-check.sh、kubectl rollout history等命令互补。钩子层插件还提供了 pre-deploy.js 与 post-deploy.js。虽然它们名义上服务于部署但在事故场景中同样关键——post-deploy.js中的kubectl wait --forconditionready pod -l appmyapp --timeout300s正是验证修复是否真正生效的标准手段可作为第 6 步记录解决方案前的验证动作。四、前置条件与配置要在你的环境中运行/incident及配套命令需要满足插件 README.md 中列出的要求Claude Code 2.1Kubernetes CLIkubectl已安装集群访问已配置其中集群访问通过设置KUBECONFIG环境变量完成export KUBECONFIG~/.kube/config该环境变量同时被kubernetes-config.json中的 MCP 服务器引用因此配置一次即可同时满足命令行工具与 MCP 通道的需求。五、典型的/incident端到端响应示例将七步流程与仓库资源串联起来一次完整的/incident响应大致如下创建事故记录Claude 建立事故文档记录时间与来源如/status报告 API 不可用评估严重级别调用health-check.sh与 Kubernetes MCP发现 API ❌、数据库 ✅、Pod 0/3 ready判定为高严重级别P0/P1通知值班团队调用通知脚本告知事故级别、影响面与事故记录链接收集诊断信息alert-analyzer关联告警并定位到最近一次kubectl apply的 Deployment 变更Claude 用kubectl rollout history确认版本漂移协调响应incident-commander决策立即回滚止血调用 rollback.sh 回滚到上一版本再用post-deploy.js的kubectl wait等待 Pod 恢复就绪并配合curl健康检查确认恢复记录解决方案Claude 将根因有问题的镜像版本、处置动作回滚到 revision N、恢复时间写入事故记录安排复盘incident-commander引导生成 post-mortem输出改进项——例如为部署流程补充更严格的 pre-deploy 校验可参考pre-deploy.js的 kubectl 与集群连通性检查逻辑并在/status巡检中新增对应监控项。整个过程因为每一步都被固化为命令、脚本或子代理职责所以可重复、可审计也便于事后对照复盘。六、总结/incident的价值不在于让 AI 替人修故障而在于把事故响应从个人经验驱动的随机过程升级为组织级的标准化流程七步工作流保证了处置不遗漏关键环节incident-commander与alert-analyzer两个子代理分别承担协调与分析的职责health-check.sh、deploy.sh、rollback.sh与 Kubernetes MCP 提供了从诊断到处置的完整工具链。对于任何把生产环境稳定性当回事的团队这套模式都值得直接参考——你可以先阅读 incident.md 与插件的 README.md 理解整体设计再结合 incident-commander.md、alert-analyzer.md 与 kubernetes-config.json 逐项搭建属于自己的事故响应体系。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考