我们建议标准化一些常见的SLI，以避免每次都要重新评估它们。任何一个符合标准定义模板的服务可以不需要再次自己定义 SL1。

●汇总间隔∶每1分钟汇总一次

●汇总范围∶集群中的全部任务

●度量频率∶每 10 秒一次

●包含哪些请求∶ 从黑盒监控任务发来的HTTP GET 请求

●数据如何获取∶通过监控系统获取服务器端信息得到

●数据访问延迟∶ 从收到请求到最后一个字节被发出

为了节约成本，应该为常见的指标构建一套可以重用的SLI模板，从而使得理解每个SLI 更简单。

我们应该从思考（或者调研）用户最关心的方面入手，而非从现在能度量什么入手。用户真正关心的部分经常是度量起来很困难，甚至是不可能的，所以我们需要以某种形式近似。然而，如果我们只是从可以简单度量的数值入手，最终的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章"使用错误预算的目的"一节），利用这两个数值的差值可以指导新版本的发布。

我们建议标准化一些常见的SLI，以避免每次都要重新评估它们。任何一个符合标准定义模板的服务可以不需要再次自己定义 SL1。

●汇总间隔∶每1分钟汇总一次

●汇总范围∶集群中的全部任务

●度量频率∶每 10 秒一次

●包含哪些请求∶ 从黑盒监控任务发来的HTTP GET 请求

●数据如何获取∶通过监控系统获取服务器端信息得到

●数据访问延迟∶ 从收到请求到最后一个字节被发出

为了节约成本，应该为常见的指标构建一套可以重用的SLI模板，从而使得理解每个SLI 更简单。

我们应该从思考（或者调研）用户最关心的方面入手，而非从现在能度量什么入手。用户真正关心的部分经常是度量起来很困难，甚至是不可能的，所以我们需要以某种形式近似。然而，如果我们只是从可以简单度量的数值入手，最终的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章"使用错误预算的目的"一节），利用这两个数值的差值可以指导新版本的发布。