在线服务的目标应该是提供与业务需求匹配的可用服务。此流程的关键部分应该涉及组织中的不同团队，例如，从业务开发团队到工程团队。

要验证一个服务如何符合这些目标，可以用这些目标可衡量的“成就”来定义“阈值”，例如，“服务必须在 99.9% 的时间内可用”，这应该与用户的期望和业务连续性相匹配。

SLA, SLO, SLI

已经有很多关于这些话题的文章，如果你不熟悉这些术语，我强烈建议你先阅读谷歌关于 SLO(服务级别目标) 的 SRE 书籍中的文章。

总而言之：

• SLA：服务水平协议

  • 你承诺向用户提供的服务，如果你无法满足，可能会受到惩罚。

  • 例如：“99.5%”的可用性。

  • 关键词：合同

• SLO：服务水平目标

  • 你在内部设置的目标，驱动你的测量阈值 (例如，仪表板和警报)。通常，它应该比 SLA 更严格。

  • 示例：“99.9%”可用性 (所谓的“三个 9”)。

  • 关键字：阈值

• SLI：服务水平指标

  • 你实际测量的是什么，以确定你的 SLO 是否在满足目标 / 偏离目标。

  • 示例：错误率、延迟。

  • 关键词：指标。

SLO 关注时间

99% 的可用性意味着什么？它不是 1% 的错误率 (失败的 http 响应的百分比)，而是在一个预定义的时间段内可用服务的时间百分比。

在上面的仪表板中，服务在 1 小时内的错误率超过 0.1% (y 轴为 0.001)(错误峰值顶部的红色小水平段)，从而在 7 天内提供 99.4% 的可用性：
这一结果中的一个关键因素是你选择度量可用性的时间跨度 (在上面的示例中为 7 天)。较短的周期通常用作工程团队 (例如 SRE 和 SWE) 的检查点，以跟踪服务的运行情况，而较长的周期通常用于组织 / 更广泛的团队的评审目的。

例如，如果你设置了 99.9% 的 SLO，那么服务可以停机的总时间如下:

• 30 天：43 分钟 (3/4 小时)

• 90 天：129 分钟 (~2 小时)

另一个无关紧要的“数字事实”是，给 SLO 多加一个 9 都会产生明显的指数级影响。以下是 1 年的时间跨度的时间组成部分:

• 2 个 9: 99%: 5250min (87hrs 或 3.64 天)

• 3 个 9: 99.9%: 525min (8.7hrs)

• 4 个 9: 99.99%: 52.5min

• 5 个 9：99.999%：5min< - 经验法则：5 个 9 -> 5 分钟 (每年)

输入错误预算

在服务可以停机的允许时间内，上面的数字可能被认为是错误预算，你可以从以下事件中消耗这些错误预算: