Torrent Gear

Práticas 24/7-operação e on-call no casino

1) Alvos 24/7-operações

Negócio SLO, login 99. 9%, depósito ≥ 99. 85%, taxa/setlent ≥ 99. 9%, p95 WS PTT ≤ 120 ms.

Alvos incidentes: MTTD ≤ 1 min (sintético), MTTR ≤ 15-30 min para flow em dinheiro.

Qualidade de suporte: <3% dos tíquetes vão para o segundo dia sem resposta; CSAT safort ≥ 90%.

2) Organização on-call: modelos e agendamentos

Modelos

Follow-the-sun: 3 equipes geo (Europa/América/APAC), carga mínima noturna.

Rotatividade noturna na região: semana de turnos noturnos por pessoa a cada N semanas (compensação/folga).

Celas (Cell-based): supervisão das células de alimentação (marcas/mercados) + L1 geral.

Papéis de turno

L1 On-call - aceita alert, coordena, mantém contato com a saforta.

L2 Engenheiros de domínio - pagamentos, game-gateway/WS, BD/carteira, plataforma SRE.

Oficial de Operações - Página de Status, Parceiros/Provedores, Updates Internos.

Duty Gerente - escalação de negócios, priorização, exclusão (VIP/regulador).

Modelo de turno (12 x 7 ou 8 x 5 + turno)

Turno: 8/10/12 horas. Mudança de 15-30 min «warm handover».

Cumpra a regra de 2 noites consecutivas no máximo e não mais de 7 on-call-dias em uma janela de 14 dias.

Cada turno tem um Roster, uma reserva, um gerente de chamadas, um contato L2.

3) Classificação de incidentes e SLA

SEV	Exemplo	Influência	Reações SLA	Soluções SLA
SEV-1	Fracasso de depósito em massa, não disponível	Perda de receita/risco regulatório	≤ 5 min	30 min antes da estabilização
SEV-2	Alto atraso nas apostas, provedor de jogos	Redução da conversão	≤ 10 min	≤ 2h
SEV-3	Falha parcial na promoção/relatório	Influência limitada	≤ 30 min	≤ 8 h
SEV-4	Menores bags/alertas de qualidade	Sem influência imediata	Planeado	Planeado

4) Alerting sem ruídos

Princípios: alertas SLO sintomáticos → contextos → causais.

Симптомы: `login_success_ratio↓`, `deposit_success_by_psp↓`, `ws_rtt_p95↑`, `game_launch_success↓`.

Причины: `db_conn_saturation↑`, `queue_lag↑`, `psp_timeout↑`, `provider_launch_latency↑`.

Protecção contra ruídos: required consectiva violações 3, supress automático ao lançamento, dedução e agrupamento.

Conjunto de atendimento: crítico - PagerDuty/Opsgenie; o resto é Slack/correio.

O texto do alert é «O que/Onde/Quanto/Ação». Exemplo:

💡 SEV-2: deposit success DE/PSP-A 97. 1% < 99% 10m. Impact: EU. Probable cause: PSP timeout↑. Runbook: `PD-42`.

5) Runbook 'e e escalar

Mini-modelo de runbook

1. Referências a dashboards (SLO, causais), trade, logs.

2. Verificações rápidas: health PSP/provedores, Dr. região sintética, status BD/cachê.

3. Medidas temporárias: flagra/kill-switch, rate-limits, mudança PSP/provedor, degradação de fichas pesadas.

4. Escalação: quem é L2/L3, contatos 24 x 7 provedor.

5. Critérios de área verde: SLO normal N minutos, filas

6. Coms: modelo de status, affected markets/brands, ETA/next update.

Escada escalante

T0-5 min: L1 aceita, atribui IC, executa runbook.

T5-10 min, chamamos L2 de Perfil + Oficial de Comando.

T10-15 min: Duty Gerente/produto, se necessário legal/complacência.

Externo: PSP/Game provider - por regulamento (canal SLA, tíquete, chamada).

6) Comunicações e página de status

Updates internos a cada 10-15 min para o V-1/2 (canal # war-room, modelo de mensagens).

Status - Status atual, mercados afetados, medidas temporárias, próximo update em X min.

Post-invent note para safort/afiliados/parceiros: O que foi, como compensamos.

Os modelos são curtos, sem «cozinha interna», sem culpa.

7) Trabalhar com dependências externas (PSP/jogos/CDN)

Catálogo de contatos 24 x 7: PSP A/B, provedores de jogos, CDN/WAF, nuvem.

Monitoramento SLA: Sintético de depósito/lançamento de jogos, tíquetes de tíquetes automáticos.

Políticas Failover: rota para PSP-B a 'sucess <99% 10 min', alternando provedor de jogos para 'TTFS> 800ms'.

