Torrent Gear

Pratiche 24/7 e on-call nel casinò

1) Obiettivi 24/7-operazioni

Business SLO, Login 99. 9%, deposito ≥ 99. 85%, tasso/settlent 99. 9%, p95 WS RTT per 120 mc.

Obiettivi di incidente: MTTD 1 min (sintetico), MTTR 15-30 min per flow .

Qualità del supporto: <3% dei ticket passa al secondo giorno senza risposta, CSAT zapport al 90%.

2) Organizzazione on-call: modelli e pianificazioni

Modelli

Follow-the-sun: 3 team geo (Europa/America/APAC), minimo carico notturno.

Rotazione notturna nella regione: una settimana di turni a persona ogni N settimane (rimborso/permesso).

Celle (cell-based) - Controllo celle alimentari (marchi/mercati) + L1 generale.

Ruoli di cambio

L1 On-call (Incent Comment di default) - Accetta l'alert, coordina, mantiene il contatto con lo zappone.

L2 Ingegneri di dominio - pagamenti, game-gateway/WS, database/portafogli, piattaforma SRE.

Comms Ufficiale - Status Page, partner/provider, update interni.

Duty Manager - escalation aziendale, priorità, eccezioni (VIP/regolatore).

Modello di turno (12 x 7 o 8 x 5 + turno)

Turno: 8/10/12 ore. Cambio di turno 15-30 min «warm handover».

Seguire la regola delle 2 notti consecutive al massimo e non più di 7 on-call-giorni in una finestra di 14 giorni.

Ogni turno ha un Roster, di turno, riserva, responsabile di chiamata, contatto L2.

3) Classificazione degli incidenti e SLA

SEV	Esempio	Impatto	Reazioni SLA	Soluzioni SLA
SEV-1	Depositi di massa falliti, login non disponibile	Perdita di ricavi/rischio regolatorio	≤ 5 min	30 minuti prima della stabilizzazione
SEV-2	Scommesse in ritardo elevato, provider di giochi	Riduzione della conversione	≤ 10 min	≤ 2 ore
SEV-3	Errore parziale del promo/report	Impatto limitato	≤ 30 min	≤ 8 ore
SEV-4	Picchi minori/alert di qualità	Nessuna influenza immediata	Pianificazione	Pianificazione

4) Alerting senza rumore

I principi sono gli alert SLO sintomatici, il contesto delle risorse causali.

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

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

Protezione contro il rumore: richired consortive violations 3, supress automatico di rilascio, deduplicazione e raggruppamento.

Set di servizio critico - PagerDuty/Opsgenie; Il resto è Slack/Posta.

Il testo dell'alert è «Cosa/Dove/Quanto/Azione». Esempio:

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

5) Runbook e e escalation

Mini modello runbook

1. Dettagli - riferimenti a dashboard (SLO, causa), trance, logi.

2. Controlli rapidi: health PSP/provider, DR-area sintetica, stato database/cache.

3. Misure temporanee: flag fich/kill-switch, rate-limits, failover PSP/provider, degrado dei file pesanti.

4. Escalation: chi è L2/L3, contatti 24 x 7 provider.

5. Criteri area verde: SLO nella norma N minuti, code

6. Comms: modello di stato, affected markets/brands, ETA/next update.

Scala di escalation

T0-5 min: L1 accetta, assegna IC, avvia runbook.

T5-10 min, chiamiamo L2 + Comms Ufficiale.

T10-15 min: Duty Manager/prodotto, se necessario legale/compilation.

Esterni: PSP/Game provider - per regolamento (canale SLA, ticket, chiamata).

6) Comunicazioni e stato pagina

Update interni ogni 10-15 minuti per la SEC-1/2 (canale # war-room, modello di messaggio).

Stato pagina: stato corrente, mercati interessati, misure temporanee, successivo update in X min

Post-insidioso note per zapport/affiliati/partner: cosa è stato, come compensato.

I modelli sono brevi, senza «cucina interna», senza colpa.

7) Lavorare con dipendenze esterne (PSP/giochi/CDN)

Catalogo contatti 24 x 7: PSP A/B, provider di giochi, CDN/WAF, cloud.

Monitoraggio SLA - Sintetico deposito/avvio giochi, ticket ticket automatico.

Criteri Failover: percorso su PSP-B a «success <99% 10 min», cambio del provider di giochi a «TTFS> 800ms».

Inbox-webhocks: firma HMAC, idempotenza, re-play dalla coda dopo il degrado del provider.

8) GameDay e allenamento

Esercitazioni tavoletop settimanali (30-45 min): lettura grafica, decisione.

