PSP-X latency & loss

(Secção Tecnologia e Infraestrutura)

Resumo curto

Chaos Engineering é um método científico para a produção: você está formulando uma hipótese de estabilidade, violando o ambiente de forma controlada e provando que o valor do usuário (SLO/métricas de negócios) é preservado. Para iGaming, são verificações de pagamentos (PSP), inicialização de jogos, filas de conclusões, multirregiões e cargas de pico - em casos de atrasos, falhas e «tempestade» de retais - antes que isso aconteça aos usuários vivos.

1) Princípios de caos e engenharia

1. De steady-state para hipótese. Defina a norma: Availability, p95/p99, TTW, conversão de pagamentos.
2. Pequeno blast radius. Experimento primeiro em estaging/canais, 1-5% de tráfego/1-2 para/uma região.
3. Observabilidade acima de tudo. Métricas/logs/trailers + anotações da experiência.
4. Guardrails и abort. Liminares rígidos SLO/business KPI para parar automaticamente.
5. Repetição e automação. Experimentos como código (IaC/GitOps), plano game-day.
6. Blameless cultura. O experimento não é encontrar culpados, é encontrar pontos fracos.

2) Steady-state e métricas de sucesso

TexSLI: p95/p99 API, erro-rate, saturação (CPU/IO), queue lag (withdrawals/deposits), latency provedores.
SLI de negócios: conversão de 'attempt→success', TTW p95, sucesso de 'game init', taxa de rejeição de PSP de códigos.

3) Classes de experimentação (que «quebramos»)

Rede: latency/jitter/packet loss/blackhole, falhas DNS, anomalias MTU.
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Processos e locais: kill/evict pod, node failure, zona/region failover.
Dependências: temporizações PSP/erros, indisponibilidade do provedor de jogos, degradação do CDN/cachê.
Filas/streaming: crescimento de Kafka lag, interrupção de consoantes, quebra de partituras/líder.
Dados/BD: atrasos de replicação, degradação de índice, modo read-only.
Lançamentos/fichiflags: falhas de migração, configs errados, kill-switch.
Frente/RUM: Queda do LCP/INP, crack do cliente no pico.
Data/ML: envelhecimento das fichas, aumento da latency modelo, queda do tocens/s, degradação da qualidade.

4) Processo: de hipótese a melhorias

1. Formular uma hipótese (SLO/Business KPI + o comportamento previsto).
2. Projetar o tipo de falha, duração, blast radius, guardrails/abort.
3. Preparar observação: dashboards «release/experiment compare», anotações.
4. Iniciar sob controle IM/TL, notificar on-call/negócio (se afetado).
5. Mede o resultado: SLO, p95/p99, TTW, conversão, laje, retraí.
6. Formar action items: limites, temporizações, retais com jitter, outlier-ejation, pDB/HPA/KEDA, flow de reposição.
7. Automatizar (incluir no pacote de game-day/CI).

5) Guardrails e critérios de paragem

• O SLO fast-burn foi ativado (por exemplo, 14 x orçamento por 1h),
• conversão de pagamento ↓ mais de 0. 3 p.p.,
• TTW p95> 3 min consecutivas 10-15 min,
• error-rate > 1. 5% e cresce em duas janelas.
• Comunicações: canal/modelo de status pré-aprovado, botão vermelho no ChatOps ('/experiment abort ').

6) Exemplos de experiências (Kubernetes/nuvem)

6. 1 Atrasos de rede para PSP (pouso de canário)

O objetivo é verificar os retais/temporizadores/roteiros.
Injecção: + 200 ms RPT e 3% packet loss apenas para 'payments-api' n' ".

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

Esperado: p95 '/deposit '<250 ms, error-rate <1%, conversão ≥ baseline - 0. 3 p.p.; Quando piora, alterna a rota PSP de forma automática.

6. 2 Falha de nó e PDB

O objetivo é verificar PDB/anti-affinity/HPA.
Injeção: drain/terminate de um nó com «games-api».

Espera: Sem perda de disponibilidade, p99 de pico não sai do SLO, autoscaler obtém réplicas, PDB impede «duplo impacto».

6. 3 Kafka lag и KEDA

Objetivo: Resiliência de saques na acumulação de mensagens.
Injecção: congelar os consoadores de 5 a 10 min, depois ligar.

Espera: KEDA escala os workers, TTW p95 fica ≤ 3 min após a descarga, sem duplicação (idempotidade, chaves).

