SLO 從定義到 Prometheus 落地需要多層 rule。一個 SLO 對應 4 組 time window 的 recording rule（計算各窗口的 burn rate），再對應 fast burn 和 slow burn 兩組 alerting rule。手動維護這些 rule 容易出錯：window 參數不一致、新增 SLO 忘記補 alert、修改 SLI expression 只改了部分 rule。

Sloth 的責任是把這個過程自動化。輸入一份 SLO YAML，產出一組完整的 Prometheus recording + alerting rules，讓 SLO 維護回到宣告式：改 YAML、重新生成、載入 Prometheus。

SLO YAML 設計

Sloth YAML 的核心結構是 version → service → slos[]。每個 SLO 定義三件事：目標數字（objective）、量測方式（SLI）、告警等級（alerting）。

 1version: prometheus/v1
 2service: checkout-api
 3slos:
 4  - name: availability
 5    objective: 99.9
 6    description: "checkout API 的請求成功率"
 7    sli:
 8      events:
 9        error_query: sum(rate(http_requests_total{service="checkout",code=~"5.."}[{{.window}}]))
10        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
11    alerting:
12      name: CheckoutAvailability
13      page_alert:
14        labels:
15          severity: critical
16      ticket_alert:
17        labels:
18          severity: warning

SLI 有兩種類型。events-based SLI 用 error/total ratio 定義，Sloth 自動把 {{.window}} 參數代入各 recording rule 的 range vector。raw SLI 直接寫 PromQL expression 算 error ratio，適合非 request-based 的 SLO（如 data freshness、replication lag）。

raw SLI 範例 — data freshness：

1  - name: data-freshness
2    objective: 99.5
3    sli:
4      raw:
5        error_ratio_query: |
6          1 - clamp_max(
7            replication_lag_seconds{service="checkout-db"} / 60,
8            1
9          )

objective 數字的來源是 6.6 SLO 政策 — 先從使用者旅程定義服務承諾，再把承諾轉成 objective。Sloth 不負責決定 objective 該是多少，只負責把 objective 轉成可執行的 Prometheus rule。

alerting 分 page（嚴重，觸發即時通知）和 ticket（一般，產生工單）。兩者的 burn rate 門檻不同：page 用 fast burn window，ticket 用 slow burn window。label 設計跟 Alertmanager routing 對齊 — severity: critical 走 PagerDuty / Slack alert channel，severity: warning 走 ticket system（Jira / Linear）。

Multi-window Multi-burn-rate Alert

Sloth 預設產生 Google SRE 推薦的 4-window alert 結構。每個 SLO 生成以下 recording rules 和 alerting rules。

fast burn alert 回答「error budget 是否正在被快速吃掉」。當 5 分鐘窗口的 burn rate 超過 14.4 倍（代表如果持續下去，1 小時會消耗完整個月的 budget），觸發 page。這個門檻的設計邏輯是：越短的窗口允許越高的 burn rate 容忍，因為短窗口的 false positive 率較高，需要搭配較長窗口的確認。

slow burn alert 回答「error budget 是否在不被注意的情況下被緩慢消耗」。6 小時窗口的 burn rate 超過 1 倍（代表月底會剛好用完 budget），觸發 ticket。slow burn 常被忽略，但它是高變更頻率服務最常見的可靠性退化模式 — 每次小回歸都不夠大到觸發 fast burn，累積到月底才發現 budget 已透支。

burn rate alert 跟 6.6 SLO error budget 政策 直接對應：fast burn → 凍結變更；slow burn → 提高驗證門檻；budget 健康 → 正常發版。

Sloth 產出的 recording rule 範例（5m window）：

1- record: slo:sli_error:ratio_rate5m
2  expr: |
3    sum(rate(http_requests_total{service="checkout",code=~"5.."}[5m]))
4    /
5    sum(rate(http_requests_total{service="checkout"}[5m]))
6  labels:
7    sloth_service: checkout-api
8    sloth_slo: availability

對應的 alerting rule（fast burn）：

