1.4 要记住的事情

近年来，基于SLO的可靠性方法变得异常流行，这实际上在某些方面是有害的。SLO已经成为一个流行语：许多领导团队认为他们需要的原因仅仅是它是站点可靠性工程（SRE）的重要组成部分，不幸的是，SRE本身经常被理解成一个只表示用户希望它的意思的术语。我们应该尽量避免掉进这个陷阱。以下是一些关于成功的基于SLO方法的案例，在阅读本书的过程中，你应该记住这些事情。

在采用基于SLO的可靠性方法时，需要考虑的关键问题是：“你是否考虑到了你的用户？”使用可靠性栈主要是帮助你更有效地完成这项工作的数学运算。

1.4.1 SLO只是数据

如果采用基于SLO的方法，最重要的是要记住，最终目标是为你提供一个新的数据集，在此基础上，你可以进行更好的讨论并做出更好的决策。没有硬性的规则：使用SLO是一种帮助你从新的角度思考服务的方法，而不是一种严格的意识形态。没有什么是完美的，这包括SLO提供的数据。它比原始的遥测要好，但不要期望它是完美的。SLO将会指导你但不要求你做任何事。

1.4.2 SLO是一个过程，而不是一个项目

一个常见的误解是，你可以将SLO作为季度计划的一个目标和关键结果（OKR），并在某种意义上完成它。这根本不是基于SLO的可靠性方法的工作原理。本书中描述的方法和系统是对服务的不同思考方式，而不仅仅是你可以完成的任务。它们是一种哲学，而不是你可以为一两次冲刺而分发的门票。

1.4.3 迭代所有内容

目前没有与SLO或任何与之相关的协议。这意味着你可以，也应该在需要时更改它们。先尝试开发一些SLI。然后，一旦你观察了一段时间，就可以确定是否可以选择一个有意义的SLO目标。一旦你有了其中的一个SLO，也许就可以为你的错误预算选择一个窗口。但也许你已经意识到你的SLI并不像你所希望的那样代表你的用户，所以就需要你更新它。现在你已经改变了SLI，你意识到需要选择一个不同的SLO目标，这完全否定了你选择的错误预算窗口。所有这些都必须与服务的开发人员、服务的维护人员、负责产品路线的人员、领导者等携手合作。这一切都很好。这是一次旅行，而不是目的地。

1.4.4 世界将会改变

世界总是在变化，你应该准备好更新和改变你的SLI和SLO来考虑新的发展。也许你的用户现在有了不同的需求，也许你的依赖性使你的服务更健壮，也许你的依赖性使你的服务更脆弱。所有这些事情，以及更多的事情，都将在服务的生命周期中发生。你的SLI和SLO应该根据这些变化而发展。

1.4.5 一切都是关于人的

如果你在尝试实施本书中概述的方法时发现参与其中的人对事情感到沮丧或不安，退一步反思一下你迄今为止所做的选择。SLO的最终目标是让用户更快乐、让工程师更快乐、让产品团队更快乐和让业务更快乐。这应该始终是我们的目标——而不是达到在SLO目标末尾添加几个9。