Wiki Notes

Appearance

多通道告警设计专题 ​

版本：v1.3

最后更新：2026-07-08

适用对象：正在做 LLM 平台、RAG、Agent、审批系统和实时语音系统，需要让告警既能及时触达，又不把团队吵垮的平台、值班和运营同学

很多系统都有告警，但真正出问题时经常还是会出现两种极端：

  • 小问题把所有人吵醒
  • 大问题却没有在关键渠道及时触达

这通常不是“没有告警”，而是：

  • 告警通道、告警级别、升级路径和处理角色没有一起设计。

这篇专题聚焦的不是如何接一个机器人发消息，而是：

  1. 哪些问题应该走哪些通道
  2. 如何把告警按严重级别、时效和责任角色拆开
  3. 怎样避免“渠道很多，但没有闭环”

Google SRE 当前关于 Alerting on SLOs、Implementing SLOs、Postmortem analysis 的资料，以及 OpenAI 当前关于 Production best practices、Integrations and observability、Trace grading、Evaluate agent workflows 的资料，在 2026-07-08 复核时都在提醒同一个现实：

  • 多通道告警不是通知工程，而是响应工程。

1. 什么是多通道告警 ​

更实用的理解通常是：

  • 根据故障级别、影响范围、响应时限和责任角色
  • 把同一类事件投递到不同渠道和不同节奏

重点不是“渠道越多越好”，而是：

  • 合适的问题进合适的通道，合适的人在合适的时间被打扰。

2. 为什么 AI 系统比传统系统更需要多通道 ​

因为 AI 系统的异常不仅有：

  • 服务不可用

还包括：

  • 质量退化
  • 高风险动作异常
  • 审批积压
  • 成本异常
  • 评测回归
  • 实时体验劣化

这些异常对不同角色的影响完全不同：

  • 一线值班关心先止血
  • 平台研发关心定位链路
  • 业务 owner 关心用户影响
  • 安全 owner 关心风险暴露

如果所有问题都走同一条通道，结果通常只有两种：

  • 噪音太大，所有人免疫
  • 高优先级问题被淹没

3. 多通道设计真正要解决的是什么 ​

很多团队会把它理解成：

  • 群消息、短信、邮件都接上

这只是最表层。

真正更重要的问题通常是：

  • 什么级别触发什么通道
  • 多久升级一次
  • 谁必须被通知
  • 谁只需要知情
  • 哪些告警需要确认回执
  • 哪些告警需要工单化
  • 哪些告警要能直接进入桥接会议或事故群

如果这些问题没定义，渠道再多也只是：

  • 多了一堆会发消息的地方

4. 常见告警通道分别适合什么 ​

4.1 Dashboard / 日报 / 周报 ​

适合：

  • 趋势观察
  • 非即时处理问题
  • 长期质量和成本监控

4.2 IM 群消息 ​

适合：

  • 需要工作时间内快速处理的问题
  • 一线值班协作
  • 带 trace 链接的调查入口

4.3 工单系统 ​

适合：

  • 需要责任归属
  • 需要留痕和 SLA
  • 需要跨团队跟进

4.4 电话 / 短信 / Pager ​

适合：

  • 高优先级事故
  • 高风险动作异常
  • 影响面大的线上故障

4.5 主管升级 / 桥接会议 ​

适合：

  • 长时间未恢复
  • 影响关键租户
  • 需要跨业务、安全、平台同步决策

这几个通道本身都不复杂，复杂的是：

  • 哪类事件该进哪类通道

5. 单一通道为什么通常不够 ​

如果所有问题都发到一个群里，最后很容易发生：

  • 观察类波动把处理类问题淹没
  • 紧急类事故也和普通趋势提醒混在一起
  • 值班同学被迫自己人工判断严重级别

对 AI 系统来说，这种风险更高，因为不同问题的响应方式差别很大：

  • 评测退化可能要阻断发布
  • 工具越权可能要立即停用自动执行
  • 成本异常可能先看路由和缓存
  • 审批积压可能要同步业务 owner 调整值班和策略

