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），在和客户的互动中实现着产品服务的业务价值。
文档 - 以网页或者纸张的形式向用户描述了某个应用服务所提供的服务内容和质量信息。向用户提供这个文档并不是强制、显性和必须的。
SLI
Service Level Indicator 服务水平指示器，服务水平，简称SLI。对于业务来说是最重要的指标。比如，对于网站来说，一个常见的SLI是请求得到正常响应的百分比。
SLO
Service Level Object 服务水平目标，是围绕SLI构建的目标。通常是一个百分比，并与一个时间范围挂钩。比如，月度、季度、年度等。通常用一连串9来度量。如果脱离了时间的度量，SLO的意义就不大了。
90%（1个9的正常运行时间）：这意味着10%的停机时间，也就是说在过去的30天里停机了3天。
99%（2个9的正常运行时间）：意味着在过去30天中有1%，或者说7.2小时的停机时间。
99.9%（3个9的正常运行时间）：意味着0.1%，或者说43.2分钟的停机时间。
99.95%（3.5个9的正常运行时间）：意味着0.05%，或者说21.6分钟的停机时间。
99.99%（4个9的正常运行时间）：意味着0.01%，或者说4.32分钟的停机时间。
99.999%（5个9的正常运行时间）：意味着0.001%，或者说26秒的停机时间。
SLA
Service Level Agreement 服务水平协议，是企业围绕SLO发布的协议。它要求在不满足SLO时向客户补偿的协议。
实例
假如我有一个网站http://eample.com，我对这个网站的监控指标是请求正常响应数，从2021年1月1号上线到今天2021年3月18号，请求数据如下：
1月，总请求数500，错误响应20；
2月，总请求数600，错误响应10；并因为故障宕机10分钟；
3月1号-3月18号，总请求数400，错误响应15；
那么我计算出来的SLI、SLO，SLA是多少呢？
SLI：1 -（20+10+15）/ (500+600+400) = 97%
SLO：1 - ( 10 / 79天 * 24 * 60 ）= 99.991%
SLO：假如我们是给第三方做的网站，并签订了协议SLO达不到99.999%，就赔偿多少钱，那么根据我上面的这个SLO，再根据签订的SLA协议，算出补偿的金额。