前言

已经有很多文章讨论什么是 SLI, SLO, SLA，它们是有什么关系，为什么它们很重要以及通常有哪些指标当作 SLI，比如著名的 RED 原则，USE，但是如何设置合理的 SLO 呢？本文重点不是一些具体的指标，比如一个 HTTP API 应该考察错误率，延迟，请求次数等等，已经有很多非常棒的模板，这里主要聊一下一些制定良好 SLI，SLO 的若干准则。

避免一蹴而就

罗马不是一天建成的，没有人可以一次定好完美的模型和目标，如果团队做到如下几点就非常好了：

1. 定期评审，取决于业务特点，最好做到每周评审一次，三次没人看的指标就剔除

2. 公开透明，数据可视化展示给所有人，任何人都可以质疑甚至挑战这个规则是不是不合理

3. 和产品，运营团队保持持续沟通，有没有可能有些热点事件有可能导致意外的压力或者预计有什么重大活动有额外的需求等等

内外兼顾

我们的系统对客户来说是个黑盒，所有客户能感受到的都是需要制定 SLI 和对应的 SLO，但是内部子系统也需要各自制定 SLO 和 SLI。

1. 外部指标帮助监控问题，我们给客户什么样的使用体验，量化系统可用性

2. 内部指标帮助排查问题，客户抱怨响应慢，不稳定，如何快速定位问题

这一点并不容易做到，需要具有清晰的系统依赖关系，数据流转示意图，并且快速链接到对应的 SLO dashboard。

保持简单

我们往往会一开始就把问题想的很复杂， 什么 QoS，面临极限压力下的表现，从而定制非常复杂的 SLO，团队的注意力很容易分散出去，60 分钟会议以后，发现绕来绕去还是讨论这几个问题。最好从一些简单的指标开始，比如可用性，延迟，先把简单的 SLO 定下来，经过观察进一步完善。

1. 可用性一般用请求成功率来衡量，请求成功率是一段时间里成功请求数占所有请求数的百分比来衡量，即：

1 - (failure / total requests)

这里 request 不仅仅是 HTTP 请求数，也可以表示某种定时任务执行次数，由若干请求组合而成的一次操作等等，根据实际情况去梳理。那么问题来了，什么样的请求定义为失败的请求？我们可以认为所有影响用户体验的都是失败的请求，比如响应 401 状态码的 HTTP 请求，正常情况下客户不应该会频繁发送未授权请求的，如果遇到这种情况，一样需要调查，也许是有人攻击，也许是认证服务有问题。

2. 延迟，即在一个预设阈值内，没有完成的请求。这里如果要细分，可以再写一页纸。这里主要讨论如何设置一个合理的阈值。假设我们维护一个网站，有些请求就是很快返回，有些请求确实就是需要 1 秒，在产品经理认为不影响客户体验的情况下，这就是正常的。所以即使我们想要简单，一刀切的设置个阈值也是比较鲁莽的。此时不妨将一段时间（24 小时，48 小时）的所有请求和响应时间记录显然，然后按照若干登记分类，比如 200ms 以下的请求有哪些，有多少，500ms 以下的请求有哪些，有多少。我们可以通过类似于 Promethus 或者 ELK 等工具轻松的获取这些数据，就很容易设置一个比较合理的阈值了。

回过头来，刚刚说，所有影响客户体验的，都是失败的请求，那么广义的来说，延迟的请求也应该算在失败请求里，所以除了失败请求数，我们还可以把两者加起来做一个广义失败率来给一个更加直观的数据来衡量我们的服务状态：

1 - [(slow requests + failures) / totoal requests]

切忌盲目追究几个 9

经常在一些简历或者某些介绍中说，我负责的平台实现了 4 个 9 设置 5 个 9 的可靠性。然而现实是及其残酷的，这张表的出境率相当高：

4 个 9 意味着一年服务受影响的时间也才 50 分钟，平均到每个月才 4 分钟，如果电话通知我，接电话，打开电脑，查以下日志，15 分钟就过去了，所以这个要求是非常非常高的。

同时，我们运维的往往是一个极为复杂的系统，里面包含了若干子系统，互相之间有依赖关系，比如下面这个我随便画的一个拓扑图。

用户看到的就是 Web1, Web2 两个服务，Web1 有两个独立依赖：Service1 和 Service2，Service1 又依赖 DB1，还有一连串串行依赖：MQ1->Service3->MQ2->Service4->DB2。

学过概率的人都可以简单计算出来，这条路上，所有服务的可靠性相乘才能等于最终的可靠性，如果这条路径长达 10 个节点，那么即使每个服务都是 99.99%的可靠性（前面说过，这并不容易），最终的可靠性也才 99.9%。

因此，设置几个 9 的目标是需要合理分析，计算出每个依赖组件的可靠性要求得到的，不能人为拍脑袋定。根据需求设置对应的冗余方案，选择合理的架构，付出的代价，衡量是否值得。面对日益复杂的系统，怎么才能设置一个合理的目标，或者根据目标做到合理的设计，尽量的投入少，见效大呢？我们需要公开透明。

公开透明

这更像是一种倡议的文化，而不是某种技术手段，首先所有的 SLO 和 SLI 都应该公开透明，任何人都可以查看并质疑是否合理，同时并不局限于 SRE 的领域，实际上，从项目立项，设计文档，源代码，测试结果都是公开透明的。其实非常能理解人类天生自带的微妙心理：），一个良好的团队文化，的确是无价的！

统一的工具

所谓工欲善其事，必先利其器。前面讨论和一些通用的准则，接下来我们简单讨论一下工具。其实就简单一句话：一定要保持统一的工具，统一的术语。这样才能保持高效的沟通，形成统一的标准。

结束语

回到开头说的，SLI 和 SLO 是 SRE 工作中重点的重点，它不仅仅关系到我们维护的服务的可靠性，设置一个合理的指标也关系到运维人员的工作量，值得琢磨再琢磨。这里仅仅粗略的列一些经验之谈，希望和大家学习。