🥇Metriche DevOps – da dove ottenere i dati per i calcoli

A dire il vero, Ivan sorrideva spesso degli sforzi vani dei colleghi del reparto monitoraggio. Si impegnavano enormemente per realizzare le metriche ordinate dalla direzione dell'azienda. Erano così occupati che non volevano più fare niente per nessuno.

E la direzione era insaziabile – continuava a ordinare sempre nuove metriche, smettendo molto rapidamente di utilizzare quelle già realizzate.

Negli ultimi tempi tutti parlavano del LeadTime – il tempo di consegna delle funzionalità aziendali. La metrica mostrava un numero folle: 200 giorni per consegnare un compito. Come tutti si meravigliavano e alzavano le mani al cielo!

Dopo un po’, il rumore si è gradualmente spento e la direzione ha ordinato la creazione di un'altra metrica.

Ivan sapeva perfettamente che anche la nuova metrica sarebbe morta silenziosamente in un angolo buio.

Infatti, pensava Ivan, sapere un numero non dice nulla a nessuno. 200 giorni o 2 giorni – non c'è alcuna differenza, perché non è possibile determinare la causa e capire se sia una cosa buona o cattiva.

Questa è una trappola tipica delle metriche: sembra che una nuova metrica rivelerà l’essenza dell’esistenza e spiegherà qualche segreto nascosto. Tutti ci sperano, ma stranamente non accade nulla. Perché il segreto non si deve cercare nelle metriche!

Per Ivan, questo era un passaggio già superato. Comprendeva che le metriche sono semplicemente un righello di legno per le misurazioni, e tutti i segreti devono essere cercati nel oggetto d'influenza, cioè in ciò che forma questa metrica.

Per un negozio online, l'oggetto d'influenza sono i suoi clienti, che portano ricavi, mentre per DevOps – i team che creano e distribuiscono i pacchetti utilizzando la pipeline.

Un giorno, sistemato in una comoda poltrona nel hall, Ivan decise di riflettere su come vorrebbe vedere le metriche DevOps tenendo conto che l'oggetto d'influenza sono i team.

Obiettivo delle metriche DevOps

È chiaro che a tutti piace ridurre il tempo di consegna. 200 giorni – non vanno proprio bene.

Ma come, ecco la questione?

Nell'azienda lavorano centinaia di squadre e ogni giorno passano attraverso il pipeline DevOps migliaia di pacchetti. Il tempo reale di consegna apparirà come una distribuzione. Ogni squadra avrà il proprio tempo e le proprie peculiarità. Come si può trovare qualcosa in mezzo a questo caos?

La risposta è venuta da sé: è necessario identificare le squadre problematiche e capire cosa stia succedendo e perché ci vuole tanto tempo, mentre dalle squadre 'buone' imparare come fare tutto rapidamente. E per questo è necessario misurare il tempo trascorso dalle squadre su ciascuno degli stand DevOps:

«L'obiettivo del sistema sarà la selezione delle squadre in base al tempo di attraversamento degli stand, ovvero alla fine dobbiamo ottenere un elenco di squadre con il tempo selezionato, non un numero.

Se riusciremo a scoprire quanto tempo è stato speso complessivamente per lo stand e quanto tempo è stato speso in attese tra gli stand, potremo trovare le squadre, contattarle e approfondire le cause per risolverle», — pensò Ivan.

Come calcolare il tempo di consegna per DevOps

Per il calcolo è stato necessario approfondire il processo DevOps e le sue entità.

Nell'azienda viene utilizzato un numero limitato di sistemi, e le informazioni possono essere ottenute solo da essi e da nessun altro.

Tutte le attività nell'azienda venivano registrate in Jira. Quando un'attività veniva presa in carico, veniva creato un branch per essa, e dopo l'implementazione veniva effettuato un commit in BitBucket e una Pull Request. Quando il PR (Pull Request) veniva accettato, veniva automaticamente creato un pacchetto e salvato nel repository Nexus.

Successivamente, il pacchetto veniva distribuito su vari stand tramite Jenkins per verificare la correttezza dell'installazione, test automatici e manuali:

Ivan ha elencato da quali sistemi è possibile ottenere quali informazioni per calcolare il tempo sugli stand:

Da Nexus – Tempo di creazione del pacchetto e nome della cartella in cui era contenuto il codice della squadra
Da Jenkins – Tempo di avvio, durata e risultato dell'esecuzione di ogni lavoro, nome dello stand (nei parametri del lavoro), fasi (passi del lavoro), link al pacchetto in Nexus.
Ivan ha deciso di non includere Jira e BitBucket nel pipeline, in quanto si riferivano maggiormente alla fase di sviluppo e non all'implementazione del pacchetto pronto sugli stand.

Sulla base delle informazioni disponibili, è stata elaborata la seguente schema:

Sapendo quanto tempo ci vuole per creare le distribuzioni e quanto tempo è necessario per ognuna di esse, è facile calcolare i costi totali per l'intero processo DevOps (ciclo completo).