Metriche DevOps per Misurare il Successo dei Tuoi Processi
Quindi, hai iniziato ad adottare DevOps nella tua azienda. Ma come puoi capire se sta migliorando i tuoi processi? Devi in qualche modo misurare il successo e puoi farlo monitorando alcune metriche chiave di DevOps.
Esistono molti modi per valutare la qualità di un sistema o di un'applicazione, ma in questo articolo mi concentrerò sulle metriche chiave che aiutano a valutare la qualità dei tuoi processi. Tenendo traccia di questi indicatori, puoi ottenere una comprensione più approfondita dei tuoi punti di forza e di debolezza, migliorare le best practice DevOps e sfruttare i giusti strumenti e software per il miglioramento continuo.
Perché sono importanti le metriche DevOps?
Come abbiamo visto sopra, obiettivi e metriche condivisi possono essere una sfida per i team che implementano DevOps all'interno di un'azienda. Senza metriche DevOps, non ci sarebbe alcun test o misurazione e nessun miglioramento nello sviluppo. Sarebbero solo iterazioni dello stesso software basate su intuizioni e idee, gettandole nel vuoto, e poi provando qualcosa di nuovo. Senza feedback o metriche di successo del prodotto per comprendere come qualcosa si comporta, non c'è direzione.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ad esempio, i reparti finanziari vogliono mantenere i costi il più bassi possibile, mentre gli sviluppatori desiderano mantenere le prestazioni il più elevate possibile. Questi due obiettivi potrebbero non essere allineati a meno che i rischi non siano stati valutati e i team non comprendano gli obiettivi reciproci.
Quando i tuoi sviluppatori possono scegliere di distribuire un prodotto incompleto e gestirlo in seguito, il costo di questo impatto genera debito tecnico. L'implementazione di DevOps può allineare gli obiettivi e le strategie di entrambi i team, e puoi aiutare i tuoi sviluppatori a comprendere l'impatto dei costi delle loro decisioni tecniche.
Questo è solo un piccolo aspetto di DevOps e dell'importanza delle metriche condivise.
5 Metriche DevOps Chiave (DORA)
Implementare DevOps e comprendere i framework basati su principi è una cosa, ma sono le metriche DevOps che ti permettono davvero di vedere i benefici di questo approccio collaborativo al ciclo di vita dello sviluppo software. Come la maggior parte delle strategie aziendali, ci sono infinite metriche che potresti scegliere di misurare per la crescita, a seconda del tuo settore, pubblico e obiettivi.
Il team DevOps Research and Assessment (DORA) di Google Cloud è il team di ricerca di questo tipo attivo da più tempo. Inizialmente hanno individuato quattro metriche chiave per misurare le prestazioni dei ‘top’ in DevOps. Tuttavia, da allora è stata aggiunta una quinta metrica chiave, e la loro analisi dei cluster rileva solo tre livelli di team DevOps: alto, medio e basso, con "top" che appartiene ormai al passato.
1. Frequenza di deployment (DF)
DF misura quanto spesso effettui rilasci di successo in produzione. Questa metrica riguarda la costanza ed è un ottimo indicatore del completamento degli obiettivi.
I team appartenenti alla categoria "top" distribuivano regolarmente in produzione più volte al giorno, mentre quelli a bassa performance erano più vicini a una volta ogni sei mesi.
Migliorare la DF è semplice come rilasciare diversi aggiornamenti minori. Il principale vantaggio di questa pratica è mettere in evidenza eventuali blocchi nei processi, colli di bottiglia o progetti complessi che richiedono attenzione. I team più grandi potrebbero preferire effettuare i deployment a intervalli regolari costruendo Agile release train; questo aiuterà a eliminare la pressione dovuta al ritmo sostenuto e alle tante persone coinvolte.
2. Lead Time per i Cambiamenti (LTC)
LTC si riferisce al tempo che impiega una commit a finire in produzione. Questa metrica è un buon indicatore della reattività e dell'agilità del team perché misura quanto velocemente si riesce ad agire sulle esigenze e sulle richieste degli utenti.
Lo standard "top" del passato mirava a meno di un giorno per LTC, mentre i team a bassa performance potevano impiegare più di sei mesi. Una performance nella parte bassa della scala per LTC è probabilmente dovuta a processi inefficienti.
Puoi migliorare questa metrica incrementando i processi di automazione, soprattutto nei test. Migliorando la tua pipeline di integrazione continua e delivery continua (CI/CD), puoi portare gli aggiornamenti in produzione più rapidamente. Tuttavia, un rischio da tenere presente è la sostenibilità: se il team non riesce a mantenere questo ritmo migliorato, si potrebbe riscontrare una scarsa esperienza utente e potenziali vulnerabilità di sicurezza.
3. Change Failure Rate (CFR)
CFR è la percentuale di distribuzioni che causano un guasto in produzione. Il guasto può consistere in downtime, rollback o deterioramento del servizio. Questa metrica mostra l'efficacia del tuo team durante il rilascio delle modifiche.
I benchmark di performance di livello elite sono compresi tra 0 e 15%, mentre le performance alta, media e bassa si collocano tutte tra il 16 e il 30%.
Migliorare il CFR significa puntare sulla qualità piuttosto che sulla quantità. Le aziende rilasciano un numero variabile di modifiche e, quindi, subiscono un numero variabile di guasti. Tuttavia, le modifiche di qualità superiore porteranno a un minor numero di guasti, sia che si rilascino cambiamenti due volte l’anno che due volte al giorno.
4. Tempo Medio di Ripristino (MTTR)
MTTR indica quanto tempo impiega il tuo team a ripristinare il servizio in caso di guasto o interruzione. Questa metrica misura non solo l'agilità del team, ma è anche un valido indicatore della stabilità del tuo software.
Se punti a un livello "elite", dovresti mirare a un MTTR inferiore a un'ora. I team con prestazioni basse possono impiegare anche più di sei mesi.
Puoi migliorare il MTTR puntando su rilasci piccoli e veloci, rendendo più facile individuare e correggere gli errori. Potresti anche valutare di utilizzare feature flags per dare al team maggiore controllo — soprattutto negli scenari sperimentali.
C'è ancora una metrica da trattare.
5. Affidabilità
La metrica bonus numero cinque è l’affidabilità. Questa metrica è stata introdotta successivamente dal team DORA (2021), poiché in precedenza veniva misurata la disponibilità come riferimento per la qualità del software. Tuttavia, si è deciso che l'affidabilità comprende meglio disponibilità, latenza, prestazioni e scalabilità. In sostanza, include la misurazione delle prestazioni operative accanto allo sviluppo.
Altre Metriche DevOps Comuni
Tempo di Ciclo
Il tempo di ciclo è il tempo totale che intercorre dall’inizio di un’attività alla consegna finale. In superficie, monitora la velocità di lavoro del tuo team. Tuttavia, analizzando questa metrica puoi individuare i colli di bottiglia come lunghe code d’attesa e pull request che durano molto.
Un tempo di ciclo breve indica un flusso di lavoro efficiente, con minori colli di bottiglia e maggiore velocità di sviluppo.
Come Misurare il Tempo di Ciclo
Il tempo di ciclo viene calcolato tracciando i timestamp dei commit, delle fusioni di codice e delle distribuzioni tramite strumenti come GitHub, GitLab o Jenkins.
Tempo di Ciclo = Tempo di Rilascio - Tempo di Commit
Per migliorare il Tempo di Ciclo, i team dovrebbero:
- Ottimizzare le pipeline CI/CD per l’integrazione e la distribuzione più rapide.
- Automatizzare le build e i test.
- Migliorare la collaborazione tra team di sviluppo e operations.
- Ridurre le dipendenze tra le attività per limitare i colli di bottiglia.
Tempo Medio di Rilevamento (MTTD)
Questa è la media del tempo necessario al team per riconoscere un problema. Un MTTD basso indica sistemi di monitoraggio e alerting efficienti, che consentono una rapida risposta e risoluzione degli incidenti.
Come Misurare il MTTD
Il MTTD può essere misurato tracciando il tempo medio tra il verificarsi di un problema e la sua rilevazione da parte degli strumenti di monitoraggio o tramite la segnalazione dagli utenti. Ridurre il MTTD significa migliorare il monitoraggio automatico, perfezionare i meccanismi di alerting e garantire l’individuazione proattiva delle anomalie.
Test Automatici Superati
È importante puntare a una buona copertura dei test, specialmente quelli automatici. Parlo quindi di test unitari, d’integrazione, UI e end-to-end. Tuttavia, la buona copertura non basta a garantire la qualità del software. Ciò che conta è la percentuale di questi test superati.
Ovviamente, l’obiettivo è di avere una percentuale di test superati il più vicina possibile al 100%. Monitorare questa metrica può anche mostrare quanto spesso le nuove funzionalità rompono i test già esistenti.
Come Misurare la Percentuale di Test Automatici Superati
Il calcolo è una semplice percentuale: moltiplica il numero di test superati per 100 e poi dividilo per il totale dei test. Puoi ottenere queste informazioni dallo strumento della pipeline che esegue le build (Jenkins, Azure DevOps, CircleCI, ecc.).
Il numero può essere un buon indicatore della qualità del prodotto. Tuttavia, può anche essere ingannevole se si hanno test instabili o inaffidabili.
Tasso di fuga dei difetti
Il tasso di fuga dei difetti indica quanti bug non vengono individuati durante i test e vengono rilasciati in produzione – quanti cioè "sfuggono". Questa metrica è ideale da monitorare se si desidera migliorare i processi di test e di automazione.
In un mondo utopico, tutte le nostre applicazioni sarebbero prive di difetti. Tuttavia, ciò accade raramente. In modo ideale, i difetti dovrebbero essere intercettati durante le fasi di sviluppo e test del processo DevOps, non in produzione.
Questa metrica aiuta a determinare l'efficacia dei tuoi processi di test e la qualità complessiva del tuo programma. Un tasso di fuga dei difetti elevato suggerisce che le procedure devono essere migliorate e che è necessaria più automazione, mentre un tasso basso (idealmente vicino allo zero) indica un'applicazione di alta qualità.
Come misurare il tasso di fuga dei difetti
Per misurare questo aspetto puoi utilizzare il tuo strumento di tracciamento dei bug e, per ogni difetto aperto, tracciare dove è stato rilevato—se nell'ambiente di test o in produzione (o in altri ambienti che potresti utilizzare, come l'UAT).
Ticket dei clienti
La soddisfazione del cliente è un elemento trainante per l'innovazione, e con buone ragioni: un'esperienza utente impeccabile è un buon servizio clienti e solitamente corrisponde a un aumento delle vendite. Di conseguenza, i ticket dei clienti, soprattutto durante il processo di escalation dei ticket, sono un buon indicatore di come sta andando la transizione DevOps.
I clienti non dovrebbero fungere da controllo qualità segnalando difetti e bug. Pertanto, una diminuzione dei ticket dei clienti è un buon segnale delle buone prestazioni dell'applicazione.
Utilizzo di CPU e memoria
Identifica le tendenze di utilizzo delle risorse.
Tempo di risposta
Misura il tempo impiegato dall'applicazione per rispondere alle richieste.
Tasso di errore
Monitora il numero di richieste fallite nel tempo.
Throughput
Misura il numero di richieste elaborate al secondo.
Latenza delle richieste API
Misura il ritardo tra l'invio di una richiesta e la ricezione di una risposta.
Prestazioni delle query del database
Monitora i tempi di esecuzione delle query e i possibili colli di bottiglia.
Analisi dei comportamenti degli utenti
Monitora l'adozione delle funzionalità e le tendenze di coinvolgimento.
Tempo medio tra i guasti (MTBF)
MTBF misura il tempo medio trascorso tra guasti di sistema, periodi di inattività o incidenti. Questa metrica valuta l'affidabilità e la stabilità dei tuoi sistemi software, mettendo in luce l'efficacia della manutenzione preventiva e delle strategie di mitigazione degli errori.
Tempo di mitigazione (TTM)
Il tempo impiegato per risolvere un problema una volta rilevato corrisponde al TTM. Questa metrica aiuta a valutare i processi di risposta e risoluzione degli incidenti, indicando l'efficienza dei tuoi team nell'affrontare e nel recuperare dai problemi.
Tempo di attraversamento delle modifiche (CLT)
Il CLT fornisce un riferimento per il processo end-to-end di implementazione delle modifiche, includendo sviluppo, test, revisione e rilascio. Un CLT più breve indica cicli di rilascio più rapidi e maggiore agilità.
Come stabilire KPI con le metriche DevOps
Ora che hai una buona conoscenza delle metriche che puoi utilizzare per implementare e ottimizzare DevOps nella tua azienda, vorrai esplorare gli indicatori chiave di prestazione (KPI) per fissare alcuni obiettivi e parametri di riferimento per il tuo team.
Metriche vs KPI
Potresti chiederti qual è la differenza tra metriche e KPI. Una metrica è ciò che misuri. Si tratta di una misurazione quantitativa che offre dati su uno specifico aspetto delle prestazioni. Non tutte le metriche sono necessariamente collegate a obiettivi o target precisi.
I KPI, invece, sono un tipo di metrica selezionata e definita strategicamente per riflettere gli aspetti più critici delle prestazioni e del progresso verso gli obiettivi strategici. I KPI sono solitamente collegati a obiettivi e spesso sono associati a target, soglie o benchmark da raggiungere.
Impostare i KPI per il tuo team DevOps
Il primo passo per impostare i KPI per il tuo team DevOps è collegare le metriche DevOps con la strategia e gli obiettivi aziendali. Dando priorità alle metriche più importanti da monitorare, puoi iniziare a stabilire obiettivi e parametri di riferimento per il miglioramento continuo. Selezionare le metriche giuste richiede di considerare la dimensione della tua azienda, il prodotto e il mercato. Concentrati su ciò che fornirà le informazioni più utili, evitando l’errore comune di sovraccaricare con troppi indicatori.
Monitorare i tuoi KPI è importante tanto quanto definirli. Esplora gli strumenti di visualizzazione dei dati per offrire al tuo team dati in tempo reale su dashboard intuitive. Questo garantisce piena visibilità, responsabilizzazione e consente a tutti di lavorare insieme su obiettivi comuni, allineando i team di sviluppo e operativi e sostenendo l’adozione e la maturità di DevOps.
Prendendo le metriche core DORA, possiamo vedere i parametri di riferimento per ciascuna metrica in base ai team di livello elite, alto, medio e basso. Questa tabella può aiutarti a stabilire i KPI per la tua azienda, a seconda di ciò che consideri prioritario.
Quando imposti i tuoi KPI, è meglio valutare attentamente il tuo team e la tua azienda senza confrontarli con altre realtà. Se prendiamo il CFR come esempio, il valore di riferimento è lo stesso per le prestazioni alte, medie e basse. Questo dipende molto dalla frequenza di deployment, ma può anche influenzare quest’ultima. Se il tuo team impiega tutto il tempo a risolvere i guasti, avrà meno tempo per sviluppare e rilasciare aggiornamenti. I KPI potrebbero inoltre cambiare con la maturazione del team DevOps. Un’automazione e processi di test impeccabili dovrebbero automaticamente permetterti di alzare il livello degli obiettivi.
Come usare le metriche DevOps per scalare
Con il mercato globale DevOps che dovrebbe raggiungere $24,71 miliardi entro il 2027 (un tasso di crescita annuale composto del 22,9%, sulla base dei $10,84 miliardi del 2023), consideralo come un segnale se stai cercando il momento migliore per iniziare a implementarlo nella tua azienda.
DevOps non solo accelera lo sviluppo, riducendo il time-to-market, ma migliora anche la collaborazione eliminando i silos, eleva la qualità grazie ai test continui e ai circuiti di feedback, e utilizza in modo efficiente le risorse, il che consente di risparmiare. Infine, DevOps è facilmente scalabile, supportando la crescita dell’azienda verso nuovi limiti, con l’83% dei decisori IT che hanno ottenuto più valore business implementando DevOps nel 2021.
Misurazione delle prestazioni e miglioramento continuo
Monitorare le prestazioni è la chiave per scalare un’azienda che adotta DevOps. Si tratta di un approccio veloce con un flusso di produzione costante, quindi la misurazione e la reportistica devono essere altrettanto frequenti. Le metriche DevOps ti permettono di monitorare le prestazioni dei processi di sviluppo e delivery. Quantificando aspetti chiave come frequenza di deployment, lead time e tasso di insuccesso delle modifiche, puoi identificare colli di bottiglia, inefficienze e aree di miglioramento. Ciò permette di ottimizzare spesso flussi di lavoro e processi.
Monitorando metriche come il tasso di insuccesso delle modifiche e il tempo medio di ripristino puoi individuare tendenze che permettono di rilevare i problemi in anticipo. Questo approccio proattivo consente di attuare misure correttive e ridurre al minimo l’impatto sui clienti, garantendo affidabilità – un altro ingrediente fondamentale per scalare mantenendo un’elevata qualità.
Infine, l’utilizzo delle metriche DevOps aiuterà a maturare il tuo team DevOps promuovendo una cultura di miglioramento continuo. I cicli di feedback favoriscono apprendimento e crescita; deve sempre esserci spazio per sperimentare nuovi approcci.
Quali metriche DevOps supportano la crescita del business?
Quando si impostano i KPI, la maggior parte delle metriche dovrebbe essere valutata nel contesto del proprio team e orientata alla crescita, invece che confrontata con altre aziende e squadre a livelli di maturità differenti.
Ad esempio, un LTC basso può indicare che il tuo team è efficiente, ma se non riescono a mantenere il ritmo, non è sostenibile e potrebbe alla lunga compromettere la user experience. Questa metrica va analizzata nel tempo invece di impostare un KPI che rispecchi una squadra DevOps già matura o addirittura di livello elite. Definire KPI per ridurre l’LTC mese su mese, trimestre dopo trimestre o anno su anno dimostra crescita all’interno del tuo team e della tua azienda.
Il CFR è una metrica preziosa perché non tutti hanno lo stesso numero di errori o problemi, ma attribuendo una percentuale a questo dato puoi misurare quanto sono efficaci i tuoi deployment. Il tuo team potrebbe avere pochissimi errori se rilascia modifiche raramente, ma se ogni rilascio causa un problema, il CFR sarà molto elevato. Se segui pratiche CI/CD, potresti riscontrare un numero più alto di errori, ma se il tuo CFR è basso, avrai un vantaggio poiché puoi contare su velocità e qualità per sostenere la crescita. Anche l’MTTR dovrebbe essere misurato nel tempo per assicurare una crescita costante.
DORA ha rilevato che i team di tutti i livelli di performance nello sviluppo hanno ottenuto risultati migliori concentrandosi sulle prestazioni operative. Questo potrebbe significare fissare KPI per report sugli incidenti o ticket aperti, tempo di attività e disponibilità delle applicazioni.
Un alto numero di ticket aperti potrebbe indicare un problema nella soddisfazione del cliente, ma puntare a una diminuzione nel tempo riflette una crescita in quest’area. Potresti approfondire e misurare i tempi di risposta e di coda per accelerare il miglioramento di questa metrica.
L’unica metrica che combina completamente sia lo sviluppo sia le operazioni come team DevOps è il tempo di ciclo. Questo apre la strada alla costruzione di una cultura basata sul feedback e sulla crescita. Quando le altre metriche migliorano e l’automazione cresce, dovresti aspettarti che il tempo di ciclo si riduca. Se il servizio clienti è elevato e gli errori di sviluppo sono pochi, hai trovato la combinazione vincente per scalare la tua azienda.
Considerazioni finali
Come qualsiasi altra metodologia, DevOps ha successo solo se viene implementato correttamente. E non puoi conoscere il successo finché non sai come utilizzare le metriche DevOps.
Naturalmente, implementare le metriche DevOps comporta delle sfide. Richiede un approccio strategico, una cultura collaborativa e un impegno verso il miglioramento continuo. Tuttavia, i risultati sono workflow e processi ottimizzati su cui puoi costruire una solida base per scalare la tua azienda.
Se vuoi rimanere aggiornato su notizie e articoli, iscriviti alla nostra newsletter!
