SLO, SLA e monitoramento de confiabilidade

(Secção Tecnologia e Infraestrutura)

Resumo curto

O SLO é um objetivo interno de qualidade, o SLA é um compromisso externo com o cliente, o SLI - como medimos a qualidade. Em iGaming, os principais SLI são disponibilidade de API e oplatação, p95/p99 laticínios de rotas críticas, Time-to-Wallet (TTW), conversão de pagamentos, execução de jogos e métricas de filas. O gerenciamento de confiança é baseado em um orçamento de erros, multi-burn alerts, lançamentos de gate claros e dashboards visualizados com anotações.

1) Termos e diferenças

O SLI (Service Level Indicator) é um indicador medível (por exemplo, proporção de pedidos bem-sucedidos por janela de tempo).
SLO (Service Level Objectiva) - Destino SLI (por exemplo, "disponibilidade 99. 9% em 30 dias").
SLA (Service Level Agreement) - contrato/compromisso com compensações; baseado em SLO real, mas inclui reservas legais e janelas de exceção (planned maintenance, força maior).

Regra: Primeiro estabilize o SLI/SLO dentro, e só depois instale o SLA para fora.

2) Esqueleto SLI para iGaming

TexSLO

Availability: 2xx/3xx com sucesso/todas as solicitações.
Latency: p95/p99 em rotas-chave ('/deposit ', '/bet', '/game/init ').
Errors: 5xx/temporizadores.
Saturation/Queues: atraso nas filas de pagamento/transação.

SLI de negócios

Payment conversion: `success/attempt`.
TTW p95: Tempo desde o pedido de retirada até a inscrição.
Game start sucess: sessões de jogos, inicialização do provedor.
KYC/AML flow sucess: conclusão do caminho com sucesso.

3) Orçamento de erros: como contar

Error Budget = 1 − SLO.
Exemplo: SLO de disponibilidade 99. 9 %/30d ⇒ orçamento de erros = 0. 1% do tempo ≈ 43m2 na janela de 30 dias.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

O SLO é considerado em uma janela deslizante (30/7/1 dia) e visível em dashboards.

• Orçamento rápido «combustão» de lançamentos freeze, estopim de canário, trabalhando com estabilidade.
• O estoque de orçamento permite alterações mais frequentes (controladas).

4) Exemplos de SLO para fluxos-chave

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (saída) ≤ 3 min/24h

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job sucess ≥ 99 %/7d, liga <5 min (janelas de pico separadamente).

5) Medição: fórmulas e PromQL (ideias)

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 alert (multi-window)

A ideia é comparar a taxa atual de vazão do orçamento com a taxa permitida.

• Fast burn: 14 x orçamento em 1 hora → em 5 a 15 minutos.
• Slow burn: 6 x orçamento para 24 horas → tíquete para analisar a causa.

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) Dashboards «SLO Card» e operacionalização

• Cartões de serviço: Availability, p95, Erro-rate, Burn-rate, restante do Erro Budet.
• Filtros: «env», «region», «tenant», «version».
• Anotações de lançamento: Git SHA, tipo (canary/blue-green), hora de mudança.

• Comparação de stable vs canary.
• Corte por PSP/provedores de jogos.
• Vai para exemplars (trace _ id) e logs relacionados.
• Queue lag e saturação (métricas USE).

8) Processos SLO: gates, freeze, escaladas

Gates em CD: promoção canarinho só é permitido quando o proxy SLO (availability, p95, 1962).
Freeze: com fast-burn ou saldo de orçamento zero - parar lançamentos antes da recuperação.
Escalonamento: matriz SEC (SEV1 pagamentos/depósitos, SEV2 jogos, SEV3 bacofis).
RCA: análise sem acusações, atualização de testes/limites/fichiflags.

9) Data/ML-SLO (para recomendadores/LLM)

Latency: p95 do modelo ≤ 300 ms (ou tocens/s ≥ N).
Quality proxy: proporção de respostas validas/baixa toxicidade, share of helpful.
Freshness: idade das fichas/dados ≤ X horas.
Vale por 1k events: gastos no orçamento.
Os gates SLO são integrados em lançamentos de modelos (A/B/rollout canário).

10) Construção de SLA baseado em SLO

Selecione o SLO conservador como base do SLA.
Defina exceções (trabalho programado, provedores de dependentes externos, regulamento de incidentes).
Insira compensações por níveis de infração (crédito/desconto), mecanismos de relatórios e verificações.

11) Erros frequentes e anti-pattern

Não há SLO, só «uptime 100%» é irrealista, desmotiva e esconde riscos.
Alertas de «cada métrica» em vez de burn-rate - alert-fetig e ignorado.
Mistura de PII em métricas/logs para SLO - riscos de complacência.
A cardinalidade explode como 'user _ id/sessions _ id'.
Sem anotações de lançamento, é difícil associar a degradação às alterações.
Orçamento de erro opaco - a equipa não entende quando «pode» correr riscos.
A SLO não está ligada ao negócio - a técnica verde, a receita vermelha.

12) Folha de cheque de implementação

1. Aprove o SLI básico (Availability, p95/p99, Erro-rate, TTW, Conversion).
2. Defina o SLO nas janelas de 30/7/1 dia e conte o Erro Budet.
3. Adicione recording rulas e burn-rate alerts (fast/slow).
4. Construa um mapa SLO com anotações de lançamento e comparações canary/stable.
5. Inclua os gates no CD, sem SLO-ok, sem promoção.
6. Digite os procedimentos freeze e a matriz de escalações.
7. Vincule o SLO às métricas de negócios (1962, TTW) e rotas de pagamento.
8. Para o Data/ML, defina latency/quality/freshness-SLO.
9. RCA regular e revisão SLO/liminares (trimestral).
10. Confira o SLA apenas após a estabilização do SLO.

13) Exemplos de metas «prontas» (como início)

API geral: Availability 99. 9 %/30d; p95 ≤ 250 ms/30d; Error-rate ≤ 0. 3 %/30d.
Payments: Conversion ≥ baseline − 0. 3 %/24h; TTW p95 ≤ 3 min/24h.
Games init: Success ≥ 99. 5 %/7d; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; liga ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness ≤ 6h.

Resumo

A abordagem SLO/SLA transforma a confiabilidade de «melhor do que ontem» em disciplina medida: SLI transparente, orçamento compreensível de erros, alertas de velocidade de combustão, dashboards compreensíveis e gates de qualidade integrados. Este circuito dá à plataforma iGaming um p95/p99 previsível, pagamentos estáveis e TTW, o que significa melhor receita e menos incidentes nas horas mais quentes.