1- alert: CheckoutAvailabilityFastBurn
2  expr: |
3    slo:sli_error:ratio_rate5m{sloth_slo="availability"} > (14.4 * 0.001)
4    and
5    slo:sli_error:ratio_rate1h{sloth_slo="availability"} > (14.4 * 0.001)
6  labels:
7    severity: critical

fast burn alert 要求 5m 和 1h 兩個窗口同時超過門檻，短窗口防止 spike false positive、長窗口確認趨勢持續。

實作流程

CLI 生成

1sloth generate -i slo.yaml -o rules.yaml
2sloth validate -i slo.yaml

generate 產出的 rules.yaml 包含所有 recording rules 和 alerting rules，直接放入 Prometheus 的 rule_files 載入。validate 在 CI 中先行檢查 YAML 格式與 SLI expression 語法。

K8s Operator mode

Sloth 提供 K8s Operator，用 PrometheusServiceLevel CRD 定義 SLO。Operator 自動 reconcile，把 CRD 轉成 Prometheus rules 並同步到 Prometheus Operator 的 PrometheusRule 資源。

Operator mode 適合 K8s-native 環境：SLO 定義跟 service deployment 放在同一個 GitOps repo，變更 SLO 跟變更服務走同一套 PR review + CI 流程。

CI / GitOps 整合

在 CI pipeline 中跑 sloth validate 驗證 YAML，再跑 sloth generate 產出 rules，commit 進 GitOps repo。Prometheus 透過 config reload 或 Operator reconcile 載入新 rules。這條流程讓 SLO 變更有版本歷史、有 review、有 rollback 能力。

邊界與陷阱

Sloth 只支援 Prometheus 作為後端。若觀測平台是 Datadog、New Relic、Honeycomb 或 Grafana Cloud，需要各平台自己的 SLO 功能或 Nobl9 的 multi-source 整合。

SLI expression 錯誤是最常見的問題。分母為零（service 沒有流量）會產生 NaN，cascading 到所有 recording rule。label 不匹配（service label 拼錯）會產生空 series，alert 永遠不觸發。sloth validate 檢查語法但不檢查 Prometheus 中是否真的有對應 series — 上線後需要用 Prometheus query 確認 recording rule 產出非空結果。

SLO 數量增長會累積 recording rule 成本。每個 SLO 產生約 30 條 recording rule（4 windows × 多組 aggregation）。100 個 SLO 產生 3000 條 rule，Prometheus 的 rule evaluation 會消耗明顯的 CPU 和記憶體。定期監控 prometheus_rule_evaluation_duration_seconds 和 prometheus_rule_group_rules，在 rule 數量影響 evaluation latency 前調整。

升級路徑：Sloth YAML 跟 OpenSLO spec 部分相容。從 Sloth 移到 Nobl9 時，SLO 定義的語意可以保留，SLI expression 需要改寫成 Nobl9 的 data source query。這條路徑適合從 Prometheus-only 環境逐步擴展到 multi-source SLO governance。

整合路由

• 上游：6.6 SLO 與 Error Budget 政策 — SLO 定義與 objective 來源
• 下游：6.8 Release Gate — burn rate alert 觸發凍結
• 平行：Nobl9（SaaS multi-source）、Pyrra（K8s-native + UI）
• 案例回寫：Google G1（error budget policy 原典）、Honeycomb HC1（burn rate 驅動可靠性操作）

SLO 與 performance budget 的責任是讓容量決策有「可衡量的目標 + 可審查的代價」。沒有 SLO 時、容量規劃容易變「越大越好」、沒邊界；有 SLO + budget 之後、所有決策都能回答「是否在 budget 內」、「超出 budget 該怎麼辦」。

跟 06.6 SLO 與 Error Budget 的關係：06.6 處理「可靠性 SLO」（用 error budget 凍結 release）、9.12 處理「效能 SLO」（用 performance budget 約束容量）。兩者用同一套方法論、目標不同。讀者可以把本章當作 06.6 的 效能對應 章節。

本章覆蓋 SLI/SLO/SLA 分層、latency budget 分解、performance budget vs error budget、SLO 等級的成本含義、多 SLO 對齊、SLO drift 維護。讀完後讀者能設計一套完整的 SLO + budget 系統、把容量決策跟 SLO 對接。

