Operazioni e Controllo → Controllo delle metriche e SLA

Controllo delle metriche e SLA

1) Perché è necessario

Se le metriche non sono corrette, le soluzioni non saranno corrette, la SLA verrà violata sulla carta o al contrario nasconderà i problemi. Il controllo delle metriche e della SLA garantisce la comparabilità, la validità e la protezione legale delle promesse verso utenti e partner.

• Fornisce un'unica «fonte di verità» (SSOT) e calcoli riproducibili.
• Riduce le discrepanze tra dashboard, report/bollo.
• Rende SLA fattibile e verificabile (evidence-based).
• È presto per rilevare il degrado nelle dimensioni come nei servizi.

2) Concetti di base e limiti di responsabilità

Metric - Valore misurato (RPS, p95, CR, GGR, Success Rate).
KPI/OKR - Obiettivi a cui le metriche sono legate.
SLO: servizio di qualità mirata (ad esempio «p99» 400 ms 99. 9% del tempo").
SLA: una promessa esterna; giuridicamente rilevante, basato su SLO.
OLA - Accordo interno tra team/venditori, supporta SLA.
SSOT: sistema/storage i cui dati sono considerati di riferimento per i report.

3) Tassonomia metriche (livelli)

1. Infrastruttura: CPU/Memory/IO/Net, sotto/sito, HPA/VPA.
2. Piattaforma: code/striam (lag, throughput), database/cache (connettori, hit), API (p95/p99, 5xx).
3. Flussi di lavoro: depositi/conclusioni, scommesse, avvio giochi, autorizzazioni, KYC.
4. Prodotto/marketing: conversioni, ARPPU/LTV, campagne.
5. Qualità dei processi: MTTA/MTTR, Cambio Failure Rate, copertura degli assegni.

Regola: ogni metrica deve avere uno strato, un proprietario e una formula.

4) Origini dati e verità

Telemetria online: Prometheus/OTel, logi (ELK/ClickHouse), tracciabili.
Eventi e contabilità: Kafka/Outbox, DWH/data-firma (BigQuery/ClickHouse).
Manufatti manuali, postmortem, ticket, registri degli incidenti.
Registri esterni: Report provider (PSP/KYC/Studio), bollo.

Risoluzione dei conflitti: le soluzioni online vs DWH hanno un regolamento di priorità (ad esempio, le unità SLA da DWH con tracciabilità sorgente).

5) Processo di controllo delle metriche (tracciato di controllo)

1. Inventario: catalogo metriche/SLO/SLA (nome, proprietario, livello, formula, origine, frequenza di calcolo).
2. Verifica delle formule - Comprimere le query SQL/prom con la definizione (test unit di calcolo).
3. Simulazione e ricontrollo: campionamenti di righe di eventi/fogli e compressione manuale.
4. Mappatura dei tracciati: confronta i report dashboard online e DWH.
5. Controllo delle modifiche: ruota le formule nelle release di diagrammi/logiche.
6. Controllo SLA - Verifica della correttezza degli assiemi e delle eccezioni (planned mainenance, forza maggiore).
7. Report e miglioramenti: elenco delle soluzioni temporanee rilevate e dei record con deadline.

6) Definizioni e formule (campioni)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• SSOT fissa un'unica definizione di finestra (rolling 5m/1h) e aggregazione (HDR/TDigest).

• 'SLO _ availability _ month = (tempo di lavoro - eccezioni consentite )/tempo _ totale '

