WebhookWise：我给告警群做了一个「守门人」
每个运维过生产系统的人都见过那个场景：告警群一晚上刷出几百条消息，真正重要的那一条淹没在第 217 和第 219 条之间，而第二天早上追问「昨晚为什么没人处理」的时候，答案往往是——“消息太多了，划走了”。
告警本身不是问题，无差别地转发告警才是问题。于是我做了 WebhookWise：一个自部署的告警网关，站在监控系统和通知群之间，把「收到告警」和「打扰人类」这两件事拆开，中间插进去分析、去重、抑制、路由和一整套可追溯的决策记录。
项目开源在 GitHub：github.com/itswl/WebhookWise。技术栈是 FastAPI + TaskIQ + PostgreSQL + Redis，观测走 OpenTelemetry。它已经先后在两家公司的生产环境跑了 8 个月，累计处理上万条真实告警——文中的截图和成本数字都取自当前在跑的这套环境，不是 benchmark。
一条告警的完整旅程
理解这个项目最快的方式，是跟着一条告警走一遍（仪表盘里有个 #/guide 教程页，就是按这条路线组织的）：
1. 接入。 Grafana、Prometheus、Zabbix、阿里云、腾讯云、Sentry、Jenkins、Uptime Kuma……十来种来源有现成适配器，任意 JSON webhook 也能收。接入向导会为每个来源签发独立的、可吊销的凭据——泄露一个密钥不会波及其他来源。
2. 分诊。 AI 对每条告警给出结构化判断：重要度之外还有 triage_verdict（立即处理 / 观察 / 可延后）和置信度。但 AI 不是无脑调用的——低价值告警走廉价的规则通道，相同告警复用缓存的分析结果，月度预算可以强制执行。我的真实账单：上周 AI 花费 $5.55，靠缓存和降噪省下了 $9.95——省下的比花掉的多。
3. 八道抑制闸门。 去重、静默、维护窗、风暴抑制、冷却、预算……每条告警要过八道门才能打扰到人。关键的设计是：每一次「拦下」都有记录。决策链（decision trace）会告诉你这条告警止步于哪道门、命中了哪条规则——“为什么没收到通知”这个千古难题，在这里永远有一个可点开的答案。
4. 路由与投递。 关键词、严重度、事件类型匹配转发规则，投递到飞书或任意 webhook。投递走事务性 Outbox：处理结果和投递意图在同一个数据库事务里落盘，然后异步投递、指数退避重试、耗尽进死信队列——死信可以单条、批量、一键全量回放。规则上线前可以在沙箱里用真实报文试跑，全程不入队、不调 AI、不落库。
5. 事故与协作。 相关告警自动聚合成事故。飞书卡片上直接认领（真的会写入指派人）、解决、一键静默 2 小时；解决时可自动生成一张 AI 复盘卡片发回群里。交接班有自动生成的简报，复盘有一键导出的 Markdown（时间线、根因、处置过程、行动项全部预填），全局有 MTTA / MTTR / 认领率看板。
6. 知识沉淀。 已解决事故的摘要自动沉淀为知识库草稿，人工审核发布后进入 RAG——下次相似告警来的时候，AI 分析会带着”上次是怎么解决的”来见你。未经审核的内容永远不会影响分析，这是刻意的设计边界。
几个我觉得值得写下来的设计
决策要可追溯，而不只是可配置。 大多数告警工具的问题不在于抑制能力不够，而在于抑制之后变成了黑盒。WebhookWise 把「每条告警的每个决策」都记成一等公民的数据——所以降噪中心可以给每条静默规则算 ROI（拦了多少、省了多少分钟），规则审计可以指名道姓地告诉你哪条规则是僵尸（90 天零匹配）、哪条是纯噪音，新静默规则可以先对历史数据回测再上线。降噪不靠感觉，靠数字。
运行时设置平面。 81 个策略参数（去重窗口、风暴阈值、AI 预算、断路器……）可以从仪表盘直接改，DB 覆盖 → 环境变量 → 代码默认三层优先级，约 60 秒内在所有进程生效，不用重启。凭据和端点仍然只在环境变量里——可热调的是策略，不是秘密。
给 AI Agent 的一等公民接口。 这可能是和同类工具差异最大的地方。WebhookWise 内建一个只读 MCP Server（18 个工具 + 使用指南资源 + 调查提示词），任何 MCP 客户端——Claude Code、Cursor、自定义 Agent——一条命令接入：
1 | claude mcp add --transport http webhookwise \ |
接上之后你可以直接问：”为什么 #923 没通知我？””这个班发生了什么？””哪些规则可以删了？”仓库里还带了三个现成的技能（.claude/skills/）：单条告警全链路调查、交接班简报、降噪审计——Claude Code 打开仓库即用。刻意只读：Agent 负责回答问题，动手仍然走有审计的仪表盘。
深度调查则交给 hookprobe——它来自我做的另一个开源项目 hookstack：一组小而专的告警工具件，走的是和 WebhookWise 相反的路线。hookrelay 只做一件事——可靠的告警转发管道；hookjudge 只做告警判定；hookprobe 是基于 Claude Agent SDK 的自治调查员，会把每次调查的结论蒸馏成 SKILL.md runbook，自己长经验（模型可换，我在 DeepSeek 上验证过供应商无关）。三件都能独立用，也都和 WebhookWise 打通了：relay + judge 正通过 WW 的一条影子规则在真实流量上灰度陪跑，hookprobe 挂着 WW 的只读 MCP、还把 WW 仓库里的技能库以只读 user 层挂载进自己的技能体系。
触发深度分析时，WebhookWise 会把决策链、7 天重复压力、既往结论、所属事故和知识库命中打包成「证据包」随请求送过去——调查 Agent 不用再花一轮工具调用回查背景。
外部输入永远是数据，不是指令。 告警报文会被送进 LLM，这天然是提示注入的攻击面。所有进入模型的外部文本都经过中和处理并被明确围栏标注「不可信输入」——包括上面说的证据包里引用的告警原文和知识库摘录。
工程上的底气
这个项目是「AI 辅助开发 + 契约测试压舱」的产物：1300+ 测试，其中有一批很有性格的契约测试——比如「禁止 markup 引用任何 CSS 里不存在的类」（一次全量 UI 排查发现的整类 bug，现在被棘轮契约永久冻结）、「禁止两个元素复用同一个静态绑定 ID」（曾经让点击搜索框误触发凭据清除）。本地有一个和 CI 完全等价的门禁脚本，红了就不许 push——这些规矩都是用真实的红 CI 换来的。
观测是 OTel-first：应用只往 OTLP 发遥测，Alloy 分发到 Prometheus / Loki / Tempo，Grafana、Pyroscope、Alertmanager 补完诊断闭环。网关自己坏了也有自监控告警——监控系统的监控，不能靠它自己。
适合谁
WebhookWise 走的是「自部署、大而全、AI-first」路线：一套 docker compose 起全家桶，数据不出你的机器，LLM 可以接任何 OpenAI 兼容端点（我在用 DeepSeek，成本见上文）。如果你是几个人的小团队，被告警群刷屏但又不想上商业 SaaS，这就是为你做的。
如果连 PostgreSQL + Redis 都嫌重，仓库里还有个 WebhookWise Lite：同一套产品思路的单进程版，SQLite、无 Redis、约 800 行、四道抑制闸门——先用 Lite 感受一下，再决定要不要上全量版。
值班表和状态页刻意不做——那是 Grafana OnCall 和状态页服务的地盘，做好告警的「守门人」这一件事就够了。
仓库：github.com/itswl/WebhookWise（中英双语 README）
一条命令体验：docker compose up -d，打开仪表盘，把你的 Grafana 指过来。欢迎 issue 和 PR。