Alerting e risposta ai guasti

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Un forte alerting è un segnale di violazione del valore degli utenti, non solo una metrica rossa. Per i iGaming sono importanti le regole SLO (latitanza, disponibilità, conversione dei pagamenti, Time-to-Wallet), multi-burn, i ruoli chiari on-call, escalation, ChatOps e runbooks. Lo scopo è quello di vedere rapidamente la deviazione, informare coloro che sono in grado di correggere e fissare la conoscenza per la prossima volta reagire ancora più velocemente e meno costoso.

1) Base: da metriche a azioni

SLI-SLO-Alert: qualità misurabile, livello target, condizioni di bilancio in fiamme.
Severity (SEC): SEV1 è critica (ricavi/GGR a rischio), SEV2 è seria, SEV3 è moderata, SEV4 è minore.
Impatto/Urgency: chi soffre (tutto/regione/tenente/canale) e quanto è urgente ( , , - ).
Actionability: per ogni ansia, un'azione specifica (runbook + proprietario).

2) Tassonomia dei segnali

ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
Business SLO: conversione dei pagamenti (attempt→success), Time-to-Wallet (TTW), successo delle scommesse, esecuzione dei giochi.
Percorsi di pagamento: metriche specifiche PSP (timeout/decline spikes).
Fronte/mobile: metriche RUM (LCP/INP), crash-rate, sintetico degli script (login/deposito/tasso/output).

3) Criteri di alerting: SLO e burn-rate

Esempi SLI/SLO

Disponibilità dì payments-api '99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d

Conversione dì "baseline - 0. 3% / 24h

TTW p95 3 min/24h

Multi-window / Multi-burn (идея PromQL)

Fast burn: violazione dello SLO 5-10 x più veloce della norma (alert-page 5-15 min).
Slow burn: aumento del budget lento (ticket + analisi in 1-3 ore).

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4) Rumore e qualità dei segnali

La giusta fonte di verità è allinearsi per aggregazioni (recording rule), non per espressioni pesanti «crude».
Deduplicazione: Alertmanager raggruppa in «service/region/severity».
Gerarchia: prima alert per business/SLI, sotto c'è la tecnologia come diagnostica.
Supressione: durante il rilascio planned-mainenance (annotazioni), durante gli incidenti upstream.
Cardinalità: non usare «user _ id/pression _ id» nelle etichette degli alert.
Test alert - Trigger di apprendimento regolari (controllo dei canali, dei ruoli, dei collegamenti runabook).

5) Alertmanager: routing e escalation

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

Idea: SEC = page ; Il resto è Slack/Ticket. L'inibizione sopprime il «rumore» dei livelli inferiori quando il SEC attivo è superiore.

6) Grafana Alerting (come strato)

Alert rule centralizzati su dashboard (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Attività programmate, migrazioni, release.
Snapshots con lo screenshot automatico del pannello in ticket.

7) On-call e processi «vivi»

Rotazione: linea 1 (SRE/piattaforma), linea 2 (proprietario del servizio), 3 (DB/Payments/Sec).

Reazioni SLA: riconoscimento di 5 min (SEV1), diagnosi di 15 min, comunicazioni ogni 15-30 minuti

I canali di servizio sono «# incident-warroom», «# status-updates» (solo fatti).
Runbooks: riferimento in ogni alert + comandi veloci ('/rollback ', '/freeze', '/scale ').
Allarmi di formazione mensili (controllo delle persone, dei canali, dell'attualità runabook).

8) Incidenti: ciclo di vita

1. L'oggetto (alert/report/sintetico) è Acknowledge on-call.
2. Triage - Identificare le SV/interessate/ipotesi, aprire la war room.
3. Stabilizzazione: rotoli/rientro/ridimensionamento/ficcoflagi.

5. Chiusura: conferma del ripristino SLO.

6. Post-Incent Review (RCA): 24-72 ore, senza accuse, action items.

• Cosa è rotto/chi ha colpito (regione/tenante/canale)
• Quando è iniziato/SEC
• Misure temporanee (mitigation)
• Prossimo aggiornamento dello stato in N minuti
• Contatto (Gestione incidenti)

9) Specificità delle zone «dolore» e degli alert

Payments/TTW: percentuale di timeout PSP, aumento dei guasti di codice, TTW p95> 3m

Picchi tornei: p99 API/orario di inizio giochi/queue lag; esplorazione dei limiti/auto-scale.
Le conclusioni dei fondi sono SLA backofis/controlli manuali, limiti per paese.
Provider di giochi: disponibilità negli studi, tempo di inizializzazione della sessione, avvio in calo.
RG/Compliance: picchi di lunghe sessioni/» raggiungimento», il superamento delle soglie non è un server, ma un ticket + notifica al comando RG.

10) Esempi di regole (opzionale)

Alta latitudine p95 (API)

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

Coda di conclusioni «brucia»

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

Conversione dei pagamenti richiesta

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11) ChatOps e automazione

Posting automatico degli alert con pulsanti di azione: Stop canary, Rollback, Scale + N.

Scorciatoie di comando: '/incident start ', '/status update', '/call ', '/grafana '

I bot trascinano il contesto: gli ultimi deploi, il conte delle dipendenze, gli esempi di trace (exemplars), i tickets associati.

12) Post-incidente (RCA)

I fatti sono la timeline che hanno visto/provato, che ha funzionato.
Root cause - ragioni tecniche e organizzative.
Detection & Defense: quali segnali hanno aiutato/deluso.
Action items: attività specifiche (SLO/alert/codici/limiti/test/runabook).
Date & owners: tempi e responsabilità; sessione follow-up tra 2-4 settimane.

13) Assegno-foglio di implementazione

1. Definire SLI/SLO per i flussi chiave (API/Payments/Games/TTW).
2. Configura recording rule e multi-burn alert + routing Alertmanager.
3. Immettere on-call con rotazione, SLO reazioni e scalate.
4. Collegare gli alert ai comandi runbooks e ChatOps.
5. Regolare le soppressioni o le finestre silenziose, le annotazioni di rilascio/lavoro.
6. Fare istruzioni e script game-day (calo PSP, crescita p99, crescita queue lag).
7. Misura Alert Quality: MTTA/MTTR,% noisy/false, coverage SLO.
8. RCA regolari e revisione delle soglie/processi.
9. Immettere lo stato di comunicazione con il business/zapport (modelli).
10. Documentare tutto come codice: regole, percorsi, link runabook.

14) Anti-pattern

Alerting per ogni metrica, alert-fetig, ignora.
Non c'è nessun SLO che non sappia cosa sia normale e cosa stia bruciando.
Nessuna soppressione/inibizione è una valanga di duplicati.
Paige di notte per eventi minori (SEC non è compatibile con l'Impatto).
Alert senza runbook/proprietario.
Azioni manuali senza ChatOps/Check-In.
Niente RCA/Action items per ripetere gli incidenti.

Riepilogo

Alerting e risposta sono un processo, non un insieme di regole. Collegare lo SLO ai multi-burn-alert, creare un'escalation on-call chiara, aggiungere runabook vivente e rustico, organizzare regolarmente RCA e allenamento. Allora gli incidenti saranno più rari, più brevi e più economici, e i comunicati sono prevedibili anche nelle ore calde.