Interazione dei comandi nelle operazioni

1) Perché

La piattaforma iGaming è una dozzina di domini (Payments, Games/Core, Risk/KYC, Data, Infra/SRE, Support, Compliance). Senza interazione formalizzata aumentano MTTR, CFR e rischi operativi. Lo scopo è quello di trasformare le funzioni separate in un unico sistema operativo: contatti prevedibili, code trasparenti, segnali comuni e priorità coerente.

2) Principi

1. SLO-first: le soluzioni condivise sono collegate a SLO/budget degli errori.
2. Un'unica fonte di verità sono i dashboard, gli statuti e gli artefatti comuni.
3. Limiti e interfacce chiare: ogni coppia di comandi ha il contratto descritto (OLA/Runbook/API).
4. Piccoli battelli e reversibilità: variazioni tramite phicheflagi/canarie, rollback veloce.
5. No blame - yes data - Analisi fatti, miglioramenti - parte obbligatoria del ciclo.
6. Privilegi e privilegi minimi necessari: separazione dei ruoli per le operazioni sensibili.
7. Automatizza la routine, standardizza il resto.

3) Ruoli e RACI (end-to-end)

Head of Ops/SRE Lead è il proprietario dell'armatura operativa, KPI/KRI. A

Service Owners (Payments/Games/KYC/Data) - obiettivi di dominio, modifiche, rischi. A/R

Platform/Infra - accessibilità, performance, release/canarie. R

Risk/Compliance/Security - SoD, RG/KYC/PII, verifiche. C/A

Supporto/CRM - fronte di lamentele, comunicazioni ai giocatori. R/C

On-call IC/CL - Gestione incidenti e update esterni. R

Release Manager - Calendario, CAV, stato delle modifiche. R

Data/Analytics - metriche alimentari e operative, supporto RCA. R/C

4) Contratti di interazione (OLA/SLx)

• Zone di responsabilità: che zona (ad esempio, routing PSP - Payments; cache/database - Infra).
• Target/soglia metriche: MTTA dell'incidente, tempo di risposta all'escalation, finestra post-monitoraggio.
• Code e priorità: P1-P4, criticità aziendale, finestre freeze.
• Interfacce: canali, comandi bot, API/Runbook, cartelle dei proprietari.
• Artefatti: quali documenti/logi/dashboard sono obbligati ad accompagnare l'evento.

5) Canali e protocolli di comunicazione

Chat operatoria - update giornalieri, mini rituali, handover.
I diramatori di incidenti sono creati da un botto; i ruoli IC/CL sono assegnati da un comando.
Canale AB/Change - Discussione dei cambiamenti, dei rischi, del calendario di rilascio.
Stato canale (read-only) - Riepilogo SLO/incidenti/operazioni pianificate.
Ingrandimento: modelli di comando «/page », «/escalate», report SLA.

Un unico protocollo di segnalazione: «Il fatto che la ETA/ETR influisca sulla prossima finestra di update del proprietario».

6) Hendover tra turni e regioni

1. SLO/SLI: dove si rischia di bruciare il budget.

2. Incidenti/escalation aperti e la loro ETA.

3. Lavoro/rilascio programmato nelle prossime 24-48 ore

4. Provider (PSP/KYC/Studio) - Ticket attivi, attesa.

5. Composizione on-call e contatti (IC/CL/domains).

6. Watchlist - Zone di massima attenzione (code/replica/cache).

Hendover è registrato nella rivista di turno, i riferimenti sono i rum e i dashboard.

7) Collaborazione in caso di incidenti

Avvio: l'alert → bot crea la cartella' # inc-YYYY-MM-DD-XXX ', assegna l'IC/CL e le lidi di dominio.
Regola di una voce: IC - soluzione finale; Comunicazione CL.
Fatti e ipotesi: separiamo; I segnali rossi sono la priorità.
Guardrails: phicheflagi/routing PSP cambiano solo tramite runbook con SoD/dual-control.
Comunicazioni: bozze di apdate pubbliche via CL, partner targati.
Chiusura: post-monitoraggio, generazione post mortem e attività di miglioramento con proprietari/scadenze.

8) Collaborazione per le modifiche

Calendario di release: pubblico, con periodi freeze e slot on-call.
Gate di qualità: unit/contract/e2e, sicurezza, SLO-gate staging.
Scansioni canarie: passo per passo del 5%→25%→100% su GEO/tenenti/banche.
Reimpostazione automatica: regole SLI/KRI chiave, registro WORM.
Pacchetti comm: bozze di update concordate in anticipo con CL/Legale.
Le modifiche RI sono: RM (A/R), SO (A/R), SRE (R), Sec/Compliance (C/A), CAV (A), IC/CL (R/C).