所以多通道设计本质上是在给：

  • 不同类型的问题安排不同节奏的打扰

6. 更实用的第一层分流：观察类、处理类、紧急类 ​

一个简单但很稳的拆法通常是三层。

6.1 观察类 ​

适合：

  • 指标轻微波动
  • 尚未超过动作阈值
  • 更适合进入 dashboard 或报表

6.2 处理类 ​

适合：

  • 需要工作时间内跟进
  • 已影响某类 workflow 或某类租户
  • 需要 trace 调查和责任人动作

6.3 紧急类 ​

适合：

  • 高风险动作异常
  • 大面积质量或时延故障
  • 审批链失效
  • 关键租户严重受影响

这类分流的价值在于：

  • 降低噪音
  • 保护高优先级通道

7. 第二层分流：按问题类型继续拆 ​

AI 系统里，观察类、处理类、紧急类还不够，通常还需要按问题类型拆。

7.1 质量告警 ​

例如：

  • grader 分数跌破阈值
  • 引用质量下降
  • 某场景通过率下降

7.2 成本告警 ​

例如：

  • token 突增
  • 缓存命中下降
  • 重试成本上升
  • 某 workflow 单次成本翻倍

7.3 安全告警 ​

例如：

  • guardrail 命中异常
  • 高风险动作误放行
  • 审批超时
  • 越权工具调用

7.4 稳定性告警 ​

例如：

  • 延迟升高
  • 工具超时
  • fallback 激增
  • session 中断率上升

这样分桶后，团队更容易判断到底该：

  • 降级
  • 回滚
  • 转人工
  • 找平台
  • 找安全

8. 多通道路由矩阵最好同时看四件事 ​

更可执行的矩阵通常至少同时看：

  1. 严重级别
  2. 影响范围
  3. 响应时限
  4. 责任角色

一个简化版可以这样理解：

告警类型首通道升级通道主要角色
观察类波动dashboard / 周报IM 群提醒平台、运营
处理中异常值班群 / 工单电话 / 短信值班、一线支持
紧急类事故电话 / Pager主管升级、桥接会议平台、业务 owner、安全

重点不是表长什么样，而是：

  • 每类告警都能落到明确动作

9. 同一条告警对不同角色，最好生成不同视图 ​

同一条告警，对不同角色的意义并不一样。

例如：

  • 一线值班需要快速定位入口
  • 二线研发需要技术上下文
  • 业务 owner 需要影响评估
  • 安全 owner 需要风险判断

更稳的设计方式通常是：

  • 值班视图：严重级别、trace、止血建议
  • 研发视图：版本、链路、失败样例
  • 业务视图：影响租户、影响功能、预计恢复时间
  • 安全视图：风险类型、动作类型、暴露面、审批状态

这比“把所有信息都堆在一条消息里”更实用，也更不容易让人忽略重点。

10. 告警要和 trace / 回放 / runbook 一起设计 ​

AI 告警如果只有“发出去了”，价值其实很有限。

更稳的做法通常是让告警里直接带上：

  • trace id
  • release bundle / 配置版本
  • workflow / route
  • 任务类型
  • 最近失败样例或回放入口
  • runbook 链接
  • 首个建议动作

OpenAI 当前 Integrations and observability 文档说明 trace 默认可以包含：

  • model calls
  • tool calls
  • handoffs
  • guardrails
  • custom spans

对 AI 系统来说，这些字段通常比“HTTP 500 次数”更有定位价值。

11. 高优先级告警必须设计回执和升级 ​

高优先级告警最怕的不是没发出来，而是：

  • 发了，但没人真正接手

更稳的升级设计通常至少包含：

  1. 首次触发后多久提醒一线值班
  2. 多久未确认就自动升级
  3. 哪些告警会自动桥接到业务 owner 或安全负责人
  4. 哪些高风险告警必须带人工确认回执