• `SLA_month = 99. Il 90% della farmacia UTC, escluse le finestre di pianificazione (T-48 notifiche), gli incidenti dimostrabili negli operatori di transito (documenti) '

7) Qualità dei dati: controlli e alert

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Tempestività (timelava): la lega di carico del ≤ N minuti.
• Univoco (uniqueness) - Senza doppie di chiave (idempotency-key).
• Coerenza (consistency): importi/valuta/caratteri.
• Linearità (monotonicity) - I contatori non vengono rimossi.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Controllo SLA/OLA: metodologia

1. Raccogli il calendario delle eccezioni, le finestre pianificate, il degrado concordato, gli atti dei venditori.
2. Calcolo della farmacia per un'unica zona temporale, con supporto SSOT.
3. Incrociando gli incidenti, timeline, biglietti, postmortem.
4. Assegnazione: guasti personali, provider, transito, DDoS, lavori regolamentari.
5. Perimetro SLA: esperienza utente (E2E) vs una API specifica.
6. Report mensile/trimestre: fatto, rifiuto, risarcimento (se applicabile), misure correttive.

9) Verifica della riproduzione dei calcoli

Versioning delle formule: repository git con SQL/PromQL/dock-specifiche.
Test unit delle metriche sui dati synthetic (edge-valigette: omissioni, riprese, limiti di data).
Data lineage - Da dashbord a tabella ed eventi originali.
Snapshot: congelamento dei dati di alloggiamento in modo che i calcoli delle penne siano comparabili.

10) Campionamenti di controllo (sampling)

Ogni giorno: 10-20 eventi per flussi chiave (deposito/tasso/CUS) - Comprimere manualmente il tracciamento del ↔ DWH.
Ogni settimana: 1% sample per confrontare «online vs DWH» per aggregazione.
Ogni mese, una serie di incidenti con effetto SLA - ricostruzione dettagliata.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Controllo dei dashboard e degli avvisi

Un unico dizionario di metriche, un glossario proprio sul dashbord.
Annotazioni di rilascio/event - Per visualizzare la causa delle anomalie.
Confronto prima/dopo il lancio: pannelli di regressione automatici.
Ripresa/soluzione temporanea: identificazione di due p99 diversi - Modifica di formule/finestre.
Disponibilità dei pannelli: diritti, riserva, controllo dei collegamenti/versioni.

12) Gestione delle modifiche alle metriche

Processo RFC: modifica della formula/finestra/sorgente tramite RFC per valutare l'impatto su SLA/report.
Migrazione «expand → migrate → contract»: gestiamo temporaneamente entrambe le versioni, confrontiamo, quindi disattiviamo quella precedente.
Comunicazioni: notifica in anticipo al prodotto/business gli spostamenti dei valori «con la nuova metodologia».

13) Specifiche iGaming/Fintech

Picchi di domanda: le metriche devono resistere a carichi esplosivi (le aggregazioni non sono «piegate»).
Provider: La SLA dipende dai venditori OLA di memorizzare i loro rapporti, gli stati degli incidenti e le quote.
Costo: «cost _ per _ 1k _ calls» e «costo di successo» - pannelli obbligatori.
Antifrode/rischio: sensibilità ai ritardi e ai falsi effetti delle metriche.

14) Dashboard di controllo (set minimo)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: SLO calcolato, SLA effettivo, eccezioni, riferimenti a incidenti/atti.
Online vs DWH Compare: p95/p99/Success Rate, deviazioni e tendenze.
Vendor SLA: farmacie/quote/time-out/costo nel taglio dei provider.
Effetto Release: regressione delle metriche dopo l'accensione/l'accensione del filetto.

15) Foglio di controllo (operativo)

• Il catalogo delle metriche/SLO/SLA con i proprietari e le formule è valido.
• SSOT definito per ogni report/pannello.
• Test unit delle formule verdi, calcoli pipeline documentati.
• Gli alert sulla qualità dei dati sono attivi (completeness/timelansa/duplicates).
• «Online vs DWH» di una soluzione temporanea valida (ad esempio, %).
• Le eccezioni SLA concordate sono documentate e allegate al report.
• Sono stati effettuati dei controlli e sono stati compilati degli atti.
• Tutti i cambiamenti di formula sono stati RFC e migrazione.

16) Esempi (sezioni)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-pattern

Due diverse formule di metriche su pannelli diversi.
La modifica della metrica senza migrazione e notifica è «salto» in OKR/SLA.
Report in Excel locale come «verità» (impermeabile).
Miscela fusi orari e calendari nei calcoli SLA.
Le eccezioni SLA non sono documentate.
Niente alert sulla qualità delle misure.

18) KPI maturità misurazione

Draft Rate Online↔DWH (obiettivo ≤2%).
Metrics Health Uptime (tempo senza degrado ingest/ETL).
Time-to-Fix Formula (tempo di risoluzione dell'errore nella formula).
SLA Dispute Rate (frequenza delle valigette controverse con i partner).
Coverage SLO/SLA (percentuale di percorsi critici con SLO/SLA).

19) Ruoli e responsabilità

Proprietario della metrica/servizio: formula, sorgente, dashboard, alert.
Osservabilità/SRE: SSOT/piattaforma, test di formula, alert di qualità dei dati.
Data/BI: DWH, riproduzione dei report, lineage.
Avvocati/soci manager: accordi SLA e eccezioni.
Il responsabile dell'incidente è l'attribuzione e il collegamento degli incidenti con la SLA.

20) Partenza rapida (30 giorni)

Settimana 1: inventario delle metriche/SLO/SLA e dei proprietari; assegnare SSOT.
Settimana 2: abilita gli alert di qualità dei dati e il pannello «Online vs DWH».
Settimana 3: eseguire i controlli, allineare la finestra p95/p99.
Settimana 4: formalizzare il processo RFC per le formule, preparare un rapporto mensile SLA con le applicazioni.

21) FAQ

Q: Cosa conta SSOT per SLA?
A: Storage con calcolo riproduttivo (DWH) e lineage completo i pannelli online sono per il controllo operativo, non per gli atti legali.

Come si combatte il «due p99»?
A: Fissa la finestra/metodo di aggregazione nella directory delle metriche, migra i pannelli, aggiungi alert alla deriva.

Q: Come si tiene conto del lavoro programmato?
A: Tenere il calendario delle eccezioni e sottrarle automaticamente alla SLA secondo le regole contrattuali; Conservare gli artefatti di prova.