SLO与告警体系：燃尽策略

可视化演示

动态展示告警从原始源头经去重/聚合/分级/抑制四阶段降噪管线到达输出的过程，切换策略观察各阶段告警削减效果与信噪比变化。

燃尽策略概述

想象你是奶茶店店长，每月有 100 杯“试错赠饮额度”——只要因为做错口味、超时出杯送出的赠饮不超过这个数，总部就认为你服务达标。但你很快发现：最可怕的不是月底超支，而是月初 5 天就送掉了 80 杯。 这时你必须立刻调整配方、加派人手；如果月末还剩 50 杯，员工偶尔手抖也无需兴师动众。燃尽策略的核心，就是把“还剩多少”和“烧得多快”两件事结合起来做决策。

在 AI 系统可观测性中，告警系统如果只盯着“当前错误率是否超过 5%”，就像店长只看“今天送了几杯”——完全忽略了预算消耗的速度。一个 5% 的错误率放在月初可能无伤大雅，放在预算快见底的月末就是灾难。燃尽策略的洞察是：告警的紧急程度应由“剩余错误预算”和“消耗速度”共同决定，而非一个静态的百分比红线。

这套逻辑落地到工程上，就是围绕错误预算建立“燃尽率”指标。当燃尽率超过某个阈值，说明按当前速度，预算会在窗口结束前耗尽——此时立即触发高等级告警，让工程师火速介入。它解决了传统告警两大痛点：一是告警噪音太多导致“狼来了”效应，二是真正致命的缓慢劣化反而无人察觉。燃尽策略让告警系统像一位精明的账房先生，只在最危险的时刻敲响警钟。

SLO与错误预算

SLO（Service Level Objective，服务等级目标） 是团队对外承诺的服务质量指标，比如“系统每月 99.9% 的请求延迟低于 500ms”。这个数字不是拍脑袋定的，而是产品需求与技术成本之间的平衡。设定 SLO 的同时，我们其实悄悄定义了一笔 错误预算（Error Budget） ：

有了预算，就有了“记账”的依据。系统每发生一次错误请求，就从错误预算中扣除一笔；每天结束后，剩余预算 = 初始预算 − 已消耗预算。如果剩余预算长期保持充裕，说明服务质量健康；如果它像盛夏的冰块一样迅速融化，那就要警惕了。

这里的关键在于“预算”这个词的双重含义。在财务上，预算告诉你还能花多少钱；在 SRE 中，错误预算是你还能犯多少错的许可证。燃尽策略正是围绕这笔“犯错本金”设计的——它不关心你犯了什么错，只关心本金以什么速度消失。

燃尽率的计算

现在，我们要量化“烧钱速度”。燃尽率（Burn Rate）的定义是：在给定时间窗口内，错误预算被消耗的比例。用公式表示，就是窗口内已消耗预算占窗口期理论总预算的比例：

燃尽率的精妙之处在于，它是一个无量纲的倍数，天然适应不同规模的服务。无论你的错误预算是 0.1% 还是 1%，燃尽率 4 都意味着“预算会提前 4 倍速度耗尽”。这让团队可以用统一的阈值（如 1、2、4、8）来分级告警，而不必逐服务调参。

但燃尽率有一个隐藏变量——时间窗口长度。同样是燃尽率 2，放在 5 分钟窗口里可能只是瞬时毛刺，放在 24 小时窗口里就是真实劣化。因此工程上往往同时计算多个窗口的燃尽率，这就是后文将提到的“多窗口策略”。

多级告警设计

有了燃尽率这把尺子，告警等级就清晰了。我们可以根据剩余错误预算和燃尽率，把告警划分为多个等级：低危、中危、高危。设计原则是：剩余预算越少、燃尽率越高，告警级别越高，响应的工程师级别也越高。

多级告警的实际效果是“收敛响应”——把不同紧急度的问题分流到不同级别的处理通道。低危告警可能只是一条手机推送，中危告警要求 30 分钟内响应，高危告警则启动紧急热线。这样的设计避免了全军覆没式的“全员 on-call”，也防止了重要告警被海量噪音淹没。

此处的关键洞察是：告警级别可以随剩余预算动态变化。同样是 5% 的错误率，月初可能只发低危通知，月末却会升级为高危——因为在预算不足时，任何一点消耗都可能是压垮骆驼的最后一根稻草。

动态阈值调优

静态阈值最大的问题在于“刻舟求剑”。假设你为推理服务的延迟设置了 500ms 的硬阈值，但业务低谷期平均延迟只有 80ms，高峰期却长期在 450ms 徘徊——一个 450ms 的延迟在低谷期是异常，在高峰期却是常态。动态阈值调优的核心思想是：让告警阈值跟随系统的“健康基线”自适应移动，而不是钉死在一个固定数字上。

在工程中，这通常通过滑动窗口的分位数统计实现。例如，动态基线 = 过去 7 天同时间段的 P95 延迟 × 1.2。当实时延迟超过这个动态上限时，才触发告警：

动态阈值与燃尽策略是一对黄金搭档。燃尽率负责回答“错误预算烧得快不快”，动态阈值负责回答“当前这个指标是否偏离了它应有的形态”。二者结合，告警系统既懂“绝对剩余量”，也懂“相对历史形态”，误报率与漏报率同时降低。

但动态阈值需要谨慎使用：如果基线本身在缓慢劣化（比如每天变慢 1%），动态阈值会“温水煮青蛙”式地跟着抬升，让系统在不知不觉中越过 SLO。因此成熟的团队会把动态阈值与燃尽率形成双校验——阈值触发只是候选告警，燃尽率确认后才真正拉响警报。