SLI / SLO / SLA 三層分清

三個名詞常被混用、實際是三個不同層的概念。

SLI（Service Level Indicator）：客觀量測值。p99 latency、availability、throughput、error rate 都是 SLI。 SLO（Service Level Objective）：團隊內部目標。「99.95% 用戶請求 < 500ms」這類具體承諾。 SLA（Service Level Agreement）：對外合約承諾。達不到要退款、違約金、信用補償。

SLO 比 SLA 嚴 — 給內部 buffer。SLA 訂 99.9%、SLO 訂 99.95% — 萬一 SLO 沒達到、SLA 還沒違約、有反應時間。

容量規劃針對 SLO、不是 SLA：SLA 是「最低不能跌破」、SLO 才是「日常目標」。用 SLA 做容量規劃會經常 violate SLA、給用戶 / 客戶不好體驗。

詳見 SLI / SLO 卡片。

Latency budget 分解

Latency budget 是把 SLO 翻成可分解工程目標的關鍵工具。

從 end-to-end latency 開始：

• 用戶感受到的 latency：DNS resolution + TLS handshake + CDN + load balancer + application + cache + DB + serialization + network back
• SLO 訂在 user-perceived：例如「p99 end-to-end < 500ms」

拆到每個 stage 的 budget：

• DNS：5ms（assume cached）
• TLS handshake：50ms（first request）
• CDN：20ms
• Load balancer：5ms
• Application：100ms
• Cache lookup：5ms（hit）/ 100ms（miss）
• DB query：30ms
• Serialization：10ms
• Network return：15ms
• 總和：240ms（cache hit）/ 335ms（miss）

每個 stage 的 budget 必須 跟 SLO 對齊：

• 每個 stage 加總 = SLO 上限
• 任何 stage 超 budget → 該 stage 必須改善（不是其他 stage 來補）
• 每個 stage 必須有 current measurement — 不能訂了沒量

Cross-region call 自帶不可壓縮 latency：

• 同 AZ：< 1ms
• 跨 AZ：1-2ms
• 跨 region 同 continent：20-30ms
• 跨 continent：100-200ms
• SLO 訂 50ms 但服務要跨 region 設計 → 不可能達成

任何新增 stage 都會吃 budget：middleware、sidecar、interceptor、API gateway 都會增加 latency。設計時要明確認知這層代價。

對應案例：Coinbase sub-ms — sub-millisecond 反推所有架構選擇（Cluster Placement Group 壓網路、z1d 壓 CPU、RAFT 壓共識）；Tubi p99 < 10ms — ML inference 多 stage 各自分配 budget。

Performance budget

Performance budget 跟 error budget 是 姊妹概念 — 用同一套方法論處理可靠性 vs 效能。

Error budget（06.6）：

• 每月有允許的 unavailability 額度
• 例如 SLO 99.95% → error budget = 0.05% × 30 days = 21.6 分鐘 / 月
• 額度用完 → freeze new release、focus on reliability

Performance budget（本章）：

• 每月有允許的 latency 退化額度
• 例如「p99 允許比 baseline 高 10ms 連續 X 分鐘」、用 burn rate alert
• 額度用完 → freeze new feature release、focus on perf

兩個 budget 並列、不衝突：

• 一個燒一個健康 → 部分 freeze（freeze 對應的那條）
• 兩個都健康 → 全速 release
• 兩個都燒 → 全面 freeze、deep review

Burn rate alert 比 threshold alert 好：

• threshold：p99 > 500ms 就 alert → false positive 多
• burn rate：過去 1 小時 budget burn rate > 14.4x 就 alert（Google SRE 推薦）→ 對應「再這樣下去 budget 5 分鐘內燒光」

對應案例：Coinbase 延遲就是收入 — 沒 performance budget 等於沒 release control；FanDuel 多 SLO — 直播 vs 投注不同 budget。

SLO 等級的成本含義

不同 SLO 等級對應不同容量成本、選 SLO 就是選成本。

每多一個 9、容量成本指數成長：

