2.1 KiB
2.1 KiB
给你的 SLO 增加"9"的现实
- 期号: SRE Weekly Issue #432（2024-07-07）
- 作者: Thomas Stringer
- 链接: https://trstringer.com/slo-adding-nines/
简介
关于再多拿一个"9"的可靠性所涉及的数学问题，简明扼要的拆解。
归根结底，创建 SLO 和相应的要求是为了让用户满意，仅此而已。不必要的可靠性代价高昂。
正文
很多时候，人们都有一个错误的假设：给 SLO 增加"9"是线性的，无论是收益还是相关成本。不幸的是，这种想法会给那些负责构建和维护方案的工程师带来大量不必要的负担。
我非常喜欢看数据、算数学。
30 天 SLO 窗口内的停机时间
| Uptime | Nines | Downtime (minutes) |
|---|---|---|
| 99% | 2 | 432 |
| 99.9% | 3 | 43 |
| 99.99% | 4 | 4 |
| 99.999% | 5 | 0.4 |
| 99.9999% | 6 | 0.04 |
从 2 个 9 提升到 3 个 9，我们获得了将近 400 分钟正常运行时间的巨大收益。这相当于一个月里接近六个半小时的正常运行时间，只差一点点就是一个完整的工作日。我得说，这在正常运行时间和可靠性上是一次相当大的飞跃！
但从 4 个 9 提升到 5 个 9，只带来大约 3 分钟的正常运行时间收益。你的用户会在意吗？他们会注意到吗？当你开始攀登"9 的阶梯"时，把收益可视化会很有帮助：
对许多业务利益相关者来说，这可能不是他们原本想象的样子。和正常运行时间的收益一样，增加的成本和复杂度也远远不是线性的：
当你开始增加"9"时，尤其是超出 3 个 9 之后，成本和复杂度会急剧上升。一个月内停机时间少于 5 分钟，需要高水平的冗余、分布和自动化。你再也不能指望靠值班工程师响应并缓解来达成这个 SLO。
归根结底，创建 SLO 和相应的要求是为了让用户满意，仅此而已。不必要的可靠性代价高昂。