SLO 是什么? 为什么 SLO 对软件团队很重要?

当谈到可靠性工程，SLO (service-level objective) 是多数人第一个会联想到的关键词；在 Google 出的《Site Reliability Engineering》一书中甚至提到「当团队没有 SLO，就没有 SRE 的存在必要」，因为 SRE 是基于 SLO 去排定事情的优先顺序，以确保能够有效达到 SLO。

SLI、SLO、SLA 分别是什么?

在具体谈 SLO 的定义之前，让我们回到软件产品的本质来讨论。

推荐大家在往下读前，可以自己先试着写下对以下问题的回答：

软件产品的存在目的是什么? (可以试着想自己在工作或个人项目写的软件，为什么要花时间写)
软件团队该如何判断有「可靠地」达成上述提到的目的? (可以试着思考，当别人问你的团队负责的软件产品有多可靠? 你会怎么回答? 是基于什么来判断的?)
身为软件工程师的你想跟产品经理提案，让团队花更多时间在技术面的改进与重构，但你该如何证明时间花在这些事情上面有价值?

在一个软件团队中，上述的第一个问题通常是由产品经理回答 (但好的工程师也要对该问题有自己的观点)。上述的第二个与第三个问题，则是团队的资深工程师在实务工作中需要面对的，而 SLO 的存在正是在协助回答这两个问题的指标。

在谈 SLO 之前需要先有 SLI

SLO 是 Service-level Objective 的简写，用中文直观理解是「服务水准目标」。对工程师来说，SLO 是一系列需要去达成的目标，在业界中常见的 SLO 包含「API 请求的成功率达到 99.9%」，或者「90% 以上的 API 请求需要在 10 ms 完成」。不同的软件产品会有不同的 SLO，而工程师的职责是去定义出 SLO，并且确保 SLO 能够被达成。

很不幸地，在业界有工程团队，会随便抓一些目标，应付上级来订定 SLO；也有一些工程团队，是看其他产品定义的 SLO 然后直接照抄。要避免这两种状况，在设定 SLO 之前，需要先收敛出有意义的 SLI，才能确保 SLO 不是乱枪打鸟或随波逐流。

所谓的 SLI 是指 Service-level Indicator，也就是「服务水准指标」，白话来说，是指什么对软件产品来说重要。

不同的软件产品看重的点会不同，例如对金融或会计相关的软件来说，正确性的重要性是最高的，任何一点错误都不该被允许，所以在这类产品的技术取舍上，很常会为了求正确性，让时间 (速度) 被稍微牺牲。

不过对于社群媒体类的软件来说，速度就会比较重要，因为使用者很可能会因为觉得慢而跳出，但是社群媒体的正确性要求就没那么高，如果贴文按赞数不是最正确反映当下的也不会造成大碍。

因此，SLI 的设定通常会与产品经理合作，去把对产品最重要的指标写下来，常见的指标包含速度 (延迟度)、可用性、耐用性、正确性、完整性等。

基于 SLI 设定 SLO

在有了 SLI 写下的重要指标后，这时相信多数读者会觉得不够，畢竟假如在工作上，产品经理说对团队的产品来说可用性高最重要，多数工程师的第一个回应大概会是「可用性怎么样算高?」。

举例来说，可用性达到 99% 算高吗? 还是 99.9% 才算高? API 的回应速度在 100 ms 算延迟度低吗? 还是要 50 ms 以内才算?

SLO 的 O (objective) 就是在回应这个问题。SLO 的目标，是根据 SLI 的指标来设定。指标让团队知道什么重要，目标则是进一步让团队知道要做到什么程度才算有守护好这个重要的指标。即使有相同的指标，不同系统设定的目标也可能会不一样。甚至同一个系统中，相同指标也可能有不同目标，我们会在后面的段落详细谈可以如何订定适合团队的目标。

回到最开始请大家先思考的问题「软件团队该如何判断有可靠地达成软件的目的?」，要能够判断就需要先定好可靠性相关的 SLO，有达到 SLO 才能说有可靠地达成。

对客户承诺的 SLA

对于工程团队来说，SLO 已经足够，不过假如从产品的角度来看，通常会再进一步设定 SLA (service-level agreements)，也就是「服务水准协议」。

SLA 通常是对外部使用的一种承诺。举例来说，假如你所在的团队正在开发一个 AWS S3 的竞品，如果你想说服客户使用你团队的产品，而不是用 S3，你可以跟客户说「我们的产品可用性比 AWS S3 来得高」，这时客户肯定会问「你要如何保证?」。

SLA 的存在就是在解决这个问题背后的疑虑。假如你声称自己的存储系统可用性达到 99.999%，客户多半不会轻易买单。但假如说法改成「假如可用性没有达到 99.999%，我们就退还所有费用」，这时就更可能说服客户。

以 AWS S3 为例，在 S3 的 SLA 中 (连结) 就有提到，如果可用性低于 99% 会退款 10%，如果可用性低于 95% 则会全额退款。

多数团队在设定 SLO 与 SLA 时，通常会把 SLO 设定得比 SLA 严格，因为这样做能够给团队一些缓冲。举例来说，假设 SLA 设定为 99.9%，内部 SLO 可能会设为 99.95%。这样在 SLA 没有达标前，SLO 就会先没达成；当 SLO 没达成时，团队有缓冲的时间去修复，而不至于直接违反 SLA 导致赔偿。

閱讀更多

在了解 SLO 是什么后，相信多数人会问「要如何为团队与产品设定好 SLO 呢」? 容我们在 E+ 成长计划的主题文，有透过具体案例来进一步谈。感兴趣的读者，欢迎加入 E+ 一起成长 (连结)。