Alerting e resposta a falhas
(Secção Tecnologia e Infraestrutura)
Resumo curto
Um alerting forte é um sinal de violação do valor do usuário, não apenas uma métrica vermelha. Para iGaming são importantes os gates SLO (latência, disponibilidade, conversão de pagamentos, Time-to-Wallet), multi-burn regras, papéis nítidos on-call, escalação, ChatOps e runbooks. O objetivo é rapidamente ver o desvio, informar aqueles que podem corrigir e fixar o conhecimento para que a próxima vez reaja ainda mais rápido e barato.
1) Fundamentos: de métricas para ações
SLI → SLO → Alert: A qualidade → o nível de meta a ser medido → a condição de orçamento a arder.
Severity (SEC): SEV1 é crítico (receita/GGR ameaçada), SEV2 é grave, SEV3 é moderado e SEV4 é menor.
Impacto/Urgency: Quem sofre (tudo/região/tenante/canal) e quão urgente (TTW↑, p99↑, error- rate↑).
Activability: para cada alarme, uma ação específica (runbook + proprietário).
2) Taxonomia de sinais
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
Negócios SLO: Conversão de pagamentos (attempt→success), Time-to-Wallet (TTW), apostas bem sucedidas, execução de jogos.
Rotas de pagamento: métricas específicas PSP (timeout/decline spikes).
Frente/mobile: métricas RUM (LCP/INP), crash-rate, sintético (login/depósito/taxa/retirada).
3) Política de alerting: SLO e burn-rate
Exemplos de SLI/SLO
Disponibilidade de 'payments-api' ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Conversão 'payments_attempt→success' ≥ baseline - 0. 3% / 24h
TTW p95 ≤ 3 min/24h
Multi-window / Multi-burn (идея PromQL)
Fast burn: violação do SLO 5-10 x mais rápido (alert-page 5-15 min).
Slow burn: dilaceração lenta do orçamento (tíquete + análise em 1-3 horas).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) Barulho e qualidade dos sinais
A fonte correta da verdade é alinhar-se por agregados (recording rulas) em vez de expressões «cruas» pesadas.
Deduplicação: Alertmanager agrupa por 'service/region/severity'.
Hierarquia: Primeiro alert para o negócio/SLI, abaixo, técnica como diagnóstico.
Supressão: durante planned-maintenance/lançamento (anotação), em incidentes upstream.
Cardinalidade: Não use 'user _ id/sessions _ id' nas marcas de alertas.
Alertas de teste: Trechos de treinamento regulares (verificação de canais, papéis, links de runabook).
5) Alertmanager: rotação e escalação
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]Ideia: SEC = page → PagerDuty/SMS; o resto é Slack/tíquete. A inibição suprime o «tumulto» dos níveis mais baixos quando o SEC ativo é superior.
6) Grafana Alerting (como camada extra)
Alert centralizado em dashboards (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silências: trabalho de planejamento, migração, lançamentos.
Snapshots com tela automática do painel no tíquete.
7) On-call e processos «ao vivo»
Rotação: linha 1 (SRE/plataforma), linha 2 (proprietário do serviço), linha 3 (DB/Payments/Sec).
SLA reações: reconhecimento de 5 minas (SEV1), diagnóstico 15 minas, comunicações de 15 a 30 minutos
Os canais de atendimento são '# invident-warroom', '# status-updates' (apenas factos).
Runbooks: referência em cada alerte + comandos rápidos ChatOps ('/rollback ', '/freeze', '/scale ').
Ansiedade curricular mensal (verificação de pessoas, canais, atualidade runabook).
8) Incidentes: ciclo de vida
1. Detect (alert/reporte/sintético) → Acknowledge on-call.
2. Triagem: definir o SEV/afetado/hipótese, abrir o war-room.
3. Estabilização: rolos/reversão/zoom/fichiflags.
4. Comunicações: modelo de status (veja abaixo), ETA/os seguintes passos.
5. Encerramento: confirmação da recuperação do SLO.
6. Post-Invident Review (RCA): 24-72 h, sem acusações, action items.
- O que está quebrado/quem foi afetado (região/tenante/canal)
- Quando o/SEC começou
- Medidas provisórias (mitigation)
- Próxima atualização de status em N minutos
- Contato (Gerente de incidente)
9) Especificidades do iGaming: zonas de «dor» e alertas
Payments/TTW: proporção de temporizações PSP, aumento de falhas de código, TTW r95> 3m.
P99 API/hora de início dos jogos/queue lag; exaltação de limites/skale automático.
As conclusões são SLA bacofis/verificações manuais, limites por país.
Provedores de jogos: disponibilidade por estúdio, hora de inicialização da sessão, queda nos lançamentos.
RG/Compliance: picos de sessões de longa duração/» dogon», excesso de liminares - Não é um software, é um tíquete + uma notificação de RG para o comando.
10) Exemplos de regras (opcional)
Alta latência p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"Fila de conclusões em chamas
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"Conversão de pagamentos solicitada
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) ChatOps e automação
Alertas de posting automático com botões de ação Stop canary, Rollback, Scale + N.
Abreviações de comando: '/invent start ', '/status update', '/call
Os bots puxam o contexto: os últimos deplois, gráficos de dependências, exemplos de trace (exemplars), tíquetes relacionados.
12) Trabalho pós-incidente (RCA)
Os factos são o tempo que viram/o que tentaram, o que funcionou.
Root causa: razões técnicas e organizacionais.
Detections & Defenses: Quais sinais ajudaram/falharam.
Action items: tarefas específicas (SLO/alert/códigos/limites/testes/runabook).
Dentes & owners: prazos e responsáveis; folow-up-sessão daqui a 2-4 semanas.
13) Folha de cheque de implementação
1. Defina o SLI/SLO para os fluxos-chave (API/Payments/Games/TTW).
2. Configure recording rulas e multi-burn alert + routing Alertmanager.
3. Digite on-call com rotação, SLO reações e escalações.
4. Vincule as alertas aos comandos runbooks e ChatOps.
5. Configure as supressões/janelas silenciosas, anotações de lançamento/trabalho.
6. Faça alarmes de treinamento e cenários de game-day (queda PSP, p99, crescimento queue lag).
7. Mede Alert Quality: MTTA/MTTR,% noisy/falso, coverage SLO.
8. RCA regular e revisão de liminares/processos.
9. Digite o status da comunicação com o negócio/safort (modelos).
10. Documente tudo como código: regras, rotas, links runabook.
14) Anti-pattern
Alerting de cada métrica → alert-fetig, ignorado.
Não há SLO. Não sei o que é normal e o que está a arder.
Nenhuma supressão/inibição → avalanche de duplicação.
Paige à noite para eventos menores (O SEV não é compatível com o Impact).
Alertas sem runbook/dono.
Ações manuais sem ChatOps/auditoria.
Nenhum RCA/Action items repetição de incidentes.
Resumo
Alerting e resposta é um processo, não um conjunto de regras. Vincule o SLO a multi-burn-alerts, construa uma escalação on-call clara, adicione ChatOps e runabook vivo e realize regularmente RCA e treinamento. Os incidentes serão mais raros, mais curtos e mais baratos, e os lançamentos mais previsíveis, mesmo nas horas mais quentes.