Dall’osservabilità alla Continuous Quality: raccogliere segnali in produzione non basta. La vera sfida è chiudere il ciclo e usare ogni release per rendere il prossimo ciclo di sviluppo più solido.
Per anni, la qualità del software è stata misurata al momento del rilascio. Test superati, coverage soddisfacente, nessun blocco critico in staging: il sistema poteva andare in produzione. Questo modello funzionava bene quando i cicli di release erano lunghi, le architetture erano monolitiche e il comportamento del software in esercizio era relativamente prevedibile.
Oggi le condizioni sono cambiate. I deployment sono quotidiani, le architetture distribuite moltiplicano i punti di fallimento e il traffico reale genera scenari che nessun ambiente di test riesce a riprodurre fedelmente. In questo contesto, la qualità non può più essere una soglia da superare prima della pubblicazione: deve diventare una proprietà che il sistema acquisisce e consolida nel tempo.
Le piattaforme di osservabilità ci hanno dato la capacità di vedere cosa succede davvero in produzione: metriche, trace distribuiti, log strutturati, anomalie rilevate in tempo reale. Ma vedere non è sufficiente. La domanda che questo articolo vuole affrontare è: come si trasforma ciò che si osserva in un sistema che migliora? È questo che segna il passaggio dall’osservabilità alla Software Quality.
Il rilascio non è la fine del ciclo
Nei sistemi distribuiti moderni, il comportamento in produzione diverge sistematicamente da quello osservato in pre-produzione. Le ragioni sono strutturali: il volume e la distribuzione del traffico reale non sono replicabili, le dipendenze esterne si comportano in modo diverso sotto carico, e le configurazioni – nonostante l’IaC – presentano spesso sottili disallineamenti tra ambienti.
Questo significa che ogni release porta con sé informazioni che i test pre-produzione non possono generare. Problemi di latenza che emergono solo con concorrenza elevata, race condition nei flussi asincroni, degradazione progressiva sotto carico sostenuto, timeout che si manifestano solo quando le dipendenze sono sotto stress: sono tutti segnali che appartengono alla produzione, non alla pipeline.
Il punto critico non è che questi problemi esistano, ma che senza un processo sistematico rimangono incidenti da correggere invece di diventare conoscenza da incorporare nel ciclo successivo.
Dal dato alla decisione tecnica
Le piattaforme di osservabilità odierne generano un volume di segnali che fino a pochi anni fa era semplicemente impraticabile gestire. Ma la correlazione tra quantità di dati e capacità di governo della qualità è tutt’altro che lineare.
Un picco di error rate al 5% può indicare un bug applicativo, ma anche un upstream degradato, una query non ottimizzata che supera il timeout sotto carico o un problema di saturazione nel connection pool. Un aumento della latenza al p99 può derivare da codice inefficiente, da garbage collection pressure su JVM, da una coda Kafka che cresce senza essere consumata abbastanza velocemente, o semplicemente da un nodo del cluster sotto-dimensionato.
La differenza tra osservabilità e qualità sta qui: il dato grezzo richiede contesto tecnico per diventare diagnosi, e la diagnosi richiede un processo per diventare miglioramento. Senza questo passaggio, i team si trovano a reagire agli stessi tipi di incidenti in modo ciclico, senza mai aggredire le cause strutturali.
Continuous Quality: chiudere il ciclo
La Continuous Quality è l’approccio che trasforma le evidenze di produzione in input strutturati per il ciclo di sviluppo successivo. Non si tratta di un framework specifico, ma di un principio operativo: ogni release alimenta il ciclo, invece di chiuderlo.
Un esempio concreto. Un servizio supera tutti i test funzionali e di integrazione in CI, ma in produzione – sotto un carico sostenuto di circa 800 richieste al secondo – mostra un degrado progressivo della latenza media che porta i valori p95 oltre la soglia di SLA. L’analisi dei trace rivela un collo di bottiglia nella serializzazione JSON: un campo calcolato in modo ricorsivo che, con payload di grandi dimensioni, introduce un overhead significativo. Il bug era invisibile nei test perché il dataset di test non riproduceva la distribuzione reale dei payload.
In un approccio reattivo, si corregge il problema e si chiude il ticket. In un approccio di Continuous Quality, quella evidenza produce: un test di performance aggiunto alla pipeline con dataset rappresentativi del traffico reale; soglie di regressione sulle latenze p95 e p99 per quel servizio; una revisione dei contract test tra servizi per validare le dimensioni dei payload attesi. Il problema viene risolto e il sistema di qualità diventa più robusto.
Un secondo scenario riguarda i sistemi che adottano pattern di resilienza come retry con backoff esponenziale e circuit breaker. In condizioni normali tutto funziona. Ma quando una dipendenza degrada gradualmente (invece di fallire nettamente) i retry amplificano il carico proprio quando la dipendenza è più fragile, i circuit breaker si aprono e si chiudono in modo oscillante, e il sistema sviluppa errori intermittenti difficili da riprodurre. Il problema non è il singolo bug: è l’interazione tra le strategie di resilienza, i timeout configurati, l’idempotenza delle operazioni e il comportamento reale delle dipendenze sotto stress.
Questo tipo di comportamento emergente richiede chaos engineering e test di resilienza che simulino degradazione graduale, non solo failure netti. È un’evidenza che, in un approccio di Continuous Quality, porta a rivedere la strategia di test complessiva, non solo a correggere la configurazione del circuit breaker.
Qualità come processo, non come checkpoint
Negli ultimi anni abbiamo costruito la capacità di osservare i sistemi in produzione con una granularità che prima non era praticabile. Il passo successivo non è raccogliere più segnali, ma usarli per cambiare il modo in cui si progetta, si sviluppa e si testa il software.
Il vantaggio competitivo non deriva dalla visibilità in sé, ma dalla capacità di trasformare quella visibilità in decisioni tecniche migliori più velocemente dei competitor. È questo il passaggio che distingue un team che reagisce agli incidenti da un team che costruisce sistemi progressivamente più resilienti.
La qualità smette di essere un’attività di controllo e diventa un meccanismo di apprendimento continuo. Ogni release non è solo un deploy: è un esperimento i cui risultati alimentano il ciclo successivo.
Nei prossimi articoli di questa serie esploreremo la qualità del software da diverse prospettive: il suo ruolo come leva di fiducia per il business, l’impatto dell’intelligenza artificiale sul ciclo di sviluppo e l’importanza di costruirla a partire dall’organizzazione, dalle persone e dalle pratiche, prima ancora che dagli strumenti e dalle scelte tecnologiche. Infine, racconteremo l’esperienza di Spindox attraverso casi concreti.