• 99 → 99.9：成本 +30-50%
• 99.9 → 99.99：成本 +50-100%
• 99.99 → 99.999：成本 +200-500%

選 SLO 不是 marketing 決策、是工程經濟決策：選太高、燒錢；選太低、用戶不滿。要算 每個 9 對應的業務價值、是否值得對應的容量投資。

對應案例：Amazon Ads 99.999% — 廣告計費 1 分鐘斷線損失幾百萬美金、5 個 9 是真實營收邊界；Genesys 99.999% — B2B 客服 SaaS、客戶停線 = 客戶失去用戶信任、5 個 9 是合約義務。

多 SLO 對齊

同一系統不同工作負載可以有不同 SLO、按業務重要性分級。

設計原則：

• 按「業務重要性 × 用戶感知」分級
• 同一個 endpoint 不同情境可能有不同 SLO（例如登入 vs 結帳）
• 多 SLO 必須有 優先順序、衝突時知道犧牲哪個

範例：

衝突處理：當 capacity 不夠時、優先保 結帳 而非 推薦、即使技術上推薦比較好擴容。

對應案例：FanDuel 直播秒級 SLO vs 投注毫秒級 SLO、同一個 user 同一場 NFL Super Bowl、兩個服務必須分開部署、各自 SLO。

SLO 演進：baseline drift

SLO 不是訂了就不動 — 業務變化要重新校準。

SLO drift 來源：

• Structural surge：COVID 類外部衝擊讓 baseline 永久上移
• Product change：新 feature 改變用戶 journey
• Architectural improvement：DB 換型、cache 加強、CDN 擴點
• User behavior：mobile share 上升、跨 region 比例變化

Drift 不是 anomaly、是 新常態。

Review 節奏：

• 每季 review SLO：拉過去 90 天 SLI 分布、看是否需要調整
• 重大產品改動立即 review
• Drift 確認後要更新：alert threshold、autoscaler trigger、performance budget 額度、容量規劃 baseline

對應案例：Zoom 30x COVID — 30 倍成長後 baseline 永久上移、SLO threshold 跟著重新校準、不能套用 COVID 前的標準。

SLO 跟容量規劃對接

回到本章開頭的論點 — SLO 是容量決策的目標。

容量公式：能撐多少 RPS @ SLO 條件。 規劃時用「SLO-constrained capacity」、不是「max capacity」：

• max capacity：絕對極限、進 cliff
• SLO-constrained capacity：知道在 SLO 條件下能撐多少
• 兩者差 30-50%（headroom）

9.4 saturation 找 knee 是技術指標、9.6 容量規劃用 SLO-constrained knee：

• saturation 在 utilization 80% 時開始
• 但 SLO 可能要求 utilization 60% 以下
• 容量規劃用 60% 而非 80%

跟 9.7 成本工程 對接：

• 每多一個 9 多花多少錢
• 業務需要這個 9 嗎
• 不需要的話降 SLO 省成本

SLO 跟 performance budget 一起用

最後的整合 — error budget + performance budget 一起治理 release 節奏。

Error budget 控制 變更節奏：

• error budget 健康 → release 可以快
• error budget 燒光 → freeze release

Performance budget 控制 容量決策：

• performance budget 健康 → 新 feature 可以引入 perf cost
• performance budget 燒光 → freeze new feature

兩個 budget 並列：

• 都健康 → 全速 release + 新 feature
• error 健康 + perf 燒 → release 但只接 perf-neutral 變更
• error 燒 + perf 健康 → 暫停 release、修可靠性
• 都燒 → 全面 freeze、deep review

對應 06.6 SLO 跟 06.8 release gate。

案例對照

下一步路由

• 上游：9.1 壓測理論（latency budget 反推）
• 上游：9.4 Saturation Discovery（SLO-constrained capacity）
• 跨模組：06.6 SLO 與 Error Budget 政策（可靠性 SLO）
• 跨模組：04.16 SLI / SLO 訊號（量測層）

既建知識卡片

• SLI / SLO
• Latency Budget
• Performance Budget
• SLO Baseline Drift
• Error Budget