SLI、SLO和SLA
SLI(Services Level Indicator)服务水平指示器
Service Level Indicator 服务水平指示器,简称SLI,是反映服务质量/水平的指标(对内产品服务质量评价指标),对于业务来说是最重要的指标。比如,对于网站来说,一个常见的SLI是请求得到正常响应的百分比。常见的测量指标:
1、性能
-
响应时间(latency)
-
吞吐量(throughput)
-
请求量(qps)
-
实效性(freshness)
2、可用性
-
运行时间(uptime)
-
故障时间/频率
-
可靠性
3、质量
-
准确性(accuracy)
-
正确性(correctness)
-
完整性(completeness)
-
覆盖率(coverage)
-
相关性(relevance)
4、内部指标
-
队列长度(queue length)
-
内存占用(RAM usage)
SLO(Service Level Objective) 服务水平目标
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秒的停机时间。
服务提供者用它来指定系统的预期状态;开发人员编写代码来实现;客户依赖于SLO进行商业判断。
SLO是用SLI来描述的,比如以下SLO:
-
每分钟平均qps > 100k/s
-
99% 访问延迟 < 500ms
-
99% 每分钟带宽 > 200MB/s
设置SLO时的几个最佳实践:
-
指定计算的时间窗口
-
使用一致的时间窗口(XX小时滚动窗口、季度滚动窗口)
-
要有一个免责条款,比如:95%的时间要能够达到SLO
如果Service是第一次设置SLO,可以遵循以下原则
-
测量系统当前状态,设置预期(expectations),而不是保证(guarantees)
-
初期的SLO不适合作为服务质量的强化工具
-
改进SLO,设置更低的响应时间、更改的吞吐量等
-
保持一定的安全缓冲,内部用的SLO要高于对外宣称的SLO
-
不要超额完成,定期的downtime来使SLO不超额完成
设置SLO时的目标依赖于系统的不同状态(conditions),根据不同状态设置不同的SLO:总SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …
SLO的好处:
对于客户而言,是可预期的服务质量,可以简化客户端的系统设计
对于服务提供者而言
-
可预期的服务质量
-
更好地取舍成本/收益
-
更好地风险控制(当资源受限的时候)
-
故障时更快地反应,采取正确措施
SLO设好了,怎么保证能够达到目标呢?需要一个控制系统来:
-
监控/测量SLIs
-
对比检测到的SLIs值是否达到目标
-
如果需要,修证目标或者修正系统以满足目标需要
-
实施目标的修改或者系统的修改
该控制系统需要重复的执行以上动作,以形成一个标准的反馈环路,不断的衡量和改进SLO/服务本身。
我们讨论了目标以及目标是怎么测量的,还讨论了控制机制来达到设置的目标,但是如果因为某些原因,设置的目标达不到该怎么办呢?也许是因为大量的新增负载;也许是因为底层依赖不能达到标称的SLO而影响上次服务的SLO。这就需要SLA出场了。
SLA(Service Level Agreement )服务水平协议
Service Level Agreement 服务水平协议,服务质量/水平协议(对外承诺),是企业围绕SLO发布的协议。它要求在不满足SLO时向客户补偿的协议。
SLA是一个涉及两方的合约,双方必须都要同意并遵守这个合约。当需要对外提供服务时,SLA是非常重要的一个服务质量信号,需要产品和法务部门的同时介入。
SLA用一个简单的公式来描述就是: SLA = SLO + 后果
SLO不能满足的一系列动作,可以是部分不能达到
比如:达到响应时间SLO+未达到可用性SLO
对动作的具体实施
需要一个通用的货币来奖励/惩罚,比如:钱
SLA是一个很好的工具,可以用来帮助合理配置资源。一个有明确SLA的服务最理想的运行状态是:增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。
一个简单的例子就是某服务可用性从99.9%提高到99.99%所需要的资源和带来的收益之比,是决定该服务是否应该提供4个9的重要依据。
实例
假如有一个网站https://163.com,我对这个网站的监控指标是请求正常响应数,从2021年1月1号上线到2021年3月20号,请求数据如下:
1月,总请求数500,错误响应20;
2月,总请求数600,错误响应10;并因为故障宕机10分钟;
3月1号-3月20号,总请求数400,错误响应15;
那么计算出来的SLI、SLO,SLA是多少呢?
SLI:1 -(20+10+15)/ (500+600+400) = 97%
SLO:1 - ( 10 / 79天 * 24 * 60 )= 99.991%
SLO:假如是给第三方做的网站,并签订了SLA:“若SLO达不到99.999%,根据相关指标确定补偿金额”,那么根据上面的这个SLO和签订的SLA,可以算出补偿的金额。