{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"Metriche DevOps \u2013 da dove prendere i dati per i calcoli","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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\u00ec occupati che non volevano pi\u00f9 fare niente per nessuno. <\/p>\n

E la direzione era insaziabile \u2013 continuava a ordinare sempre nuove metriche, smettendo molto rapidamente di utilizzare quelle gi\u00e0 realizzate.<\/p>\n

Negli ultimi tempi tutti parlavano del LeadTime \u2013 il tempo di consegna delle funzionalit\u00e0 aziendali. La metrica mostrava un numero folle: 200 giorni per consegnare un compito. Come tutti si meravigliavano e alzavano le mani al cielo!<\/p>\n

Dopo un po\u2019, il rumore si \u00e8 gradualmente spento e la direzione ha ordinato la creazione di un'altra metrica.<\/p>\n

Ivan sapeva perfettamente che anche la nuova metrica sarebbe morta silenziosamente in un angolo buio.<\/p>\n

Infatti, pensava Ivan, sapere un numero non dice nulla a nessuno. 200 giorni o 2 giorni \u2013 non c'\u00e8 alcuna differenza, perch\u00e9 non \u00e8 possibile determinare la causa e capire se sia una cosa buona o cattiva.<\/p>\n

Questa \u00e8 una trappola tipica delle metriche: sembra che una nuova metrica riveler\u00e0 l\u2019essenza dell\u2019esistenza e spiegher\u00e0 qualche segreto nascosto. Tutti ci sperano, ma stranamente non accade nulla. Perch\u00e9 il segreto non si deve cercare nelle metriche!<\/p>\n

Per Ivan, questo era un passaggio gi\u00e0 superato. Comprendeva che le metriche sono semplicemente un righello di legno<\/a><\/noindex> per le misurazioni, e tutti i segreti devono essere cercati nel oggetto d'influenza<\/a><\/noindex>, cio\u00e8 in ci\u00f2 che forma questa metrica.<\/p>\n

Per un negozio online, l'oggetto d'influenza sono i suoi clienti, che portano ricavi, mentre per DevOps \u2013 i team che creano e distribuiscono i pacchetti utilizzando la pipeline.<\/p>\n

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.<\/p>\n

Obiettivo delle metriche DevOps<\/h2>\n

\n\u00c8 chiaro che a tutti piace ridurre il tempo di consegna. 200 giorni \u2013 non vanno proprio bene. <\/p>\n

Ma come, ecco la questione?<\/a><\/noindex><\/p>\n

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

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

\"Metriche
\n
\n\u00abL'obiettivo del sistema sar\u00e0 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.<\/p>\n

Se riusciremo a scoprire quanto tempo \u00e8 stato speso complessivamente per lo stand e quanto tempo \u00e8 stato speso in attese tra gli stand, potremo trovare le squadre, contattarle e approfondire le cause per risolverle\u00bb, \u2014 pens\u00f2 Ivan.<\/p>\n

\"Metriche
\n <\/p>\n

Come calcolare il tempo di consegna per DevOps<\/h2>\n

Per il calcolo \u00e8 stato necessario approfondire il processo DevOps e le sue entit\u00e0.<\/p>\n

Nell'azienda viene utilizzato un numero limitato di sistemi, e le informazioni possono essere ottenute solo da essi e da nessun altro.<\/p>\n

Tutte le attivit\u00e0 nell'azienda venivano registrate in Jira. Quando un'attivit\u00e0 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. <\/p>\n

\"Metriche
\n
\nSuccessivamente, il pacchetto veniva distribuito su vari stand tramite Jenkins per verificare la correttezza dell'installazione, test automatici e manuali:<\/p>\n

\"Metriche
\n
\nIvan ha elencato da quali sistemi \u00e8 possibile ottenere quali informazioni per calcolare il tempo sugli stand:<\/p>\n