Google Cloud Platform Blog: SLO v/s SLI v/s SLA

查看原文

本文介绍了 Google 内部如何为系统定制 Service Level Objective (SLO)。这个指标用于表示系统是否正在可靠高效地运行着,以及指导设计与架构变迁能够在继续满足要求。一般来说 Service Level Indicator (SLI) 适合 SLO 保持一致的,我们用 SLI 得到 service availability percentage,与 SLO 做对比,如果抵御 SLO,那系统可能性就偏低了,可能需要起新的健康的实例恢复指标。

SLO 存在的意义是,它指出了服务的 downtime 在多大限度内是可接受的。否则的话,一有问题,就有人打小报告。我们需要认识到:unhealthy 也是一种 healthy。

SLA 是跟客户约定的保障服务稳定运行的合约,违反了一般会有 Penalty。怎么算钱要跟客户实现说清楚。

文章末尾建议

  • 如果从头构建系统的时候,一定要把 SLI, SLO, SLA 咧清楚,否则无法准确得知系统的可用性和稳定性。
  • 如果系统已经有了却没有这样的指标,那么一定要将设定 SLI/SLO/SLA 作为最高优先级。
  • 如果想要有可靠的服务,就必须衡量服务的可用性。
  • 如果想知道服务又多可靠,那就要设定基本 SLI: 成功率和失败的请求。
  • 将 SLO 设定为 lowest level of reliability。因为指标越高意味着成本越高。
  • SLO 要比 SLA 更严格,因为 SLA 要赔钱啊!
  • 只有设定好 SLO,我们才能调整服务的可靠性(调高适合稳定运行,调低适合冲刺开发)
  • SRE 工程师认清自己的责任:理解维护的系统怎么达到预期的 SLO,降低威胁指标的风险。