Dashboard operatorio

(Sezione Operazioni e Gestione)

1) Assegnazione e principi

Il dashboard operativo è una finestra unificata per monitorare la salute della piattaforma e agire. Aggregazione metriche, eventi, alert e prestazioni aziendali nel contesto del ruolo utente (SRE, Product, Finanza, Compliance, Support, Partner).

• Actionable by design - Ogni widget ha un pulsante azione (rollback, paul, re-run, re-route).
• Rolle-aware - I diritti e i livelli di dettaglio dipendono dal ruolo/tenante/regione.
• Fonte-of-truth - I numeri corrispondono al biglietto/riviste/ricevute.
• Near-real-time + storytelling: secondi/minuti per incidenti, mesi/anni per trend.
• Esplainability: qualsiasi aggregazione si sviluppa a un evento crude con'trace _ id '.

2) Ruoli e script (chi e perché viene)

SRE/Piattaforma: disponibilità, latitanza p50/p95/p99, errore/retrai, capacity, cost per 1k eventi.
Prodotto/Operazioni: E2E-Success Rate, conversione, tempo di onboording dei partner, phicheflagi.
Finanza/FinOps: ricavi/COGS/CM per unità, egress/ingress, budget e caps, deviazioni.
Compilazione/Sicurezza: ricevute/firme, Richieste PII, violazioni SoD, Stato di riscossione.
Supporto/CS: coda di ticket, MTTA/MTTR, SLA per partner e regioni.
Partner/Tenenti: metriche SLO personalizzate, stati Web, usage e quote.

3) North Star e SLI/SLO chiave

North Star: E2E Success Rate attraverso percorsi critici con target p95 in ogni regione.

• Disponibilità per canale/regione.
• Latenza p50/p95/p99.
• Errore-rate e la parte dei retrai.
• Successo delle consegne Web (% con ricevute).
• Costo 1k eventi e egress/ingress per unità.
• Riepilogo degli incidenti: MTTA, MTTR, errore-budget burn.

• Disponibilità ≥ 99. 95 %/regione/canale.
• p95 120 ms (vetrina), 250 ms (checkout/quota).
• Il successo dei webhoot è stato di 99. 5% per 5 minuti finestra.
• Tra quota e checkout = 0 (© 1 minor unit secondo le regole di distribuzione).
• Tempo di risposta al P1 di 10 min, MTTR di 60 min.

4) Architettura dati dashbord

Pneumatico evento: telemetria (traces/metrics/logs), business events, billing, compilation.
Flusso/aggregazione: finestre T + 5s/T + 1m per near-real-time; CDC/outbox per la consegna garantita.
Storage: time-series (online), OLAP (lunga storia), registri WORM (verifiche).
Livello semantico: dizionario delle metriche, unità, normalizzazione per regione e tenanti.
Linea di materie prime: drill-down a «trace _ id »/« event _ id» e firme (receipt _ hash).

5) Design interfaccia e widget

Cappello globale: filtri (tempo, regione, tenante, prodotto, ambiente), indicatori di stato.
Piastrelle (KPIS): E2E Success, disponibilità, p95, errato-rate, cost/1k, egress.
Grafici: tendenze sparkline, heat-map per regione, grafici perentori.
Tabelle: errori top, partner con degrado, eccesso di quote, incidenti non risolti.
Le sezioni di azione sono «Pausa promo», «Reimpostazione fitch», «Aumento quota», «Riavvia consegna».
Text-help - Suggerimenti sulle metriche/tecniche e la relazione con SLO.

6) Moduli dashbord (set consigliato)

1. Piattaforma di salute: disponibilità/latitanza/errori, burn-down budget.
2. Integrazioni di partnership: stato di webhoop, ricevute, prese idipotenti, code.
3. Checkout & Prezzi: corrispondenza vitrina↔checkout, 'fx _ version', 'tax _ rule _ version', guasto-valigetta.
4. Contenuto/Directory: tempo di pubblicazione, errori cache/disabile, freshness.
5. RTP & Limits (se applicabile) - Teor. vs observed RTP, l'attivazione dei limiti, l'esposizione.
6. FinOps: COGS/unità, egress/ingress, compute/storage, budget/cap-alert.
7. Sicurezza/Compliance: SoD, JIT, MFA, transazioni firmate, richieste PII e registri.
8. Supporto: code, MTTA/MTTR, motivi, runbook auto.
9. Release/Feature Flags - Stati di rilascio, regioni canarie, schede automatiche di regressione con incidenti.
10. Experimenti: A/B guardrails, effetto del fiocco su SLI/RE.

7) Alerti, rune e escalation

Alert di livello P1-P3 con rumore e deduplicazione per «trace _ id».
Runbook automatico - Quando si attiva, si avviano controlli/registri (pulizia cache, interruzione routing, pausa promo).
Scala: matrice 24 x 7, risposta SLO, canali (chat/voice/SMS), pulsante rosso.
Post-input - Modelli di report con relazioni causali e action items.

8) Multiregionalità e multi-tenant