DRIVE tecnici mensili (60-90 min): guasto del PSP, del provider, caduta del database/cluster WS.

Esercitazioni KPI: tempo di riconoscimento della causa, qualità delle comunicazioni, correttezza delle soluzioni di ficcoflag.

9) Hendover e documentazione

Foglio di assegno Warm handover (15-20 min):

Rischi correnti (aumento delle corse, limiti PSP, rilascio caldo).
Ticket/escalation non completati.
Ficheflagi/limiti temporanei e quando togliere.
Riepilogo degli incidenti di turno (SEC/tempo/azione/rischi residui).
Documentazione: base di runbook vivente, contatti, schemi, flow card denaro/giochi.

10) On-call salute e sostenibilità

Regola 8/8/8: lavoro/sonno/personale. Turni notturni per le vacanze.

Sistema Buddy per principianti, servizio shadow 2-3 settimane.

Sicurezza psicologica: «blameless» retrò, supporto per i gravi incidenti.

Controllo del carico: 2 «risveglio» a notte in media per ingegnere - obiettivo; sopra il → di alerting/architettura.

11) Metriche di efficienza operativa

MTTD/MTTR per dominio (login/deposito/WS/giochi).

Alert quality:% rumoroso/chiuso senza azione, numero medio di alert/cambio.

Change failure rate:% degli incidenti causati dalle release; mean time between failures.

Toil: la percentuale di attività manuali ripetute è un piano di automazione.

Provider impact: Quota di SEC-2/1 a causa di partner esterni (argomento SLA/Migrazione).

12) Strumenti e pannelli di servizio

«Rosso» dashboard SLO: login/deposito/puntata/avvio giochi, 5xx/429, p95, regioni.

Pannelli causali: database/code/cache, PSP/provider, CDN/WAF.

Gestore on-call: incidenti attivi, timer di update, one-click riferimenti runbook e phicheflagi.

Registro azioni (timeline) - Chi ha fatto cosa quando, con l'aggancio a SLO.

13) Script tipici e soluzioni veloci

A. I depositi cadono in DE a PSP-A

Azioni: PSP-B 50%; alzare il timeout dei webhoot; includere il challenge JS in WAF dai bot.

Comms: pagina di stato «Degradation DE deposits via PSP-A».

Esci: success ≥ 99% 15 min, coda di retrai

B. Crescita p95 WS nei giochi di lave APAC

Azioni: aumentate le repliche dei gateway WS, includete il pool di nodi warm; rate-limit messaggi di trasmissione il provider ticket della RTT.

Uscita: p95 WS RTT da 120 ml 20 min.

C. Provider di giochi (TTFS> 1. 2 c)

Azioni: sposta la lobby a tavoli/studi alternativi, abilita la cassetta di metadati; stato-update.

Uscita: TTFS <800 ms, ↓.

14) Foglio di assegno pronto per il 24/7

Rotazioni e turni di servizio approvati, «numero due» a ogni turno.
SLO-alert + causali, anticum, modelli di messaggio unificati.
Runbook completi e con «pulsanti veloci» (phicheflagi, PSP/provider, limiti).
Contatti 24 x 7 partner esterni, test di chiamata una volta al trimestre.
Stato pagina e modelli di update esterni.
GaDay/DR.-esercitazioni pianificate, retrospettive senza accuse.
Strumenti on-call: dashboard, timeline, cronologia delle soluzioni.
Politica di compensazione/riposo, limite di risveglio notturno, assistenza sanitaria.
Processo post-incidente: RCA in 48 ore, operazioni di correzione con proprietari e scadenze.

15) Modello post mortem (blameless)

1. In breve, cosa è successo quando, quale SEC, impatto e portata.

3. Le cause radici sono quelle/processi/persone/fornitori (5 Why).

4. Cos'ha funzionato? Alert, runbook, comunicazioni.

5. Action items: tecnico, processuale, partner - responsabile e deadline.

6. Prevenzione: test/monitoraggio/esercitazione, modifiche SLO/alert.

Curriculum

Il 24/7 successo del casinò è una disciplina SLO, un alarming correttamente progettato senza rumori, runbook nitide'e e escalation, esercitazioni regolari e atteggiamenti attenti alle persone on-call. Collegare i pannelli SLO con pulsanti veloci (ficheflagi, PSP/provider, degrado dei FIP pesanti), comunicare con giocatori e partner, misurare l'efficienza (MTTD/MTTR/alert quality) e mantenere la piattaforma stabile 24 ore su 24 e il team produttivo e sostenibile.