Google Cloud 架构框架：可靠性部分中的本文档详细介绍了有关 SLO 的提醒。
引入 SLO 等新可观测性系统的错误方法是使用该系统完全替换旧系统。相反，您应该将 SLO 视为一个补充系统。例如，我们建议您不要删除现有的提醒，而是将它们与这里介绍的 SLO 提醒并行运行。这种方法允许您发现哪些就有提醒是可预测的 SLO 提醒，哪些提醒与您的 SLO 提醒并行触发，以及哪些提醒永远不会触发。
SRE 的一个原则是根据症状而不是原因来提醒。SLO 本质上是对症状的测量。在用 SLO 提醒时，您可能会发现症状提醒与其他提醒一起触发。如果您发现旧有的基于原因的提醒触发时没有 SLO 或症状，则不妨完全关闭这些提醒、将它们转换为工单提醒或登录以供以后参考。
如需了解详情，请参阅 SRE 手册，第 5 章。
SLO 消耗率
SLO 的消耗率衡量的是故障向用户暴露错误和消耗错误预算的速度。通过测量消耗率，您可以确定服务违反其 SLO 的时间。基于 SLO 消耗率的提醒是一种很有价值的方法。请记住，您的 SLO 基于时长，而后者可能会很长（数周甚至数月）。但是，目标是快速检测在违规实际发生之前，导致 SLO 违规的条件。
下表显示了在给定的时间间隔内，如果 100% 的请求都失败（假设每秒查询数 (QPS) 是恒定的），则超过目标所需的时间。例如，如果您在 30 天内测量了 99.9% 的SLO，那么您可以在这 30 天内承受 43.2 分钟的完全停机时间。例如，所有停机时间可能会一次性发生，也可以分散到多个事件。
| 目标 | 90 天 | 30 天 | 7 天 | 1 天 |
|---|---|---|---|---|
| 90% | 9 天 | 3 天 | 16.8 小时 | 2.4 小时 |
| 99% | 21.6 小时 | 7.2 小时 | 1.7 小时 | 14.4 分钟 |
| 99.9% | 2.2 小时 | 43.2 分钟 | 10.1 分钟 | 1.4 分钟 |
| 99.99% | 13 分钟 | 4.3 分钟 | 1 分钟 | 8.6 秒 |
| 99.999% | 1.3 分钟 | 25.9 秒 | 6 秒 | 0.9 秒 |
在实践中，如果您想获得较高的成功率，就不能承受任何 100% 中断的突发事件。但是，许多分布式系统可以部分失败或平缓降级。即使在这种情况下，您仍想知道是否需要人工介入（即使发生的是部分故障也是如此），而 SLO 提醒为您提供了确定这一点的方法。
何时提醒
一个重要问题是，何时根据 SLO 消耗率采取行动。通常情况下，如果将在 24 小时内耗尽错误预算，那么“现在”就是找人解决问题的时候了。
衡量故障率并不总是简单的。一系列小错误可能在当时看起来很可怕，但结果是短暂的，并且对 SLO 产生的影响无关紧要。同样，如果系统长时间轻微损坏，这些错误会累积为 SLO 违规。
理想情况下，您的团队会对这些信号做出反应，以便您在给定时间段内用完几乎所有的错误预算（而不是超出）。如果用得太多，则表示您违反了 SLO。如果用得太少，则承担的风险不够，或者让待命团队疲于应付。
您需要一种方法来确定系统何时崩溃到需要人工干预的程度。以下部分讨论了解决这个问题的一些方法。
快速消耗
SLO 消耗的一种类型是“快速 SLO 消耗”，因为它会快速消耗您的错误预算，并且需要您干预以避免 SLO 违规。
假设您的服务以每秒 1000 个查询 (QPS) 的速度正常运行，并且希望在一周七天的时间内保持 99% 的可用性。您的错误预算约为 600 万个允许错误（总请求数为 6 亿个）。例如，如果在错误预算耗尽之前还有 24 小时，则每秒的错误数限制为 70 个，或者是一小时内 252,000 个错误。这些参数基于一般规则：可呼叫事件至少占季度错误预算的 1%。
您可以选择在这一个小时过去之前检测这个错误率。例如，在观察 15 分钟每秒 70 个错误的速率后，您可能会决定呼叫待命工程师，如下图所示。
理想情况下，这个问题在您用掉 24 小时预算中的一个小时之前就解决了。选择较短的时段（例如，一分钟）来检测此速率可能太容易出错。如果检测目标时间短于 15 分钟，则可以调整此数字。
慢速消耗
另一种消耗率是“慢速消耗”。假设您引入了一个错误，在第 5 天或第 6 天消耗掉了周错误预算，或者在第 2 周消耗掉了月预算？最佳应对方法是什么？
在这种情况下，您可能会引入一个“慢速 SLO 消耗”提醒，让您知道在提醒时段结束之前，您将消耗掉整个错误预算。当然，该提醒可能会返回很多误报。例如，可能经常存在这样一种情况，即错误发生的时间很短，但速度很快就会消耗掉您的错误预算。在这些情况下，该条件是误报，因为它只持续很短的时间，不会长期威胁您的错误预算。请记住，目标不是消除所有的错误来源；而是要“保持在可接受的范围内，不超出您的错误预算”。对于不会对错误预算构成合理威胁的事件，您希望避免提醒人工干预。
对于慢速消耗事件，我们建议您通知一个工单队列（而不是呼叫或发送电子邮件）。慢速消耗事件不是紧急事件，但是在预算到期之前需要人工干预。这些提醒不应以电子邮件的形式发送给团队列表，否则很快会被忽略。工单应该可跟踪、可分配和可转移。团队应该针对工单负载、完结率、可操作性和重复项创建报告。过多的、无法操作的工单是手动操作的好例子。
熟练地使用 SLO 提醒需要时间，并取决于团队的文化和期望值。记住，您可以随着时间的推移对 SLO 提醒进行微调。根据需要，您还可以有多种提醒方法和不同的提醒时段。
延迟提醒
除了可用性提醒之外，您还可以设置延迟提醒。借助延迟时间 SLO，您可以测量未达到延迟时间目标的请求的百分比。通过使用此模型，您可以使用与用于检测错误预算是快速还是慢速消耗的相同提醒模型。
正如前面提到的延迟时间中位数 SLO，有一半的请求可以不符合 SLO。换句话说，在您检测到对长期错误预算的影响之前，您的用户会面临数天的延迟。相反，服务应定义“尾延迟时间目标”和“典型延迟时间”目标。我们建议使用历史第 90 百分位数来定义典型延迟时间，并使用第 99 百分位数定义尾延迟时间。设置这些目标后，您可以根据希望计入每个延迟时间类别的请求数量，以及速度太慢的数量，来定义 SLO。此方法的概念与错误预算相同，应同等对待。因此，您可能会得到这样的结论：“90% 的请求将在典型延迟时间内处理，99.9% 的请求将在尾延迟时间目标范围内处理”。这些目标可确保大多数用户体验到您的典型延迟时间，并且仍允许您跟踪有多少请求比您的尾延迟时间目标慢。
一些服务可能有高度不同的预期运行时。例如，在数据存储区中读写数据可能会有显著不同的性能预期。您可以引入运行时性能存储桶，而不是枚举所有可能的期望，如下表所示。这种方法假定这些类型的请求是可识别的，并预先分类到各个存储桶中。不要期望动态地对请求进行分类。
| 面向用户的网站 | |
|---|---|
| 存储桶 | 预期最大运行时 |
| 读取 | 1 秒 |
| 写入/更新 | 3 秒 |
| 数据处理系统 | |
|---|---|
| 存储桶 | 预期最大运行时 |
| 小 | 10 秒 |
| 中 | 1 分钟 |
| 大 | 5 分钟 |
| 巨大 | 1 小时 |
| 特大 | 8 小时 |
通过测量当前的系统，您可以了解这些请求通常需要多长时间才能运行。以处理视频上传的系统为例。如果视频很长，处理时间应该会更长。我们可以使用视频长度（以秒为单位）来将这个工作分类到一个存储桶中，如下表所示。该表记录了一周内每个存储桶的请求数以及不同的运行时分布百分比。
| 视频时长 | 一周内测量的请求数 | 10% | 90% | 99.95% |
|---|---|---|---|---|
| 小 | 0 | - | - | - |
| 中 | 190 万 | 864 毫秒 | 17 秒 | 86 秒 |
| 大 | 2500 万 | 1.8 秒 | 52 秒 | 9.6 分钟 |
| 巨大 | 430 万 | 2 秒 | 43 秒 | 23.8 分钟 |
| 特大 | 81000 | 36 秒 | 1.2 分钟 | 41 分钟 |
从这样的分析，您可以得出提醒的几个参数：
- fast_typical：最多有 10% 的请求比这个时间快。如果有太多请求的速度超过了这个时间，则您的目标可能是错误的，或者您的系统可能发生了变化。
- slow_typical：至少 90% 的请求都比这个时间快。这个限制得出您的主延迟 SLO。这个参数指示大多数请求是否足够快。
- slow_tail：最少 99.95% 的请求比这个时间快。此限制可确保不会有太多慢速请求。
- deadline：用户 RPC 或后台处理超时并失败的点（通常已经硬编码到系统中的限制）。这些请求实际上不会很慢，但实际上会失败并报错，然后计入可用性 SLO。
定义存储桶的一项准则是将存储桶的 fast_typical、slow_typical 和 slow_tail 放在一个数量级内。这条准则可确保存储桶的宽度不会太大。我们建议您不要尝试防止存储桶之间的重叠或间隙。
| 存储桶 | fast_typical | slow_typical | slow_tail | deadline |
|---|---|---|---|---|
| 小 | 100 毫秒 | 1 秒 | 10 秒 | 30 秒 |
| 中 | 600 毫秒 | 6 秒 | 60 秒（1 分钟） | 300 秒 |
| 大 | 3 秒 | 30 秒 | 300 秒（5 分钟） | 10 分钟 |
| 巨大 | 30 秒 | 6 分钟 | 60 分钟（1 小时） | 3 小时 |
| 特大 | 5 分钟 | 50 分钟 | 500 分钟（8 小时） | 12 小时 |
这会产生类似于 api.method: SMALL => [1s, 10s] 的规则。在这种情况下，SLO 跟踪系统将看到一个请求，确定其存储桶（可能通过分析其方法名称或 URI，并将名称与对照表进行比较），然后根据该请求的运行时更新统计信息。如果这个过程花了 700 毫秒，则在 slow_typical 目标范围内。如果花了 3 秒，则在 slow_tail 范围内。如果是 22 秒，则超出 slow_tail，但仍不是错误。
在用户满意度方面，您可以将缺少尾延迟时间视为等同于不可用。（即响应速度很慢，应被视为失败）。因此，我们建议您使用与可用性相同的百分比，例如：
典型延迟时间由您自己决定。Google 的一些团队认为 90% 是不错的目标。这与您的分析以及您为 slow_typical 选择时长的方式相关。例如：
建议的提醒
根据这些准则，下表包含一组 SLO 提醒基准。
| SLO | 测量时段 | 消耗率 | 操作 |
|---|---|---|---|
|
可用性，快速消耗 典型延迟时间 尾延迟时间 |
1 小时时段 | 不到 24 小时会违反 SLO | 呼叫某人 |
|
可用性，慢速消耗 典型延迟时间，慢速消耗 尾延迟时间，慢速消耗 |
7 天时段 | 超过 24 小时才会违反 SLO | 创建工单 |
SLO 提醒是需要时间来培养的技能。本部分中的时长是建议时长；您可以根据自身需求和精确程度来调整这些值。将提醒与测量时段或错误预算支出进行绑定可能会有所帮助，或者您可以在快速消耗和慢速消耗之间添加另一层提醒。