PCA 架構之旅 04 — 定義 SLO 與 SLI
SLO 與 SLI 是 PCA 考試的大戶，也是實務上最容易被美化的數字。幾乎每份提案簡報都寫「99.99% 可用性」，但多數團隊連 SLI 是什麼都還沒定。
這一步要做的，就是把上一篇的 user story 變成可監控的指標（SLI）跟承諾的目標（SLO），然後老實面對它們到底要花多少錢。
這是 PCA 架構之旅 的第四步。上一篇 03 · User Stories。
為什麼這一步重要
在 PCA case study 題目中怎麼出現
PCA 題目很愛出「客戶要求 99.99%，你會建議什麼架構？」這類選項。正確答案常常是「先問他們現在的 SLI 是多少」或「先協商 error budget」，而不是直接堆 multi-region active-active 上去。
另一類題目會給你一組「SLO：P99 < 300ms」，再問你要用什麼監控工具、alert policy 怎麼設。沒搞懂 SLI 跟 SLO 差在哪就會答錯。
考生常見錯誤
- 混淆 SLA、SLO、SLI。
- 把所有 SLO 設一樣：所有故事都給 99.99% 等於都沒重點。
- 忘記 error budget（誤差預算）：SLO 不是拿來炫耀的數字，是拿來決定發佈節奏的工具。
核心概念
| 名詞 | 全名 | 意思 | 範例 |
|---|---|---|---|
| SLI | Service Level Indicator | 實際量測的指標 | P95 首頁響應時間 |
| SLO | Service Level Objective | 對自己的承諾 | P95 < 1.5 秒、成功率 > 99.9% |
| SLA | Service Level Agreement | 對客戶的合約 | 違反賠 X 元、通常寬鬆於 SLO |
| Error Budget | 誤差預算 | (1 - SLO) 能容許的失敗量 | 99.9% 每月允許 43.2 分鐘不符 |
99.9% 的月度誤差預算 = 43.2 分鐘；99.99% = 4.3 分鐘；99.999% = 26 秒。每多一個 9，成本往往就是指數級往上跳。
SLI 的四大面向（官方建議）
- 可用性（Availability） — 成功請求佔比。
- 延遲（Latency） — P50 / P95 / P99 響應時間。
- 吞吐（Throughput） — QPS、MBps。
- 正確性（Correctness） — 回傳資料是否正確。
思考框架
每個 user story 至少選 2 個 SLI，依序問：
- 怎麼量測？ 用 load balancer log？用前端 RUM（real user monitoring）？用後端 trace？
- 量測邊界在哪？ 從使用者瀏覽器到後端 API 全程？還是只算 API 到 DB？
- 99.9% 真的有必要嗎？ 內部報表工具 99% 可能就夠。
- 達不到 SLO 會怎樣？ 沒有後果的 SLO 等於沒 SLO，要定義 error budget 的使用規則。
- 誰來擁有這個 SLO？ 必須有 owner，不然沒人會為它負責。
走一遍範例 — 登雲書店
根據前一篇的 5 個 user story，定義對應 SLI / SLO：
故事 3.1 · 瀏覽暢銷榜
| 項目 | 值 |
|---|---|
| SLI 1（延遲） | Load balancer 量測的 P95 首頁回應時間 |
| SLO 1 | P95 < 1.5 秒，月度達成率 ≥ 99.5% |
| SLI 2（可用性） | 2xx/3xx 回應 / 總請求 |
| SLO 2 | 可用性 ≥ 99.9%（月度） |
| Error Budget 政策 | 若月度 budget 用超過 50%，暫停新功能發佈 |
故事 3.2 · 下單結帳
| 項目 | 值 |
|---|---|
| SLI 1（可用性） | /api/checkout 成功率 |
| SLO 1 | 99.99%（月度 4.3 分鐘以內不可用） |
| SLI 2（延遲） | P95 結帳 API 端到端延遲 |
| SLO 2 | P95 < 6 秒 |
| SLI 3（正確性） | 每筆訂單金流狀態一致性 |
| SLO 3 | 每月金流錯帳件數 = 0 |
故事 3.3 · 同步閱讀進度
| 項目 | 值 |
|---|---|
| SLI 1（延遲） | 裝置切換後進度同步完成時間 |
| SLO 1 | P95 < 10 秒 |
| SLI 2（正確性） | 進度衝突解決符合 last-write-wins |
| SLO 2 | 錯誤進度回報率 < 0.1% |
故事 3.4 · 每日批次上傳庫存
| 項目 | 值 |
|---|---|
| SLI（吞吐） | 單批 200MB 處理時間 |
| SLO | 99% 的批次在 30 分鐘內完成 |
| SLI（正確性） | 批次失敗 email 送達率 |
| SLO | 100% 失敗案件 5 分鐘內通知 |
故事 3.5 · 查詢昨日銷售
| 項目 | 值 |
|---|---|
| SLI（資料新鮮度） | 前一日資料於 6am 前到位比率 |
| SLO | 月度達成率 ≥ 95% |
| SLI（查詢延遲） | 標準報表查詢 P90 |
| SLO | P90 < 30 秒 |
整體 error budget 政策：結帳相關 SLO 若燒超過 20% budget，必須停止非必要變更；其他服務燒超過 50% 才凍結。
這份表格會直接決定下一步怎麼切微服務、怎麼選服務。例如結帳要 99.99%，就會逼你選 regional 以上、甚至 multi-region；而暢銷榜只要 99.9%，你就可以用 Cloud CDN 加上快取降級來撐。
常見陷阱
- 把 SLA 當 SLO 訂：Cloud Run 的 SLA 是 99.95%，代表只有當實際可用性低於 99.95% 時，Google 才會依 SLA 提供 service credits 補償；你的 SLO 該比它嚴一些，留安全邊際。
- 所有服務一律 99.99%：結帳跟內部報表不需要一樣可靠。考試會偷放這種陷阱，選項寫「全部 99.99%」通常是錯的。
- 只量後端不量前端：使用者感受到的是瀏覽器到瀏覽器的時間，你只量 API P95，就會低估實際體驗。
延伸閱讀
- 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 Engineering — 工作坊教材。
下一步：有了 SLO，就可以開始把系統拆成微服務（Microservices），每個服務有清楚的 SLO 目標。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 4 填入你的 case study，邊寫邊內化。