Selezionare i segnali a partire da rischi e risultati attesi

Tipo

Pratica

DAL DESIDERIO ALLA DOMANDA. «Ciò che non riesci a misurare è un desiderio» è la provocazione scelta per questo percorso, senza attribuzione a un autore. Non significa che ogni qualità debba diventare un numero. Significa chiedere quali evidenze potrebbero sostenere o smentire una promessa architetturale. «Il checkout funziona» è troppo vago: per chi, fino a quale stato del processo e con quali rischi? La pratica seguente è una proposta didattica originale, non un'analisi eseguita su un sistema reale. PARTI DA UN PERCORSO, NON DALLA CONSOLE. Nel caso inventato Ordini/Pagamenti, rappresenta le tappe: richiesta ricevuta, richiesta accettata, esito del pagamento, ordine persistito, conferma resa disponibile. Concorda con prodotto, sviluppo e operation quali tappe contano per l'utente e quali sono effettivamente osservabili. Separare il percorso utente dalle sue implementazioni aiuta a scegliere misure pertinenti prima degli strumenti [1]. Una conferma emessa dal backend non dimostra che sia stata visualizzata dal cliente; un pagamento autorizzato non dimostra che l'ordine sia stato registrato. Scrivi il risultato che intendi proteggere e il confine entro cui puoi verificarlo. DISTINGUI TRE DOMANDE. Il risultato del processo riguarda ciò che è avvenuto: la richiesta ha prodotto l'ordine atteso? La qualità del servizio riguarda come è avvenuto: con quale tempestività, disponibilità e capacità di recupero? Il vincolo architetturale riguarda una proprietà da preservare: Ordini dipende direttamente dalla persistenza di Pagamenti? Non sommare queste risposte in un unico punteggio di salute. Latenza, traffico, errori e saturazione sono segnali operativi utili, ma richiedono una lettura collegata al servizio [2]. Una CPU poco occupata non basta, da sola, a dimostrare il completamento di un ordine; può comunque essere preziosa per diagnosi e pianificazione. COSTRUISCI UNA MAPPA RISCHIO → PROPRIETÀ → SEGNALE → DECISIONE. Nel caso didattico, una richiesta accettata ma mai completata suggerisce di osservare esiti terminali e anzianità delle richieste ancora aperte; la decisione potrebbe essere indagare il flusso e riconciliare lo stato prima di ripetere operazioni. Il rischio di un ordine duplicato suggerisce una verifica di unicità rispetto all'operazione di dominio, non il solo conteggio delle chiamate HTTP; la conseguenza richiede una procedura dedicata, non un retry automatico. Il rischio di dipendenza dalla persistenza di Pagamenti è invece osservato dal controllo statico descritto in KA-153. Un rischio di mancato recupero richiederebbe anche una prova di ripristino, perché una dashboard non esegue quel recupero. Questi sono candidati da selezionare, non un elenco universale di controlli obbligatori. SCEGLI POCHI RISCHI, ESPLICITAMENTE. Per ogni candidato discuti impatto, esposizione, tempo per cui il problema potrebbe restare invisibile, costo della misura e decisione disponibile. Usa un ordinamento motivato, senza fingere che un punteggio numerico sia una misura oggettiva del rischio. Un incidente raro ma grave può meritare più attenzione di una metrica facile da ottenere. Per partire scegli un piccolo insieme, assegna un responsabile alla definizione del segnale e documenta cosa rinvii. I segnali esclusi non diventano garanzie implicite. Autorizzazioni, integrità dei dati e altri vincoli critici non devono essere compensati da buoni tempi di risposta. RENDI VISIBILI LE PROXY E I LIMITI. Il tasso di conversione commerciale può essere interessante, ma una sua variazione non identifica da sola una causa tecnica. Un indicatore vicino al risultato osserva meglio una specifica domanda; un indicatore interno può anticipare un problema o aiutare a spiegarlo. Dichiarane il ruolo. Se manca una misura sufficiente, registra il punto cieco e una verifica alternativa, anche manuale e ripetibile; non chiamare verde ciò che non hai valutato. OUTPUT MINIMO. Per ogni priorità conserva domanda, utente o processo interessato, rischio, proprietà protetta, segnale candidato, fonte e confine di osservazione, principali esclusioni, frequenza necessaria, responsabile e decisione resa possibile. In questa fase non fissare percentuali soltanto perché usuali: il contratto della misura e i criteri di accettabilità saranno sviluppati separatamente. Il risultato è una mappa breve che un collega può discutere e contestare, non una dashboard già pronta. COLLEGAMENTI CANONICI. KA-006 tratta l'osservabilità fin dalla progettazione; KA-094 la governance di un portfolio; KA-153 il primo controllo su un confine modulare. Questo Asset aggiunge la selezione motivata dei segnali senza sostituire quei contenuti. FONTI PRIMARIE. [1] Google Cloud, Adopting SRE: Standardizing your SLO design process: https://cloud.google.com/blog/products/devops-sre/how-to-design-good-slos-according-to-google-sres (percorsi critici, aspettative e punti di misura). [2] Google, Site Reliability Engineering, Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/ (segnali operativi e loro interpretazione). Le tappe Ordini/Pagamenti, la mappa e le scelte proposte sono esempi originali, non dati di Production.