KPI异常检测加AI调查加告警闭环

原文要点

原工作流两段定时：凌晨 01:00 从 Postgres 的 kpi_metrics 表读取启用的指标定义并执行各自 metric_sql，把昨日观测写入 kpi_observations，同时用 28 天中位数和 MAD（另含按星期几的中位数）重建基线，历史不足的指标发 Slack 预警；早 07:00 把昨日 KPI 与基线对比算出稳健 z 分，按方向与最小变化幅度过滤、按未关闭事件去重并限制单次事件数。每个入列异常在 kpi_incidents 建档后，由 OpenRouter 上的 Claude 智能体带 Postgres 与 GitHub 工具查佐证，证据一致性检查不过关就丢弃结论；按严重度路由 Slack，危重事件另建 GitHub Issue 并 Gmail 通知指标负责人确认。支持 header 鉴权 webhook 回写 confirmed/false_positive/wont_fix 三种处置，每周一发准确率报告并建议 z 阈值调整。模板免费。

这次做成什么

在本站练习中搭起“采集→基线→检测→AI 调查→告警→回写”闭环的最小版本：建 4 张表、灌 28 天合成指标数据、触发一次异常检测，观察 Claude 调查与 Slack 告警，并用 webhook 回写处置结果。

准备什么

• n8n 实例，已从 n8n.io/workflows/19804 导入原工作流
• 一个 Postgres 数据库（测试库即可），有建表与读写权限
• OpenRouter 账号及凭据（Claude 模型调用按 OpenRouter 计费，非免费）
• Slack Bot Token、GitHub Token（建 Issue 需仓库写权限）、Gmail 凭据
• 至少 14 天的指标历史（原文要求；推荐 28 天，可用合成数据回填）

具体怎么做

1. 建表并灌入合成历史

   在测试库执行下方建表 SQL，建 kpi_metrics、kpi_observations、kpi_baselines、kpi_incidents 四张核心表（原模板还含报告相关表，以导入后的节点报错提示补齐）。在 kpi_metrics 插入一条指标 daily_signups，其 metric_sql 指向一张合成业务表；用下方 CSV 导入 28 天观测值，其中最后一天人为抬高制造异常。

2. 配置凭据与占位符

   全部 Postgres 节点绑数据库凭据；Slack 节点绑 Token 并把 ALERT_SLACK_CHANNEL 占位改为测试频道；GitHub 节点绑 Token 并指向一个测试仓库；Gmail 节点绑凭据并把 DATA_ONCALL_EMAIL 改成你自己的邮箱；OpenRouter 节点绑凭据。

3. 手动跑凌晨采集与基线重建

   先手动执行 01:00 的采集流程，确认 kpi_observations 新增昨日观测、kpi_baselines 重算出 median 与 MAD 且 coverage 达标（28 天数据应无“历史不足”预警；删掉一半数据再跑可看到 Slack 预警分支）。

4. 触发检测并观察 AI 调查

   手动执行 07:00 检测流程。昨日观测相对基线 z 分超过阈值且满足方向与最小变化幅度规则，应生成一条 incident；随后 Claude 智能体被允许用 Postgres 与 GitHub 工具查证，输出含证据的解释并做一致性自检；你可以在测试仓库先开一个标题含“signups”的 PR，观察它是否会引用该 PR 作为佐证。

5. 走告警与处置回写

   确认严重度路由：普通异常只发 Slack；把测试指标阈值临时调低造出 critical，验证会同时建 GitHub Issue 并发邮件。然后复制 Disposition Webhook 的 URL，用带 header 鉴权的 POST 提交 {"incident_id":1,"disposition":"false_positive"}，确认 incident 状态回写；周一报告可手动触发查看准确率统计。

可直接复制的材料

CREATE TABLE kpi_metrics (
  id SERIAL PRIMARY KEY,
  metric_name TEXT UNIQUE NOT NULL,
  enabled BOOLEAN DEFAULT TRUE,
  metric_sql TEXT NOT NULL,
  owner_email TEXT,
  direction TEXT DEFAULT 'both',
  min_change_pct NUMERIC DEFAULT 10
);

CREATE TABLE kpi_observations (
  id SERIAL PRIMARY KEY,
  metric_name TEXT NOT NULL,
  obs_date DATE NOT NULL,
  value NUMERIC NOT NULL,
  UNIQUE (metric_name, obs_date)
);

CREATE TABLE kpi_baselines (
  metric_name TEXT PRIMARY KEY,
  median_28d NUMERIC,
  mad_28d NUMERIC,
  coverage_days INT,
  recomputed_at TIMESTAMP DEFAULT now()
);

