GH GambleHub

Correção automática de erros

1) Propósito e princípios

O objetivo é reduzir o MTTR e evitar uma escalada de incidentes, mantendo SLO, receita e conformidade.

Princípios:
  • SLO-first: As ações automáticas só são permitidas se o orçamento for ameaçado.
  • Segurança acima de tudo, blast-radius mínimo, limites aparentes e timbox.
  • Explainable by design: cada ação é explicável e audível.
  • Disposição Rollback: Qualquer etapa é acompanhada de critérios de retorno.
  • Human-in-the-loop onde o risco é alto: mudanças P1-críticas - via dual controle ou confirmação IC/on-call (a menos que uma política diferente).

2) Termos

Auto-remediação: resposta programática ao evento (alert/anomalia) sem participação humana.
Guardrails: política de restrição (limite, duração, número de tentativas, área de exposição).
Runbook-Action: operação atômica com pré/pós-verificação e reversão.
O Decision Engine é um serviço que mapeia o evento com as políticas e executa as ações.

3) Arquitetura de solução

1. Sinais: SLO/burn-rate, KRI, sintético, RUM, deep-health.
2. Correlação de contexto: lançamentos, fichflags, trabalhos de planejamento, provedores de dependentes.
3. Decision Engine: regras/políticas (policy-as-código), avaliação de impactos e riscos, escolha de um cenário.
4. Execução: Orquestrador de ação runbook (idempotidade, retrai com jitter).
5. Controle, pré-validadores, pós-verificadores, taimbox, reversão.
6. Auditoria e observabilidade: trade de ação, métricas de sucesso, registro (WORM/imutable).
7. Comunicação: Página status (via Comms Lead), war rum, macros de safort.

4) Políticas e tolerâncias (policy-as-código)

Exemplos de condições (pseudo-rego/lógica): Failover PSP:
  • `allow if burn_rate(payments. auth) > fast && impact>threshold && psp_alt. healthy && within_limits("psp_reroute")`
Degrade Non-Critical Features:
  • `allow if p99(bet_settlement)>3x && queue_lag>limit && feature("replay_center"). enabled`
Autoscale by Lag:
  • `allow if consumer_lag>target && cost_budget. ok && region_capacity. available`
Block PII Exports:
  • `allow if export_spike && no_ticket && data_class=PII -> action=block + notify(Compliance)`

Cada política contém condição, ação, limite (scope/tempo/frequência), critérios de sucesso, reversão.

5) Catálogo de ações seguras (runbook-action atômicas)

Pagamentos: trocar o tráfego para PSP/banco alternativo; mudar as prioridades de routing health x fee x conversion; incluir o 3DS simplificado; aumentar os limites de retrações com jitter.
Apostas/jogos: Escala Worthers Setl; incluir cachê-warmup; desativar temporariamente as fitas não-ríticas (animações, fidas secundárias); incluir waiting-room/queue-page.
Infraestrutura: remover espécimes degradantes (outlier-detector), evacuar o tráfego para a região vizinha AZ/região; aumentar o pool/quotas; reiniciar os workers com verificação de lentes.
Dados/filas: redistribuir partituras; elevar os consumidores para cap; mudar o tráfego read para uma réplica saudável; incluir trechos de sempling adaptativo.
Segurança/Complacência: bloquear temporariamente a exportação de PII sem tíquete; Reforçar os limites de conclusão velocity; ativar o dual controle em operações sensíveis.
Camada comm: rascunho de status automático + slots update para Comms Lead; notificação de parceiros em caso de degradação PSP.

6) Pré e pós-validação

Antes:
  • Verificar que o problema é real e recente (N-de-M janelas; sem silens/trabalhos programados).
  • Certifique-se de que a ação é permitida pela política e existe um orçamento de recursos.
  • Estimar o custo (FinOps) e os limites de complacência.
Post:
  • Confirmar redução burn-rate/métricas; gravar o resultado; programar a devolução (auto-rollback) de acordo com os termos.

7) Rollback и “escape hatch”

Retorno automático na estabilização das métricas e através de ação max-TTL.
Botão de reversão para IC/On-call na sala de war.
O Break-glass é apenas para acesso de emergência; uma auditoria pós-auditoria obrigatória.

8) Integração com alerting e incidentes

Qualquer ação automática é anexada ao cartão de incidente: quem/o/o/o/o/porquê, o resultado, links de gráficos.
O pager é abaixado para duplicados, mas não para os carros-fixos fracassados (escalação).
O status da página é atualizado através do Comms Lead no modelo.

9) Design de segurança e complacência

