SLO 是什麼? 為什麼 SLO 對軟體團隊很重要?

當談到可靠性工程，SLO (service-level objective) 是多數人第一個會聯想到的關鍵詞；在 Google 出的《Site Reliability Engineering》一書中甚至提到「當團隊沒有 SLO，就沒有 SRE 的存在必要」，因為 SRE 是基於 SLO 去排定事情的優先順序，以確保能夠有效達到 SLO。

我們曾在 軟體工程師該如何做好監控 (monitoring)? 一文用小篇幅提到 SLO 相關的內容，在這篇文章，我們會更深入且全面地討論 SLO 這個主題。包含什麼是 SLO (以及很常聽到的 SLI 與 SLA 又分別是什麼)、團隊要如何設定 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+ 的版本中，我們也會討論，如果要把 SLO 相關機制建立的列點寫在履歷上，可以如何寫來展現自己的資深度。感興趣的讀者，歡迎加入 E+ 一起成長 (連結)。