Tagli: regione/tenente/canale/provider, SLO indipendenti e budget.
Zone di fiducia: i dati PII/finanza sono visibili solo nelle rispettive aree, gli altri sono aggregati.
Cost-aware: confronto tra le rotte e il prezzo a p95; linee guida per l'ottimizzazione.

9) Sicurezza e privacy

RBAC/ABAC: visibilità e azioni sui ruoli; ReBAC per la proprietà del prodotto/tenante.
Firme e ricevute: per eventi finanziari/critici - hashtag e ricevute DSSE.
Igiene PII - Tornizzazione, occultamento, accesso solo tramite jobs approvati.
Controllo: registri WORM per modificare configuri, ruoli/limiti, riproducibilità.

10) Modello dati metriche (esempio)

`metric` `{name, unit, type: counter/gauge/hist, owner, sla_ref}`

`dim` `{region, tenant, product, provider, version, environment}`

`point` `{metric, value, ts, dims{}, trace_id, signature?}`

`event` `{type, severity, subject_id, payload_hash, receipt_hash, ts}`

`slo` `{name, target, window, burn_rate, owners[], runbook_url}`

`alert` `{slo_ref, condition, status, ack_by, acknowledged_at, runbook_step}`

11) API/webhoop dashbord

"POST/ingest/metrics' - ricezione di metriche (schema, limiti, autenticazione).
«POST/ingest/events» è un evento aziendale (versioni/firme).
`GET /kpis? filters... '- apparecchi per widget.
«GET/traces/{ trace _ id}» è una promozione profonda.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookDeliveryLag`, `SecuritySoDViolation`.

12) Qualità dei dati e test

Data contracts: schemi e convalida in ricezione, versioning ('expand' migrate 'contract').
Anomalie: monitoraggio dei passaggi/corse, soglie flatline/noise.
Samplace: per alta-QPS, le metriche sono scorrevoli, mantenendo la rappresentatività.
Download sicuri con contrassegno di versione di Backfill.

13) Metriche del dashbord stesso (metriche di metriche)

Disponibilità UI/API ≥ 99. 9%.
Latency p95 richieste API da 300 mc.
Completeness, la percentuale di fonti che hanno inviato i dati alla finestra è di 99. 5%.

Freshness: gruppo di aggiornamenti incrementali da 30 secondi

Correctness: soluzione temporanea con report di riferimento ≤ 0. 1%.

14) Economia e FinOps nel dashbord

Cost per 1k eventi con decomposizione per provider/regione.
Egress/Ingress mappe termiche, raccomandazioni di cache/routing.
Budget/cap-alert: 80/90/100%, autotrasportaggio e priorità.

15) Disponibilità e UX

Tema notturno, firme brevi, icone di stato.
Navigazione a tastiera e a11y: contrasto, alt, etichette aria.
I preset salvati sono SRE, finanza, partner.
Snapshot e shering - Registra lo stato con filtri e riferimenti/esportazioni.

16) Rischi e anti-pattern

Dash-sprawl: 20 dashboard diversi senza un unico dizionario di metriche.
Le metriche Vanity sono bellissime grafiche senza collegamento con le attività SLO.
Numeri irrecuperabili, rapporti di ≠/verifica.
Alert rumorosi, stanchezza e pass P1.
Nessun drill-down - Impossibile raggiungere il primogenito e le cause.

17) Assegno-foglio di implementazione

• Definire ruoli e script concordare North Star e SLI/SLO.
• Creare un dizionario di metriche e unità formalizzare data contracts.
• Configura ingest (metrics/events/traces), OLAP e controllo WORM.
• Implementare i moduli chiave (salute, partner, checkout, FinOps, sicurezza).
• Includere gli alerti con le rune e le escalation; «pulsante rosso».
• Aggiungi azioni: rollback/pausa/re-route/raise-limit.
• Costruire heat-map per regione/tenore; filtri e presetti.
• Convalida il saldo dei numeri con il biglietto/ricevute.
• Gioco-giorno (GameDay): disattivazione del provider, valanga di retrachi, risincronizzazione dei prezzi.
• Ringhiera settimanale SLO e post-mortem-qualità.

18) RACI

19) FAQ

È possibile sostituire tutti i rapporti con un dashboard?
No, no. Dashboard - per l'operatività e le azioni; rapporti/verifiche formali sono manufatti separati.

Quanto tempo ci vuole?
Per gli incidenti - secondi/minuti, per l'economia - minuti/ore; la coerenza è importante, non l'assoluta «online».

Come si combatte il rumore degli alert?
Condizioni orientate SLO, aggregazione, deduplicazione «trace _ id», priorità e runbook automatico.

Come faccio a controllare la correttezza delle metriche?
Controlli regolari con report di riferimento, fidi di prova, controlli e registri WORM.

Riepilogo: Il dashboard operativo non è una «bella tavola», ma uno strumento di controllo: un unico SLI/SLO, azioni dall'interfaccia, tracciamento alla materia prima e rigorosa coerenza con il bollettino e l'udienza. Costruitelo su un'architettura di eventi, fornite un contesto di ruolo, aggiungete rune e scalate per ottenere operazioni prevedibili, soluzioni rapide e una crescita sostenibile.