錯誤預算和SLO管理

1）為什麼SLO和錯誤預算

SLO（服務級別目標）是用戶感知的目標質量級別；SLI是可測量的度量；Error Budget-每個窗口的偏差入場（通常為30/90天）。
錯誤預算將可靠性從「抽象」轉換為可管理的資源：當預算迅速燃燒時-凍結菲奇和奇尼姆；當預算正常時-您可以加快發布速度。

2）SLI選擇： 什麼算是「好」

標準：「從用戶的角度來看是成功的」。

2.1經典SLI

可用性：成功請求的百分比（不包括客戶端取消的請求）。
'success=http_status ∈ {2xx，3xx，404}和沒有時間表'（如果是期望的語義，則404可能被認為是讀取API的成功）。
Latency：請求的百分比快於閾值（例如p95 ≤ 300 ms）。

`good_latency = duration_ms ≤ 300`.

Freshness/Staleness：「數據不超過X分鐘」（緩存、目錄、系數）。
質量：結果正確（通過業務驗證器/後端不變量）。

2.2邊界和段

SLI必須從重要的部分中考慮：「route」，「tenant/brand」，「region/jurisdiction」，「payment_provider」。因此，您不會「侵蝕」整個系統中單個關鍵手柄的故障。

3）公式和預算

3.1基於Request（最好用於API）

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3.2個基於時間的（用於後臺服務/流媒體）

SLO_uptime = good_minutes / total_minutes

3.3目標示例

API通用： 99。30天內可用性的9％ →預算=0。1%.

關鍵支付筆： 99。95%;目錄/搜索：99。5%.

潛伏期：p95 ≤ 300毫秒對'/v1/payments'，p99 ≤ 800毫秒。

4）SLI指導

4.1項原則

Logi/Traces →帶有顯式桶的RED （Rate/Errors/Duration）度量標準。
請務必提供「tenant」、「region」、「route_class」（沒有PII）。
考慮兩個指標：「成功」和「一切」，對於後坐力-「快速」和「一切」。

4.2 Prometheus示例（5m的價格）

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5） Alerta按燃燒率計算（多窗口、多燃燒）

5.1個想法

我們正在研究預算相對於目標的燃燒速度。如果在短窗口和長窗口上速度很高-信號。

5.2閾值配置文件（適用於SLO 99.9%)

分頁：burn rate ≥ 14。4 × （1小時預算的10%，6小時預算的5%）。
Tiket：燃燒率≥ 6 ×（6小時2%，24小時1%）。

5.3規則示例（Prometheus，pseudo）

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

同樣，tiket在6h/24 h。

6）預算辦公室： 程序

6.1個發布門戶

如果預算余額為<25％，趨勢為負值-fici上的「凍結代碼」，則SRE/可持續性的優先級。

金絲雀發行版必須具有單獨的SLO剪輯（'部署。environment="canary"`).

6.2 beclog優先級

按燃燒速度和收入影響比例分配團隊容量。

用指標證明技術債務是合理的： 「fix X將使燃燒率降低Y％。」

6.3事後事件

每個事件都是RCA和「無法回滾的假人」（動作），控制權「是否已返回SLO」。

7） SLO作為代碼

7.1 SLO清單（YAML）示例)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7.2規則生成

使用生成器（slo-generator, pyrra, sloth）自動生成規則、行車記錄和報告。

8）SLO降解和保護

Load shedder：在高峰時給出沒有「昂貴」依賴性的快速答案。

Cache & stale: `stale-while-revalidate` для read.

Rate/Concurrency限制：保護後端；重要路線是優先級。
電路/時間表：快速時間表和「倒退」分支。
功能閃光燈：一鍵關閉重型幻燈片。

9） SLO的可觀察性

Dashbords：SLO actual vs target，預算余額，burn rate，路線/提供商捐款。
相關：從SLO的「漏洞」→ →特定的跟蹤→ 邏輯/profile。
報告：每周-趨勢，預算消費，退化的最高原因。

10）反模式

一個「全球」SLO適用於所有→掩蓋了問題。分段。
«99.99%全部"不考慮成本和現實。從用戶體驗中選擇目標。
根據CPU/heap代替burn rate/SLO。
忽略破壞UX的4 x/長重復。
不透明窗口（滾動vs日歷）-比較「蘋果與橙子」。

11） iGaming/財務細節

貨幣路徑（存款/結算）：單獨的SLO高於總體水平（例如，99。95%的可用性；p95 ≤ 250毫秒）。
PSP/KYC提供商：每個提供商+Alerta的SLO對燃燒的貢獻；自動路由切換（智能路由）。
司法管轄區/特南特：SLO和「區域/司法/品牌」預算，以使本地問題不會「淹沒」全球度量標準。
負責任的遊戲：SLO應用限制/自我體驗（compliance formulation）的時間。
審計/監管：保存SLO和事件報告；內部審計的透明度。

12）準備就緒支票清單

• 由SLI （可用性/latency/quality/freshness）和路段（route/tenant/region）定義。
• 目標（SLO）是現實的，與業務一致；有30/90天的滾動窗口。
• Alerta的燃燒率與多窗口（分頁/滴答聲）。
• SLO作為代碼（規則/dashbord生成器）；預算報告。
• 釋放門與預算余額掛鉤；金絲雀切片。
• 已實施並測試了降解機制（shedder、cache stale、circuit、limits）。
• 指標↔跟蹤的相關性（exemplars）,清晰的運行手冊。
• 財務/司法途徑-單獨的SLO/Alertes；PSP/KYC分類。
• 定期復古事件和基於燃燒的可靠性投資。

13) TL;DR

通過用戶價值定義SLI,設置逼真的SLO,並通過多窗口通過Error Budget和burn rate進行控制。按計劃啟用SLO代碼、發布門和降級。按路線/特南特/地區細分；對於金錢的路徑，保持更嚴格的目標和單獨的差。