n8n事故分诊与处置：Claude评估风险，Slack审批后执行修复

原文要点

原模板是一个n8n事故处置工作流：支持定时、事故接收webhook或手动三种触发；从事故管理API取未结事故组成队列，逐个拉监控指标快照和近期部署记录，交Anthropic Claude先做分诊评估、再提出单个runbook修复动作及风险等级；中高风险或超过autoRemediateMaxSeverity的动作发Slack审批并置为pending，低风险直接调runbook引擎执行并记录结果；Claude再起草状态更新发Slack，结果回写事故API，队列清空后发汇总摘要。配置项含各API地址、Slack webhook、模型名、maxIncidentsPerRun。

这次做成什么

在n8n里搭一条事故分诊流水线：收到事故后自动收集诊断信息、让Claude给出风险评级和单一修复动作，按风险阈值决定直接执行还是转人工审批，最后回写结果并发汇总。本站设计一个两事故的隔离演练方案，所有API用本地mock地址代替。

准备什么

• 一个可登录的n8n Cloud或自托管实例
• Anthropic API密钥，用于Claude分诊与状态更新起草
• Slack工作区及两个incoming webhook地址（审批频道与状态频道）
• 可访问的事故管理/监控/部署记录/runbook引擎API及各自的Header Auth凭据，演练时可用mock服务代替

具体怎么做

1. 配置凭据与全局参数

   在n8n凭据页为监控API、部署历史API、事故管理API、runbook引擎API各建一条HTTP Header Auth凭据，再建Anthropic凭据。打开配置节点，填入monitoringMetricsUrl、deployHistoryUrl、openIncidentsUrl、incidentUpdateUrl、runbookExecuteUrl、两个Slack webhook地址、Anthropic模型名，并把autoRemediateMaxSeverity设为low、maxIncidentsPerRun设为2做演练。

2. 接通触发与事故队列

   保留Schedule Trigger与Incident Intake Webhook，演练时直接用Manual Trigger。在构建队列的节点里确认字段映射：incidentId、title、severity、service、openedAt。若从事故API取数，确认openIncidentsUrl返回数组后逐条转成队列项；若用webhook推入，把webhook URL配到告警系统。

3. 挂接诊断数据与Claude分诊

   在循环内确认每个事故先请求监控快照和部署历史，把两者连同事故字段拼进Claude分诊提示词（见材料1），要求模型只输出JSON：triage_summary、probable_cause、proposed_action、risk_level（low/medium/high）。在Claude节点后加JSON校验，解析失败则标记为需人工处理。

4. 配置风险分支与审批回调

   在IF节点设置条件：risk_level为medium/high，或severity大于autoRemediateMaxSeverity时走审批分支——向Slack审批webhook发送含incidentId、action描述的卡片，事故状态置pending；否则走执行分支，向runbookExecuteUrl POST动作并记录返回。把审批回调webhook地址提供给审批界面，回调体含incidentId、action、approved字段。

5. 收尾回写与汇总

   确认每个事故处理完后：Claude起草利益相关方状态更新发到Slack状态频道，完整结果POST到incidentUpdateUrl。循环结束后触发汇总节点，向Slack发本轮处理条数、成功/待审批/失败统计，webhook触发时同时在响应里返回该摘要。用下方测试数据空跑一轮核对字段。

可直接复制的材料

你是站点可靠性事故分诊助手。根据下面的事故信息、监控指标快照和近期部署记录完成两件事：
1) 给出不超过80字的分诊结论和最可能原因；
2) 只提出一个可执行的runbook修复动作，并评估其风险等级。
严格只输出JSON，不要输出任何其他文字，格式：
{"triage_summary":"...","probable_cause":"...","proposed_action":{"runbook_id":"...","description":"...","target_service":"..."},"risk_level":"low|medium|high"}
风险判定规则：只读操作和重启单个实例为low；影响单个服务的配置变更为medium；涉及数据库、网络策略或多服务为high。
事故信息：{{$json.incident}}
监控快照：{{$json.metrics}}
近期部署：{{$json.deploys}}

{
  "incidents": [
    {
      "incidentId": "INC-2041",
      "title": "checkout-api 5xx错误率升高",
      "severity": "high",
      "service": "checkout-api",
      "openedAt": "2026-09-28T21:14:00Z",
      "metrics": {"error_rate_5m": 0.18, "p95_latency_ms": 2400, "cpu_pct": 61},
      "deploys": [{"version": "v3.7.2", "at": "2026-09-28T20:40:00Z", "change": "升级支付SDK"}]
    },
    {
      "incidentId": "INC-2042",
      "title": "静态资源CDN缓存命中率下降",
      "severity": "low",
      "service": "cdn-edge",
      "openedAt": "2026-09-28T22:03:00Z",
      "metrics": {"cache_hit_rate": 0.62, "origin_latency_ms": 310},
      "deploys": []
    }
  ]
}

输入与输出示例

本站虚构演示，未真实调用Claude或任何API，输出结构与字段仅为方案示意。

输入

手动触发后队列载入上述两条虚构事故：INC-2041（high，checkout-api错误率18%，事发前40分钟有支付SDK升级部署）和INC-2042（low，CDN命中率62%）。

对应输出

示意输出：INC-2041由Claude判定proposed_action为回滚checkout-api至v3.7.1、risk_level为high，因超过阈值转Slack审批并置pending；INC-2042判定为刷新CDN缓存、risk_level为low，直接POST到runbookExecuteUrl并记录执行成功。最终Slack摘要：本轮2起事故，1起已自动处置，1起待审批，0起失败；该摘要同时作为webhook响应返回。

做完检查这些

• 两条测试事故分别走了审批分支和自动执行分支，分支条件与阈值配置一致
• 审批分支的事故在事故管理API中状态为pending，且Slack卡片含incidentId与action描述
• 每个事故处理完成后incidentUpdateUrl都收到完整结果回写，含分诊结论与执行/审批状态
• 队列清空后Slack收到汇总摘要，webhook触发的响应体也包含同一摘要
• Claude输出非合法JSON时该事故被标记为需人工处理而非中断整个循环

容易卡住的地方

• 原文只给出配置项名称，未提供可下载的工作流JSON，节点连接需按本文步骤自行搭建
• 审批回调要求外部审批UI或Slack工作流能回传incidentId、action、approved，缺任一字段会匹配不上待审批事故
• autoRemediateMaxSeverity的判定口径（按事故severity还是动作risk_level）需在IF节点里明确写清，两种口径结果不同
• 演练时务必用mock地址替换真实事故管理和runbook API，避免测试数据触发真实修复动作
• Anthropic API调用按量计费，队列长度受maxIncidentsPerRun限制但每事故至少两次模型调用