第 13 章：从错误比例到可以行动的告警

13.1 先选择用户可感知的完成条件

本实验的入口 SLI 把业务请求分成可接受与失败两类。202 表示请求已经接受并完成示例中的发布流程；它不表示异步订单处理成功。我们可以为入口定义可用性目标，但若真正的用户承诺涉及处理完成时间，还必须增加异步 SLI。

以 99% 请求可用性为计算示例，允许的错误比例是 1%。若短窗口实际错误比例为 5%，消耗率就是允许水平的 5 倍，称为 burn rate 5。这个比值解释了为什么同样的错误率，在不同目标下意味着不同紧迫程度。

本书并不据此宣称一个几分钟实验能够证明月度 SLO。实验窗口只验证规则的计算、最小流量条件、pending 与 firing 状态，生产窗口和阈值需要依据用户目标、流量形态与响应能力另行确定。

13.2 一条可执行的演示规则

Prometheus 规则文件使用一分钟 rate 窗口，错误比例超过 5%，同时窗口内请求增量不少于 5，持续两秒后进入 firing。最小请求量条件避免一次低流量错误立刻触发百分比告警；两秒是为了缩短教学验收，不是推荐的值班阈值。

验收先提交正常请求，再逐步注入五次应用失败，最后查询 /api/v1/alerts。原始返回保存在 alerts.json，可以检查 alertname、state、activeAt 与当时的计算值。应用失败分支返回 503 并设置 span ERROR，关联日志保留请求上下文；这样告警与具体执行之间有可核查的路径。

规则只说明条件满足。没有配置 Alertmanager、值班路由、静默、去重或通知发送，因此不能把 firing 截图写成“告警已经通知到人”。在真实交付中，通知链与运行手册必须另外验收。

13.3 告警为什么还需要恢复与反例

单看触发测试会忽略另一半生命周期。若规则直接对累计错误计数大于零告警，那么一旦出现过错误，系统再健康也不会恢复。使用 rate 或 increase 才能让观察窗口随时间滑动；重启导致的计数重置也需要正确处理。

短窗口对突发敏感，长窗口对持续退化更稳定。多窗口 burn-rate 规则尝试同时限制短期噪声与长期风险，但增加了团队解释和维护成本。引入它之前，应当能说明每个窗口希望捕捉的用户损害，以及维护者多久能够行动。

实验只自动检查 firing，没有为了等待一分钟窗口完全过期而把恢复状态算作已验证。读者可以增加恢复阶段：停止注入错误，持续提交正常流量，等待规则回到非 firing，并保存查询返回。只有实际执行后，才能把这项写进验证记录。

练习。 将目标从 99% 改为 99.9%，相同 5% 错误比例对应多少倍预算消耗？再解释为什么一条 202 入口 SLO 无法保证异步任务一分钟内完成。

SLO 告警设计可参考 Google SRE Workbook：Alerting on SLOs，查询行为以 Prometheus HTTP API为准。