A dire il vero, Ivan rideva spesso degli inutili sforzi dei suoi colleghi del dipartimento di monitoraggio. Hanno compiuto grandi sforzi per implementare i parametri che il management dell'azienda aveva ordinato loro di raggiungere. Erano così occupati che non volevano che nessun altro facesse nulla.
Ma alla direzione non bastava: ordinavano costantemente sempre più nuovi parametri, cessando molto rapidamente di utilizzare ciò che era stato fatto in precedenza.
Ultimamente tutti parlano di LeadTime, il tempo per la consegna delle funzionalità aziendali. La metrica mostrava un numero folle: 200 giorni per consegnare un'attività. Come tutti hanno emesso ooh e aah e hanno alzato le mani al cielo!
Dopo qualche tempo, il rumore si è gradualmente attenuato e la direzione ha ricevuto l'ordine di creare un altro parametro.
Per Ivan era del tutto chiaro che la nuova metrica sarebbe morta altrettanto silenziosamente in un angolo buio.
In effetti, pensò Ivan, conoscere il numero non dice proprio niente a nessuno. 200 giorni o 2 giorni: non c'è differenza, perché è impossibile determinare il motivo in base al numero e capire se è buono o cattivo.
Questa è una tipica trappola della metrica: sembra che una nuova metrica racconterà l'essenza dell'esistenza e spiegherà qualche segreto segreto. Tutti sperano tanto in questo, ma per qualche motivo non succede nulla. Sì, perché il segreto non va ricercato nelle metriche!
Per Ivan questa era una fase superata. Lo aveva capito per le misurazioni, e tutti i segreti vanno ricercati , cioè. è che questa metrica è formata.
Per un negozio online, l'oggetto dell'influenza saranno i suoi clienti che portano denaro, e per DevOps saranno i team che creano e implementano le distribuzioni utilizzando una pipeline.
Un giorno, seduto su una comoda sedia nell'ingresso, Ivan ha deciso di riflettere attentamente su come voleva vedere le metriche DevOps, tenendo conto del fatto che l'oggetto dell'influenza sono i team.
Scopo delle metriche DevOps
È chiaro che tutti vogliono ridurre i tempi di consegna. 200 giorni ovviamente non vanno bene.
Ma come, questa è la domanda?
L'azienda impiega centinaia di team e migliaia di distribuzioni passano ogni giorno attraverso la pipeline DevOps. Il tempo di consegna effettivo verrà visualizzato come distribuzione. Ogni squadra avrà i propri tempi e le proprie caratteristiche. Come puoi trovare qualcosa in questo caos?
La risposta è arrivata in modo naturale: dobbiamo trovare i team problematici e capire cosa sta succedendo loro e perché ci vuole così tanto tempo, e imparare dai team “buoni” come fare tutto rapidamente. E per fare ciò è necessario misurare il tempo trascorso dai team in ciascuno degli stand DevOps:
“Lo scopo del sistema sarà quello di selezionare le squadre in base al tempo in cui passano sugli spalti, cioè. Di conseguenza, dovremmo ottenere un elenco di comandi con l'ora selezionata e non un numero.
Se scopriamo quanto tempo è stato trascorso sullo stand in totale e quanto tempo è stato dedicato ai tempi di inattività tra gli stand, possiamo trovare le squadre, chiamarle, capire più in dettaglio le ragioni ed eliminarle”, ha pensato Ivan.
Come calcolare i tempi di consegna per DevOps
Per calcolarlo è stato necessario approfondire il processo DevOps e la sua essenza.
L'azienda utilizza un numero limitato di sistemi e le informazioni possono essere ottenute solo da loro e da nessun'altra parte.
Tutte le attività dell'azienda sono state registrate in Jira. Quando veniva intrapresa un'attività, veniva creato un ramo per essa e, dopo l'implementazione, veniva effettuato un commit su BitBucket e Pull Request. Quando veniva accettata una PR (Pull Request), una distribuzione veniva automaticamente creata e archiviata nel repository Nexus.
Successivamente, la distribuzione è stata implementata su diversi stand utilizzando Jenkins per verificare la correttezza del rollout e dei test automatici e manuali:
Ivan ha descritto da quali sistemi quali informazioni si possono prendere per calcolare il tempo in tribuna:
- Da Nexus: ora di creazione della distribuzione e nome della cartella che conteneva il codice del comando
- Da Jenkins – Ora di inizio, durata e risultato di ogni lavoro, nome dello stand (nei parametri del lavoro), fasi (fasi di lavoro), collegamento alla distribuzione in Nexus.
- Ivan ha deciso di non includere Jira e BitBucket nella pipeline, perché... erano più legati alla fase di sviluppo e non al lancio della distribuzione finita sugli stand.
Sulla base delle informazioni disponibili è stato disegnato il seguente schema:
Sapendo quanto tempo è necessario per creare distribuzioni e quanto tempo viene dedicato a ciascuna di esse, puoi facilmente calcolare i costi totali derivanti dall'esecuzione dell'intera pipeline DevOps (ciclo completo).
Ecco le metriche DevOps con cui Ivan ha ottenuto:
- Numero di distribuzioni create
- Quota delle distribuzioni che “sono arrivate” allo stand e “hanno superato” lo stand
- Tempo trascorso sullo stand (ciclo dello stand)
- Ciclo completo (tempo totale per tutti gli stand)
- Durata del lavoro
- Tempi morti tra gli stand
- Tempi di inattività tra i lanci di lavoro nello stesso stand
Le metriche da un lato hanno caratterizzato molto bene la pipeline DevOps in termini di tempo, dall'altro sono state considerate molto semplici.
Soddisfatto del lavoro ben svolto, Ivan ha fatto una presentazione ed è andato a presentarla alla direzione.
Tornò cupo e con le mani abbassate.
“Questo è un fiasco, fratello”, sorride ironico il collega…
Leggi di più nell’articolo “'.
Fonte: habr.com