Il dato c’è. Possiamo fidarci?

Dalla serie

Obiettivo

Definire e verificare il contratto di una misura: fenomeno, unità osservata, confini, popolazione, fonte, tempo, aggregazione, copertura, dati mancanti e limiti; scegliere tra controllo sul codice, prova periodica e osservazione runtime.

Una misura precisa può misurare la cosa sbagliata

Avere un numero non significa avere un'evidenza. Una misura può essere stabile, precisa e ripetibile, ma osservare un fenomeno diverso da quello che pensiamo di proteggere. «Tempo di conferma dell’ordine», per esempio, può indicare la risposta dell’API, l’elaborazione interna o l’attesa percepita dal cliente: tre misure tecnicamente valide, ma semanticamente diverse. Prima della dashboard, scrivi quindi un contratto breve che dichiari fenomeno, unità osservata, inizio e fine, popolazione ed esclusioni, fonti, semantica temporale, aggregazione, copertura, trattamento dei mancanti, responsabile e limiti. Solo dopo scegli il luogo della verifica: un vincoloGlossarioVincoloUna condizione che limita lo spazio delle soluzioni praticabili e non può essere semplicemente ignorata.Apri la voce completa tra package si controlla sul codice; una capacità di ripristino richiede una prova periodica; il comportamento delle richieste reali richiede osservazione runtime. Metriche, log e trace offrono prospettive complementari, non prove intercambiabili.

Verifica anche la misura

Come per una fitness functionGlossarioFitness FunctionUn controllo automatizzato o ripetibile che misura nel tempo una caratteristica architetturale.Apri la voce completa, non fidarti di una misura soltanto perché produce valori plausibili. Prepara casi con esito noto e scrivi il risultato atteso prima di osservare la telemetria. Verifica almeno un completamento, un errore, un’operazione ancora aperta, un retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa della stessa operazione, un eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa duplicato, un evento tardivo e un’interruzione della raccolta. Controlla anche freschezza e copertura: zero violazioni con una fonte valida è diverso da nessun dato ricevuto. In quest’ultimo caso l’esito deve essere non valutabile, non positivo. Mantieni inoltre distinti tempo dell’evento e tempo di ricezione, e non confrontare timestamp prodotti da sistemi diversi senza considerare la sincronizzazione degli orologi. • Definisci l’identità dell’operazione di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa e la regola di deduplicazione. • Rendi visibili richieste accettate, completamenti, fallimenti e anzianità delle richieste aperte. • Dichiara finestra, popolazione, esclusioni, granularità e ritardo di acquisizione ammesso. • Verifica il comportamento in presenza di eventi duplicati, tardivi o fuori ordine. • Pubblica copertura e freschezza accanto al valore della misura. • Dimostra con casi noti che il numero cambia nel modo atteso quando cambia il fenomeno osservato.

Più dettaglio non significa automaticamente più fiducia

Un conteggio completo delle operazioni eleggibili offre una base solida per i rapporti di esito, ma aumenta costo di raccolta, conservazione e governo. Il campionamento riduce volume e spesa, però può alterare la popolazione osservata, soprattutto se trattiene preferenzialmente errori o richieste lente. Gli istogrammi sono aggregabili e utili per le distribuzioni; i quantili precalcolati possono essere convenienti localmente, ma non si possono mediare per ottenere un percentile globale corretto. Anche la cardinalità ha un prezzo: correlare un ordine non richiede trasformare ogni identificativo in un’etichetta metrica. Ma il trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa più importante viene prima di tutti questi dettagli tecnici: una misura economica e precisa del fenomeno sbagliato resta una cattiva evidenza. La decisione architetturaleGlossarioDecisione architetturaleUna scelta progettuale significativa il cui contesto e i cui effetti devono restare comprensibili nel tempo.Apri la voce completa consiste nel raccogliere il minimo dettaglio necessario per rispondere alla domanda dichiarata, esplicitando cosa si perde e proteggendo i dati sensibili.

Ordini e Pagamenti: un p95 corretto, ma della popolazione sbagliata

Un’organizzazione misura il tempo dalla registrazione autorevole di una richiesta accettata alla persistenza dell’ordine con conferma disponibile. L’unità è l’operazione di dominio, non ogni tentativo HTTP. La dashboard mostra un buon p95 e il calcolo è tecnicamente corretto. Il problema è un altro: l’istogramma contiene soltanto operazioni concluse, quindi gli ordini ancora aperti non entrano nella distribuzione, mentre alcuni retry vengono contati due volte. Il percentile non è sbagliato rispetto ai dati raccolti; è incompleto rispetto alla domanda che il team pensa di porre. Il contratto viene corretto introducendo correlazione nel perimetro autorizzato, deduplicazione, conteggi separati di richieste accettate, completamenti e fallimenti, anzianità delle operazioni aperte e stato di freschezza della raccolta. La misura ora descrive esplicitamente l’elaborazione interna; non pretende però di dimostrare che il cliente abbia visto la conferma. Per quella domanda serve una misura aggiuntiva dal punto di osservazione dell’esperienza utente.

Il contratto minimo della misura

Prima di usare un numero in una decisione architetturale, rendi verificabile cosa significa e quali limiti porta con sé. • Quale fenomeno dichiariamo di osservare? • Qual è l'unità che stiamo contando o misurando? • Dove iniziano e finiscono osservazione e popolazione? • Quali casi sono esclusi e perché? • Come gestiamo retry, duplicati, eventi tardivi e operazioni incomplete? • Quanto sono freschi e completi i dati? • Quale aggregazione utilizziamo e cosa può nascondere? • Quali casi di prova dimostrano che la misura reagisce correttamente? • Quale domanda non possiamo rispondere con questa misura?

Per approfondire

Fonti autorevoli su segnali, aggregazione, campionamento e protezione dei dati di telemetria. • Signals — OpenTelemetry — https://opentelemetry.io/docs/concepts/signals/ • Histograms and summaries — Prometheus — https://prometheus.io/docs/practices/histograms/ • Sampling — OpenTelemetry — https://opentelemetry.io/docs/concepts/sampling/ • Handling sensitive data — OpenTelemetry — https://opentelemetry.io/docs/security/handling-sensitive-data/

Una misura affidabile non dice ancora cosa sia abbastanza

Ora sappiamo definire e verificare una misura. Ma osservare correttamente un fenomeno non stabilisce ancora quale risultato sia accettabile. Il prossimo passaggio è dare significato alle soglie: distinguere ciò che stiamo osservando dall'obiettivo che vogliamo sostenere.