Affidabilità e operatività
Osservabilità del software aziendale: progettare metriche, log e tracce utili
L'applicazione risponde, il database è raggiungibile e il monitoraggio non segnala errori. Eppure un gruppo di ordini non avanza, una coda accumula attività o un collegamento esterno lascia alcune pratiche in sospeso. Nel software aziendale la disponibilità tecnica racconta soltanto una parte della situazione. Progettare l'osservabilità significa raccogliere segnali che aiutino a formulare e verificare ipotesi sul funzionamento del sistema, fino a individuare un intervento concreto e controllarne l'effetto.
Partire dalle domande a cui il gruppo deve rispondere
La prima scelta non riguarda lo strumento di raccolta. Riguarda le domande che sviluppatori e responsabili operativi devono risolvere: quali attività sono ferme, da quando, in quale passaggio e con quali dipendenze. Per un processo che acquisisce documenti, ad esempio, ricezione, validazione e registrazione possono essere momenti distinti. Una conferma di ricezione non dimostra il completamento. Prima di aggiungere contatori occorre quindi definire gli stati osservabili e il significato dell'esito che l'utente considera conclusivo.
Da questa descrizione si ricavano ipotesi verificabili. Se cresce l'attesa ma la durata della singola elaborazione resta stabile, il problema potrebbe riguardare capacità disponibile o distribuzione del lavoro. Se il ritardo interessa soltanto una dipendenza esterna, serve una vista più circoscritta. Sono possibilità da indagare, non diagnosi automatiche. La strumentazione è utile quando permette di distinguere spiegazioni concorrenti e riduce il numero di verifiche manuali necessarie prima di intervenire, senza nascondere i casi che rimangono incerti.
Assegnare un compito preciso a metriche, log e tracce
OpenTelemetry descrive diversi segnali, tra cui metriche, log e tracce distribuite. In un progetto applicativo questi strumenti possono essere usati in modo complementare: le metriche aiutano a leggere volumi e distribuzioni nel tempo; i log descrivono eventi selezionati; le tracce collegano le attività che partecipano a una richiesta. La progettazione deve stabilire quali informazioni passano da un segnale all'altro. Una dashboard può mostrare dove nasce una variazione, mentre una traccia o un evento contestualizzato aiutano ad approfondirne il percorso.
Un identificativo di correlazione permette di collegare evidenze senza replicare tutto il contenuto del documento. È opportuno distinguere però la telemetria tecnica dalle evidenze che ricostruiscono un'operazione aziendale. Hanno scopi e requisiti diversi. Per il versante applicativo della ricostruzione delle modifiche, la guida all'audit trail di Gestionale sul Web affronta quel tema specifico. Qui il fuoco rimane sulla strumentazione con cui il gruppo tecnico analizza prestazioni, attese ed errori del software.
Seguire il lavoro anche quando attraversa una coda
Le elaborazioni asincrone interrompono l'equivalenza tra durata della richiesta e tempo del processo. Un'interfaccia può confermare in pochi istanti l'acquisizione, mentre il risultato finale arriva molto dopo. Conviene osservare separatamente tempo in attesa, durata di esecuzione e tempo complessivo fino all'esito. Anche l'età dell'attività più vecchia ancora da completare può essere più istruttiva del solo numero di messaggi presenti. Una coda numerosa può smaltirsi rapidamente; poche pratiche ferme possono invece richiedere attenzione immediata.
Il contesto di correlazione deve attraversare il passaggio tra produttore e consumatore secondo il protocollo adottato. Un ritentativo va riconosciuto come tale, evitando di contare ogni tentativo come un nuovo documento completato. Per attività molto lunghe può essere preferibile collegare tracce relative a fasi diverse, invece di mantenere artificialmente aperta un'unica operazione. I confini vanno dichiarati: che cosa misura la singola fase, quale evento la conclude e come si cerca il lavoro rimasto sospeso dopo un'interruzione.
Scegliere dimensioni sostenibili per le metriche
Una metrica utile può diventare costosa se ogni osservazione introduce combinazioni sempre nuove di etichette. La documentazione Prometheus richiama il costo delle serie temporali associate a differenti insiemi di valori. Identificativi di documenti, indirizzi e-mail e testi liberi sono quindi candidati problematici per le dimensioni di una metrica: moltiplicano le serie e rendono difficile governarne la crescita. Il dettaglio di una singola operazione dovrebbe essere ricercabile attraverso strumenti adatti, senza trasformare il monitoraggio aggregato in una copia dell'archivio applicativo.
È utile concordare un vocabolario limitato: tipo di operazione, fase ed esito possono offrire segmentazioni comprensibili, se i loro valori sono controllati. Anche l'uso del cliente come dimensione richiede una valutazione dei volumi e degli accessi, soprattutto in una piattaforma con molte organizzazioni. La scelta va provata con dati rappresentativi prima di estenderla. Il controllo comprende costi di raccolta, conservazione e interrogazione, perché una dashboard lenta o troppo onerosa può diventare inutilizzabile proprio durante un incidente.
Trasformare una misura in un allarme utilizzabile
Un allarme ha senso quando esiste un'azione appropriata o almeno un percorso di diagnosi definito. Prima di configurarlo, il gruppo dovrebbe chiarire chi lo riceve, quale impatto indica e quali verifiche eseguire. Le soglie devono derivare dal comportamento osservato e dagli obiettivi del processo, considerando orari, carichi e scadenze. Una media può nascondere una minoranza di casi molto lenti: per questo occorre esaminare anche distribuzioni e quote di operazioni che superano il tempo concordato.
Le condizioni di allarme devono evitare due estremi: reagire a ogni variazione breve oppure attendere così a lungo da rendere tardivo l'intervento. Persistenza del fenomeno, quantità di lavoro coinvolta e ritardo accumulato possono contribuire alla decisione. È importante osservare anche ciò che smette di accadere. Se un collegamento non invia più documenti, il contatore degli errori può rimanere a zero. Per distinguere un periodo normalmente inattivo da un'interruzione serve conoscere il ritmo atteso e il calendario operativo.
Proteggere il contesto senza perdere la capacità di diagnosi
La correlazione non richiede di inserire informazioni personali negli identificativi di traccia. La raccomandazione W3C Trace Context specifica vincoli sulla presenza di dati identificativi o sensibili nei campi usati per propagare il contesto. Il progetto dovrebbe scegliere identificativi tecnici e definire quali attributi possano attraversare confini organizzativi. Anche un dato apparentemente innocuo può diventare rivelatore quando viene associato ad altre informazioni, perciò il contenuto dei segnali va selezionato in funzione dello scopo diagnostico.
Richieste, risposte ed eccezioni possono contenere credenziali, allegati o dettagli commerciali. È preferibile adottare elenchi espliciti dei campi ammessi, controlli di mascheramento e prove sugli errori reali, invece di presumere che un filtro generico elimini tutto ciò che non serve. Accessi e tempi di conservazione devono essere definiti per il sistema di telemetria. Nelle integrazioni, la pagina delle API e dei Web Services di Gestionale sul Web offre il contesto applicativo; protocolli e modalità di strumentazione effettivamente disponibili vanno verificati nel progetto specifico.
Collaudare anche la perdita dei segnali
La raccolta delle evidenze può guastarsi indipendentemente dall'applicazione. Un collettore indisponibile, un limite raggiunto o una configurazione errata possono produrre una vista incompleta mentre gli utenti continuano a lavorare. Il gruppo deve sapere quali segnali vengono persi, quali vengono temporaneamente accodati e quale effetto ha l'attesa sulle risorse del servizio. La strumentazione diagnostica non dovrebbe introdurre un blocco imprevisto nel processo operativo: questo comportamento va verificato attraverso prove deliberate, non lasciato alle impostazioni predefinite.
Anche il campionamento richiede attenzione. Se si conserva soltanto una parte delle tracce, l'assenza di una traccia non dimostra che l'operazione non sia avvenuta. La politica va documentata e collegata alle domande che si vogliono risolvere. Per eventi che richiedono una ricostruzione completa può essere necessario un canale distinto dalla telemetria campionata. La revisione periodica dovrebbe cercare interruzioni nella raccolta, cambiamenti nei nomi degli attributi e metriche che non corrispondono più al significato dei processi attuali.
Introdurre l'osservabilità con un esperimento circoscritto
Un avvio sostenibile sceglie un flusso significativo e una domanda concreta, ad esempio individuare dove si accumula l'attesa tra acquisizione e registrazione. Si definiscono gli eventi di inizio e fine, le poche misure necessarie e il percorso per arrivare dal segnale aggregato al dettaglio tecnico. Poi si simula un rallentamento, un ritentativo e un'interruzione della raccolta. La verifica consiste nel ricostruire ciascuna situazione usando le evidenze disponibili e annotare ciò che rimane ambiguo.
L'estensione ad altri processi segue questi risultati. Ogni nuovo segnale dovrebbe avere un utilizzatore, una domanda e un costo sostenibile; quelli privi di utilità vanno riesaminati. Il lavoro prosegue dopo il rilascio, perché cambiano dipendenze, volumi e significato degli stati. L'osservabilità diventa parte dell'ingegneria del software quando permette al gruppo di formulare ipotesi, scegliere un intervento e verificare se il processo ha ripreso a funzionare, conservando una spiegazione leggibile del percorso seguito.
Riferimenti tecnici
Per approfondire i temi tecnici trattati:
- OpenTelemetry — segnali di telemetria e loro ruolo
- W3C Trace Context — propagazione del contesto e considerazioni di riservatezza
- Prometheus — buone pratiche di strumentazione e gestione delle etichette
A cura della redazione tecnica SoftJob. Pubblicato il .