9) Telemetria unica e manufatti

Catalogo comune delle metriche: SLI/SLO, metriche aziendali, KRI (code, PSP, replica).
Dashboard Mappe delle Operazioni - resoconto dei domini, regioni, stato degli incidenti/lavori.
Timeline: formato unico (ora, autore, azione, risultato, link).
Post mortem: modello senza accuse, misure di prevenzione, data di revisione.
Runbooks/Checklists: versioned; il link degli alert e delle carte degli incidenti.

10) Priorità e pianificazione

Piano Ops settimanale (30-45 min): allineamento dei rischi top, rilasci, limiti, miglioramenti post mortem.
Le colonne "Backlog Ready" In progress "Validate" Done ", limiti WIP.
Criteri di priorità: impatto su SLO/ricavi/compilazione, dimensione/reversibilità, dipendenza da provider.

11) Matrice di escalation (spremuta)

12) Politici e SoD

SoD/4-eyes: conclusioni/bonus/routing PSP/esportazione PII - solo con doppia approvazione.
Diritti JIT - Escalation temporanea dei privilegi per le azioni runbook.
Criteri dati: proibizione del PII nei canali/dashboard aperti; geo-limite.
Controllo - Registri attività invariati (WORM), revisioni dei criteri.

13) Strumenti di interazione

Incidente-bot: '/incident new ', ruoli, timer di update, bozze di comma, '/runbook', '/flag ', '/config'.
API Metrics: comune SLO-View e KRI, execuplars (trace _ id) per RCA.
Release-portale: manifesti, gate, stato di apertura/ritocco.
Elenco dei proprietari/CMDB: domini, contatti, canali di riserva.

14) Metriche di collaudo (KPI/KRI)

MTTA/MTTR per domini e slot (giorno/notte), percentuale di incidenti catturati prima delle denunce.
Handover Quality - Difetti di trasferimento (voci foglio di assegno non chiuse in tempo).
Cambio collaborazione:% di release con pacchetti comm finiti e nessun rimborso.
Guardrail Discipline: frequenza di violazioni SoD/regole (obiettivo 0).
Comms Cadence: rispetto degli intervalli degli update pubblici a P1/P2.
Post-mortem SLA: percentuale di post-mortem di D + 5, esecuzione delle azioni.
Fair-Share Load: distribuzione di notti/picchi per persona/comando.
Customer Signal Lead - Una lega tra degrado oggettivo e le prime denunce.

15) Road map di implementazione (6-10 settimane)

Ned. 1-2: inventario dei domini/proprietari; Modelli OLA Avvio di un canale sostitutivo e di un foglio di assegno hendover matrice di base delle escalation.
Ned. 3-4: incidente-bot (MVP), canale di stato comune, scheda unica SLO/SLI/KRI; directory runbooks.
Ned. 5-6: CAV/calendario di uscita, pacchetti comm e finestre freeze; SoD/4-eyes per operazioni sensibili.
Ned. 7-8: rivestimenti canari e auto-ritorno come standard; modello post mortem, Exec/Ops-dashboard collaudi.
Ned. 9-10: esercitazioni P1, hendover regionali, controllo WORM, report KPI/KRI, regolazione OLA.

16) Modelli (sezioni)

16. 1 OLA (Payments ↔ Infra/SRE)

yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"

16. 2 foglio di assegno Hendover (10 punti)

1. Stati SLO dei domini

2. Incidenti aperti (ETA/proprietari)

3. Lavoro/rilascio pianificato + finestre di sorveglianza

4. Provider (PSP/KYC/studio) - rischi/attesa

5. Code/replica/cache - lag/anomalie

6. Modifiche ai limiti/ficcoflagi

7. Reclami/ticetti e soglie di carico

8. Piani comm e bozze di stato

9. Composizione on-call e riserva

10. «Watchlist» sullo slot

17) Antipattern

«Qualcuno se ne occuperà?» senza RACI o proprietario.
Incidenti senza IC/CL e timer di update.
Modifiche nascoste (click manuali), nessun Git/Auditel.
Telemetria non comunicata, numeri diversi in squadre diverse.
Rilasci senza pacchetti comm o canarie.
Violazioni soD per la velocità.
Gli Hendover sono verbali, senza registrazioni e senza scontrini.
Post mortem senza azioni o scadenze.

Totale

L'interazione dei comandi nelle operazioni è una collaborazione contrattuale: OLA/SLx, canali e ruoli chiari, disciplina degli hendover, telemetria generale, comunicati coerenti e processi di incidente. Questa struttura riduce MTTR e CFR, allinea le priorità, protegge SLO, fatturato e compagine e rende il lavoro quotidiano prevedibile e sostenibile.