PCA 雲端架構師之旅 04 — 定義 SLO 與 SLI

提案裡寫「系統可用性 99.99%」很容易，但這個數字要怎麼量？是首頁能打開、結帳能完成，還是 API 沒回 5xx？若量測對象沒說清楚，目標就很難拿來判斷架構是否夠用。

這一步會把上一篇的 User Story 轉成實際觀測的指標（SLI），再訂出目標值（SLO）。目標訂得越嚴格，通常需要更多備援與維運投入，得和業務需求一起討論。

這是 PCA 雲端架構師之旅 的第四步。上一篇 03 · User Stories。

先把三個長很像的縮寫分清楚

SLI、SLO、SLA 名字很像，先用「量測、目標、合約」分清楚：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

把三者串起來看：SLI 是實際量到的表現，SLO 是團隊想達到的目標，SLA 則是對客戶的合約承諾。通常會把內部 SLO 訂得比對外 SLA 更嚴，留下處理波動的空間；量到的 SLI 再拿來檢查是否達標。

先對客戶承諾 SLA，事後才定義 SLI 和 SLO，會讓團隊連目前是否達標都說不清楚。比較穩妥的順序是先決定怎麼量、掌握現況，再討論對外承諾。

flowchart TB
  U[使用者旅程] --> I[定義 SLI<br/>量什麼、在哪裡量]
  I --> B[量出基準線]
  B --> O[訂 SLO 與 error budget]
  O --> P[建立告警與處置政策]
  P --> A[設定較寬鬆的 SLA]
  A --> R[持續用實際 SLI 回饋調整]
  R --> O

可用性目標提高，設計也要跟著檢查

若用 30 天、以時間計算可用性的 SLO，換算成可容許的中斷時間會是：

• 99.9%（三個 9）= 每月可以掛 43.2 分鐘
• 99.99%（四個 9）= 每月只剩 4.3 分鐘
• 99.999%（五個 9）= 每月 26 秒

每月只容許約 26 秒中斷，人工收到告警後再處理通常來不及。若真的需要五個 9，就要檢查故障能否自動偵測與切換，以及資料層、網路和相依服務是否還有單點。Multi-region active-active 是可能的做法之一，但不是單看目標數字就能決定的架構。

可用性目標越高，通常越需要處理備援、故障切換和相依服務；成本不會照「多一個 9」的比例增加。當需求提出五個 9 時，先確認停機會造成什麼損失、現況最常壞在哪裡，再估算改善方案的成本。

📝 考場提點

遇到很高的可用性要求，先問目標量的是什麼、目前 SLI 表現如何，以及可容忍多少失敗。這些資料能幫你判斷要改善哪個故障點，再決定是否需要跨區域部署；直接增加區域與備援，不一定能處理真正的瓶頸。

flowchart TB
  R[有人要求四個或五個 9] --> M{目前 SLI 已量測？}
  M -- 否 --> B[先建立基準與故障分布]
  M -- 是 --> I{業務損失大於<br/>新增可靠度成本？}
  B --> I
  I -- 否 --> N[協商較合理的 SLO]
  I -- 是 --> G[找出最主要單點與失敗模式]
  G --> U[針對故障模式調整備援<br/>與切換]
  U --> V[驗證 SLI 是否達標]
  V --> I

SLI 要量什麼：四個面向

可以從這四類指標找出真正影響使用者的失敗；不必每個故事都湊滿四項：

• 可用性（Availability） — 成功的請求佔總請求多少。
• 延遲（Latency） — P50 / P95 / P99 回應時間。注意是看分位數，不是看平均；平均會被大量的快請求拉得很好看，把真正卡住的那批使用者藏起來。
• 吞吐（Throughput） — QPS、MBps，批次處理量。
• 正確性（Correctness） — 回傳的資料對不對。這個最容易被忘記，但對金流、帳務類服務反而是最致命的——服務「有回應」不代表「回對」。

延遲只看平均值，可能藏住少數很慢的請求。假設多數請求在 50ms 完成，少數卻等了 8 秒，平均值仍可能看起來不差；P95、P99 能補上尾端體驗。實際要追哪個百分位，得看流量、使用者任務與慢請求的代價。

flowchart TB
  O[使用者期待的成果] --> Q{最怕哪種失敗？}
  Q --> A[請求沒有成功<br/>Availability]
  Q --> L[回應太慢<br/>Latency<br/>P95／P99]
  Q --> T[工作來不及完成<br/>Throughput]
  Q --> C[結果錯誤<br/>或資料不一致<br/>Correctness]
  A --> M[定義量測邊界與好事件]
  L --> M
  T --> M
  C --> M
  M --> S[用實際資料訂 SLO]

訂 SLO 之前，先問自己幾個問題

訂 SLO 前，先把量測邊界和未達標的處理方式談清楚；下面幾個問題若還答不上來，數字也很難用來做決策：

