你好，我們是來自 LINE 服務工程部門的 Dahee Eo（ Enablement Engineering team）與 Ki Cheol Cheon（Service Reliability team），負責站點可靠性工程 (Site Reliability Engineering: SRE) 相關工作。
我們兩個團隊皆隸屬於服務工程部，專注於提升 LINE App 所提供服務的品質與可用性。具體來說，我們負責 LINE App 內的即時通訊服務與媒體平台等服務的 SRE。為了達成目標，我們會識別服務上線與活動所需的技術要素，提供合適的解決方案，並藉由技術支援與自動化來消除不確定性、減少重複性工作，讓開發團隊能更專注於開發與營運。此外，我們也從需求預測、效能優化、可觀察性提升與事件回應等多方面努力，持續提升服務的可靠性。
基於這些經驗，我們計畫發表一系列三篇文章，主題為「採用 SLI/SLO 以提升服務可靠性」。本篇文章作為開端，將簡單介紹服務水準目標（Service Level Objective : SLO）與服務水準指標（Service Level indicator: SLI）是什麼，並說明為何對初次接觸這些概念的人來說，它們是必要的。
SRE 的主要角色
SRE 負責執行所有必要的工程任務，以確保向客戶提供「穩定性(stability)」與「可靠性(Reliability)」的服務。具體來說，這包括撰寫程式碼來提升效能與自動化流程、系統監控，以及事件回應。SRE 的目標是在盡可能適應變動的同時，維持服務的穩定性，進而提供高度可靠的服務。
「可靠性(Reliability)」這個詞彙較為抽象，可以理解為與「信賴」相關的任何正面描述，常見的面向包括：
- 提供快速的服務。
- 提供穩定的服務。
- 提供安全的服務。
最終，服務可靠性代表的是用戶能夠信任並持續使用該服務。換句話說，可靠性並非由服務提供者的監控數據單方面決定，而是取決於用戶的實際體驗與感知。
因此，SRE 必須能夠透過數據來表達用戶對服務的感受。舉例來說，不應該只用「服務很慢」或「服務不穩定」等定性描述，而是要用量化的方式呈現，例如：「訊息傳送 API 的回應速度已放慢至超過 1 秒，對用戶造成不便。」這就需要明確的標準、分級以及針對不同情況的應對方案。
這正是 SLI（服務水準指標）、SLO（服務水準目標） 以及 SLA（Service Level Agreement 服務水準協議） 這些概念發揮作用的地方。LINE App 也導入了 SLI 和 SLO，藉此向用戶提供更可靠的服務。
可靠性如何被衡量？
如前面簡短提及，可靠性如何以量化方式進行衡量呢？
讓我們以「影片服務」為例來說明。對用戶而言，使用影片服務時最重要的是影片能夠快速啟動且播放順暢不中斷。在這裡，影片啟動所需的延遲時間（Latency）即成為服務水準指標（SLI），也就是衡量服務表現的指標。而這個指標的目標值，即是服務水準目標（SLO）。
另外，對於訂閱制服務來說，因為這是用戶與公司間的契約，會明確規定與這些指標相關的標準，若未 達標則會有相應的賠償條款，這就是服務水準協議（SLA）。
我們使用的這個例子是簡化且直觀的，目的是讓任何人都能輕鬆理解。接下來，我們將更深入地探討每個概念的細節。
使用者旅程（User Journey）
要理解 SLI、SLO 和 SLA，首先需要了解「使用者旅程」的概念。使用者旅程指的是用戶在使用服務時所經歷的過程或流程。
以先前提到的影片服務為例，「用戶在服務中播放影片的過程」就是一個使用者旅程。在即時通訊服務中，則可能是「用戶發送訊息的流程」或「用戶新增好友的過程」。
而使用者旅程中關鍵功能與服務的流程，稱為關鍵使用者旅程（Critical User Journey, CUJ）。導入 SLI 和 SLO 的第一步，就是先定義服務的主要功能所對應的 CUJ，並識別每個使用者旅程中所使用的 API。
SLI, SLO, SLA
以下表格總結了概念關於 SLI, SLO 與 SLA
| 分類 | Service Level Indicator (SLI) | Service Level Objective (SLO) | Service Level Agreement (SLA) |
|---|---|---|---|
| 敘述 |
|
|
|
| 範例 |
|
|
|
以下範例對 SLI 與 SLO 的定義做了更細緻的說明，文字顏色分別代表：事件（Event），成功標準（Success Criterion），在哪裡及如何測量（API 與測量方法）和測量時間窗（Measurement Window）。
請注意，這些範例為一般性示範，尚未針對特定關鍵使用者旅程（CUJ）進行定義。
<範例 1：基於延遲的 SLI/SLO>
| SLI 類型 |
|
|---|---|
| SLI 規格 |
|
| SLI 實作細節 |
|
| SLO |
|
<範例 2：基於可用性的 SLI/SLO>
| SLI 類型 |
|
|---|---|
| SLI 規格 |
|
| SLI 實作類型 |
|
| SLO |
|
以下是基於 SLI/SLO 的可靠性衡量流程總結:
定義與衡量 SLI/SLO 的原則
-
從使用者角度出發: 重要的不是能測量什麼數值，而是找出用戶真正關心的指標。
-
保持簡單明瞭: 若 SLI 以過於複雜的方式彙整，可能無法清楚反映系統的真實狀況，因此應盡量簡單。
-
設定最少數量的 SLO: 挑選能準確反映系統特性的最少數目 SLO，避免過多目標造成管理與判斷困難。
-
設定合理目標: 設定能反映期望的目標，但避免過高（例如 100%）的要求，以免不切實際。
-
持續發展與改進: 無法一開始就完美設定 SLI/SLO，必須持續檢視、調整與優化。
錯誤預算（Error Budget）
當你已經量測了 SLI 並設定了 SLO 作為目標後，接下來需要管理風險與錯誤，以應對目標未達成的狀況。
這時「錯誤預算」的概念就非常重要。錯誤預算是根據 SLO 所定義的，允許服務在一定範圍內發生失敗或穩定性下降的容忍度。舉例來說，如果 SLO 設定為一個月內可用率 99.9%，代表允許有 0.1% 的錯誤率。用公式計算的話，這 0.1% 的錯誤率相當於一個月內約 40.32 分鐘 的容錯時間。
譯者說明：
- 99.9% 的可用率意即每個月允許 0.1% 的錯誤時間。
- 0.1% 換算成數值為 0.001。
- 以 28 天為一個月計算，乘上每天 24 小時與每小時 60 分鐘，得到每月允許的錯誤時間約為 40.32 分鐘。
如下面所示，SLO 設定越高，允許的錯誤時間自然越少（以下計算皆以一個月為基準）。不過，目標設定過高並非總是好事。Google 說明，將可用率從 99.9% 提升到 99.99%，或從 99.99% 提升到 99.999%，所需的努力是原本的 10 倍（參考資料）。因此，根據不同服務的特性與狀況，適當設定目標非常重要。
| SLO 目標 | 允許的錯誤時間（每月） | 對應說明 |
|---|---|---|
| 99.9% | 約 40 分鐘 | 可由人工偵測異常、監控、找出根因並修復 |
| 99.99% | 約 4 分鐘 | 錯誤時間過短，人工難以即時偵測與修復，需設計系統自動偵測與自我修復 |
| 99.999% | 約 24 秒 | 人工無法偵測，必須完全依賴系統自動監控與修復 |
錯誤預算的最大優點是讓開發團隊與 SRE 團隊能以「同一語言」討論「服務可靠性」問題，也就是判斷服務是否正常運作。此外，錯誤預算讓開發團隊能夠自主管理風險。透過觀察錯誤預算的使用狀況，開發團隊可以決定是優先投入新功能開發，還是專注於提升服務穩定性。
- 當錯誤預算已用盡且服務不穩定時，所有新功能開發與發布應暫停，重點放在修復與穩定服務上。
- 當錯誤預算尚未用盡時，則可以繼續推動新功能開發。
需要注意的是，錯誤預算中涵蓋的錯誤不僅限於應用程式本身，還包括網路、儲存等各種可能影響服務的錯誤，且這些錯誤的定義應依據各服務的特性來設定。
SLI/SLO 的實際運用
當你已經定義並實作了 SLI/SLO，就能開始以量化方式評估用戶對服務可靠性的感受。那麼，SRE 如何在實際運維工作中善用 SLI/SLO 呢？
-
共用語言評估可靠性
服務相關的各方利害關係人可以共同使用「SLI」、「SLO」與「錯誤預算」來評估可靠性，透過這些量化指標以相同語言討論服務狀況。 -
定期監控與回顧
透過定期會議（如每週或每月），共同監控 SLI/SLO 狀態，分享指標變化，找出變化原因或問題，並定義改善方案。 -
建立基於錯誤預算的警示系統
利用錯誤預算設計分階段的警示機制，向值班人員或服務運維團隊發出警告，讓他們能及時採取相應行動。 -
根據 SLO 與錯誤預算調整策略與資源分配
根據錯誤預算的餘額，決定是否可以加快新功能發布與短週期部署；若錯誤預算不足，則將資源優先投入服務穩定性提升與修復。
結語
希望本篇文章能幫助對 SRE 角色感到好奇，或對 SLI/SLO 概念感到困惑的讀者有所幫助。在接下來的第二與第三部分，我們將介紹應用於 LINE App 服務的量測與實作案例。第二部分將聚焦於平台層面的案例，第三部分則介紹應用程式層面的案例。期待各位的關注與支持，本文到此結束，謝謝大家。