Inbox webhooks: assinatura HMAC, idempotidade, ré-play da fila após a degradação do provedor.

8) GameDay e treinos

Ensinamentos tabletop semanais (30-45 min): leitura de gráficos, tomada de decisões.

DR-drive mensal (60-90 min): falha do PSP, do provedor, queda do BB/cluster WS.

KPI exercícios: tempo de reconhecimento de causa, qualidade das comunicações, correção das soluções de fichiflags.

9) Hendover e documentação

Warm handover folha de cheque (15-20 min):

Riscos atuais (crescimento das lajes, limites PSP, lançamentos quentes).
Tíquetes/escalações não preenchidos.
Ficheflags/limites temporários e quando retirar.
Resumo de incidentes de turno (V/hora/ação/risco residual).
Documentação: base de dados ao vivo runbook's, contatos, esquemas, «cartão flow» dinheiro/jogos.

10) On-call saúde e sustentabilidade

Regra 8/8/8: trabalho/sono/pessoal. Turnos noturnos → folgas.

Sistema Buddy para novatos, serviço shadow 2-3 semanas.

Segurança psicológica: «blameless» retrô, apoio para incidentes graves.

Auditoria de carga: ≤ 2 «despertar» por noite em média por engenheiro - objetivo; acima → reciclagem de alerting/arquitetura.

11) Métricas de eficiência operacional

MTTD/MTTR para domínios (login/depósito/WS/jogos).

Alert quality:% ruído/fechado sem ação, média de alertas/turno.

Mudar failure rate:% dos incidentes causados por lançamentos; mean time between failures.

Toil: proporção de tarefas manuais repetidas → plano de automação.

Provider impact: proporção de SEV-2/1 devido a parceiros externos (argumento para SLA/migração).

12) Ferramentas e painéis de serviço

«Vermelho» dashboard SLO: login/depósito/apostas/lançamento de jogos, 5xx/429, p95, regiões.

Painéis de causa: BD/filas/dinheiro, PSP/provedores, CDN/WAF.

Central on-call: incidentes ativos, temporizadores de update, one-click links de runbook 'e e ficheflags.

Registro de ação (timeline) - quem fez o quê, quando, com uma ligação SLO.

13) Cenários típicos e soluções rápidas

A. Os depósitos caem em DE no PSP-A

Ações: canário PSP-B 50%; levantar o tempo dos webhooks; incluir o desafio JS no WAF dos bots.

Coms: Página de status «Degradation DE deposits via PSP-A».

Saída: sucess ≥ 99% 15 min, fila de retais

B. Crescimento de p95 WS em jogos de lave APAC

Ações: Aumentamos as réplicas de passarelas WS, incluímos o wart pool nod; rate-limit mensagens de transmissão; O provedor é um tíquete de RPT.

Saída: p95 WS PTT ≤ 120 ms 20 min

C. O provedor de jogos (TTFS> 1. 2 c)

Ações: mudar o lobby para mesas alternativas/estúdios, incluir kesh de metadados; status-update.

Saída: TTFS <800 ms, queixas ↓.

14) Folha de cheque pronta para 24/7

Rotações e turnos de serviço aprovados, «número dois» em cada turno.
Alertas SLO + causais, antissistema, modelos de mensagens unificados.
Runbook completo 'e com «alavancas rápidas» (fichiflags, PSP/provedores, limites).
Contatos 24 x 7 parceiros externos, teste de chamada uma vez por trimestre.
Status da página e modelos de update externos.
GaDay/Dr. Ensinamentos programados, retrospectivos sem acusações.
Ferramentas on-call: dashboard, timeline, registro de soluções.
Política de compensação/folga, limite de despertar noturno, apoio à saúde.
Processo pós-incidente: RCA em 48 h, tarefas de correção com proprietários e prazos.

15) Modelo pós-mortem (blameless)

1. Resumidamente, o que aconteceu quando, que tipo de SEC, influência e escala.

2. Timeline, detecção → escalar a → → estabilização.

3. Razões de raiz: aqueles/processos/pessoas/fornecedores (5 Why).

4. O que deu certo é que não, alertas, ranbooks, comunicações.

5. Action items: técnica, processual, parceira - responsável e deadline.

6. Prevenção: testes/monitoramento/exercício, alterações SLO/alertas.

Currículos

As operações bem sucedidas 24/7 no casino são uma disciplina SLO, alarming bem projetado sem ruídos, runbook nítido e escalação, ensinamentos regulares e cuidado com as pessoas on-call. Vincule painéis SLO com alavancas rápidas (ficheflags, mudança de PSP/provedores, degradação de fichas pesadas), mantenha comunicação com jogadores e parceiros, meda eficiência (MTTD/MTTR/alert quality) - e sua plataforma será estável 24 horas por dia e sua equipe, produtiva e sustentável.