6. 4 DNS falha do provedor de jogos

Alvo: fallback/cachê/retrai.
Injeção: NXDOMAIN/timeout para o domínio 's'. example`.

Espera: folback rápido em 'providerB', em UI - modo de degradação e banner de status; 'game init sucess' ≥ 99. 5%.

6. 5 Read-only BD

O objetivo é comportar-se quando se perde a gravação.
Injecção: mudança de réplica para read-only de 10-15 min.

Espera: o código trata corretamente os erros, as rotas críticas são limitadas, as filas retêm as solicitações, não há perdas ou cancelamentos duplos.

7) Automação e GitOps

Experimentos como código: armazene os cenários/parâmetros/guard em Git, revivendo através do PR.
Plano de game-day: horários, proprietários, métricas, condições de abort, cheque-folha de comunicação.
Anotações em Grafana: início/fim da experiência, config, SLO final.

8) Observabilidade durante o caos

Explars: de p95/p99 para «trace _ id» específicos.
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Trailers: chamadas externas marcadas 'fault. insected = true ', visto retrai/timeout.
Dashboards: «SLO Card», release/experiment compare, Payments/Game init/Queues.

9) Especificidade iGaming: O que verificar primeiro

1. Pagamentos e TTW: temporizações PSP, rota de folback, idempotação.
2. Inicialização de jogos: indisponibilidade/lentidão dos estúdios, falhas CDN.
3. Filas de conclusão/bónus: crescimento de lag, reaproveitamento.
4. Multiregião: falha da zona/RR, mudança de líder, replicação da base de dados.
5. Picos: skale automático, rate-limit, circuito-breaker, aquecimento de dinheiro.
6. RG/Compliance: Logagem correta em casos de falhas, falta de PII na telemetria.

10) Gerenciamento de risco (governance)

Calendário e janelas: experiências fora de torneios de pico, alinhamento com negócios.
Роли: Experiment Lead, Observer (SRE), Business Rep; IM na linha de telefone.
Políticas de dados: nada de PII nos artefatos; Armazenamento WORM para auditoria.
Limites legais: excluir cenários de violação de SLA sem concordância.

11) Game-day: modelo de cenário

12) Descobertas e ações típicas

Retraias agressivas demais → pedidos tempestade → adicionar timeouts/jitter/limites.
Não há outlier ejation → uma instância «venenosa» estraga o p99 → ativa a seleção.
Migrações frágeis de read-only quebram o fluxo de   + ficheflags.
Sinal HPA inválido  escaneia tarde demais para as métricas RPS/lag.
O cachê compartilhado para as versões de reversão põe os dados  as chaves de versão.

13) Cheque folha de maturidade prática de caos

1. Steady-state e SLO são descritos, os dashboards estão prontos.
2. Experimentos como código, revezamento/auditoria em Git.
3. Guardrails/abort automatizados (Alertmanager/ChatOps).
4. Observabilidade: exemplars, trace/not correlation, anotações.
5. Game-day trimestral, os cenários cobrem pagamentos/jogos/filas/multiregião.
6. O pós-experimental action items faz parte do plano de sprint; Controle de execução.
7. Políticas de liminares de retrações/temporizadores/circuito-breaker em config-repo.
8. As políticas de segurança/PII são respeitadas, artefactos sem dados sensíveis.
9. As remunções automáticas por SLO (rollback/scale/rerute) foram testadas com caos.
10. Métricas de processo:% de abort, MTTR em exercícios, redução de incidentes de classe.

14) Anti-pattern

«Quebramos tudo na venda» sem SLO/guardrails/observabilidade.
Experimentos sem hipóteses ou objetivos mensuráveis.
Grande blast radius no primeiro lançamento.
Retrações sem temporizadores/jitter → resistência em cascata.
Caos em vez de prevenção, tratamos os sintomas, ignoramos as causas da raiz.
Falta de RCA/action items após o exercício.
Experiências no relógio de pico sem acordo com o negócio.

Resumo

O caos-engenharia é uma prova metódica de sustentabilidade: você reproduz com antecedência falhas reais, mede o impacto sobre o SLO e as métricas de negócios e fortalece a arquitetura, desde retais e circuito-breaker até orquestrações multirregionais e remunções auto. Com os jogos-day regulares e a disciplina dos guardas, a plataforma iGaming mantém p95/p99, conversão e TTW mesmo nos períodos mais quentes.