4.2 基于 SLO 的告警：让告警从噪音变成 actionable

4.2 基于 SLO 的告警：让告警从噪音变成 actionable

我接手过一个团队的告警治理，第一周打开他们的告警历史，过去一个月收到了 3000 多条告警，平均每天 100 条。结果呢？值班工程师把告警群静音了——因为 99% 是误报或无关紧要的，真故障来时反而错过了。这是典型的"告警疲劳"，根因是告警策略设计得糟糕。这一节讲如何用"错误预算告警"替代传统的"阈值告警"，让每一条告警都是可行动的、值得叫醒人的。

为什么传统阈值告警会变成噪音

传统告警长这样：TTFT 大于 1 秒就告警。看起来合理，但实际跑起来全是问题。

阈值难定是第一个难题。定低了频繁误报（正常高峰也会短暂超 1 秒），定高了真故障漏报。没有一个阈值能同时满足"不误报"和"不漏报"，因为系统的正常波动和故障之间没有清晰边界。

不看持续时间是第二个问题。一次 GC 暂停或网络毛刺导致 TTFT 瞬间飙到 2 秒，立刻触发告警——但这种瞬时毛刺是正常的，根本不需要人介入。传统阈值告警不分"瞬时毛刺"和"持续故障"，把所有超阈值都当事故，自然噪音满天飞。

不分严重度是第三个问题。所有告警一个级别，值班人面对海量告警会麻木——反正都是"重要"，等于都不重要。真正需要立即处理的 P0 故障，被淹没在"磁盘用了 80%"这种低优先级告警里。

结果是告警疲劳：值班人把告警群静音，真故障来时反而错过。这是一个恶性循环——告警越多越不准，越不准越被忽略，越被忽略越要发更多告警试图引起注意。

错误预算告警：面向 SLO 的正确姿势

1.2 节讲过错误预算：错误预算 = (1 − SLO) × 总请求量。基于错误预算的告警，逻辑不是"某个指标超阈值就告警"，而是"错误预算的消耗速率异常才告警"。这从根本上改变了告警的语义——从"指标波动"变成"SLO 受威胁"。

错误预算告警分两类。消耗速率告警（快）是看错误预算在短时间内的消耗速度，比如"1 小时内消耗了全天预算的 20%"，提示"正在快速失血"，用于快速响应突发故障。预算耗尽告警（慢）是看错误预算在长周期内的消耗趋势，比如"按当前速率，本月预算将在 3 天后耗尽"，提示"按这个趋势 SLO 守不住"，用于规划性介入。

这两类告警覆盖了不同的时间尺度。快告警应对突发的、需要立即介入的故障；慢告警应对慢性的、需要规划调整的趋势。它们都比"阈值告警"更贴近"是否真的需要人介入"这个本质问题。

告警分级与路由

每条告警必须明确两件事：严重度和响应动作。没有这两个要素的告警不该存在。

我推荐的分级体系是 P0 到 P2。P0 是核心服务不可用，响应是立即电话叫醒值班，通知方式是电话加 IM。P1 是 SLO 受严重威胁，值班立即处理，IM 艾特值班。P2 是趋势异常需关注，工作时间处理，IM 群通知。

这里有一条铁律：如果一条告警没有明确的响应动作（比如"看看就好"），它就不该存在——删掉它。每条告警都应该能回答"收到后我该做什么"，否则就是噪音。这条铁律推行的初期会很痛苦（团队会不舍得删"万一有用"的告警），但坚持几周后，告警质量会质变。

告警规则的实用范式

给一个生产级 TTFT SLO 告警规则的示例（伪 promql），说明错误预算告警怎么写。核心逻辑是统计 1 小时内 TTFT 违反 SLO 的请求占比，超过正常速率的 2 倍就告警。

几个要点：用 rate 加时间窗口而非瞬时值，过滤掉瞬时毛刺，因为毛刺不需要人介入。按 service 聚合，定位到具体服务，而不是笼统的"系统慢"。阈值与 SLO 挂钩，而不是拍脑袋——告警的本质是"SLO 受威胁"，阈值自然要从 SLO 推导。

写告警规则时还要注意"告警内容本身的可读性"。一条告警触发后，值班看到的应该包括：是什么问题（TTFT 违反 SLO）、影响多大（违反率多少、影响多少用户）、发生在哪（哪个服务）、该怎么处理（链接到对应的 runbook）。把这些信息塞进告警通知里，值班收到后能立刻行动，而不是还要花时间排查"告警是什么意思"。

告警的"可Runbook化"

告警的价值在于被响应，而高质量的响应依赖 runbook（操作手册）。每个告警都应该有一份对应的 runbook，写清楚：这个告警意味着什么、第一时间该做什么止血、怎么进一步排查根因、历史上这个告警的常见原因有哪些。

runbook 让新值班人员也能有效响应——不需要"经验丰富的老员工"才能处理故障，照着 runbook 走就能完成基础的止血和排查。每次故障后，把新的经验补充进 runbook，让它越来越完善。runbook 是团队故障响应能力的沉淀，比任何个人的经验都可靠。

我强烈建议团队推行"无 runbook 不告警"——新增任何告警，都必须同时写好它的 runbook。强制这个纪律，能倒逼团队思考"这条告警到底有没有可执行的响应"，从而自然地过滤掉那些"看起来有用但实际无法响应"的噪音告警。

告警之后：值班响应流程

告警只是起点，配套的值班响应流程才是闭环。一个成熟的响应流程包括四步。确认（Ack），收到告警立即 Ack，避免重复通知。定位，用 4.1 节的三层看板下钻到根因。止血，先恢复服务（降级、扩容、回滚），再深究根因——故障时刻，先保可用比查清楚原因更重要。复盘，事后写 incident report，把告警规则、看板、runbook 的改进固化为常态能力。

这四步里，止血优先于根因是新手最容易犯的错。很多工程师故障时第一反应是"查清楚为什么"，结果花了 20 分钟排查，期间服务一直不可用。正确做法是先用最快的方式恢复服务（哪怕是降级、重启这种"治标不治本"的手段），服务稳定后再慢慢查根因。

这一节与第四章的收尾

用错误预算告警替代裸阈值告警，告别告警疲劳——这是告警策略的根本转变。每条告警必须有严重度和明确响应动作，否则删掉，并强制"无 runbook 不告警"。告警只是起点，配套的值班响应流程（确认、定位、止血、复盘）才是闭环。

至此第四章完成。下一章做全书的方法论收拢与未来展望。