告警设计与值班运行
本节目标
将运行信号转化为少而可操作的告警，并为每个告警定义用户影响、紧迫性、所有者、runbook、抑制、恢复和审计流程。
告警不是异常检测器的全部输出
一个好的实时呼叫（page）应满足：
- 有正在发生或即将发生的用户/业务影响；
- 人现在可以采取行动；
- 等到工作时间会显著放大损失；
- 有明确的所有者和起始runbook。
不满足实时响应条件的容量趋势、质量缓慢下降或成本优化机会，可以建立工单或定期审查，不应在凌晨叫醒人。
优先为症状告警
症状告警回答“用户正受什么影响”，根因信号帮助诊断“可能为什么”。例如：
- 叫醒人：交互请求错误预算正高速燃烧；
- 诊断面板：模型供应商限流、某工具超时、队列饱和。
如果顶层用户延迟仍正常，一个内部组件短暂慢通常不需要同时叫醒另一组人。但非用户可见但后果严重的数据泄露、安全越权或费用失控，仍可需要紧急告警；这些应有独立风险策略。
一条告警的完整契约
| 字段 | 应回答什么 |
|---|---|
| 名称与意义 | 发生的用户症状是什么？ |
| 严重级别 | 何时响应，应否叫醒人？ |
| 条件与持续时间 | 如何抑制短暂抖动？口径版本是什么？ |
| 范围 | 哪个环境、release、任务或切片受影响？ |
| 所有者 | 谁应第一响应，如何升级？ |
| runbook | 前5分钟查什么，可安全做什么？ |
| Dashboard/Trace | 哪个视图和示例Trace可下钻？ |
| 抑制/聚合 | 哪些下游告警应被根事件抑制？ |
| 恢复条件 | 何时结束，是否需人工核对？ |
| 验证 | 规则如何测试，通知链路如何演练？ |
告警消息应包含当前观察、目标/预算、窗口、影响范围和直接链接，而不是“指标异常，请处理”。
消抖、聚合、抑制与静默
- 持续时间/消抖：信号持续足够久才触发，避免短尖峰；严重安全事件可能不适合等待。
- 聚合：将同一事件的多个实例合并，保留范围信息。
- 抑制：当已知根事件触发时，暂不通知预期的下游症状。
- 静默：在受控维护时窗禁止通知；必须有范围、原因、所有者和过期时间。
不要通过永久扩大静默范围“解决噪声”。噪声告警应被修复、降级为工单或删除，不能把值班人员训练成忽略告警。
若使用Prometheus Alertmanager，应区分其当前产品语义：grouping把相关告警合成通知，routing按label与接收策略分发，deduplication避免重复通知，inhibition在某告警存在时抑制匹配的其他告警，silence按匹配器和时段屏蔽通知。这些词有助于设计，但具体配置字段、默认行为和版本支持必须按部署版本核对，不能把本节当可直接粘贴的配置。
AI系统特有的告警取舍
- 质量标签延迟时，用快速代理信号做早期警告，但明确其不是真值；
- 低流量高风险任务不能只用总体比率，可对高损失单事件直接升级；
- 漂移本身一般先产生调查或工单，不应无条件触发再训练/发布；
- 费用告警同时看总额、单任务、重试/循环和质量，防止“通过停止服务降低费用”被当成优化。
监控系统也要被监控
通知链路、采集器、查询后端和规则评估器可以故障。建立端到端合成心跳、采集新鲜度、丢弃计数和通知演练。只监控每个组件进程存活，可能漏掉“所有组件都活着，告警却到不了人”。
练习与自测
为一个在线RAG Agent写三条告警：快速错误预算燃烧、高风险越权工具调用、单成功任务成本突增。每条补齐契约表的字段。回答：
- 为什么内部模型延迟上升但用户SLI正常时不一定要page？
- 为什么漂移告警不应直接连接“自动重训练并上线”？
- 你如何证明告警从规则评估到值班人员的链路真的可用？
小结与下一步
告警是一个需要版本化、测试和运营的人机接口。下一步用 Dashboard 与诊断视图 给值班人员一条从症状到证据的路径。
参考资料
- Prometheus Alerting practices（访问于2026-07-14；症状导向、可操作性与监控自监控）
- Prometheus Alertmanager（访问于2026-07-14；分组、路由、去重、抑制与静默）
- Prometheus Alerting overview（访问于2026-07-14；具体配置语法和版本能力需按部署版本核对）
- Google SRE: Monitoring Distributed Systems（访问于2026-07-14）