SLO, SLA e monitoraggio dell'affidabilità

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

SLO è un obiettivo interno di qualità, SLA è un obbligo esterno verso il cliente, SLI - come misuriamo la qualità. I principali SLI includono la disponibilità di API e pagamenti, p95/p99 latitanza delle rotte critiche, Time-to-Wallet (TTW), conversione dei pagamenti, avvio dei giochi e metriche delle code. La gestione dell'affidabilità si basa su budget di errori, multi-burn alert, gate chiari di rilascio e dashboard visibili con annotazioni.

1) Termini e differenze

SLI (Service Level Indicator) - Indicatore misurato (ad esempio, percentuale di richieste di successo per finestra di tempo).
SLO (Service Level Objective) - Destinazione SLI (ad esempio, "disponibilità 99. 9% in 30 giorni").
SLA (Service Level Agreement) - contratto/obbligo di compensazione; basato su un vero SLO, ma include riserve legali e finestre di esclusione (planned mainenance, forza maggiore).

Regola: prima stabilizzate la SLI/SLO all'interno e poi fissate la SLA all'esterno.

2) Ossatura SLI per iGaming

TexSLO

Availability: tutte le richieste di successo 2xx/3xx.
Latency: p95/p99 per rotiti chiave ('/deposit ', '/bet', '/game/init ').
Errors, quota 5xx/timeout.
Saturation/Queues: ritardo delle code di pagamento/transazione.

SLI aziendale

Payment conversion: `success/attempt`.
TTW p95: tempo dalla richiesta di ritiro all'iscrizione.
Game start success: sessioni di giochi, inizializzazione del provider.
KYC/AML flow success: completamento del percorso completato.

3) Bilancio degli errori: come contare

Error Budget = 1 − SLO.
Esempio: SLO di disponibilità 99. 9 %/30d bilancio degli errori = 0. L' 1% del tempo ha ≈ 43mn 12s in una finestra di 30 giorni.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

La SLO è considerata sulla finestra di scorrimento (30/7/1 giorno) ed è visibile sui dashboard.

• La rapida «combustione» del budget, i rilasci freeze, il canarino, lavoriamo sulla stabilità.
• Il budget → consente modifiche più frequenti (controllate).

4) Esempi di SLO per flussi chiave

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (output) 3 min/24h

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success 99 %/7d, lega <5 min (finestre di punta separate).

5) Misurazione: formule e PromQL (idee)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-rate alert (multi-window)

L'idea è di confrontare la velocità attuale del budget con quella valida.

• Fast burn: 14 x di budget in un'ora di programmazione tra 5-15 minuti.
• Slow burn: 6 budget in 24 ore.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Dashboard «SLO Card» e operatore

• Carte di servizio: Availability, p95, Errore-rate, Burn-rate, Saldo Errore Budget.
• Filtri: «env», «region», «tenant», «variante».
• Annotazioni di rilascio: Git SHA, tipo (canary/blue-green), ora di cambio.

• Confronto stabile vs canary.
• Taglio per PSP/provider di giochi.
• Passa agli exemplars (trace _ id) e ai fogli associati.
• Queue lag e saturation (metriche USE).

8) Processi SLO: gate, freeze, escalation

Gates in CD: la promozione dei canarini è consentita solo se eseguite il proxy SLO (availability, p95, 1962).
Freeze: con fast-burn o saldo del budget zero - Stop delle release prima del ripristino.
Escalation: matrice SEC (SEV1 pagamenti/depositi, giochi SEV2, becofis SEV3).
RCA: analisi senza accuse, aggiornamento dei test/limiti/ficcoflagi.

9) Data/ML-SLO (per raccomandatori/LLM)

Latency: p95 risposta modello ≤ 300 ms (o tokens/s ≥ N).
Quality proxy - percentuale di risposte validi/bassa tossicità, share of helpful.
Freshness: Età dei file/dati X ore.
Cost per 1k events - spese in bilancio.
I gate SLO sono integrati nelle release dei modelli (A/B/rollout canario).

10) Progettazione SLA basata su SLO

Scegli SLO conservatori come base SLA.
Identificare le eccezioni (operazioni pianificate, fornitori di servizi dipendenti esterni, regolamento degli incidenti).
Immettere i compensi relativi ai livelli di infrazione (credito/sconto), ai meccanismi di segnalazione e verifica.

11) Errori frequenti e anti-pattern

No SLO, solo «uptime 100%» è irrealistico, demotivante e nasconde i rischi.
Alert per «ogni metrica» invece di burn-rate - alert-fetig e ignora.
Miscelazione PII in metriche/logi per SLO - Rischi di compilazione.
La cardinalità esplode come etichette.
Nessuna annotazione di rilascio - È difficile associare il degrado alle modifiche.
Budget degli errori opaco - il team non capisce quando si può rischiare.
La SLO non è collegata agli affari - la tecnologia verde, il ricavato rosso.

12) Assegno foglio di implementazione

1. Approva le SLI di base (Availability, p95/p99, Errore-rate, TTW, Conversion).
2. Impostate lo SLO sulle finestre da 30/7/1 giorno e contate l'Errore Budget.
3. Aggiungi recording rule e burn-rate alert (fast/slow).
4. Costruisci una mappa SLO con annotazioni di release e confronti canary/stabile.
5. Includere i gate nel CD senza SLO-OK senza promozione.
6. Immettere le procedure freeze e la matrice SEC delle escalation.
7. Collegare SLO alle metriche aziendali (1962, TTW) e ai percorsi di pagamento.
8. Per Data/ML, definire latency/quality/freshness-SLO.
9. RCA regolari e revisione SLO/soglie (trimestrale).
10. Documentazione SLA solo dopo la stabilizzazione SLO.

13) Esempi di obiettivi «finiti» (come partenza)

API comuni: Availability 99. 9 %/30d; p95 ≤ 250 ms/30d; Error-rate ≤ 0. 3 %/30d.
Payments: Conversion ≥ baseline − 0. 3 %/24h; TTW p95 ≤ 3 min/24h.
Games init: Success ≥ 99. 5 %/7d; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness 6h.

Riepilogo

L'approccio SLO/SLA trasforma l'affidabilità da «migliore di ieri» in una disciplina misurabile: SLI trasparenti, bilancio comprensibile degli errori, alert per la velocità di combustione, dashboard comprensibili e gate di qualità integrati nelle release. Questo tracciato dà alla piattaforma iGaming prevedibile p95/p99, pagamenti stabili e TTW, quindi migliori ricavi e meno incidenti nelle ore più calde.