• 怎麼量？ 從 load balancer 的 log 算？前端塞 RUM（real user monitoring，真實使用者監控）抓瀏覽器端的數字？還是看後端 trace？量的位置不同，數字差很多。
• 量到哪為止？ 是從使用者瀏覽器一路到後端 API 的全程，還是只算 API 進來到 DB 出去那一段？邊界沒講清楚，SLO 就是各說各話。
• 目標要多高？ 內部報表與結帳流程的失敗代價不同，先和使用者確認可接受範圍。
• 沒達標怎麼處理？ 先約定告警、事故檢討與發版調整的條件，讓 SLO 能影響實際決策。
• 誰負責？ 指定維護量測與回應問題的團隊，避免指標沒有人追蹤。

Error budget（誤差預算）是目標範圍內可容許的失敗量：99.9% 留下 0.1%。若 SLI 依時間計算，30 天約是 43.2 分鐘；若依請求計算，預算則是可失敗的請求數，不能直接換成停機分鐘。

Error budget 可以幫團隊決定發版節奏：餘額充足時維持正常發布；接近用完時，先處理可靠性問題，再評估非必要變更。最好把門檻寫進發版流程，讓討論有共同依據。

flowchart LR
  S[持續計算 SLI] --> B{Error budget 狀態}
  B -- 充足 --> F[正常發版與功能實驗]
  B -- 快耗盡 --> C[提高審查門檻<br/>減少高風險變更]
  B -- 已耗盡 --> Z[凍結非必要發版<br/>優先修可靠度]
  F --> S
  C --> S
  Z --> R[完成根因修正與驗證]
  R --> S

走一遍範例 — 登雲書店

接著拿上一篇那 5 個 user story 來實際走一次，每個故事挑對應的 SLI / SLO 填出來。

故事 3.1 · 瀏覽暢銷榜

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

故事 3.2 · 下單結帳

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

故事 3.3 · 同步閱讀進度

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

故事 3.4 · 每日批次上傳庫存

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

故事 3.5 · 查詢昨日銷售

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這裡的 error budget 政策也要依服務分級。結帳預算消耗太快時，先檢查近期變更與故障原因，必要時暫緩高風險發布；內部報表則可用不同門檻。門檻應看消耗速度、剩餘時間和業務影響，不是每個團隊都套 20% 或 50%。

這幾張表刻意給不同目標：結帳、暢銷榜和內部報表的中斷影響不一樣。數字只是案例假設，正式訂 SLO 還得看流量、使用者回饋與歷史故障資料，不能只按服務名稱分級。

目標訂下來後，再找最可能讓服務失敗的地方。結帳可能要處理資料庫與付款依賴，暢銷榜則可評估快取或降級回應；是否需要多區域，要看故障範圍、RTO／RPO 和成本。下一篇談服務邊界時，也會把這些目標帶進去。

幾個常見的 SLO 誤用

第一個，把 SLA 直接當 SLO 用。 供應商的 SLA 說明服務承諾與補償條件；你的 SLO 則應反映使用者體驗和業務需求。兩者量測範圍也可能不同，不能只把 SLA 數字複製過來。若你對客戶另有承諾，還要檢查整條服務鏈能否支撐，而不只看單一雲端產品的 SLA。

第二個，所有服務都訂 99.99%。 結帳和內部報表的停機影響不同，不一定需要相同目標。先按使用者影響與業務風險分級，再決定各服務要投入多少備援成本。

第三個，只量後端、不量前端。 API 的 P95 不能代表使用者等待的全部時間；DNS、連線、CDN 與前端繪製也可能讓頁面變慢。若 SLO 是對使用者體驗的承諾，就要選能涵蓋相應路徑的量測方式。

📝 考場提點

遇到 SLI / SLO 的題目，先在腦中分兩刀。第一刀分「這是在量什麼」：可用性、延遲、吞吐、正確性，題目敘述裡的關鍵字（「回應時間」對延遲、「成功率」對可用性、「錯帳/資料對不對」對正確性）會直接告訴你。第二刀判「這個目標合不合理」——對外金流服務該嚴、內部工具該鬆，看到「全部統一」或「內部報表也要五個 9」這類，就該懷疑目標訂得比需求高。時間上別在單一 SLO 數字上糾結太久，要練的是「重要的服務訂高、次要的訂低」這個取捨原則，而不是背特定百分比。

延伸閱讀

• SRE Book — Chapter 4 Service Level Objectives — 必讀章節。
• SRE Workbook — Implementing SLOs — 把概念落地的工作指南。
• Cloud Monitoring SLO Docs — 在 GCP 上設定 SLO 與 error budget alerting。
• The Art of SLOs by Google Customer Reliability Engineering — 工作坊教材。

下一步：SLO 訂好了，就能照著它把系統拆成微服務（Microservices），讓每個服務都揹著一個清楚的可靠度目標走。

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 4 填入你的 case study，邊寫邊內化。