FYIRH 发表于 2020-12-3 16:04:46

如何定义服务质量的目标SLO

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

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

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

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

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

全球 Ch y 服务计划内停机
作者∶ Marc Alvidrez

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

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