SLO、SLI和错误预算是网站可靠性工程的关键支柱，由谷歌倡导。
100%工作的服务，但不能满足用户的需求，其目的是什么？....
或者一个永远不会有新功能的服务，因为那会要求它失败!
在极端的相反情况下，具有所有伟大的大爆炸功能的服务的目的是什么呢，用户想要的，但它是不可靠的，而且大部分时间都不工作
这两项服务都不好!
我们需要的是一种平衡，阴和阳需要完美的和谐。
这就是SLO、SLI和错误预算存在的原因。
什么是SLO？
SLO代表的是服务水平目标（Service Level Object），不要与SLA混淆，SLA更多的是被习惯于起草带有惩罚条款的合同的律师所熟知。
没有人喜欢和律师打交道，所以这就是SLOs被发明的原因。Ok....我只是在开玩笑....
服务水平协议，更常见的是SLA，并不总是可以轻易衡量的东西，而且可能是高度主观的。
另一方面，一个SLO应该很容易用数据来衡量，而且不应该有争议。
一个SLO的例子是，比如说。我希望所有对API X的请求中有95%在100毫秒内被成功提供。
或者一个更常见的SLO是关于可用性的，"我希望99.99%的对API X的请求都能成功"。
此外，一个SLO也应该在一个时间窗口内测量，例如在30天内。
因此，服务水平目标是一个可以衡量的目标，通过SLI，即服务水平指标的意思。没有SLI，你就没有SLO。如果你不能衡量它，SLO不过是一个愿望而已。
SLO是如何设置的？
人们不应该随意为服务SLO设置数值。
正确定义的SLO是拥有一个可靠和快速的服务与不断改进的愿望之间微妙平衡的结果。
这就是为什么定义寻求100%正常运行时间和可用性的SLO不是一个好主意。
除了是一个非常昂贵的目标外，拥有近乎完美的可靠性将阻止一个服务不断地进行新功能的更新。因为每次你需要添加新的功能时，可靠性肯定会下降。
但是，如果可靠性下降，那么你就会自动不满足SLO。这是因为SLO设置得太高，没有足够的缓冲，也就是所谓的错误预算。
因此，设置现实的SLO是非常重要的。
下面你可以看到一个你可以为一个项目设定的SLO的例子。
- 对X服务的所有请求有99.9%是成功的
- 95%的请求的延迟应低于100ms
- 99.99%的添加产品到购物车的请求都是成功的。
这些SLO是基于30天的时间窗口的。但是，你也可以按季度或按你认为适合你的项目的任何时间长度来设置。
定义SLO和SLI是没有好处的，因为这些SLO和SLI不容易用SLI来衡量，而且我们也没有对它们进行跟踪。
更多的时候，Prometheus和Grafana被用来收集指标和可视化企业的SLO。下面你可以看到一个仪表盘的例子，你可能会看到，跟踪SLO的遵守情况。
通常情况下，测得的SLI指标是高于目标SLO的。两者之间的区别是构成错误预算的内容。
错误预算是一个企业在进行可能使可靠性下降的改变时的松弛。
通过对SLO和错误预算的监控，企业能够控制变化的速度。
