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，这意味着在最热的时间内收入更高，事件更少。