ExplainThis 全端開發雙週報 #72 SLO 是什麼? 為什麼 SLO 對軟體團隊很重要?
SLO 是什麼? 為什麼 SLO 對軟體團隊很重要?
嗨～歡迎閱讀第 72 期 ExplainThis 全端開發雙週報！
過去兩週我們在 YouTube 頻道上發了兩支新影片。第一支是在談近期社群出現的 AI 垃圾潮，並談了如何避免在用 AI 時只是大量產出 AI 垃圾 (連結)。同時我們做了一個基於 AI 的互動小測驗，由 AI 幫忙分析與評估目前的等級，並給予如何往「更善用」邁進的具體建議。
另一支影片則是導讀了 OpenAI 前陣子發的技術文章，談 OpenAI 如何將 PostgreSQL 擴展到支撐 8 億名使用者 (連結)。
除了在 YouTube 的公開影片外，我們在 E+ 成長計畫也有更完整深入的版本，感興趣的讀者，歡迎加入 E+ 觀看與交流 (連結)。
以上，接著讓我們進到這期的雙週報主題文
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+ 一起成長 (連結)。
本期推薦
MIT 在 2020 年出的一堂 The Missing Semester of Your CS Education，不是教傳統 CS 課程的內容，而是教要做好工程師需要知道的知識與工具，在過了五年後，今年這門課再次更新，且陸續把影片上傳到 YouTube 了(連結)
Dan Abramov 上週發了《A Social Filesystem》用淺顯易懂的方式介紹 AT Protocol 這個值得關注的協定 (連結)
從 2023 年開始，Ryan Carniato 每年初都會寫一篇 JavaScript 框架的發展概覽，2026 年的已經發佈了。如果想了解目前 JavaScript 框架趨勢與未來走向，推薦一讀 (連結)
除了 OpenAI 分享的 PostgreSQL 擴展技術文外 (連結)，Supabase 也推出了 PostgreSQL 代理技能 (連結)，個人專案或工作上有用 Postgres 的讀者可以試試
社群中著名的免費 Git 教材 Beej’s Guide to Git (連結) 的作者，前陣子出了 Beej’s Guide to Learning Computer Science，也是一本免費電子書，談如何學好電腦科學 (連結)
Anthropic 團隊發表了一項研究，發現如果沒有用對方式，在用 AI 來寫程式後，反而可能會讓使用者對程式碼的學習與理解降低 (連結)。針對這個議題，近期社群也有開發者分享，如何避免越用 AI 變越笨? (連結)
隨著 AI 在程式實作的能力上越來越好，社群有不少關於工程師未來走向的討論，其中《Code is Clay》一文用陶土工藝的發展角度來類比，觀點相當精闢 (連結)
文末彩蛋
這期的文末彩蛋，是來自社群中的一句話。這句話談到「好相處、別人刻薄時你保持善良、事情搞砸時仍保持冷靜。單純的聰明才智，往往被過度高估」。
Remember: A major cheat code in life: Your personality will get you 10x richer than your intelligence. Be easy to work with. Kind when others aren’t. Calm when things fall apart. Intelligence alone is overrated.
我們過去在職場上有類似的觀察，雖然這不代表聰明才智不重要，但在軟體開發這類需要團隊合作的任務中，能夠有這樣的特質，會對團隊很有幫助。