PCA 雲端架構師之旅 04 — 定義 SLO 與 SLI
幾乎每份上雲提案的簡報，我都看過那行字：「系統可用性 99.99%」。漂亮，老闆愛看。但你回頭問做簡報的人「你怎麼量這個 99.99%」，十個有八個答不出來。連量都還沒量，數字是哪來的？通常是抄的。
這就是 SLO 跟 SLI 尷尬的地方——它是 PCA 考試的大戶，也是實務上最常被美化、最少被認真算過的數字。這一步要做的，是把上一篇的 user story 變成真的能盯著看的指標（SLI），訂出說得出口的目標（SLO），然後老老實實面對：這些數字到底要花多少錢養。
這是 PCA 雲端架構師之旅 的第四步。上一篇 03 · User Stories。
圖解：SLI 是速度表，告訴你服務實際表現；SLO 是團隊想守住的目標，沒達標的容許量就是 error budget；SLA 才是對客戶寫進合約、違反後可能要賠償的承諾，通常會比內部 SLO 寬鬆。
先把三個長很像的縮寫分清楚
SLI、SLO、SLA，三個都以 SL 開頭，考試最愛拿它們互換來騙你。先把意思釘死：
| 名詞 | 全名 | 意思 | 範例 |
|---|---|---|---|
| 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 分鐘不符 |
用一句話串起來：SLI 是你拿尺去量出來的數（指標本身），SLO 是你拿這把尺給自己訂的及格線（目標），SLA 是你跟客戶簽的、違約要賠錢的那條更鬆的底線。順序記成「量測 → 自我要求 → 對外合約」，三者一定是 SLI ≤ SLO 的嚴格度 ≤ SLA 的嚴格度。
實務上最常見的順序錯誤，是先簽了 SLA、回頭才想 SLO。我看過團隊跟大客戶談合約時，業務嘴一鬆答應了 99.95%，工程團隊事後才發現自己連 SLI 都沒在量，等於合約已經生效、但沒人知道現在到底跑在幾趴。這種就是典型的「承諾跑在量測前面」。
每多一個 9，價錢不是加法是乘法
把 SLO 換算成「一個月可以壞多久」，感覺會具體很多：
- 99.9%（三個 9）= 每月可以掛 43.2 分鐘
- 99.99%（四個 9）= 每月只剩 4.3 分鐘
- 99.999%（五個 9）= 每月 26 秒
26 秒是什麼概念？你的維運人員從手機收到告警、揉眼睛、打開筆電、連上 VPN，這時間就燒完了。五個 9 基本上代表「不能靠人反應，所有故障都得系統自動切換」，那是 multi-region active-active、自動 failover、把每一個單點都拔掉的工程量。
這裡有個我一直跟人講的觀念：從三個 9 爬到四個 9，成本不是多 10%，常常是翻倍甚至更多。 因為前面那段你靠加冗餘就能買到，越往後越是要把架構裡每一個還會壞的環節全部處理掉，邊際成本是指數往上跳的。所以「客戶要五個 9」這句話，真正該回的不是「好我做」，是「你的業務真的撐得起這個帳單嗎」。
📝 考場提點
PCA 很愛出「客戶要求 99.99%（甚至 99.999%），你建議什麼架構？」這種題。直覺會想選那個堆最多 region、最多冗餘的選項——通常就是陷阱。比較常是正解的方向是：先問他們現在實際的 SLI 是多少、先協商 error budget，而不是無腦把 multi-region active-active 疊上去。記住一條：當選項裡同時有「立刻上 multi-region」和「先量測現況再決定」，後者中的機率高很多。考試考的不是你敢不敢花錢，是你會不會先算帳。
SLI 要量什麼：四個面向
Google SRE 的建議是從這四類去想，一個 user story 通常挑其中 2 個來訂就夠：
- 可用性（Availability） — 成功的請求佔總請求多少。最常被拿來當門面的指標。
- 延遲（Latency） — P50 / P95 / P99 響應時間。注意是看分位數，不是看平均；平均會被少數又快又多的請求拉得很好看，把真正卡住的那批使用者藏起來。
- 吞吐（Throughput） — QPS、MBps，批次處理量。
- 正確性（Correctness） — 回傳的資料對不對。這個最容易被忘記，但對金流、帳務類服務反而是最致命的——服務「有回應」不代表「回對」。
延遲這欄我想多講一句，因為踩的人太多了。你如果用平均響應時間當 SLI，等於給自己一面哈哈鏡。一台機器一秒回 1000 個 50ms 的請求，再加 10 個卡了 8 秒的請求，算平均還是漂漂亮亮，但那 10 個人已經在罵了。所以延遲幾乎一律看 P95 / P99——盯的是「最慘的那一小撮使用者有多慘」。
上面剛講的四個面向，在 Cloud Monitoring 裡就長這樣：選取指標那排（可用性、延遲、其他）決定你「量什麼」，正好對上前面那張表。真正的暗坑是下半那組常被略過的「以要求為依據 vs 以時間範圍為依據」——前者是拿好請求數除以總請求數，後者是把時間切成一格一格、數有多少格達標。同樣訂 99.9%，兩種算法燒 error budget 的速度天差地遠，考題只要冒出這兩個詞，先認清它問的是哪一種再往下算。
訂 SLO 之前，先問自己幾個問題
每個要訂 SLO 的服務，我習慣先過一遍這幾關，過不了的就先別急著填數字：
- 怎麼量？ 從 load balancer 的 log 算？前端塞 RUM（real user monitoring，真實使用者監控）抓瀏覽器端的數字？還是看後端 trace？量的位置不同，數字差很多。
- 量到哪為止？ 是從使用者瀏覽器一路到後端 API 的全程，還是只算 API 進來到 DB 出去那一段？邊界沒講清楚，SLO 就是各說各話。
- 真的需要 99.9% 嗎？ 一個內部報表工具，99% 可能就夠了，沒人會因為它晚兩分鐘就丟單。
- 沒達標會怎樣？ 這題最關鍵。沒有後果的 SLO 等於沒有 SLO，你得先講好 error budget 燒完之後要做什麼。
- 誰是這個 SLO 的 owner？ 沒有掛名負責的人，這數字遲早變裝飾品。
那個「沒達標會怎樣」，就是 error budget（誤差預算）的用武之地。它的算法很簡單：1 減掉你的 SLO，剩下的就是你「被允許壞掉」的額度。99.9% 的 SLO，每月就有 0.1%、也就是那 43.2 分鐘可以花。
效能目標填進 99.9%，右邊預覽圖立刻冒出那條紅色目標線——剛才說的 error budget 不再是抽象的 0.1%，而是紅線到 100% 之間那條看得見、還能拖著調的縫。順手記一個最容易被忽略的細節：這裡的評估範圍是「滾動 28 天」，不是月曆月，代表預算每天都在重算、昨天那次當機會跟著統計整整 28 天才脫身，跟「每月一號歸零重來」的直覺完全不一樣。考題把 rolling window 跟 calendar window 混進選項時，就是在等你選錯。
重點是 error budget 不是拿來炫耀「我們這個月只用了 5%」的，它是個閥門：budget 還有餘額，就放手發版、衝功能；budget 快燒光，就該凍結非必要變更、回頭穩定系統。我見過最健康的團隊，是把這條規則寫進發版流程裡，讓「能不能上線」這件事由數字決定，而不是由當天嗓門最大的人決定。
走一遍範例 — 登雲書店
接著拿上一篇那 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%、暢銷榜只要 99.9%、內部銷售報表更鬆到月度 95%——這不是隨便填的，是有意識地把可靠度的錢花在刀口上。結帳掛一分鐘，是真金白銀的訂單流失加客訴；暢銷榜慢個幾秒，使用者頂多皺個眉。
而且這份表不是寫完就收進抽屜，它會直接決定下一步的架構長相。結帳要 99.99%，就逼著你往 regional 以上、甚至 multi-region 走；暢銷榜只要 99.9%，你大可以用 Cloud CDN 加上快取降級來撐，省下一大筆。下一篇切微服務的時候，每個服務的邊界跟規格，幾乎都能從這張 SLO 表反推出來。
幾個會在實務跟考場一起咬你的坑
第一個，把 SLA 直接當 SLO 用。 Cloud Run 的官方 SLA 是 99.95%——但這個數字的意思是「實際可用性低於 99.95% 時，Google 會依 SLA 退你 service credits」，它是 Google 對你的賠償門檻，不是你該對自己訂的目標。你的 SLO 應該比供應商的 SLA 更嚴一點，留一層安全邊際給自己，不然供應商剛好踩在合約線上沒違約，你對客戶的承諾卻已經破了。
第二個，所有服務一律訂 99.99%。 這是偷懶，也是過度設計。結帳跟內部報表的重要性差十萬八千里，給一樣的目標等於每個服務都沒有重點，還白白多花一堆錢去養那些根本不需要那麼可靠的東西。考試很愛在選項裡偷塞「全部統一 99.99%」，看到這種一刀切的答案，先警覺它八成是錯的。
第三個，只量後端、不量前端。 使用者體感的是瀏覽器到瀏覽器的完整時間——DNS、TLS、CDN、前端 render 全算在內。你只盯著 API 那段的 P95，數字會漂亮得不真實，然後你會很納悶為什麼後台一片綠、客訴卻沒停過。
📝 考場提點
遇到 SLI / SLO 的題目，先在腦中分兩刀。第一刀分「這是在量什麼」：可用性、延遲、吞吐、正確性，題目敘述裡的關鍵字（「回應時間」對延遲、「成功率」對可用性、「錯帳/資料對不對」對正確性）會直接告訴你。第二刀判「這個目標合不合理」——對外金流服務該嚴、內部工具該鬆，看到「全部統一」或「內部報表也要五個 9」這類，多半是來扣你分的。時間上別在單一 SLO 數字上糾結太久，PCA 考的是你抓不抓得到「重要的服務訂高、次要的訂低」這個取捨原則，不是背特定百分比。
延伸閱讀
- 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），讓每個服務都揹著一個清楚的可靠度目標走。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 4 填入你的 case study，邊寫邊內化。
相關文章
您可能也會對這些文章感興趣
PCA 雲端架構師之旅 04 — 定義 SLO 與 SLI
PCA 必考：如何從 user story 推導出 SLI（量測方式）與 SLO（目標值）。本文教你避免 99.999% 迷思，選出預算合理的可靠度目標。
PCA 雲端架構師之旅 01 — 讀懂案例情境
PCA 考試第一步就是讀懂 case study。本文帶你拆解業務目標、技術限制、利害關係人，避免沒看完題目就開始選 GCP 服務。
PCA 雲端架構師之旅 02 — 定義 User Personas
PCA 架構設計不是畫服務圖，而是從使用者開始。本文教你定義 User Persona，讓後續的 SLO、API、儲存選型都有依據。
