6 min di lettura
Misurazione delle metriche DORA
Raccolta dati: manuale vs. automatizzata
La raccolta automatizzata dei dati è il modo migliore per evitare metriche imprecise che potrebbero portare a decisioni aziendali errate. Tuttavia, l'automazione di ogni parametro coinvolto nel calcolo di una metrica potrebbe non essere possibile a causa di determinati vincoli. In tali casi, concordare un approccio manuale che sia ragionevole e allineato agli standard del settore.
Lead time:
Misurato in base al tempo impiegato da una funzionalità per passare da una richiesta aziendale alla produzione. Questo può essere misurato utilizzando più strumenti in ogni fase.
- Automatizza test e rilasci (pipeline CI/CD).
- Riduci le dimensioni dei lotti (modifiche più piccole e frequenti).
- Migliora i processi di revisione e approvazione del codice.
- Monitora i colli di bottiglia (ad es. cicli di QA lunghi, approvazioni manuali)
Metodo manuale:
Quando gli strumenti/plugin richiesti non sono disponibili per il calcolo automatizzato del Lead Time, è possibile adottare un approccio manuale. Puoi calcolare manualmente il Lead Time in Azure DevOps (ADO) o in sistemi simili utilizzando l'estrazione di dati grezzi. Ecco un procedimento dettagliato:
Estrazione dei dati
- Origine: Query di elementi di lavoro ADO o API.
Ambito:
- Filtra per Funzionalità/User Story contrassegnate come Completate (ovvero, distribuite in Produzione).
Estrazione:
- Data di creazione (quando è stato richiesto l'elemento di lavoro).
- Data di chiusura/completamento (quando è stato contrassegnato come "Completato").
Formula per il Lead Time di funzionalità/user story:
- Lead Time (per elemento) = Data di chiusura - Data di creazione
Formula per la media a livello di progetto
- Lead Time medio = Somma del Lead Time per elemento ÷ Numero totale di elementi
* Nota: Nei casi in cui le funzionalità pianificate vengano create in anticipo, la metrica del lead time potrebbe non essere un reflecsso veritiero e, in tali casi, il Cycle time può essere utilizzato come metrica alternativa.
Frequenza di distribuzione:
- Conta il numero di distribuzioni in produzione in un dato periodo (ad es. al giorno, alla settimana o al mese).
Estrazione dei dati:
- Usa strumenti CI/CD (ad es. GitHub Actions) per registrare il conteggio delle distribuzioni.
Formula per la frequenza di distribuzione:
- Numero totale di distribuzioni/Numero di mesi
Formula per la media a livello di progetto:
- Numero di distribuzioni del progetto/ Numero di mesi
*Nota: Come da definizione del settore, i rilasci di Hotfix sono esclusi dal conteggio dei rilasci.
Tasso di insuccesso delle modifiche:
Cosa conta come "Rilascio non riuscito"?
- Rollback (ripristino di una versione precedente a causa di problemi).
- Hotfix (correzioni urgenti post-rilascio).
Metodo di tracciamento:
- Integrazione con i fallimenti dei rilasci della pipeline CI/CD (ad es. Jenkins, GitHub Actions) per segnalare i problemi.
- Utilizzo di strumenti di gestione degli incidenti (ad es. ADO, Jira, ServiceNow).
Formula per il tasso di insuccesso delle modifiche:
- Numero di modifiche nonriusite ÷ Numero totale di modifiche × 100.
Metodo manuale:
Per calcolare il numero di modifiche nonriusite, è possibile utilizzare il conteggio degli incidenti di supporto classificati come "Bug software". Questo valore diviso per il numero totale di modifiche rilasciate fornisce il tasso di fallimento delle modifiche (CFR).
Le organizzazioni devono classificare gli incidenti in modo periodico affinché la metrica sia accurata.
Tempo medio di ripristino (MTTR):
Cosa si intende per "tempo di recupero"?
- Inizio: nel momento in cui viene rilevato il guasto (attivazione dell'avviso).
- Fine: nel momento in cui il sistema è completamente ripristinato (ad es. rollback completato, hotfix distribuito).
Metodo di tracciamento:
- Strumenti di gestione degli incidenti (ad es. ADO, Jira).
- Sistemi di monitoraggio (ad es. CloudWatch, Prometheus) per registrare i tempi di risoluzione.
Formula per calcolare il MTTR:
- Somma dei tempi di ripristino ÷ Numero di guasti
Metodo manuale:
La somma dei tempi di ripristino può essere ottenuta in base agli incidenti di supporto classificati come “Bug software”. La differenza tra “Data di creazione” e “Data di chiusura” espressa in giorni può essere utilizzata come numeratore.
È possibile utilizzare il conteggio degli incidenti classificati come “Bug software” come denominatore.
Collegamento di ADO, CI/CD e sistemi di monitoraggio
La raccolta periodica di queste metriche e la loro ottimizzazione aiutano le organizzazioni a raggiungere l'efficienza nel modo in cui rilasciano il software.
Disporre di strumenti efficaci e plugin e integrarli aiuta ad automatizzare la maggior parte di queste attività, a generare metriche e a prendere decisioni appropriate.
Azure DevOps (ADO) fornisce i Metadata necessari per acquisire i dati grezzi per il calcolo di queste metriche. Il team di DevOps deve effettuare un'attenta valutazione tenendo conto delle esigenze aziendali future.
Strumenti di visualizzazione e dashboard
Azure DevOps (ADO) offre funzionalità di dashboard con questi Metadata e widget per acquisire alcune di queste metriche. Tuttavia, assicurarsi che i Metadata siano aggiornati per ogni elemento di lavoro è essenziale per generare metriche accurate.
È possibile impiegare strumenti alternativi come Power BI e Grafana per una visualizzazione avanzata e report dedicati agli stakeholder.
Sfide e considerazioni per le organizzazioni
Raccolta dati e utilizzo degli strumenti
Integrità dei dati e limitazioni degli strumenti
Sfide:
- Fonti di dati incoerenti: le pipeline DevSecOps estraggono dati da strumenti eterogenei (sistemi CI/CD, scanner, sistemi di tracciamento degli incidenti), causando tempistiche disallineate, falsi positivi o lacune.
- Distorsione da segnalazione manuale: le metriche gestite manualmente (ad esempio, i rapporti sugli incidenti) spesso mancano di standardizzazione, falsando tendenze come MTTR (tempo medio di ripristino).
Soluzione:
- Garantisci la tracciabilità: utilizza Metadata immutabili (ad esempio, gli ID delle pipeline di Azure DevOps, i commit Git) per estrarre i dati relativi alle modifiche del codice.
- Valida tramite la correlazione tra strumenti: combina i dati di SonarQube (qualità del codice), ADO per segnalare le anomalie e gli standard di settore per convalidare i dati delle metriche
Disponibilità di strumenti e plugin
Sfida:
- Le organizzazioni potrebbero non avere accesso a strumenti DevSecOps integrati (ad esempio, scanner SAST/DAST, strumenti di tracciamento dei rilasci) o riscontrare problemi con i costi delle licenze.
Soluzione:
- Sfrutta il marketplace di Azure DevOps per i plugin (ad esempio, OWASP ZAP, SonarQube).
- Usa alternative open-source quando i budget sono limitati.
Configurazione di ADO per la raccolta di Metadata
Sfida:
- I dati grezzi di ADO (build, rilasci, elementi di lavoro) richiedono una corretta assegnazione di tag e collegamenti per generare metriche come il tempo di consegna o la frequenza dei rilasci.
Soluzione:
- Imponi campi obbligatori negli elementi di lavoro e aggiornamenti periodici
- Usa le viste di analisi di ADO o i connettori di Power BI per interrogare i Metadata della pipeline.
Aggiornamenti efficaci sulle modifiche dello stato degli elementi di lavoro
Sfida:
- Gli aggiornamenti manuali dello stato (ad esempio, Fatto → Approvato) ritardano metriche come il tempo di ciclo.
Soluzione:
- Automatizza i passaggi utilizzando i webhook di ADO o le funzioni di Azure (ad esempio, l'aggiornamento automatico quando le PR vengono unite).
- Associa gli stati ai controlli DevSecOps (ad esempio, lo stato di revisione della sicurezza prima del rilascio).
Dati insufficienti per generare metriche
Sfida:
- Dati scarsi (ad esempio, rilasci poco frequenti, basso numero di incidenti per progetto) che falsano le tendenze.
Soluzione:
- Definisci soglie minime (ad esempio, "Traccia solo se ci sono più di 5 incidenti nella categoria di bug software").
Metriche non risolutive per le decisioni
Sfida:
- Metriche di vanità (ad esempio, "MTTR di 120 giorni") che non portano a un'azione concreta.
Soluzione:
- Concentrati su metriche orientate ai risultati supportate da dati sufficienti
Resistenza organizzativa e uso improprio
Resistenza organizzativa
Sfide:
- Timore di esposizione: i team potrebbero opporsi a metriche che mettono in luce le inefficienze (ad esempio, un alto tasso di errore nelle modifiche dovuto ai rifiuti di sicurezza).
- Sovraccarico di strumenti: l'introduzione di nuovi strumenti DevSecOps, dei Metadata da acquisire e di plugin (come gli scanner SAST) può incontrare resistenza se percepita come di disturbo o non necessaria.
- Incentivi non allineati: la leadership premia una metrica rispetto a un'altra. Il solo "Lead Time" potrebbe essere fuorviante.
Strategie di mitigazione:
- Presentare le metriche come strumenti di miglioramento:
- Sottolineare in che modo queste metriche aiutano l'organizzazione a lungo termine e a confrontare o misurare le prestazioni.
- Metriche pilota:
- Iniziare con progetti non critici per dimostrare il valore prima di un'implementazione a livello aziendale e concentrarsi su metriche che offrono valore di business.
Obiettivi a lungo termine dell'organizzazione rispetto ai risultati derivati dalle metriche
Sfida:
- Disallineamento: L'ottimizzazione delle metriche a breve termine (ad esempio, il miglioramento della Frequenza di Rilascio) può entrare in conflitto con gli obiettivi a lungo termine (ad esempio, la riduzione del debito tecnico, la maturità della conformità).
- Metriche di vanità rispetto alla creazione di valore: I team potrebbero dare priorità a metriche che appaiono positive rispetto a risultati significativi.
Soluzione:
Collegare le metriche ai temi strategici:
- Mappare le metriche (ad esempio, il Tempo di Attesa) agli obiettivi aziendali (ad esempio, "Immissione sul mercato più rapida per i prodotti critici per la conformità").
Sfida:
Trappola delle metriche durante la definizione della tabella di marcia: concentrarsi eccessivamente su una metrica (ad es., MTTR) potrebbe far ignorare problemi sistemici (ad es., un'automazione dei test inadeguata).
Soluzione:
Portafogli di metriche ponderate:
- Bilancia le metriche con gli obiettivi a lungo termine dell'organizzazione (ad es. Frequenza di rilascio), la stabilità (Tasso di fallimento delle modifiche) rispetto al tempo di lead
Bilanciare le metriche con la cultura del team
I rischi culturali di un eccesso di metriche
Sfide:
- Timore della misurazione: i team potrebbero percepire le metriche come uno strumento di sorveglianza, causando stress e burnout.
- Manipolazione del sistema: la pressione per raggiungere gli obiettivi (ad es. Frequenza di rilascio) può incentivare scorciatoie (ad es. saltare le scansioni di sicurezza).
- soffocamento dell'innovazione: un'eccessiva attenzione alle metriche potrebbe disincentivare la sperimentazione (ad es. il timore che il fallimento dei rilasci influisca sul Tasso di fallimento delle modifiche).
Soluzione:
- La sicurezza psicologica prima di tutto:
- Sottolineare che le metriche sono strumenti diagnostici e non valutazioni delle prestazioni.
- Valorizzare l'"imparare dai fallimenti" (ad es. le revisioni post-incidente che migliorano il MTTR).
- Progettazione delle metriche guidata dal team:
- Coinvolgere i tecnici nella selezione delle metriche (ad es. consentire loro di scegliere tra Tempo di lead o Tempo di ciclo come priorità rispetto al Tasso di fallimento delle modifiche).
Metriche e capacità del team ed esigenze di formazione
Lacune di competenze che ostacolano le metriche
Sfida:
I team non dispongono delle competenze per migliorare le metriche chiave (ad es. Tempo di lead lento a causa della scarsa familiarità con gli strumenti di sicurezza)
Soluzioni:
- Segmentazione delle metriche basata sulle competenze:
- Esempio: tracciare il Tempo di lead separatamente per i team che adottano nuovi strumenti SAST
- Formazione just-in-time:
- Automatizza gli attivatori della formazione (ad es., se il Tasso di pipeline fallite a causa della sicurezza è >15%, assegna una formazione modulare).
- Metriche di tutoraggio:
- Misura la % di sessioni di pair programming per favorire la condivisione delle conoscenze.
Metriche che ignorano la crescita del team
Sfida:
- Un'eccessiva enfasi sulle metriche di output (ad es., Frequenza di rilascio) sminuisce lo sviluppo delle competenze.
Soluzioni:
- Bilanciare le metriche di output e di crescita:
- Associa la Frequenza di rilascio alla % di membri del team che contribuiscono al codice della pipeline.
- Metriche per il percorso di carriera:
- Esempio: monitora la % di ingegneri che guidano le revisioni della sicurezza per incoraggiare il senso di responsabilità.
Riferimenti
- Accelerate di Forsgren, Humble & Kim
- Documentazione di Azure DevOps
- Report DevOps Research and Assessment (DORA)
