SRE 之旅——开始 SLO 实施（第 2 部分——SLO 和错误预算）
https://successive.cloud/sre-fundamentals-sla-slo-sli/
先决条件：
SRE 之旅——开始 SLO 实施（第 1 部分——从 SLI 开始）
在我们了解 SLI 规范、SLI 实现、时间窗口和计算 SLI 的通用公式之后 第1部分 ，是时候建立你的 SLO 了。
A. 仅
SLO 基本规则
在我们开始构建我们的 SLO 之前，如果您想运行您的 SLO 文化，应该遵循一些规则。
- 相信 100% SLO 是错误的目标。
- 负责确保服务满足其 SLO 的人员已经同意，它是 正常情况下可以达到这个SLO .
- 该组织已承诺 使用错误预算进行决策和优先排序 .这一承诺在错误预算政策中正式化。
- 有一个流程 细化 SLO .
从 SLI 创建 SLO Starter
为了让您更好地了解从 SLI 生成 SLO，让我们以我们在 1 个月时间窗口内提取的示例为例
- 请求总数：4,789,101
- 成功请求总数（返回 200 或 201 状态码）：4,567,891
- 第 90 个百分位延迟：432 毫秒
- 第 99 个百分位延迟：891 毫秒
我们可以从该示例创建的 SLI 很少
- 潜伏
- 请求成功
您可以直接生成延迟 SLI，因为指标已显示百分位指标。但是，成功请求怎么样？
还记得我们计算 SLI 的通用公式吗？
好事件/总事件
所以在这种情况下，我们的成功请求 SLI 是
4,567,891 / 4,789,101 * 100% = 95.38 %
然后我们得到几个 SLI
成功请求 = 95.38 %
延迟 < 318ms = 90%
延迟 < 779ms = 99%
基于 谷歌 SRE 工作簿 获得我们的起始 SLO 我们可以将这些 SLI 舍入到可管理的数字
- 向下舍入可用性数，直到它达到非十进制数
- 将 SLI 向上舍入为 50 毫秒乘数（50 毫秒、100 毫秒、150 毫秒、…nx 50 毫秒）
所以对于我们的起始 SLO，它将是这样的
成功请求 = 95%
延迟 < 350ms = 90%
延迟 < 800 毫秒 = 99%
然后默认情况下，我们现有的系统没有违反我们的 SLO。
B. 错误预算
定义
在 SLO 上下文中，错误被定义为未增加您的意外行为 好的事件指标 定义。
回到我们的示例，我们可以定义 SLO 上的错误含义
success：请求成功（返回 200 或 201 状态码）
错误：不安全的请求（返回除 200 或 201 之外的所有代码）成功：延迟 < 350ms
错误：延迟≥350ms或超时成功：延迟 < 800ms
错误：延迟≥800ms或超时
根据定义， 错误预算是在特定服务或系统上应允许的错误数量 .
还记得我们的 SLO 定义是特定情况下的 SLI 目标吗？您可以从其定义中扩展错误预算。
如果 SLO 是您应该实现的 SLI 目标，则错误预算是允许发生的最大错误数，以便您的 SLI 保持在目标范围内。
我们可以这样写数学术语
错误预算 = 1 - SLO
如何计算它
回到我们的 SLO 示例，我们有 SLO
成功请求 = 95%
延迟 < 350ms = 90%
延迟 < 800 毫秒 = 99%
然后我们有错误预算
根据我们上面的数学方程，我们可以像这样将每个错误预算都放在百分位
成功请求 = 1-95% = 5%
延迟 < 350ms = 1-90% = 10%
延迟 < 800ms = 1-99% = 1%
然后我们可以计算误差预算
成功请求 = 5% * _4,789,101 = ~ 239,456
_ 延迟 < 350 毫秒 = 10% * _4,789,101 = 478,910.1
_ 延迟 < 800ms = 1% * 4,789,101 = 47,891.01
所以这些是我们每个 SLO 在 1 个月内允许的错误数量
错误成本
错误成本基本上可以定义为某种错误类型或事件的错误预算消费者组。因此，为了计算错误成本，您的监控系统应该检索与您的错误预算相关的错误指标。
这个概念将帮助您和您的团队确定应优先考虑哪些错误的优先级。
例如，记住我们成功请求的错误预算是 ** 239,456** ？，让我们说 在某些情况下，所有预算都被错误消耗了 在这些细节中
状态 500 = 150,000 = 62.64 %
状态 499 = 70,000 = 29.23 %
状态 502 = 19,456 = 8.12 %
如果您根据日志标准再次对这些错误进行分类，那就更好了，这样您和您的团队将直接知道应该优先处理的错误的根本原因是什么，但是您需要更全面的设计监控系统来获得这一点，将进行讨论关于另一个话题 .
错误预算政策
错误预算政策是 如果错误预算已消耗接近限制、达到限制或什至超过限制，应采取的操作列表 .
这个政策应该有 详细、清晰和可操作的项目 .该策略通常需要组织内的升级路径。
C. 文件
SLO 文档
基于 Google SRE Workbook，有一些特征可以定义一个好的 SLO 文档，它们是
- SLO 的作者、审阅者（检查其技术准确性）和批准者（就其是否是正确的 SLO 做出业务决策）。
- 批准的日期，以及下一次审查的日期。
- 为读者提供上下文的服务的简要描述。
- SLO 的详细信息：目标和 SLI 实施。
- 如何计算和使用错误预算的详细信息。
- 数字背后的基本原理，以及它们是否来自实验或观察数据。即使 SLO 完全是临时的，也应该记录这一事实，以便将来阅读该文档的工程师不会根据临时数据做出错误的决定。
你可以参考 SLO 示例 .
错误预算政策文档
你的错误预算政策应该有这些标准
- 策略作者、审阅者和批准者
- 批准的日期，以及下一次审查的日期
- 为读者提供上下文的服务的简要描述
- 应对预算枯竭采取的行动
- 如果在计算上存在分歧或商定的行动在具体情况下是否合适，则应遵循明确的升级路径
- 根据受众的错误预算经验和专业知识水平，包含错误预算的概述可能是有益的。
D. 有效性和改进
衡量有效性
最后，在您拥有 SLO 之后，计算错误预算，创建错误预算策略，然后记录所有这些，是时候衡量您构建的内容了。
您可以开始在中断事件（您可以从工单、运营团队或直接从指标中检索它）和发生中断时的 SLI 指标之间创建关联。如果您的 SLI 与您的中断事件不同，您可能应该更改 SLI 实施流程。
这种相关性评分可以由 Spearman 相关性 中断票和消耗的错误预算数量之间的关系。
This is an example from Google SRE Workbook ( https://sre.google/workbook/implementing-slos/ — Improve your SLO Quality)
始终精益求精
如果您的 SLO 文化进展顺利，并且所有利益相关者也都习惯了，那么您可以将 SLO 文化提炼和改进到另一个领域。
- 用户体验 SLO
您可以为您的用户体验制作 SLO，这取决于您的业务流程，例如，如果您是一家电子商务公司，您可以为其创建 SLO
- 搜索引擎数据检索的持续时间
- 交易成功 - 存储桶层 SLO
您可以创建 SLO，然后按层对其进行分组，例如在可用性 SLO
高级等级 = 99 %
标准层 = 90 % - 依赖建模
如果您的系统与许多工具或外部系统集成，这将很有用。您还可以计算与外部或依赖 SLO 相关的系统的 SLO，但此主题将在不同的文章中介绍。
结束语
所以现在，您已经完成了实现自己的 SLO，是时候构建自己的 SLO了 有效的警报和事件响应 .但这些主题将在另一个系列中。
这些 SLO 和错误预算概念将帮助您监控当前系统，并在发生某些事情时加快恢复时间。
谢谢！
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/38024/07212011
标签：之旅,错误,SRE,毫秒,SLO,SLI,预算,延迟 From： https://www.cnblogs.com/amboke/p/16710356.html