查看原文

本文介绍了 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，降低威胁指标的风险。