SLO及SLI的基本定义
确保应用程序可用性的很大部分是在建立和监控服务级别指标(service-level metrics)上,service-level在商业级别上主要指的是SLA,而在SRE的规划和事件中会使用SLO和SLI,这里的A,O,I指的是Objective,Agreement以及indicator。
SLO
SLO指的是每个服务的用户可接受的最低可靠性级别,通过这项数据,团队就可以决定是要将服务变得更加可靠,还是降低其可靠性进行一个原则性的判断,因为越可靠往往意味着运营成本越高,这就是SLO对于开发团队的作用。
SLA
而SLA相对于SLO来说,通常涉及到对服务用户的承诺,即服务可用性SLO应该在特定的时期达到一个特定的级别,之前有说过SLA是商业级别的,那么达不到对用户的承诺的话,必然也会导致某种惩罚,一般都是经济性的。通常是向客户收费的服务涉及到SLA,在whosbug中SLA应该是用不太上的。
SLI
SLI就是一个对于服务行为的直接衡量了,定义为系统成功探测的频率,当我们去评估过去一周内我们的系统是否在SLO内运行时,会查看SLI来得到服务可用性的百分比,如果低于定义的SLO,那说明系统有问题,需要去提升系统的可用性了。whosbug中的需要关注的则是SLI与SLO。
通俗一点来讲,SLI指的是服务等级指标,即QPS,响应时间等,而SLO是对SLI中指标设立的目标,即QPS要达到99.99%,响应时间应该为10ms等。
SLI及SLO的具体设计
那么理解了概念之后,常见的指标又有很多,系统层面包括了CPU的使用率,内存的使用率,磁盘使用率,在应用服务器层面包括了端口的存活状态,而应用运行的层面也包括状态码,时延等等。我们的选择主要遵循两个原则:
选择能够标识一个主体是否稳定的目标,如果不是主体本身的指标,或是不能标识主题稳定性的就需要排除在外。
选择些用户可以感知到的指标,比如whosbug中传入数据库或是get责任人的状态码返回可以作为指标。
也就是说选择指标基本上是给两个群体去看的,一个是运维,一个是客户,前者是为了了解整个系统的运转状态,后者则是使用体验。
标准化一点可以套用《谷歌SRE工作手册》的方法:VALET,即Volume、Availability、Latency、Error和Ticket。这五个单词就是谷歌推荐我们选择的五个指标。
Volume
Volume指的是容量,也就是常来衡量吞吐量的QPS和TPS等等。
Availability
Availability即可用性,他不是一个直接得到的概念,与之相关的定义有MTBF(Mean Time Between Failure)和MTTR(Mean Time To Repair),平均故障间隔和平均恢复时间,前者越长即系统正常运转的平均时间越长,那么代表系统的稳定性越高;后者是对事故处理的时间,此值越小代表了故障对于用户的影响越小,Availability的计算为:
Availability = MTBF / (MTBF + MTTR) ,计算结果是一个百分数来作为SLO的值。
Latency
Latency即延迟,这个反应的就是响应是否够快,如果是一个任务类的作业,我们会看每个任务是否在规定的时间完成了。通常对于时延这个指标,我们不会直接做所有请求时延的平均,因为整个时延的分布也符合正态分布,所以通常会以类似“90% 请求的时延 <= 80ms,或者 95% 请求的时延 <=120ms ”这样的方式来设定时延 SLO,数理统计中,这个 90% 或 95% 称之为置信区间。这样选择的原因也是因为不排除很多请求从业务逻辑层面是不成功的,这时业务逻辑的处理时长就会非常短(可能 10ms),或者出现 404 这样的状态码(可能就 1ms)。从可用性来讲,这些请求也算成功,但是这样的请求会拉低整个均值。
Latency的延迟选择应该就是类似“90% 请求的时延 <= 80ms,或者 95% 请求的时延 <=120ms ”这样的方式来设定SLO。
Error
Error就是我们最常见的错误,最能想到的就是状态码,比如在whosbug中将责任人信息传给服务器,报错了,亦或者是在get责任人的时候报错了,不光是4xx还是5xx都可以列进来,也可以去自定义一些状态码,比如创建一个用户的时候老报错什么的,也可以作为衡量的标准。我们可以用 正常的返回状态/总的返回状态 得到一个Error的SLO。
Tickets
Tickets是故障单,如果说一项任务需要去人工介入的话,类似于数据无法恢复,超时了,这些都需要人工介入,中断任务或者重新跑等等。对于Tickets的SLO就像是一个人工介入的门票一样,比如说我给SLO设置为10,那就说明我这个月每人工介入那就消耗一张Ticket,如果这十张消耗完了,那还要人工介入,那么这个月系统就不达标了。所以Ticket的SLO通常是一个整数值。
可以通过使用Prometheus和Grafana实现对各个指标的监控,我们得到这五种指标的SLO之后不一定需要得到一个唯一的SLO的值,可以看到有的是整数值,有的是百分数值,有的还是个在区间中定义的,只需要将每个指标都列出来即可。
MTBF与MTTR
下面补充下Availability中用到两个量的定义。
MTBF(Mean Time Between Failure)
这个指标指的是平均的故障时间间隔,比方说对于whosbug的webservice而言,使用者每天运行使用十小时,但是在某天的使用期间出现了两次故障,第一次故障服务器挂掉了一个小时,第二次挂了俩小时,那么总共挂了仨小时,出现故障的总次数为2,MTBF的计算为(10-7)/2 。类似的这个量也可以用错误率来表示,错误率就是MTBF的倒数。
MTTR(Mean Time To Repair)
这个指标指的是平均修复所用的时间,根据MTBF中的例子,修复时间总共为3小时,故障次数为2,那么MTTR即为3/2h。