Non misurare tutto: scegli cosa devi proteggere

Dalla serie

Obiettivo

Scegliere poche proprietà e risultati da misurare partendo da percorsi critici, rischi e decisioni, distinguendo risultato del processo, qualità del servizio e vincoli architetturali.

Misurare significa scegliere

Se tutto è importante, niente lo è davvero. «Ciò che non riesci a misurare è un desiderio» non significa raccogliere ogni dato disponibile: significa decidere quali promesse architetturali meritano un'evidenza. Parti quindi dal percorso che conta per l'utente o per il processo aziendale e chiarisci dove termina davvero il risultato atteso. Poi, per ogni rischio prioritario, costruisci una mappa breve: rischio, proprietà da proteggere, segnale candidato, confine di osservazione e decisione resa possibile. Distingui tre livelli. Il risultato del processo dice che cosa è avvenuto; la qualità del servizio dice come è avvenuto; il vincoloGlossarioVincoloUna condizione che limita lo spazio delle soluzioni praticabili e non può essere semplicemente ignorata.Apri la voce completa architetturale verifica una proprietà strutturale da preservare. Non fonderli in un unico punteggio di salute: rispondono a domande diverse e possono richiedere decisioni diverse.

Associa ogni segnale a una decisione

Un segnale è utile se può cambiare una decisione. Chiedi chi agirà, entro quanto tempo e con quale risposta. Un indicatore vicino al risultato può mostrarti che il processo non si è concluso; una metrica interna può anticipare il problema o facilitarne la diagnosi, ma resta una proxy finché non dimostri il legame con ciò che vuoi proteggere. Per ciascun segnale documenta fonte, frequenza, responsabile, principali esclusioni e punti ciechi. Se l'evidenza non è sufficiente, dichiara il limite e prevedi una verifica alternativa, anche manuale e ripetibile. L'assenza di una misura non deve trasformarsi in una garanzia implicita: se non sai osservare una proprietà, devi poterlo dire.

Pochi segnali significano anche rinunce esplicite

Concentrarsi su pochi rischi migliora chiarezza, responsabilità e velocità di risposta, ma lascia intenzionalmente alcune aree fuori dal primo perimetro. Rendile visibili: ciò che rinvii non diventa una garanzia implicita. Misure vicine al risultato sono più rappresentative dell'esperienza, ma possono arrivare tardi o spiegare poco della causa; segnali interni sono più tempestivi e diagnostici, ma rischiano di essere proxy deboli. Anche il costo conta: una misura molto precisa può richiedere correlazioni, conservazione dei dati e gestione operativa sproporzionate. Evita però di scegliere una metrica solo perché è economica o già disponibile. Un rischio raro ma grave può meritare più attenzione di un dato facile da raccogliere. La scelta deve essere motivata dal rischio e dalla decisione, non dalla comodità dello strumento.

Ordini e Pagamenti: un HTTP 200 non è il risultato

Un'azienda gestisce un checkout distribuito tra Ordini e Pagamenti. Le dashboard mostrano disponibilità delle API, latenza e CPU, eppure alcuni clienti ricevono l'addebito senza trovare l'ordine. Il problema non è che mancano metriche: mancano segnali collegati al risultato da proteggere. Gli architect ricostruiscono il percorso: richiesta ricevuta, accettazione, esito del pagamento, ordine persistito e conferma disponibile. Scelgono due rischi iniziali. Per le richieste accettate ma non concluse osservano esiti terminali e anzianità delle operazioni aperte, così operation può indagare e riconciliare lo stato prima di ripetere azioni. Per gli ordini duplicati verificano l'unicità rispetto all'operazione di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa e attivano una procedura dedicata, invece di affidarsi a retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa automatici. Latenza e saturazione restano utili per diagnosi e capacità, ma non vengono presentate come prova del completamento del checkout. Il risultato è una mappa di decisioni e rischi, non una dashboard universale.

Una verifica rapida prima di aggiungere una metrica

Prima di accettare un nuovo indicatore, verifica che risponda a una domanda concreta e che qualcuno possa usarlo. • Quale percorso, utente o processo stiamo proteggendo? • Quale rischio prioritario rende necessario questo segnale? • Stiamo osservando un risultato, una qualità del servizio o un vincolo architetturale? • Il segnale osserva direttamente la proprietà o è una proxy? • Dove inizia e termina il confine di osservazione? • Quale decisione prenderemo quando il segnale cambia? • Quali esclusioni e punti ciechi dobbiamo dichiarare? • Chi è responsabile della definizione e della revisione del segnale?

Per approfondire

Fonti esterne autorevoli per collegare percorsi critici, aspettative degli utenti e segnali operativi. • Adopting SRE: Standardizing your SLOGlossarioSLOUn intervallo target per uno SLI su un periodo definito.Apri la voce completa design process — Google Cloud, Derek Remund e Garrett Plasky — https://cloud.google.com/blog/products/devops-sre/how-to-design-good-slos-according-to-google-sres • Monitoring Distributed Systems — Google, Site Reliability Engineering — https://sre.google/sre-book/monitoring-distributed-systems/

Avere il segnale non basta

Abbiamo scelto cosa vale la pena osservare. Ma un numero disponibile in una dashboard non è ancora un'evidenza affidabile. Nel prossimo passaggio la domanda cambia: il dato che stiamo raccogliendo misura davvero il fenomeno che pensiamo di osservare?