如果没有这些机制，值班人在高压时刻很容易靠经验硬扛，结果就是：

  • 升级不及时
  • 责任不清
  • 复盘难沉淀

12. 告警系统本身也要防单点失效 ​

很多团队只考虑业务系统失败，却忽略：

  • 告警渠道本身也可能失败

例如：

  • 群机器人异常
  • 电话通知链中断
  • 工单系统延迟
  • 值班日历没同步

12.1 更稳的兜底方式 ​

  • 值班群失败时自动走 Pager
  • 工单创建失败时同时发 IM + 邮件
  • 高优先级告警保留主通道和备用通道

否则最关键的时候，告警系统本身会成为单点故障。

13. 多通道设计不该只覆盖“通知”，还要覆盖“确认、止血、复盘” ​

一个成熟的告警系统不应该只负责：

  • 通知

还应接到：

  • 确认
  • 止血
  • 回滚
  • 复盘
  • 回流评测

推荐闭环：

text
alert
 -> acknowledge
 -> route by severity
 -> mitigate / rollback
 -> attach traces and samples
 -> postmortem / eval backfill

如果告警和后续动作断开，团队就会不断重复同类事故。

14. 告警通道设计最好和组织值班结构对齐 ​

很多通道设计失败，不是技术问题，而是组织结构不匹配。

例如：

  • 平台在值班，但业务 owner 不在回路里
  • 安全事件进了业务群，但没人懂怎么处置
  • 审批积压只有运营知道，平台直到用户抱怨才知道

更稳的做法通常是：

  • 通道矩阵和 on-call / owner map 对齐
  • 让每类告警都有明确一线、二线、升级对象

这样后续的 runbook、桥接会议和复盘才不会混乱。

15. 多通道策略也要做噪音治理 ​

多通道不是越多越好，通道过多反而更容易制造噪音。

建议定期检查：

  • 哪些告警总是没人处理
  • 哪些告警经常误报
  • 哪些告警总是先在低优先级通道出现，但后来升级成事故
  • 哪些高优先级告警过于频繁，导致团队免疫

这类检查非常适合进入月度复盘或值班优化节奏里。

否则多通道系统很容易退化成：

  • 到处都在发消息
  • 但真正重要的还是没人第一时间拿住

16. 一个更可执行的多通道告警模板 ​

如果现在要给一个 AI 平台设计告警矩阵，建议至少写清下面这些字段：

16.1 告警标识 ​

  • alert name
  • alert type
  • severity

16.2 影响与阈值 ​

  • 影响对象
  • 触发阈值
  • SLO / baseline 来源

16.3 通道路由 ​

  • 首通道
  • 升级通道
  • 备用通道

16.4 责任人与时限 ​

  • first responder
  • secondary owner
  • business / security escalation
  • acknowledge SLA

16.5 告警上下文 ​

  • trace link
  • dashboard link
  • runbook link
  • representative samples

16.6 处理与回流 ​

  • first mitigation action
  • rollback option
  • postmortem required or not
  • eval backfill required or not

17. 常见反模式 ​

  • 所有问题都发到一个群
  • 观察类、处理类、紧急类不分
  • 升级路径全靠人工记忆
  • 只有发送，没有确认和回执
  • 高优先级告警没有备用通道
  • 告警不带 trace、版本和回放入口
  • 通道设计不对齐组织值班结构

18. 推荐搭配阅读 ​

19. 重点官方资料 ​

以下入口在 2026-07-08 复查时可访问：

20. 落地检查清单 ​

  • 是否已经定义观察类、处理类、紧急类三层告警
  • 是否按质量、成本、安全、稳定性继续细分告警类型
  • 是否为不同角色设计了不同触达视图，而不是一条消息塞给所有人
  • 是否定义了首通道、升级通道和备用通道
  • 是否要求高优先级告警有确认回执和自动升级时限
  • 是否在告警中携带 trace、版本、回放入口和 runbook
  • 是否让告警处理能衔接止血、回滚、复盘和 eval 回流
  • 是否定期治理噪音告警、漏告警和无效通道