9.2.5 SLO 与告警工程：让指标站岗（SLO & Alerting）

9.2 的前四节解决了"度量"：指标有了口径（9.2.1），数据有了采集链路（9.2.2），聚合有了方法（9.2.3），体验有了优化策略（9.2.4）。但监控体系建好之后还有一个朴素的问题：谁来盯？靠运维同学二十四小时盯着大盘，盯得住三天，盯不住三年。本节的主角，就是让指标自动站岗的那套机制。

这套机制来自 Google 的 SRE 体系，核心概念分三级 [6]：SLI（Service Level Indicator，服务水平指标） 是度量本身，比如"成功起播的会话占比"；SLO（Service Level Objective，服务水平目标） 是给 SLI 定的内部目标，比如"30 天滚动窗口内达到 99.9%"；SLA（Service Level Agreement，服务水平协议） 则是写进合同、违约要赔的那一档，通常比内部 SLO 宽松，留出缓冲。流媒体场景里，9.2.1 的四脉指标都可以各自立起 SLI：起播成功率、卡顿会话占比、端到端延迟达标率。

错误预算：把可靠性变成可花的钱

SLO 最有生产力的推论是 错误预算（Error Budget）。99.9% 的 SLO 意味着允许 0.1% 的失败，换算成 30 天窗口，就是：

$30 \times 24 \times 60 \times 0.1\% = 43.2 \ \text{分钟}$

或者每十万个会话里允许 100 个出问题。这 43.2 分钟就是本月可以"合法出事"的额度。预算的意义在于它给了团队一把统一的尺子：预算充足时，新功能大胆上线；预算告急时，冻结发布、全员修可靠性。可靠性与迭代速度的永恒争吵，从此有了数字化的裁判。

燃烧率告警：不对阈值告警，对预算消耗速度告警

传统的阈值告警是"错误率超过 5% 就打电话"。它有两个顽疾：一次持续三天的 1% 慢漏会烧光整月预算，却从头到尾不触发告警；而一次两分钟的毛刺把电话打醒，其实只消耗了预算的零头。SRE 体系的对策是 燃烧率（Burn Rate），当前错误率与预算允许速率的比值。燃烧率等于 1，预算刚好撑满整个月；等于 14.4，两天就烧完。

工程上落地的是多窗口、多燃烧率的组合告警 [6]：

长短两个窗口必须同时超阈才触发：长窗口负责压制毛刺带来的误报，短窗口负责确认"事情仍在发生"，恢复后也能快速复位。这套设计背后还有一条总原则：对症状告警，不对原因告警。CPU 跑到 80% 不需要半夜打电话，用户卡顿率上升才需要；告警的每一次响起都该对应一次真实的用户受损，否则告警疲劳会淹没整个体系，真正的事故反而被静音。另外低流量场景要加护栏，稀疏数据下比率抖动剧烈，需要最小事件数门槛兜底。

流媒体的特化切片

告警落到流媒体，维度切片是关键动作。全网卡顿率上升 0.5%，可能是某省某运营商的骨干故障，也可能是某家 CDN 的区域熄灯（呼应 9.1.6 的切换信号），还可能只是某场千万级赛事把容量顶到了边界。因此 SLI 的计算要按地区、运营商、CDN 厂商、码率档位分别开窗，告警阈值也应随场景分级，日常时段与赛事时段本就不该用同一条线。9.2.4 讲过的那些弱网优化策略，效果如何验收？答案也在本节：上线前后，对应切片的 SLO 曲线说了算。

至此，9.2 的五块拼图齐了：口径、采集、聚合、优化、站岗。理论体系既成，该让它见血了。9.3 我们亲手搭建一条真实直播链路，用 9.1 的地图规划架构，用 9.2 的体系度量质量，practice_10，链路搭建与质量分析。