Os menores privilégios para o orquestrador; papéis individuais por ação/domínio.
SoD e controle dual para high-risk: routing PSP, limites de bónus, exportação de PII.
Auditoria WORM/imutable de todas as soluções automáticas, incluindo sinais de entrada e versões de políticas.
Higiene PII - sem identificadores pessoais em editoras ou logs de ação.

10) Observabilidade dos circuitos automáticos

Métricas: sucess-rate de ação, tempo de reação,% de retalhos, economia de MTTR, efeitos sobre o SLO.
Trailers: trace de passagem para «sinal → solução → ação → efeito».
Logs: estruturados, com policy _ id, versões e pré/pós-verificações.
Dashboards: Exec (impacto sobre receita/SLO), Ops (matriz de ação x domínios), FinOps (custo de medidas automáticas).

11) Exemplos de cenário (iGaming)

11. 1 degradação PSP (TR/EU)

Sinal: auth-sucess do PSP-1 ↓ 25% em 10 min, cobertura> 30% das transações.
Ações: redistribuir 40% do tráfego para PSP-2/3; incluir o 3DS simplificado; elevar os retais de solicitação do banco X com o jitter.
Limites: no máximo 60% do tráfego total por PSP alternativo; TTL 45 min.
Rollback: ao normalizar o sucess-rate, ≥ o alvo dentro de 15 minutos.

11. 2 Altura p99 no setl de apostas

Sinal: p99 «bet→settle»> 3 x normas + consumer-lag> limiar.
Ações: scale-out worker até cap; O rublo da caixa de coeficientes; desligar temporariamente o histórico de repetições.
Rollback: após headroom> X e p99 em 20 min.

11. 3 Réplicas de BD atrasadas

Sinal: replication-lag> N segundos, altura lock-wait.
Ações: levar o tráfego read para uma réplica saudável; ativar operações de baixa prioridade de throttling write.
Rollback: Depois da normalização da lag e dos erros de bloqueio.

11. 4 Spike exportação PII

Sinal: rate de exportação> linha de base x K, sem tíquetes.
Ações: unidade de exportação, notificação do Compliance, ativação do controle dual.
Rollback: após confirmar os pedidos e encerrar a anomalia.

12) KPI и KRI

Para os incidentes onde o auto-fix funcionou.
TTD→Action: Tempo do detetive até a ação ser executada.
Sucess-rate de ação e Rollback-rate (baixo - bom, se não for devido a falsos efeitos).
Falso-action rate (ações sem efeito ou com efeitos negativos).
SLO impact saved (minutos/receita, multas evitadas).
Pager fatigue↓ (menos pagers manuais com os mesmos/melhores SLO).

13) Mapa de trânsito de implementação (8-12 semanas)

Ned. 1-2: selecione 3-5 cenários RI (PSP-feelover, autooscale por lag, função-degrade); descrever políticas/limites/retrocessos.
Ned. 3-4: implementar um orquestrador de ação, segredos e papéis, integração com uma plataforma de incidente; adicionar observabilidade e auditoria.
Ned. 5-6: piloto em modo «sombra» (simulate-only) → A/B de avaliação do efeito; em seguida, incluir na proda com pouca abrangência.
Ned. 7-8: expandir diretório de cenário (BD/dinheiro/fila/frente), associar a página status e Comms.
Ned. 9-10: adicionar regras de limites FinOps (custo/SLI), implementar controle dual para high-risk.
Ned. 11-12: tabletop/chaos-ensinamentos, revisão KPI/KRI, publicação de heidline e treinamento on-call.

14) Artefatos e modelos

Auto-Remediation Policy: condição, ação, limites, TTL, retrocesso, proprietário, classe de risco.
Runbook-Action Spec: predefinição, passos, verificações, erros, monitoramento, lógica de reversão.
Mudança-Control: Quem pode editar políticas, reviravolta, testes, diff e versão.
Evidence Pack: logs/trailers/métricas de exposição a SLO, relatório para pós-mortem/auditoria.

15) Antipattern

«Tratar um sintoma» sem verificar a causa e flapping SLO.
Ações sem retrocesso e TTL → degradação congelada.
Script versáteis sem guardrails → falhas em cascata.
Não há auditoria ou versionização de políticas.
Valor ignorado (scale automático sem limite) e compasso (exportes PII).
Autonomia total sem Human-in-the-loop em riscos P1.

Resultado

A correção automática de erros é um circuito controlado: sinais SLO de política → com guichês → ações runbook seguras com retrocesso → observabilidade e auditoria → treinamento em incidentes. Esta abordagem reduz a MTTR de forma mensurável, mantém os lucros em picos e alivia a rotina da coll, mantendo-se compatível com os requisitos de segurança e reguladores.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Telegram
@Gamble_GC
Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.