SLO、SLA和可靠性監控

（部分： 技術和基礎設施）

簡短摘要

SLO是內部質量目標，SLA是對客戶的外部義務，SLI是我們如何衡量質量的。在iGaming中，關鍵SLI：API和支付可用性，p95/p99關鍵路由潛伏期，時間到錢包（TTW），付款轉換，遊戲啟動以及隊列度量。可靠性管理圍繞錯誤預算，多燃燒的警報，清晰的發布門以及帶有註釋的視覺儀表板進行構建。

1）術語和區別

SLI（服務級別指示器）-可測量的指示器（例如,每個時間窗口成功查詢的比例）。
SLO（服務級別目標）是SLI的目標值（如上所述，"可用性99。在30天內達到9%"）。
SLA（服務級別協議）-合同/賠償義務；基於真實的SLO，但包括法律保留和例外窗口（計劃維護，不可抗力）。

規則：首先在內部穩定SLI/SLO，然後才將SLA固定在外部。

2）適用於iGaming的SLI框架

TexSLO

可用性：成功的2xx/3xx/所有請求。
Latency：p95/p99關於關鍵路由器（'/deposit'，'/bet'，'/game/init'）。
錯誤：5 x/taymauts的份額。
Aturation/Queues：延遲付款/交易隊列。

Business SLI

Payment conversion: `success/attempt`.

TTW p95：從撤回請求到註冊的時間。
Game start success：遊戲會話,提供程序初始化。
KYC/AML流成功：成功完成路徑。

3）錯誤預算： 如何計算

Error Budget = 1 − SLO.

示例：SLO可用99。9％/30 d ⇒錯誤預算=0。1%的時間≈ 30天窗口中的43分鐘12秒。

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO在滑動窗口（30/7/1天）上計數，在行車記錄儀上可見。

• 快速的「燒毀」預算→ freeze版本，金絲雀停止，正在努力穩定。
• 預算儲備→允許更頻繁的更改（可控制）。

4）關鍵線程的SLO示例

Payments API:

Availability ≥ 99.9%/30d

Latency p95 `/deposit` ≤ 250 ms / 30д

Payment conversion ≥ baseline − 0.3%/24小時

TTW p95（撤出）≤ 3分鐘/24小時

• Game init success ≥ 99.5% / 7д p95 game init ≤ 600 ms / 7д

• Job success ≥ 99%/7d, lag <5 min（峰值窗口分開）。

5）測量： 公式和PromQL（想法）

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6）Burn-rate alerta（多窗口）

想法：比較當前預算支出的速度與允許的速度。

SLO 99的示例。9%:

快速燃燒：1小時14 ×預算→ 5-15分鐘後佩奇。
慢燒傷：24小時預算6 × →滴答作響，分析原因。

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7）Dashbords 「SLO卡」和操作員

• 服務卡：可用性，p95，Error-rate，Burn-rate，Error Budget的其余部分。
• 過濾器：「env」，「region」，「tenant」，「version」。
• 發行註釋：Git SHA，類型（金絲雀/藍綠色），開關時間。

Drill-down:

穩定與金絲雀的比較。
PSP/遊戲提供商削減。
移至exemplars （trace_id）和相關登錄。
Queue lag和saturation（USE度量）。

8） SLO流程： 網關、凍結、升級

CD中的Gates：僅在執行SLO代理時（可用性，p95，conv）才允許金絲雀促銷。
Freeze：使用快速燃燒或零預算余額-停止發行直到恢復。
升級：SEV矩陣（SEV1付款/存款，SEV2遊戲，SEV3後綴）。
RCA：無收費分析，測試/限制/ficheflags更新。

9） Data/ML-SLO （適用於推薦者/LLM）

Latency： p95模型響應≤ 300 ms（或tokens/s ≥ N）。
Quality proxy：有效反應/低毒性,分享幫助劑的比例。
Freshness： fich/Data的年齡≤ X小時。
1k事件成本：預算支出。
SLO門集成到模型發行版中（A/B/金絲雀卷軸）。

10）基於SLO的SLA構造

選擇保守的SLO作為SLA的基礎。
定義例外（計劃工作、外部從屬提供商、事件法規）。
輸入違規級別的補償（信用/折扣）、報告和驗證機制。

11）頻繁的錯誤和反模式

沒有SLO，只有「uptime 100%」-不切實際，令人沮喪並隱藏風險。
根據「每個度量標準」而不是burn-rate，Alerta是Alert-fatig和忽略。
SLO的度量/邏輯中PII的混合是合規風險。
基數爆炸：「user_id/session_id」作為標簽。
沒有發布註釋-很難將降級與更改相關聯。
不透明的錯誤預算-團隊不明白什麼時候「可以」冒險。
SLO與業務無關-技術指標為「綠色」，收入為「紅色」。

12）實施支票

1.批準基本SLI（可用性,p95/p99, Error-rate, TTW, Conversion）。
2.在30/7/1天的窗口中設置SLO並計入Error Budget。
3.添加記錄規則和burn-rate alerta（快速/慢）。
4.構建帶有發行註釋和canary/stable比較的SLO卡。
5.在CD中打開門：沒有SLO-ok-沒有促銷。
6.輸入freeze過程和SEV升級矩陣。
7.將SLO與業務指標（conv、TTW）和支付路線連接起來。
8.對於Data/ML,定義latency/quality/freshness-SLO。
9.定期進行RCA並修訂SLO/閾值（季度）。
10.僅在SLO穩定後才記錄SLA。

13）「現成」目標的示例（作為開始）

API通用：可用性99.9%/30d；p95 ≤ 250 ms/30d；Error-rate ≤ 0.3%/30d。
Payments: Conversion ≥ baseline − 0.3%/24小時；TTW p 95 ≤ 3分鐘/24小時。
Games init: Success ≥ 99.5%/7d；p95 ≤ 600 ms/7d。
Backoffice jobs: Success ≥ 99%/7д;l ≤ ag 5分鐘/7 d。
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0.5%/7d, freshness ≤ 6小時。

結果

SLO/SLA方法將可靠性從「比昨天更好」轉變為可衡量的學科：透明的SLI，可理解的錯誤預算，燃燒速度的差異，可理解的行車記錄儀以及內置在質量門版本中的。這樣的回路使iGaming平臺具有可預測的p95/p99，穩定的支付和TTW，這意味著在最熱的時間內收入更高，事件更少。