Slack报障后AI自动排查并修问题

原文要点

原文是免费n8n模板：Slack Trigger监听指定频道（默认#incident-response）新消息，规范化文本、频道、线程时间戳、报告人并生成会话ID；GPT-4.1智能体带线程记忆，按需调用Prometheus指标、Loki日志和向量库历史故障RAG，输出结构化JSON根因分析，写入PostgreSQL incidents表；无修复建议则回帖结束，有建议则发审批请求并经resume webhook等待人工决定；批准后建Jira或GitHub工单、触发Terraform Cloud执行、回查Prometheus、加Grafana注解并在原帖汇总；拒绝则回帖结束。

这次做成什么

在测试环境复现“Slack报障→AI排查→人工审批→修复→回帖汇总”的完整链路。本站按原文描述给出等价搭建步骤、智能体系统提示词、incidents建表语句和合成测试消息，未核实的字段名与参数以原模板页面为准。

准备什么

• 一个n8n实例及可收发消息的Slack测试工作区凭据
• OpenAI API密钥，账户可访问GPT-4.1级别模型
• 可访问的Prometheus、Loki、Grafana测试实例及各自URL
• PostgreSQL数据库及建表权限
• Jira或GitHub测试项目凭据，以及Terraform Cloud测试工作区token

具体怎么做

1. 触发与规范化

   放Slack Trigger，事件选message posted，频道先建一个测试频道如#incident-test。接Code节点输出四字段：text、channel、threadTs、reporter，并用threadTs拼接生成sessionId，供后续会话记忆按线程隔离。

2. 智能体与工具

   放AI Agent节点，模型凭据选OpenAI（原模板为GPT-4.1），挂三个工具：指向Prometheus查询接口的HTTP Tool、指向Loki查询接口的HTTP Tool、以及向量库检索工具（先灌入两三篇本站虚构的历史故障复盘文档）。系统提示词用下方artifacts全文，要求最终只输出结构化JSON。

3. 解析与落库

   接Code节点解析智能体JSON，校验字段齐全；接Postgres节点执行INSERT，映射到下方建表语句的列。先手动跑一条假数据确认表结构与映射无误。

4. 分支与审批

   用IF节点判断remediation是否为空：空则Slack节点回帖说明“已记录分析，暂无修复建议”并结束；非空则发一条带Approve/Reject按钮的Slack消息，按钮回调指向本工作流的Wait节点resume webhook，载荷里带reviewerApproved布尔值。测试时可先用n8n界面里的resume链接手动模拟批准与拒绝。

5. 批准后动作链

   approved分支依次接：Jira或GitHub Issue创建节点（配置项ticketingSystem取jira或github）、HTTP节点调Terraform Cloud对测试工作区触发run（替换原模板中的REPLACE_WITH_WORKSPACE_ID）、HTTP节点回查Prometheus关键指标、HTTP节点向Grafana写annotation、最后Slack节点在原线程回复汇总。rejected分支仅回帖通知并结束。

可直接复制的材料

你是值班SRE排查助手。用户会给你一条故障报告。你可以调用三类工具：查询Prometheus获取指标、查询Loki获取日志、检索历史故障知识库。请按需调用工具收集证据，不要臆造数据；工具查不到就如实说明。最终只输出一个JSON对象：{"service":"受影响服务名","rootCause":"根因一句话","confidence":"high|medium|low","evidence":["证据1","证据2"],"remediation":"具体修复动作，若无把握填空字符串","riskLevel":"high|medium|low"}。remediation为空表示不建议自动修复。

CREATE TABLE IF NOT EXISTS public.incidents (
  id SERIAL PRIMARY KEY,
  session_id TEXT,
  service TEXT,
  root_cause TEXT,
  confidence TEXT,
  evidence JSONB,
  remediation TEXT,
  risk_level TEXT,
  reporter TEXT,
  channel TEXT,
  thread_ts TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

{"title":"2026-06-12 checkout-api延迟飙升复盘","content":"现象：checkout-api P99延迟从200ms升至2.1s。根因：某次发布将数据库连接池上限从50改为10，高峰期连接耗尽排队。修复：回滚配置并恢复连接池上限，增加发布前配置diff检查。关键词：延迟,连接池,发布回滚"}

输入与输出示例

本站虚构演示，非原作者运行结果；未实际调用模型与各系统，输出为按提示词推演的示意。

输入

测试频道#incident-test里发消息："checkout-api从14:05开始大量超时，P99延迟2秒以上，刚才14:00有一次发布。"

对应输出

智能体JSON：{"service":"checkout-api","rootCause":"14:00发布将数据库连接池上限从50改为10，高峰期连接耗尽","confidence":"high","evidence":["Prometheus显示db_pool_active_connections=10且等待队列持续增长","Loki中14:03起大量connection timeout日志","知识库命中2026-06-12相似故障"],"remediation":"回滚发布至上一版本并恢复连接池上限50","riskLevel":"medium"}；工作流写入incidents一行，随后在原线程发出带Approve/Reject的审批消息。

做完检查这些

• 在测试频道发合成报障后，incidents表新增一行且service、confidence、risk_level与智能体输出一致
• 把提示词场景改为无证据的报障，remediation输出为空字符串时工作流只回帖不创建任何工单
• 模拟reviewerApproved=true后，测试仓库出现一张新issue且Terraform Cloud测试工作区产生一次run记录
• 模拟reviewerApproved=false后，原线程收到拒绝通知且未触发任何修复动作

容易卡住的地方

• 审批依赖Slack交互按钮回调resume webhook，公网不可达的自托管n8n需先解决回调地址
• GPT-4.1调用及Prometheus、Loki、Terraform Cloud等服务的可用性与费用以各自平台为准
• 智能体输出若不是合法JSON会导致解析节点报错，需在提示词中强调只输出JSON并加容错
• 替换Terraform工作区ID前务必用测试工作区，切勿指向生产环境
• 本页节点名与字段为本站按原文描述的等价重建，具体界面、节点配置与参数细节以原模板页面实际内容为准。