4.1 确定SLI

Service Level Indicator 服务水平指示器,服务水平,简称SLI。对于业务来说是最重要的指标。比如,对于网站来说,一个常见的SLI是请求得到正常响应的百分比。没有SLI就不会有SLO,

我们通常是用2个数字的比率,合格事件数/事件总数,同时这个一定从客户角度来看的,而且要在一定时间窗口内。

那这个合格事件数要从哪些角度来看呢,我们一般选择如下几种方向:

  1. 响应时长
  2. 性能指标
  3. 错误数

这里的一定时间窗口内,这个就是表示我们多久时间范围来统计一次SLA,这个一般我们都是一个月一统计。但是有些非常核心的我们会放到半年,为什么需要这样呢,因为我们有些核心组件的改造是需要一些风险预算的。

下面这个是《Google SRE工作手册》里列的不同类型组件的潜在SLI

SLI类型服务类型描述
可用性请求驱动返回结果为成功的请求的比例
延迟请求驱动响应速度快于阈值的请求的比例
质量请求驱动在系统超载或者后端服务不可用时,服务会被优雅的降级,在这个降级状态下,你需要度量有多少比例的用户请求使用了降级后的内容。例如,如果用户数据服务不可用了,使用着通用头像的客户依然可以正常玩游戏。
时效性流水线最近一次更新时间距现在小于某个时间阈值的数据的比例。理想情况下,此指标会统计用户访问数据的次数,以便最精确的刻画出用户体验。
正确率流水线对于进入流水线的数据记录,正确地生成了处理结果的比例。
覆盖率流水线对于批处理系统,处理了超过某些目标数量级数据的作业的比例。对于流处理系统,在某个窗口时间内成功处理了传入记录的比例。
持久性存储写入记录可以被成功读取的比例。要特别小心持久性SLI; 用户想要的数据可能只是存储数据中的一小部分。例如:如果在过去10年中你的系统存储了10亿条记录,但用户只需要当天的记录(然而这部分数据不可用了),那么即使几乎他们所有过去的数据都是可读的,他们还是很不满意的。

对于请求驱动的,我们可以用http code作为统计方式,比如5xx这种。

流水线的会比较麻烦一点。我自己的经验是就看输入和输出。比如我们之前的大数据系统。数据来源是消费线上的kafka的数据的,那我就关心kafka consumer lag就行了。那输出这样一块呢,跟大数据的同学学习下,原来他们是会把结果写入到redis中。那我们就看redis key的生成时间就行了,加个ttl, 或者redis key的member里本身自带时间也行。