Featured image of post SLA、SLO 和 SLI 还是傻傻分不清么?

SLA、SLO 和 SLI 还是傻傻分不清么?

SLA、SLI 和 SLO 是 SRE 工程实践里非常核心的概念,但是大家在同时提到这些概念的时候,经常容易混淆。

SLA、SLI 和 SLO 是 SRE 工程实践里非常核心的概念,但是大家在同时提到这些概念的时候,经常容易混淆。

长篇大论的文章反而容易使人更加疑惑,还不如画一张示意图说明一下,帮助大家一次性彻底梳理清楚这些不可以含糊不清的核心概念。说明一下,下图假设所讨论的 SLA 个数为 1,使用了软件工程中 ER 图的表达方式,但也有所变化。

SLA、SLO、SLI

一图讲清 SLA、SLO、SLI

本文不讲 why,只是帮助大家梳理清楚这些概念在以上人机系统中的相互关系。虽然不想做名词解释。但是为了方便起见,整理一个术语清单。

  • SLA = Service Level Agreement = 服务质量/水平协议
  • SLO = Service Level Objective = 服务质量/水平目标
  • SLI = Services Level Indicator = 服务质量/水平指标

下面用人、事、物的逻辑进行阐释。

人和事

用从上到下,从左到右的顺序。

客户 - 每 1 个客户在使用产品服务时,都显性或隐性的基于某 1 个 SLA,SLA 和客户之间是一种 1 对 1 的文档关系,这份协议文档就显性或者隐性的存在于系统中。客户使用 1 种,或者 n 种连接方式访问产品服务的 1 个或者 n 个应用系统。

销售 - SLA 本身是所销售产品服务的一部分,它规定了承诺给客户的产品功用和质量。基于 SLA,客户可以选择用付费或者免费的方式使用产品。1 个/份 SLA 的销售工作可以由 1 到 n 位销售完成。销售和客户都幻想着几乎完美的 SLA,这样代表企业利益的销售,以及产品的客户就都可以达到双赢的局面,皆大欢喜。

产品 - 通过与销售的间接互动,或者直接的客户调研,产品经理能够确定应用系统所应该具有的功能和发展方向。

SRE - SRE 和产品共同制定了每个 SLA 相关应用系统的 SLO,SLO 定量的定义了每 1 个应用系统所应该具备的服务质量,1 个应用系统的 SLO 被该产品服务的 SLO 文档定义,在该文档中 SLO 被映射到 1 个或者 n 个 SLI,每个 SLI 都需要用监控工具持续采集数据,通常它们的数值单位各不相同。所有 SLO 都是用百分比数值形式表达的,例如:99.99% 的成功率,90% 的请求延迟 < 400 毫秒等。SRE 和产品经理/专家还应该共同关注运行应用系统的基础设施层,确保基础设施的可用性和容量足以满足目标数量的用户访问,而且还要考虑和设计底层资源的容灾和跨区多活等复杂场景。

开发/运维 - 重要但暂不做讨论。

用从下往上的顺序。

IaaS 云服务 - 也可以是其它类型的可以供应用系统运行的环境。这里存在着 1 到 n 种子服务。它和上层的 n 个应用系统通常是 n 对 n 的关系。

应用系统 - 1 个到 n 个应用系统构成了 1 个产品服务(内含SLA),在和客户的互动中实现着产品服务的业务价值。

文档 - 以网页或者纸张的形式向用户描述了某个应用服务所提供的服务内容和质量信息。向用户提供这个文档并不是强制、显性和必须的。

结束

请根据以上解释,结合你的实际工作场景,想象并描绘一下 SLA 、SLO 和 SLI 在你周围的人事物中关系网。在SRE 的工作实践中,定义 SLO,并梳理 SLI,将量化以后的目标和说明文档化,并让各个干系人认同并签署,是一项基础的起步工作。

本文参考了 Google 出品的两本SRE 书籍,这两本书的英文版在 Google 的官网可以免费在线阅读。SRE Workbook 的简体中文版会在2020 年中出版。

署名-非商业性使用-禁止演绎 4.0 (CC BY-NC-ND 4.0)
comments powered by Disqus
本博客始于 2007 年
Built with Hugo
主题 StackJimmy 设计