{"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 raccogliere i dati per i calcoli","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A dir la verit\u00e0, 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\u00ec presi che non volevano fare nulla per nessun altro. <\/p>\n

Ma la direzione non era mai soddisfatta \u2013 continuava a richiedere metriche nuove, smettendo di utilizzare rapidamente quelle gi\u00e0 realizzate.<\/p>\n

Ultimamente si parlava solo di LeadTime \u2013 il tempo di consegna delle funzionalit\u00e0 aziendali. La metrica mostrava un numero sorprendente: 200 giorni per consegnare un compito. Tutti si meravigliavano, esclamando e alzando le mani al cielo!<\/p>\n

Dopo un po', il trambusto si attut\u00ec e dalla direzione arriv\u00f2 l\u2019ordine di creare un'altra metrica.<\/p>\n

A Ivan era perfettamente chiaro che anche la nuova metrica zou si spegnerebbe silenziosamente in un angolo buio.<\/p>\n

Veramente, pensava Ivan, sapere un numero non significa nulla per nessuno. 200 giorni o 2 giorni \u2013 non c'\u00e8 alcuna differenza, perch\u00e9 da un numero non si pu\u00f2 determinare la causa e capire se sia qualcosa di buono o cattivo.<\/p>\n

Questa \u00e8 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\u00e9? Perch\u00e9 il segreto non deve essere cercato nelle metriche!<\/p>\n

Per Ivan, questa era una fase superata. Lui comprendeva che le metriche sono semplicemente un comune righello di legno<\/a><\/noindex> per misurazioni, e i veri segreti devono essere trovati in l'oggetto di influenza<\/a><\/noindex>, cio\u00e8 in ci\u00f2 che forma questa metrica.<\/p>\n

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

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

Obiettivo delle metriche DevOps<\/h2>\n

\n\u00c8 evidente che tutti vogliono ridurre il tempo di consegna. 200 giorni sono, ovviamente, inaccettabili. <\/p>\n

Ma come, questo \u00e8 il nodo della questione?<\/a><\/noindex><\/p>\n

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\u00e0 come una distribuzione. Ogni team avr\u00e0 il proprio tempo e le proprie peculiarit\u00e0. Come si fa a trovare qualcosa in mezzo a tutto questo?<\/p>\n

La risposta \u00e8 emersa da s\u00e9: \u00e8 necessario individuare i team problematici e capire cosa sta succedendo e perch\u00e9 ci mette cos\u00ec tanto, mentre dai team 'buoni' imparare a fare tutto velocemente. E per questo \u00e8 necessario misurare il tempo trascorso dai team su ciascuna delle postazioni DevOps:<\/p>\n

\"Metriche
\n
\nL'obiettivo del sistema sar\u00e0 selezionare i team in base al tempo di attraversamento delle postazioni, cio\u00e8 alla fine dovremmo ottenere un elenco di team con il tempo selezionato, non un numero.<\/p>\n

Se scopriamo quanto tempo \u00e8 stato speso in totale per ogni postazione e quanto tempo \u00e8 stato perso nei periodi di inattivit\u00e0 tra le postazioni, possiamo trovare i team, contattarli e indagare pi\u00f9 dettagliatamente sulle cause e risolverle,\u00bb pens\u00f2 Ivan.<\/p>\n

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

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

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

In azienda si utilizzano un numero limitato di sistemi, e le informazioni possono essere ottenute solo da essi e non da altre fonti.<\/p>\n

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

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

\"Metriche
\n
\nIvan ha descritto da quali sistemi si potesse ottenere quale informazione per calcolare il tempo sugli stand:<\/p>\n