CREATE TABLE kpi_incidents (
  id SERIAL PRIMARY KEY,
  metric_name TEXT NOT NULL,
  detected_date DATE NOT NULL,
  z_score NUMERIC,
  severity TEXT,
  investigation TEXT,
  disposition TEXT,
  created_at TIMESTAMP DEFAULT now()
);

metric_name,obs_date,value
daily_signups,2026-08-26,102
daily_signups,2026-08-27,98
daily_signups,2026-08-28,105
daily_signups,2026-08-29,61
daily_signups,2026-08-30,58
daily_signups,2026-08-31,104
daily_signups,2026-09-01,99
daily_signups,2026-09-02,101
daily_signups,2026-09-03,97
daily_signups,2026-09-04,103
daily_signups,2026-09-05,63
daily_signups,2026-09-06,59
daily_signups,2026-09-07,100
daily_signups,2026-09-08,106
daily_signups,2026-09-09,95
daily_signups,2026-09-10,102
daily_signups,2026-09-11,99
daily_signups,2026-09-12,64
daily_signups,2026-09-13,60
daily_signups,2026-09-14,101
daily_signups,2026-09-15,98
daily_signups,2026-09-16,104
daily_signups,2026-09-17,96
daily_signups,2026-09-18,103
daily_signups,2026-09-19,62
daily_signups,2026-09-20,57
daily_signups,2026-09-21,101
daily_signups,2026-09-22,240

你是 KPI 异常调查员。给你一个异常事件（指标名、日期、观测值、基线中位数、z 分）。你可以使用两个工具：查询 Postgres 数据库（读取相关业务表做下钻）和查询 GitHub（列出近期合并的 PR）。
要求：
1. 先提出 1-2 个可验证的假设，再用工具取证；
2. 每条结论必须附证据来源（SQL 查询结果摘要或 PR 编号/标题）；
3. 找不到足够证据时，输出 "insufficient_evidence" 而不是猜测；
4. 最终输出 JSON：{"hypothesis":"...","evidence":["..."],"confidence":"high|medium|low","verdict":"explained|insufficient_evidence"}。

异常事件：{{ $json.incident }}

输入与输出示例

本站虚构演示，z 分按稳健公式 (240-101)/(1.4826×3) 估算，实际计算与调查结果以模板和模型真实输出为准。

输入

kpi_observations 中 daily_signups 在 2026-09-22 的值为 240，此前 28 天工作日中位数约 101，MAD 约 3，min_change_pct=10，方向 both

对应输出

检测输出示意：{"metric_name":"daily_signups","obs_date":"2026-09-22","value":240,"median_28d":101,"robust_z":31.3,"change_pct":137.6,"severity":"critical"}；入列后 Claude 调查返回 {"hypothesis":"9-21 晚合并的 PR #412 启用了新落地页，带来注册激增","evidence":["PR #412 'new landing page rollout' merged 2026-09-21","signups by_source 显示 organic 占比从 40% 升至 78%"],"confidence":"medium","verdict":"explained"}；Slack 收到 critical 告警，GitHub 测试仓库新建 Issue，负责人收到确认邮件。

做完检查这些

• kpi_metrics 中 enabled=true 的指标每日都有一条新观测写入，且同一天重复跑不会产生重复行（唯一约束生效）
• 基线覆盖天数不足时收到 Slack 预警，灌满 28 天后预警消失
• 注入值 240 被判定为异常且 z 分与变化幅度均超过阈值，正常波动日（如 98→103）不产生 incident
• 同一指标存在未关闭 incident 时，新异常被去重压制，单次运行事件数不超过模板上限
• 调查 verdict 为 insufficient_evidence 时 incident 被标记丢弃而非强行告警
• webhook 只接受 confirmed、false_positive、wont_fix 三种值，其他 disposition 被拒且 incident 不改动

容易卡住的地方

• 基线依赖历史积累：新接入的指标前 14 天（原文给出的最低线）无法可靠评分，练习用回填数据解决，生产需等待或预填
• OpenRouter 上的 Claude 调用按量计费，异常越多调查调用越多，批量回填测试时注意单次运行事件上限
• GitHub 工具只读 PR 列表用于取证，建 Issue 才需要写权限，最小权限原则配 Token
• webhook 必须配 header 鉴权，否则任何人都能篡改处置结果影响周一准确率报告
• MAD 基线对周末/工作日差异靠“按星期几的中位数”修正，删除这部分逻辑会导致周末误报
• 严谨告警依赖 Postgres 里的处置回写闭环，只接告警不回写，准确率报告没有意义