算出预算并试一试告警
目标
“可用性 99.9%”很容易写进合同，但它一个月到底允许多少分钟的故障，却很少有人知道。而且大多数告警与 SLO 毫无关系。
本实验要亲手算出这些数字，用这些数字重写告警，并测试这条告警是否真的会触发。
开始
cp -r /opt/lab/slo/* .
python3 budget.py 99.9
promtool check rules rules.yml
promtool test rules test.yml
文件
| 文件 | 作用 |
|---|---|
budget.py |
计算错误预算和 burn rate。不要修改 |
rules.yml |
告警规则。在这里修改 |
test.yml |
规则的单元测试。这里也要修改 |
时间序列写法
test.yml 中的 0+90x20 表示从 0 开始，每分钟增加 90，共增加 20 次。也就是每分钟 90 条请求。
步骤
- 错误预算 →
01-budget.txt - burn rate →
02-burn.md - 现有告警的问题 →
03-why-bad.md - 用 burn rate 重写 →
rules.yml - 测试告警是否触发 →
test.yml - 也测试它是否保持安静 →
test.yml - 两个窗口 →
07-window.md - 总结 →
08-notes.md
参考
第 4、5、6 步由评分器直接运行 promtool 来确认。
99.9% 相当于一个月多少分钟
针对 99.9，99.95，99.99 三种取值，分别计算一个月的错误预算，并将结果保存到 01-budget.txt。
写法类似 python3 budget.py 99.9。
目的不是背下这些数字，而是建立对数量级的感觉。99.9% 和 99.99% 在写法上只差一位，允许的停机时间却相差十倍。
在把 99.99% 写进合同之前，必须先知道它一个月允许多少分钟。
按现在的速度，预算何时耗尽
针对 burn rate 1，6，14.4，分别计算预算何时耗尽，并写入 02-burn.md，同时说明 14.4 这个数字是怎么来的。
python3 budget.py 99.9 --burn 14.4。
burn rate 指的是错误率是允许值的多少倍。1 倍正好在一个月内把预算用完（符合设计）。
14.4 是这样得出的——它是在 1 小时内烧掉一个月预算的 2% 的速度。0.02 × 30일 × 24시간 = 14.4。达到这个速度，就意味着现在必须叫醒值班的人。
现有告警为什么没用
阅读 rules.yml 中的现有规则，在 03-why-bad.md 中写出它为什么与 SLO 无关。分别举出一个本该安静却触发的例子，和一个本该触发却保持安静的例子。
现有规则是“5 分钟错误率超过 1%”。它与 SLO（允许 0.1%）毫无关系。
想一想——如果 0.5% 的错误率持续整整一个月会怎样？（预算超支了 5 倍，却保持安静）反过来，如果凌晨错误率突然跳到 1.2% 并持续 5 分钟呢？（预算几乎没有减少，却把人叫醒）
告警疲劳不是因为告警太多，而是因为没用的告警太多。
用 burn rate 重写
修改 rules.yml，把它改成基于 burn rate 的告警。promtool check rules rules.yml 必须通过。
阈值为 14.4 × (1 - SLO)。如果 SLO 是 99.9%，则为 14.4 * 0.001。
expr: |
(sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)
告警名称也要一并修改——现在它表达的不再是“错误率很高”，而是“预算正在被快速消耗”。名称决定了应对方式。
测试告警是否真的会触发
修改 test.yml，让 promtool test rules test.yml 通过。必须与新的告警名称和注释保持一致。
这是本实验中最有价值的一步。很少有人给告警规则写单元测试，所以真正发生故障时不触发的告警并不少见。
input_series 中的 0+90x20 表示每分钟增加 90，共增加 20 次。把错误数设为 0+10x20 时，错误率是 10%，无论以什么标准都会触发。
评分器会直接运行 promtool test rules。
同时测试不该触发时是否保持安静
在 test.yml 中再加入一个告警不应触发的用例，即预算之内的正常运行状态。
用 exp_alerts: [] 来表达“不应出现任何告警”。
把错误率设为 0.05% 左右（例如 0+1x20 对 0+2000x20）就处于 SLO 之内。
只测试该触发时会触发，只完成了一半。还要测试该安静时保持安静，才能避免告警疲劳。
快窗口与慢窗口
在 07-window.md 中写出只用一个窗口（window）为什么不够，并提出使用两个窗口的方案。
只用短窗口（5 分钟）时，稍有波动就会被叫醒。只用长窗口（1 小时）时，对快速燃烧会发现得太晚。
所以通常用 and 把两者连接起来——只有短窗口和长窗口都超过阈值时才触发。这样既能过滤掉瞬时的波动，又能尽早发现真正的预算消耗。
再区分严重程度——快速消耗（14.4 倍）立即呼叫，慢速消耗（6 倍以下）转为工单。
总结
在 08-notes.md 中写至少三行：burn rate 是什么，为什么要测试告警规则，以及预算耗尽后团队约定要做什么。
正文中必须包含 번 레이트，시험，예산（韩文，依次意为“burn rate”“测试”“预算”）。最后一项最难——如果预算耗尽后没有约定好如何应对，SLO 就只是摆设。