Error Budgets e controle SLO

1) Por que SLO e orçamento de erros

O SLO (Service Level Objectiva) é uma meta de qualidade percebida pelo usuário; SLI - métrica a medir; Error Budet - permissão para desvios por janela (normalmente 30/90 dias).
O orçamento de erros transforma a confiabilidade de «abstração» em um recurso controlado: quando o orçamento é queimado rapidamente - congelamos os fiques e chinim; Quando o orçamento está saudável, é possível acelerar os lançamentos.

2) Escolha do SLI: o que considerar «bom»

Critério: «bem-sucedido do ponto de vista do usuário».

2. 1 SLI clássico

Availability: proporção de pedidos bem sucedidos (excluídos os cancelados pelo cliente).
'sucess = http _ status ∈ se é uma semântica esperada para o read API, se for uma semântica.
Latency: proporção de consultas mais rápida do que o limite (por exemplo, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «dados com menos de X minutos» (dinheiro, diretórios, coeficientes).
Quality: resultado correto (validadores de negócios/backend invariantes).

2. 2 Limites e segmentos

A SLI deve ser contada por cortes importantes: «rota», «tenant/brand», «region/jurisdicção», «payment _ provider». Então, você não vai «deslanchar» a falha de uma caneta crítica em todo o sistema.

3) Fórmulas e orçamento

3. 1 Request-based (preferencialmente para API)

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

3. 2 Time-based (para serviços de fundo/streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Exemplos de metas

API geral: 99. 9% de disponibilidade por 30 dias → orçamento = 0. 1%.
Canetas de pagamento críticas 99. 95%; diretório/pesquisa: 99. 5%.
Latência: p95 ≤ 300 ms em '/v1/payments ', p99 ≤ 800 ms.

4) Ferramentas SLI

4. 1 Princípios

Logs/trailers → métricas RED (Rate/Errors/Duration) com buckets explícitos.
Aposte "tenant", "region", "road _ class' (sem PII).
Contem duas métricas, «sucesso» e «tudo», e para latency, «rápido» e «tudo».

4. 2 Exemplo de Prometheus (rate por 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) Alertas por burn rate (multi-window, multi-burn)

5. 1 Ideia

Vejamos a velocidade com que o orçamento está a arder. Se a velocidade é alta numa janela curta e longa, é um sinal.

5. 2 Liminares (para SLO 99. 9%)

Paging: burn rate ≥ 14. 4 x (10% do orçamento em 1 hora e 5% em 6 horas).
Tíquete: burn rate ≥ 6 x (2% em 6 horas e 1% em 24 horas).

5. 3 Exemplo de regras (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"

Igual a 6h/24h para o tíquete.

6) Gerenciamento de orçamento: processos

6. 1 Gates de lançamento

Se o saldo do orçamento <25% e a tendência negativa for «código congelado» para os fichas, a prioridade é SRE/sustentabilidade.
Os lançamentos canários devem ter um corte SLO separado ('deployment. environment="canary"`).

6. 2 Priorização do Beclog

Distribua a capacidade do comando de forma proporcional à velocidade de combustão e ao impacto na receita.
Justifique a dívida técnica com métricas: «O fix X vai reduzir o burn rate em Y%».

6. 3 Pós-incidente

Cada incidente é RCA e «fix que não pode ser revertido» (actionable), o controle «voltou para o SLO».

7) SLO como código

7. 1 Exemplo de manifesto 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 Geração de regras

Use geradores (slo-generator, pyrra, sloth) para criar regras, dashboards e relatórios automaticamente.

8) Degradação e proteção SLO

Load shedder: dar respostas rápidas sem dependências «caras» no pico.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: protege backends; rotas importantes - prioridade.
Circuito/Timeout: times rápidos e «fallback» ramos.
Função flags: desativação de fichas pesadas com um único botão.

9) Observabilidade para SLO

Dashboards: SLO actual vs target, restante do orçamento, burn rate, contribuições para roteiros/provedores.
Correlação: do «buraco» do SLO para o exemplar um trace específico logs/perfis.
Relatórios semanais - tendências, consumo de orçamento, causas de degradação.

10) Antipattern

Um SLO global para toda a → disfarça problemas. Segmente.
«99. 99% para tudo" sem considerar o custo e a realidade. Selecione os alvos a partir da experiência do usuário.
Alertas por CPU/heap em vez de burn rate/SLO.
Ignorar o 4xx/longo redits que estragam o UX.
Janela opaca (rolling vs calendário) - compara maçãs com laranjas.

11) Especificidades do iGaming/Finanças

Caminhos de dinheiro (depósitos/conclusões): SLO individuais acima do nível geral (por exemplo, 99. 95% de disponibilidade; p95 ≤ 250 ms).
Provedores PSP/KYC: SLO para cada provedor + alertas para sua contribuição ao burn; câmbio automático de rotas (smart routing).
Jurisdição/Tenentes: SLO e orçamentos por 'region/jurisdicção/brand', para que o problema local não «encha» a métrica global.
Jogo responsável: SLO durante a aplicação dos limites/auto-exclusão (fórmulas compliance).
Auditoria/regulação: guarde relatórios SLO e incidentes; transparência para as auditorias internas.

12) Folha de cheque pró-prontidão

• Definidos SLIs (availability/latency/quality/freshness) e segmentos (road/tenant/region).
• Os objetivos (SLO) são realistas, alinhados com o negócio; há janelas rolling de 30/90 dias.
• Alertas por burn rate com multi-janelas (paging/tíquete).
• SLO como código (gerador de regras/dashboard); relatórios de orçamento.
• Gates de lançamento estão amarrados no resto do orçamento; Cortes de canário.
• Os mecanismos de degradação (shedder, cachê stale, circuito, limites) foram implementados e testados.
• Correlação de métricas de trailers ↔ (exemplars), runbooks claros.
• Caminhos financeiros/jurisdicionais - SLO/alertas individuais; O PSP/KYC está desativado.
• Regularmente retrô sobre incidentes e investimento em confiabilidade baseado em burn.

13) TL; DR

Defina o SLI de acordo com o valor do usuário, defina o SLO realista e controle através do Erro Budget e do burn rate com as janelas multi. Ligue o código SLO, os gates de lançamento e a degradação do plano. Segmentar por rotas/tenentes/regiões; para os caminhos do dinheiro, mantenha metas mais rígidas e alertas individuais.