对SLA的个人理解

2023-09-01 创建

2023-09-01 更新

4分钟阅读时长

前言

前段时间，有个朋友问了我这样一个问题：

“请教一个问题，假设有一个系统，可用性是99.99%，那么全年宕机时长差不多是5min，假设我现在要调用它，失败了就重试，是不是说重试的时间超过了5min，就意味着我可以保证对他的调用是永远成功的，可以这么说么，我感觉怪怪的”

这个问题乍一看好像很初级，明显陷入了对SLA的理解误区，包括提问者本人也感觉怪怪的，但一时之间却也说不出哪里有问题。

相信大家都曾经遇到类似的情况：对某些知识点看似理解了，但是换一种问法立马又懵逼了。典型问题如：“我们都说TCP协议是可靠的，那么TCP能保障消息100%送达吗？”（PS：这里不展开，读者可以自己尝试回答一下~）

再长远来看，往往在这种时候，我们如果能够多一份好奇心，多花一点精力，去探索这背后的原理，也许你就能够成为那个掌握钥匙的人。

SLA通常会与另外两个概念SLI和SLO一同被提及，那么它们的区别是什么呢？实际上，这三个概念是一个递进关系：

SLI，全称是Service Level Indicators，服务等级指标：它定义了服务的核心指标，如性能、可用性等等。
SLO，全称是Service Level Objectives，服务等级目标：它基于SLI，指明SLI要达到什么标准，例如可用性不低于99.95%，最大时延不超过3s等等。
SLA，全称是Service Level Agreement，服务等级协议：它基于SLO，是服务提供商与客户之间定义的正式承诺，这份承诺会指出当SLO低于某个值，所要承担的责任，例如赔付标准。

让我们直接用一份真实的 阿里云ECS服务等级协议 来进一步理解SLA：

在上面这样一份协议中，我们能够看出SLA必须具备三大核心要素：

SLA本质上是一个商业化的概念，它由提供服务的服务商所定义，属于服务的 “产品质量保证书”。以可用性为例，针对SLA可能会产生两个常见的理解误区，让我们结合前言的问题来看。

我们再回头来看这句话：

“请教一个问题，假设有一个系统，可用性是99.99%，那么全年宕机时长差不多是5min”

相信大家已经看出来了，这句话混淆了SLA承诺的可用性和系统实际的可用性，导致了理解上的误区。SLA承诺可用性不等于系统实际可用性，承诺归承诺，实际是实际。系统实际运行过程中会发生的事情，谁也说不好。正确的做法是根据系统的监控指标，来观测系统实际的可用性。

我们再回头来看这句话：

“假设我现在要调用它，失败了就重试，是不是说重试的时间超过了5min，就意味着我可以保证对他的调用是永远成功的”

这句话陷入了另外一个理解误区：认为调用失败就是系统内部异常，但实际上这个说法是错误的。即使系统内部成功处理的请求，也同样可能会造成失败的情况。

举例来看：

如图所示：假设有个系统，上游1和上游2都去调用系统服务的接口。此时系统内部均成功处理，但是上游1返回时可能因为网络原因导致超时。此时对于系统本身来说，可用性仍然是100%，但是上游1和上游2感受到的结果却完全不同。

让我们来思考这样一个问题：

“假设你的系统，强依赖了MySQL数据库，而MySQL的可用性是99.95%。请问，你的系统可用性能超过99.95%吗？”

答案显然是否定的。因此，这也启发了我们一个基本逻辑：即系统的可用性并非是独立的，它的上限受所有底层依赖的可用性影响。

那么，如何去提升SLA上限呢？这里提供一个通用思路：将系统的强依赖转成半强依赖或者弱依赖！ 但如何做到降低强依赖的影响，可以有不同的方式：

方式一：非核心功能降级。这个方式也称为熔断降级，尤其是针对一个系统的非核心功能，很多博客或者书上会以电商双11举例：在海量并发的情况下，购物车模块和支付模块将是系统的核心功能，而个性化推荐则是系统的非核心功能，此时可以直接熔断个性化推荐，提升系统SLA。
方式二：多副本冗余存储。这个方式会可能会引入成本、性能和一致性的额外风险，但是系统就不再对单一的存储产生强依赖，从而提升SLA。