服务质量术语

很多读者可能都对SLA这个概念非常熟悉，但SLI与SLO则可能需要一个详细定义。因为在常见的使用环境中，SLA经常被赋予了过多的意义，Google则更倾向于利用不同的词语描述其中不同的涵义，以便更加清晰地进行讨论。

指标

SLI是指服务质量指标（indicator）—该服务的某项服务质量的一个具体量化指标。

大部分服务都将请求延迟—处理请求所消耗的时间—作为一个关键SLI。其他常见的SLI包括错误率（请求处理失败的百分比）、系统吞吐量（每秒请求数量）等。这些度量通常是汇总过的：在某一个度量时间范围内将原始数据收集起来，计算速率、平均值、百分比等汇总数据。

理想情况下，SLI应该直接度量某一个具体的服务质量。但是很多时候，直接度量信息可能非常难以获取，或者无法观测，我们只能用某种指标来替代。例如，客户端的延迟数据经常是最直接的用户指标，但是由于条件限制可能只能监控服务器端的延迟数据。

可用性（availability）是另外一个SRE重视的SLI，代表服务可用时间的百分比。该指标通常利用“格式正确的请求处理成功的比例”来定义，有时也称为服务产出（yield）。对数据存储系统来说，持久性（durability）—数据能够完整保存的时间—也是一个重要指标。虽然100%的“可用性”是不可能实现的，但是接近100%的可用性指标是可以实现的一个目标。运维行业经常用9的数量来描述可用程度。例如，99%可用性被称为“2个9”,99.999%被称为“5个9”。目前Google 云计算服务公开的可用性指标是“3.5个9”— 99.95% 可用。

目标

SLO是服务质量目标（Objective）：服务的某个SLI的目标值，或者目标范围。SLO的定义是SLI≤目标值，或者范围下限≤SLI≤范围上限。例如，对莎士比亚服务来说，返回结果的速度应该是很“快”的，那么我们可以定义一个SLO，要求搜索请求的平均延迟小于100ms。

选择一个合适的SLO是非常复杂的过程。第一个困难点是很有可能无法确定一个具体的值。例如对外部传入的HTTP请求来说，每秒查询数量（QPS）指标是由用户决定的，我们并不能针对这个指标设置一个SLO。

但是，我们可以做的是指定平均请求延迟小于100ms，确立这个目标可以鼓励开发者优化前端服务降低延迟，或者采购某种延迟更低的硬件。（100ms在这里只是一个随意选择的值，但是一般来说速度快要比速度慢更好，因为用户可见的延迟超过一定数量后会使得参与程度下降。详情参见“Speed Matter”，文献[Bru09]中有详细介绍）。

而且，可能不那么直观的是，这两个SLI—QPS和延迟—很可能是相关的：QPS升高通常会导致延迟升高，服务到达一定负载水平后性能下降是很常见的。

SLO的选择和公布可以帮助设立用户对服务质量的预期。该策略可以应对那些没有根据的抱怨—“服务太慢了”。如果没有一个明确的SLO，用户经常会按照自己的理解设置一个服务性能的预期，即使这可能跟运维人员或者设计者所想的完全不同。这种问题可能会导致对某个服务的过度依赖—用户错误地认为这个服务会比实际情况更可靠（例如Chubby的例子，参见下面的“全球Chubby服务计划内停机”。另外一种情况是会导致信心不足—用户会认为系统比实际情况更脆弱和不可靠，从而不会去使用它。

全球Chubby服务计划内停机

作者：Marc Alvidrez

Chubby是Google的一个分布式锁服务，用于松散耦合的分布式系统。在全球Chubby服务中，我们将Chubby实例的副本分布在不同的地理区域。随着时间的推移，我们发现，全球实例出现问题经常会导致其他服务出现故障，其中很多故障都会影响到外部用户。但是，由于真正的全球Chubby服务故障出现的频率太低，以至于其他服务负责人开始认为全球Chubby服务永远不会出故障，从而不停地将更多的服务依赖于此。Chubby全球服务的高可靠性实际上提供了一种安全假象，因为这些服务实际上在Chubby全球服务不可用的时候不能正常工作，不管这种情况是多么罕见。

我们在这里采用了一个很有趣的解决办法：SRE保证全球Chubby服务能够达到预定义的SLO，但是同时也会确保服务质量不会大幅超出该SLO。每个季度，如果真实故障没有将可用性指标降低到SLO之下，SRE会有意安排一次可控的故障，将服务停机。利用这种方法，我们可以很快找出那些对Chubby全球服务的不合理依赖，强迫服务的负责人尽早面对这类分布式系统的天生缺陷。

协议

最后，SLA是服务质量协议（Agreement）：指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。这些后果可以是财务方面的—退款或者罚款—也可能是其他类型的。区别SLO和SLA的一个简单方法是问“如果SLO没有达到时，有什么后果？”如果没有定义明确的后果，那么我们就肯定是在讨论一个SLO，而不是SLA。[3]

SRE通常不会参与SLA的书写，因为SLA是与业务产品的决策紧密相关的。但是，SRE确实会参与帮助避免触发SLA中的惩罚性条款。同时，SRE会参与制定具体的SLI：很明显，提供一个客观的方式来度量SLO是很重要的，否则大家就会产生分歧。

Google搜索服务是没有公开SLA的一个典型服务：我们当然希望所有人都能够最方便、最快地使用Google的搜索服务，但是我们并没有与全世界签订合同。但是，即使如此，如果搜索服务不可用依然有后果产生—对Google形象有损害，同时也会使得广告业务收入下降。很多其他的Google服务，例如Google for Work，具有明确的用户SLA。不管某个服务是否具有SLA，定义SLI与SLO，并且用它们来管理服务质量都是很有价值的。

理论说了这么多，终于可以开始讲一些实践经验了。