目标在实践中的应用

我们应该从思考（或者调研）用户最关心的方面入手，而非从现在能度量什么入手。用户真正关心的部分经常是度量起来很困难，甚至是不可能的，所以我们需要以某种形式近似。然而，如果我们只是从可以简单度量的数值入手，最终的SLO的作用就会很有限。因此，与其选择指标，再想出对应的目标，不如从想要的目标反向推导出具体的指标。

目标的定义

为了更清晰地定义，SLO应该具体指出它们是如何被度量的，以及其有效条件。例如，我们可能说：

● 99%（在1分钟的时间范围内汇总）的Get RPC调用会在小于100ms的时间内完成（包括全部后端服务器）。

● 99% 的Get RPC会在100ms内完成（这一句与上一句一样，只是利用了SLI模板中的信息减少了重复信息）。

如果性能曲线也很重要的话，我们可以指定多个SLO目标：

● 90% 的Get RPC会在1ms内完成。

● 99% 的Get RPC 会在10ms内完成。

● 99.9% 的Get RPC会在100ms内完成。

如果我们同时具有批处理用户（关注吞吐量）以及在线交互式用户（关注延迟），那么可能应该为每种负载指定单独的SLO目标：

● 95% 的批处理用户Set RPC 应该在1s之内完成。

● 99% 的交互式用户Set RPC，并且RPC负载小于 1KB 的应该在 10ms之内完成。

要求SLO能够被100% 满足是不正确，也是不现实的：过于强调这个会降低创新和部署的速度，增加一些成本过高、过于保守的方案。更好的方案是使用错误预算（Error Budget）——对达不到SLO的容忍度——以天或者以周为单位计量。高层管理者可能同时也需要按月度或者季度的评估。（错误预算其实就是保证达到其他SLO的一个SLO!）

达不到SLO的现象的发生频率对用户可见的服务健康度来说是一个有用的指标。通过每日（或者每周）对SLO达标程度的监控可以展示一个趋势，这样就可以在重大问题发生之前得到预警。

SLO不达标的频率可以用来与错误预算进行对比（见第3章“使用错误预算的目的”一节），利用这两个数值的差值可以指导新版本的发布。

目标的选择

选择目标SLO不是一个纯粹的技术活动，因为这里还涉及产品和业务层面的决策，SLI和SLO（甚至SLA）的选择都应该直接反映该决策。同样的，有时候可能可以牺牲某些产品特性，以便满足人员、上线时间（time to market）、硬件可用性，以及资金的限制。SRE应该积极参与这类讨论，提供有关可行性和风险性的建议，下面列出了一些有用的讨论。

不要仅以目前的状态为基础选择目标

了解系统的各项指标和限制非常重要，但是仅仅按照当前系统的标准制定目标，而不从全局出发，可能会导致团队被迫长期运维一个过时的系统，没有时间去推动架构重构等任务。

保持简单

SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化，同时也更难以理解。

避免绝对值

虽然要求系统可以在没有任何延迟增长的情况下无限扩张，或者“永远”可用是很诱人的，但是这样的要求是不切实际的。就算有一个系统能够做到这一点，它也需要花很长时间来设计和构建，同时运维也很复杂—最关键的是，这可能比用户可以接受的（甚至是很开心地接受的）标准要高太多。

SLO越少越好

应该仅仅选择足够的SLO来覆盖系统属性，一定要确保每一个SLO都是必不可少的：如果我们无法针对某个SLO达标问题说服开发团队，那么可能这个SLO就是不必要的[4]。然而，不是所有的产品属性都能用SLO表达，用户的“满意度”就很难。

不要追求完美

我们可以随着时间流逝了解系统行为之后优化SLO的定义。刚开始可以以一个松散的目标开始，逐渐收紧。这比一开始制定一个困难的目标，在出现问题时放松要好得多。

SLO 可以成为—也应该成为—SRE和产品团队划分工作优先级的重要参考，因为SLO代表了用户体验的程度。好的SLO是对开发团队有效的、可行的激励机制。但是一个没有经过精心调校的SLO会导致浪费，某团队可能需要付出很大代价来维护一个过于激进的SLO，而如果SLO过于松散，则会导致产品效果很差。SLO是一个很重要的杠杆：要小心使用。

控制手段

SLI和SLO在决策系统运维时也非常有用：

1.监控并且度量系统的SLI。

2.比较SLI和SLO，以决定是否需要执行操作。

3.如果需要执行操作，则要决定究竟什么操作需要被执行，以便满足目标。

4.执行这些操作。

例如，如果在第2步中，请求延迟正在上涨，无操作的话，会在几个小时内超出SLO范围。第3步则会测试服务器是否是CPU资源不够，同时增加一些CPU来分散负载。没有SLO的话，我们就不知道是否（或者何时）需要执行该动作。

SLO可以建立用户预期

通过公布SLO可以设置用户对系统行为的预期。用户（以及潜在用户）经常希望知道他们可以预期的服务质量，以便理解该服务是否能够满足他们的要求。例如，某个团队想要开发一个照片分享网站，可能会避免使用一个数据持久性高、成本低，但是可用性低的系统。但是，可能会使用另外一个存档信息管理系统。

为了让用户拥有正确的预期，我们可以考虑使用以下几种策略：

留出一定的安全区

对内使用更高的SLO，对外使用稍低的SLO可以留出一些时间用来响应问题。SLO缓冲区也可以用来进行可能影响系统属性的重构，例如降低成本以及方便运维等，缓冲区保护我们不会对用户产生直接影响。

实际SLO也不要过高

用户一般不会严格按照书本定义的SLO，而是按照实际情况来构建服务，这在基础设施类服务上非常明显。如果服务的实际性能要比SLO宣传得好太多，用户可能会逐渐依赖于现在的假象。我们可以利用主观可控模式减少这种过度依赖。（Google Chubby服务会用计划内维护来避免过于可用。）[5]同时，可以采取对一些请求限速，或者限制系统在低负载情况下也不会速度过快的手段。

理解系统行为与预期的符合程度可以帮助决策是否需要投入力量优化系统，使其速度更快、更可用，或者更可靠。如果服务一切正常，可能力量应该花在其他的优先级上，例如消除技术债务、增加新功能，或者引入其他产品等。