Osservabilità e controllo dello stato
1) Obiettivi e principi
L'obiettivo è capire in tempo reale «cosa sta succedendo» e «perché», per prevenire gli incidenti e riprendersi rapidamente, senza compromettere la SLO o gonfiare l'OPEX.
Principi: SLO-first, «segnali d'oro» (latency, traffic, errors, saturation), standard unico di telemetria (OpenTelemetry), dettagli sufficienti, spiegabilità e osservazione cost-aware.
2) Livelli di osservabilità
1. Metriche: unità per SLI/SLO, capacity e tendenze (modelli RED/USE).
2. Trailer: catene causali di richieste, transazioni di pagamento e di gioco.
3. Login/Ivent: contesto dettagliato e controllo delle attività degli operatori/servizi.
4. Sintetica (black-box): controlli esterni API/percorsi Web, PSP/KYC hels-pings.
5. RUM (utente reale) - Metriche frontali (TTFB, LCP, errori JS), geo/device di taglio.
6. Telemetria a basso livello: eBPF/profiling CPU/IO/alloc, ritardi perentori di rete.
3) Set di SLI e «segnali d'oro»
Latency: p50/p95/p99 per vie critiche (login, deposito, tasso, conclusione).
Errors: quota 5xx/timeout/decline (con normalizzazione per provider/banche).
Traffic/Throughput: RPS/TPS, sessioni attive, eventi/secondi.
Saturation: caricamento CPU/RAM/IO, profondità delle code, pool-usage, replication lag.
Business SLI: depositi/tassi di successo% per finestra, deviazioni di conversione KYC/PSP, quota di marceback.
4) Architettura della telemetria
Iniezione standard: SDK/detector, normalizzazione, sempling, privacy-filtri di storage (TSDB, tracciabili, logi).
Correlazione trace-id/span-id in logi e metriche (exemplars) un unico correlation-id per i pagamenti/eventi di gioco.
Topologia - Servizio mapha (service graph), provider esterni dipendenti con SLI vivi.
Gestione dei costi: livelli di retenza, aggregazione, sempling dinamico, classi di storage calde/fredde.
5) Metriche: design e cardinalità
Regole: numero ridotto di etichette, divieto di alta-cardinalità (userId, sessionId) in time-series; Questi dettagli sono solo nelle piste/fogli.
RED/USE: Requests-Errors-Duration для API; Utilization-Saturation-Errors per l'infrastruttura.
Excplars - Allinea le percentili alte a esempi specifici trace.
Metriche aziendali: $/RPS, conversione PSP su banche/GEO, disponibilità dei provider.
6) Tracing: profondità e sempling
Contesto: percorriamo il contesto trace attraverso il fronte dell'API i broker i worker del database/PSP.
Sempling: base 1-10%, anomalie - aumento dinamico delle regole (tail-based).
Attivo: flow di pagamento (init → auth → capture/settle), transazioni di gioco (bet → settle), KYC (init → verify).
Annotazioni: PSP di risposta, banca-BIN/issuer-categoria, regione, rischio-scansione.
7) Logi e verifiche
Fogli strutturati: JSON, livello profilo (INFO in vendita, DEBUG in debug).
Filtri di privacy: maschera PII, disabilita documenti crudi KYC nei fogli.
Eventi di verifica: chi/cosa/quando/perché, ID ticetta, pre/post per le operazioni ad alto rischio (bonus, limiti, routing PSP).
Idoneità: WORM/immutabile, firma, ritocco di criteri.
8) Controllo dello stato (health)
Liveness/Readover/Startup - Campioni corretti (non controllare le dipendenze esterne in liveness).
Degraded-mode - chiare bandiere di degrado del servizio in modo che gli alert e la pagina di stato siano concordati.
Budget health: bilancio di errore burn-rate (finestra veloce/lenta), headroom per risorse e code.
9) Alerting e avviso precoce
SLO-alert: bilancio degli errori (4 ore e 1 ora di finestra) invece di «grezzo» p95.
Anomalie: STL/IQR/rilevatori online per picchi 5xx, caduta di autorizzazioni PSP in una particolare GEO/banca.
Root-cause hints - Collegare gli alert alle ultime release/ficcoflag/operazioni pianificate.
Runbooks: ogni alert ha linette per playbook, grafici, controlli rapidi.
10) Dashboard (chi e cosa vede)
Exec: farmacia/SLO, burn-rate, depositi/tassi di successo, stato dei provider, previsione di capacità e $/RPS.
SRE/piattaforma: RED/USE per servizi, code/lag, pool-usage, replication lag, CDN/WAF, profili eBPF.
Payments/Risk: successo delle autorizzazioni PSP/banche/GEO, soft/hard decolli, tempo KYC, chargeback early-signals.
Supporto/CS: la barra degli incidenti, le risposte SLA, le macro FAQ.
11) Controllo del costo di osservazione (FinOps-Observability)
Retenschn: 7-14 giorni per le piste crude, unità più lunghe; Servizi a caldo selettivo.
Sampling/aggregazione: sempling dinamico per anomalie, downsampling vecchie righe.
Criteri Ingest - Ritaglia il rumore (ping health, loghi ridondanti), quote di alta-cardinality metriche.
Valore KPI: $/GB ingest, $/trace, $/SLI dashbord; ringhiera periodica dei migliori mangiatori.
12) Privacy e compliance
PII/finanza: occultamento, tornizzazione, minimizzazione dei dati in telemetria.
Geo-localizzazione: archiviazione e elaborazione giurisdizionale loga-esportazione: solo tramite workflow autorizzati con crittografia e TTL.
Controllo dell'accesso alla telemetria: RBAC/ABAC, SoD per scaricare, registro delle richieste.
13) Integrazione con gestione e comunicati incidenti
La pagina di stato è il fido automatico degli update della scheda di emergenza.
Release-gate: SLI, rilascio automatico a burn-rate> soglia.
Post-mortem - Timeline da piste/logi, SLI effettivi e finestre di infrazione.
14) Implementazione pratica (8-12 settimane)
Ned. 1-2: inventario di percorsi critici e SLI; Selezione della pila (OTTEL, TSDB, fogli, piste) la mappa delle dipendenze.
Ned. 3-4: implementazione di OTTEL in 3-5 servizi chiave (login/deposito/tasso), RED/USE di base, contesto trace nel login.
Ned. 5-6: SLO e burn-rate-alert; sintetico PSP/KYC; i primi runbooks; RUM sul web/mobile.
Ned. 7-8: sempling dinamico, exemplars, servizio-mapha; dashboard Exec/SRE/Payments.
Ned. 9-10: eBPF/profiling dei colli di bottiglia; filtri privacy quote/retenze.
Ned. 11-12: lancio-gate e auto-rollback SLI; Integrazione con lo stato della pagina esercitazioni tabletop.
15) Modelli di manufatti
Scheda SLO del servizio: SLI, obiettivi, finestre, bilancio degli errori, alert, proprietari.
Alert Spec: metrica/condizione, soglie, deadup/silens, destinatari, runbook.
Dashboard Spec: pubblico, domande, 6-8 widget, origine dati, frequenza di aggiornamento.
Policy - Quali campi sono validi/non consentiti, retino, maschera, esportazione.
Cost Review Pack: top series/logg-stream, offerta di sampling/TTL, risparmio previsto.
16) Funzioni di osservazione KPI
MTTA/MTTR (miglioramento dopo l'implementazione dell'alerting SLO).
% degli incidenti rilevati dalla sintetica/SLI prima delle lamentele degli utenti.
Percentuale di rilasci effettuati dal gate SLI senza interferenze manuali.
Riduzione di $/RPS per la telemetria mantenendo la diagnosi.
Copertura tracciabile dei percorsi critici (> 90%).
Precisione della correlazione "update di stato" SLI effettivi ".
17) Antipattern
«Tutto logico» è un'esplosione di valore e rumore.
Alert per metriche «crude» invece di SLO/burn-rate-pager-fatige.
Alta cardinalità delle metriche ( ) della tempesta TSDB.
I trailer senza contesto aziendale (PSP/banca/GEO) non sono insiti.
Non c'è nessun collegamento di osservabilità con i comunicati/incidenti della telemetria.
Totale
L'osservabilità e il controllo dello stato non sono una serie di strumenti, ma un sistema gestito: SLI/SLO corretti, telemetria standardizzata e correlazione tra SLO-alerting e runbooks, integrazione con le release e lo status-comunicazione cost-aware di funzionamento e privacy. Questo tracciato fornisce segnali iniziali, RCA veloce e stabilità aziendale anche in picchi estremi di traffico.