Per valutare l’andamento di un processo, esistono quattro metriche principali.
Ci vuole tempo per costruire una cultura basata sui dati, soprattutto in un sistema che parte da segnalazioni o “incidenti”. La risposta agli incidenti è essenziale per l’attività ed è un ambiente ideale per il miglioramento del team. La scelta delle metriche di mappatura dell’IT sul business è essenziale.
Queste quattro principali metriche sono:
– Conteggio degli incidenti: è necessario conoscere il numero di incidenti che ogni squadra incontra nel periodo di riferimento. Si monitorano i picchi, che indicano un punto debole nel team o l’inadeguatezza degli strumenti.
– (Mean) Time to Acknowledgment: il Time to Acknowledgment è un buon modo per misurare le prestazioni individuali.
– Escalation: la gestione degli incidenti comprende il modo in cui vengono allertate le singole persone o funzioni e i ritardi tra gli allarmi stessi. Per la maggior parte delle organizzazioni che utilizzano software di gestione delle operazioni IT, le escalation sono rare. Sono un segno di inadeguatezza: o un rispondente non è stato in grado di arrivare a un incidente in tempo, oppure non sono disponibili strumenti o competenze per gestirlo.
– (Mean) time to resolution: gli incidenti aumentano con l’attività e diminuiscono con l’organizzazione. Del resto, la metrica di base più importante per l’azienda è il tempo medio di soluzione dell’incidente. Questo è uno dei numeri più complessi da maneggiare. Un problema basilare dell’analisi dei dati è il rumore di fondo. La sua presenza rende pesante separare le informazioni utili da quelle inutili.
Un team di DevOps guidato dai dati riduce questo rumore e la conseguente fatica di analisi grazie a metriche orientate al business. Partire dai dati ha un immediato vantaggio nello sviluppo del processo: l’individuazione delle responsabilità dirette e collegate è chiara e immediata e il manager sa a quale team o professionista rivolgersi per ogni punto carente. Qui s’inserisce l’importanza della cultura DevOps applicata ai dati. Grazie a metriche chiare, infatti, la risposta agli incidenti è sotto controllo e viene migliorata continuamente.
È necessario collegare le metriche con specifici obiettivi aziendali, incoraggiando i team ad agire, prendere decisioni data-driven e agire in base a tali decisioni. Le metriche sono un mezzo per capire come migliorare i processi futuri, non per assegnare responsabilità di imprecisioni passate. Un’analisi errata porterebbe alla paralisi del processo decisionale: bisogna evitare il tipico stallo che proviene dal tentativo di lavorare con troppi dati in un momento troppo anticipato.
DevOps richiede ovviamente l’utilizzo di sistemi di sviluppo e gestione delle applicazioni più integrate rispetto al passato e che abbiano anche recepito i modelli di Agile Development e Continuous Delivery, ambiti strettamente collegati ma distinti tra loro. Alcuni software vendor hanno presentato piattaforme per DevOps che cercano di raccogliere tutte le funzioni necessarie.
E’ anche possibile adottare il modello DevOps facendo cooperare moduli distinti e più mirati, molti dei quali vengono dal mondo open source. Infine, molti professionisti di cybersicurezza di aziende che fanno uso di DevOps nel cloud pubblico ritengono che si stia privilegiando la velocità a scapito della sicurezza. C’è infatti preoccupazione tra i professionisti su come riuscire a far viaggiare la sicurezza alla stessa velocità e frequenza di aggiornamento di app e servizi DevOps nel cloud pubblico.
Corso DevOps Foundation di DevOps Institute al link https://www.hrv-swiss.consulting/it/01-devops-fnd/