多窗口策略

多窗口策略是燃尽率体系中最精妙的工程实践。它的思路来自一个朴素的生活经验：“看一个人是否发烧，不能只看一分钟的体温，也不能只测一次。”短窗口对突发敏感，长窗口对趋势稳定，组合使用才能平衡。

多窗口的本质是在“灵敏度”与“准确率”之间做权衡。只用短窗口，一次瞬时的流量尖刺就会触发一堆告警，让值班工程师疲于奔命；只用长窗口，真正的突发故障可能要等 20 分钟才暴露，业务早已受损。组合策略让短窗口负责“快”，长窗口负责“稳”。

工程中常见的窗口组合有“1 分钟 / 5 分钟 / 30 分钟”或“5 分钟 / 1 小时 / 6 小时”，具体选择取决于系统指标的特性。例如，对数据库连接池这种快速恶化的资源，短窗口更敏感；对模型精度这类缓慢变化的指标，长窗口更有意义。关键原则是：绝不让单个窗口单独作出最终判决。

工程应用实践

让我们把燃尽策略放到真实的 AI 工程场景中。假设你在维护一个大语言模型推理服务，SLO 是“99.5% 的请求在 2 秒内返回”，错误预算是 0.5%。某次上线新版本后，模型推理的 P99 延迟从 800ms 涨到 1.8s——尚未超过 2 秒阈值，传统告警系统保持沉默，但错误预算正在以 3 倍燃尽率快速消耗。

此时燃尽策略的价值尽显：告警系统检测到 1 小时窗口燃尽率 = 3.2，连续 3 个周期持续走高，触发了中危告警。值班工程师收到通知后，通过已有监控面板定位到“新版本的 KV Cache 显存占用过高导致 GC 频繁”，立即回滚新版本。整个过程从预算开始异常消耗到告警触发，不到 15 分钟——而传统阈值告警可能要到 2 秒延迟击穿 SLO 数小时后才被发现。

在数据管线场景中，燃尽策略同样适用。比如一个 AI 训练数据流水线，SLO 是“每日数据产出延迟不超过 1 小时”。错误预算就是“每天允许的延迟分钟数”。当上游数据源偶发卡顿导致产出延迟时，燃尽率会快速飙升，告警系统能精准地把它归类为“需要立即处理”的高危事件，而不是等到业务方投诉“今天的数据怎么还没到位”。

最后，工程团队还应建立告警复盘机制：每次燃尽告警触发后，回顾“这次的燃尽率曲线是否准确预判了故障？阈值是否需要调整？”通过持续迭代，燃尽策略会越来越贴合系统的真实行为模式——这正是 AI 系统可观测性从“被动救火”走向“主动治理”的关键一步。

AI 应用场景

Python 演示

import randomfrom datetime import datetime, timedelta SLO = 0.999ERROR_BUDGET = 1 - SLOWINDOW_DAYS = 30daily_budget = ERROR_BUDGET / WINDOW_DAYS  def simulate_daily_errors(days: int, bad_day: int) -> list:    """模拟每日错误率: bad_day 当天爆发 5 倍错误"""    errors = []    for d in range(days):        if d == bad_day:            rate = daily_budget * 5        else:            rate = daily_budget * random.uniform(0.5, 1.2)        errors.append(rate)    return errors  def calc_burn_rate(errors: list, window: int) -> float:    """计算最近 window 天的燃尽率"""    recent = errors[-window:]    consumed = sum(recent)    standard = window * daily_budget    return consumed / standard if standard > 0 else 0  def check_alert(burn_rate: float, remaining: float) -> str:    """根据燃尽率与剩余预算确定告警等级"""    if burn_rate >= 2 and remaining < 0.3:        return "高危告警: 预算即将耗尽, 立即介入"    if burn_rate >= 1.5 or remaining < 0.5:        return "中危告警: 预算消耗偏快, 保持关注"    return "低危通知: 预算充足, 正常运行"  def main():    days = 30    bad_day = 15    errors = simulate_daily_errors(days, bad_day)    consumed = 0.0    window = 7     print(f"SLO={SLO:.3%}, 错误预算={ERROR_BUDGET:.3%}, 窗口={window}天")    print(f"{'日期':<12}{'日消耗':<10}{'燃尽率':<8}{'剩余预算':<10}{'告警状态'}")     for d in range(days):        consumed += errors[d]        remaining = ERROR_BUDGET - consumed        if d >= window - 1:            burn = calc_burn_rate(errors[: d + 1], window)        else:            burn = 0.0        level = check_alert(burn, remaining)        day_str = (datetime.now() + timedelta(days=d)).strftime("%m-%d")        print(f"{day_str:<12}{errors[d]:<10.4f}{burn:<8.2f}{remaining:<10.4f}{level}")  if __name__ == "__main__":    main()

1. SLO = 0.999设定服务质量目标，决定错误预算总额。
2. daily_budget = ERROR_BUDGET / WINDOW_DAYS把总预算平摊到每天，作为“标准消耗速度”的基准。
3. rate = daily_budget * 5模拟故障日错误率飙升至正常值的 5 倍。
4. standard = window * daily_budget计算窗口期内“应该消耗”的标准预算量。
5. return consumed / standard实际消耗除以标准消耗，得到燃尽率倍数。
6. if burn_rate >= 2 and remaining < 0.3双重条件同时满足时，才触发最高级别告警。

常见误区

面试题