A dir la verità, Ivan si divertiva spesso a ridere degli sforzi vani dei suoi colleghi del dipartimento di monitoraggio. Si impegnavano enormemente per realizzare le metriche richieste dalla direzione aziendale. Erano così presi che non volevano fare nulla per nessun altro.
Ma la direzione non era mai soddisfatta – continuava a richiedere metriche nuove, smettendo di utilizzare rapidamente quelle già realizzate.
Ultimamente si parlava solo di LeadTime – il tempo di consegna delle funzionalità aziendali. La metrica mostrava un numero sorprendente: 200 giorni per consegnare un compito. Tutti si meravigliavano, esclamando e alzando le mani al cielo!
Dopo un po', il trambusto si attutì e dalla direzione arrivò l’ordine di creare un'altra metrica.
A Ivan era perfettamente chiaro che anche la nuova metrica zou si spegnerebbe silenziosamente in un angolo buio.
Veramente, pensava Ivan, sapere un numero non significa nulla per nessuno. 200 giorni o 2 giorni – non c'è alcuna differenza, perché da un numero non si può determinare la causa e capire se sia qualcosa di buono o cattivo.
Questa è una trappola tipica delle metriche: sembra che una nuova metrica possa raccontare l'essenza delle cose e svelare un qualche segreto nascosto. Tutti ci sperano, ma per qualche motivo non accade nulla. Perché? Perché il segreto non deve essere cercato nelle metriche!
Per Ivan, questa era una fase superata. Lui comprendeva che per misurazioni, e i veri segreti devono essere trovati in , cioè in ciò che forma questa metrica.
Per un negozio online, l'oggetto di influenza saranno i suoi clienti, che portano denaro, mentre per il DevOps – i team che creano e distribuiscono i pacchetti utilizzando il pipeline.
Un giorno, seduto nel corridoio su una comoda poltrona, Ivan decise di riflettere a fondo su come avrebbe voluto vedere le metriche DevOps considerando che l'oggetto di influenza sono i team.
Obiettivo delle metriche DevOps
È evidente che tutti vogliono ridurre il tempo di consegna. 200 giorni sono, ovviamente, inaccettabili.
Ma come, questo è il nodo della questione?
In azienda lavorano centinaia di team e ogni giorno migliaia di distribuzioni passano attraverso il flusso di lavoro DevOps. Il tempo di consegna reale apparirà come una distribuzione. Ogni team avrà il proprio tempo e le proprie peculiarità. Come si fa a trovare qualcosa in mezzo a tutto questo?
La risposta è emersa da sé: è necessario individuare i team problematici e capire cosa sta succedendo e perché ci mette così tanto, mentre dai team 'buoni' imparare a fare tutto velocemente. E per questo è necessario misurare il tempo trascorso dai team su ciascuna delle postazioni DevOps:
L'obiettivo del sistema sarà selezionare i team in base al tempo di attraversamento delle postazioni, cioè alla fine dovremmo ottenere un elenco di team con il tempo selezionato, non un numero.
Se scopriamo quanto tempo è stato speso in totale per ogni postazione e quanto tempo è stato perso nei periodi di inattività tra le postazioni, possiamo trovare i team, contattarli e indagare più dettagliatamente sulle cause e risolverle,» pensò Ivan.
Come calcolare il tempo di consegna per DevOps
Per effettuare il calcolo era necessario approfondire il processo DevOps e le sue entità.
In azienda si utilizzano un numero limitato di sistemi, e le informazioni possono essere ottenute solo da essi e non da altre fonti.
Tutte le attività in azienda venivano registrate su Jira. Quando un'attività veniva presa in carico, veniva creato un branch; dopo l'implementazione veniva effettuato un commit su BitBucket e una Pull Request. Al momento dell'accettazione della PR (Pull Request), veniva automaticamente creato un pacchetto e salvato nel repository Nexus.
Successivamente, il pacchetto veniva distribuito su più stand tramite Jenkins per verificare la correttezza dell'installazione, test automatici e manuali:
Ivan ha descritto da quali sistemi si potesse ottenere quale informazione per calcolare il tempo sugli stand:
- Da Nexus – Tempo di creazione del pacchetto e nome della cartella che conteneva il codice del team
- Da Jenkins – Tempo di avvio, durata e risultato dell'esecuzione di ciascun job, nome dello stand (nelle impostazioni del job), stadi (passaggi del job), link al pacchetto in Nexus.
- Ivan ha deciso di non includere Jira e BitBucket nel pipeline, poiché si riferivano maggiormente alla fase di sviluppo, piuttosto che alla distribuzione del pacchetto sui stand.
Sulla base delle informazioni a disposizione è stata disegnata la seguente mappa:
Sapendo quanto tempo ci vuole per creare le distribuzioni e quanto tempo viene speso per ciascuna di esse, è facile calcolare i costi totali per attraversare l'intero processo DevOps (ciclo completo).
Ecco quali metriche DevOps ha ottenuto Ivan:
- Numero di distribuzioni create
- Quota di distribuzioni che sono 'arrivate' sulla scaffalatura e 'hanno superato' la scaffalatura
- Tempo trascorso sulla scaffalatura (ciclo della scaffalatura)
- Ciclo completo (tempo totale su tutte le scaffalature)
- Durata dei job
- Fermate tra le scaffalature
- Fermate tra l'esecuzione dei job su una sola scaffalatura
Da un lato, le metriche caratterizzavano molto bene il processo DevOps in termini di tempo, dall'altro erano semplici da calcolare.
Soddisfatto del lavoro ben fatto, Ivan ha preparato una presentazione e si è diretto a presentarla alla direzione.
Tornava indietro con le mani abbassate e un'espressione cupa.
— È un fiasco, amico — sorrise un collega ironicamente...
Continua a leggere nell'articolo «».
Fonte: habr.com
