制定SLO

SRE最核心的职责是保障SLA, SLA的全称是Service Level Agreement，也就是服务质量保证。但是我们内部还需要SLO,也就是服务质量目标，这个目标很多人拍脑袋就是100%，那这个只要是机器存在，必然不可能是100%的。

那我们还需要SLI来定义，没有SLI就不会有SLO, SLI就是服务质量指标。

我们通常是用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里本身自带时间也行。

下面就是我们之前定义的一些指标供参考，我们的时间窗口都是1分钟。

指标名称	基准值	P4	P3	P2	P1
在1000ms内登陆成功率	99%，0～20个	98%，21～30个，持续1分钟	95%，31～50个，持续3分钟	90%，51～80个，持续5分钟	x
在500ms内消息发送成功率	99%，0～50个	98%，51～80个，持续1分钟	95%，81～100个，持续3分钟	90%，101～150个，持续5分钟	x
在800ms内打开“发现”标签	99%，0～20个	98%，21～30个，持续1分钟	95%，31～50个，持续3分钟	90%，51～80个，持续5分钟	x

上面就是一些参考，这里有百分比，也有绝对值，还有一个是持续时长，超过3个中的任一一个就算对应的故障级别。

然后这些指标就要设置对应的报警项，然后这些报警项每个都需要有一个处理流程，这个流程要满足RTO（恢复时间目标）。

当然这些指标是从哪里来的，是从用户实际需求来的。如果还是不确定，那就从客服和产品那边多聊聊，看看用户吐槽的都是哪些点。毕竟提高SLA是为了客户满意度，如果客户不满意，我们的SLA再高也没有任何意义。