Rehellisesti sanottuna Ivan nauroi usein valvontaosaston kollegoidensa turhaille ponnisteluille. He tekivät suuria ponnisteluja toteuttaakseen mittareita, jotka yrityksen johto käski heidän saavuttaa. He olivat niin kiireisiä, etteivät halunneet kenenkään muun tekevän mitään.
Mutta se ei riittänyt johdolle - he tilasivat jatkuvasti uusia ja uusia mittareita, lakkasivat hyvin nopeasti käyttämästä aiemmin tehtyjä.
Viime aikoina kaikki ovat puhuneet LeadTimesta – liiketoimintojen toimittamisen ajasta. Mittari osoitti hullun luvun - 200 päivää yhden tehtävän suorittamiseen. Kuinka kaikki huokaisivat ja aahtivat ja nostivat kätensä taivasta kohti!
Jonkin ajan kuluttua melu vaimeni vähitellen ja johto sai käskyn luoda uusi mittari.
Ivanille oli täysin selvää, että uusi mittari kuolisi yhtä hiljaa pimeään nurkkaan.
Todellakin, Ivan ajatteli, numeron tietäminen ei kerro kenellekään yhtään mitään. 200 päivää tai 2 päivää - ei ole eroa, koska on mahdotonta määrittää syytä numerolla ja ymmärtää, onko se hyvä vai huono.
Tämä on tyypillinen metriikan ansa: näyttää siltä, että uusi mittari kertoo olemassaolon olemuksen ja selittää jonkin salaisen salaisuuden. Kaikki toivovat tätä niin paljon, mutta jostain syystä mitään ei tapahdu. Kyllä, koska salaisuutta ei pitäisi löytää mittareista!
Ivanille tämä oli ohitettu vaihe. Hän ymmärsi sen mittauksia varten, ja kaikki salaisuudet on etsittävä , eli on, että tämä mittari muodostuu.
Verkkokaupassa vaikutuksen kohteena ovat sen asiakkaat, jotka tuovat rahaa, ja DevOpsille tiimit, jotka luovat ja levittävät jakeluja putkilinjan avulla.
Eräänä päivänä istuessaan aulan mukavalle tuolille Ivan päätti harkita huolellisesti, kuinka hän halusi nähdä DevOps-mittareita, ottaen huomioon sen tosiasian, että vaikutuskohteena ovat tiimit.
DevOps-mittarien tarkoitus
On selvää, että kaikki haluavat lyhentää toimitusaikoja. 200 päivää ei tietenkään ole hyvä.
Mutta miten, se on kysymys?
Yritys työllistää satoja tiimejä, ja tuhansia jakeluja kulkee DevOps-putken läpi päivittäin. Todellinen toimitusaika näkyy jakeluna. Jokaisella joukkueella on oma aika ja omat ominaisuutensa. Miten tästä sotkusta voi löytää mitään?
Vastaus syntyi luonnollisesti - meidän on löydettävä ongelmatiimit ja selvitettävä, mitä heille tapahtuu ja miksi se kestää niin kauan, sekä opittava "hyviltä" tiimeiltä kuinka kaikki tehdään nopeasti. Ja tehdäksesi tämän, sinun on mitattava aika, jonka tiimit viettävät kullakin DevOps-osastolla:
”Järjestelmän tarkoituksena on valita joukkueet katsomoilta läpäisyn ajan perusteella, eli. Tämän seurauksena meidän pitäisi saada luettelo komennoista valitulla ajalla, ei numerolla.
Jos saamme selville, kuinka paljon aikaa vietettiin katsomossa yhteensä ja kuinka paljon seisokkeja katsomoiden välillä, voimme löytää joukkueet, soittaa heille ja ymmärtää syitä tarkemmin ja poistaa ne”, Ivan pohti.
Kuinka laskea DevOpsin toimitusaika
Sen laskemiseksi piti syventyä DevOps-prosessiin ja sen olemukseen.
Yrityksellä on käytössään rajallinen määrä järjestelmiä, ja tietoa saa vain niistä eikä mistään muualta.
Kaikki yrityksen tehtävät rekisteröitiin Jiraan. Kun tehtävä otettiin vastaan, sille luotiin haara, ja toteutuksen jälkeen tehtiin sitoumus BitBucket- ja Pull Requestiin. Kun PR (Pull Request) hyväksyttiin, jakelu luotiin automaattisesti ja tallennettiin Nexus-tietovarastoon.
Seuraavaksi jakelu otettiin käyttöön useilla osastoilla Jenkinsin avulla julkaisun oikeellisuuden tarkistamiseksi, automaattinen ja manuaalinen testaus:
Ivan kuvaili, mistä järjestelmistä mitä tietoja voidaan ottaa osastolla olevan ajan laskemiseen:
- Nexuksesta – Jakelun luomisaika ja komentokoodin sisältävän kansion nimi
- Jenkinsiltä – Jokaisen työn aloitusaika, kesto ja tulos, osaston nimi (työparametreissa), vaiheet (työvaiheet), linkki jakeluun Nexuksessa.
- Ivan päätti olla sisällyttämättä Jiraa ja BitBucketia valmisteluun, koska ne liittyivät enemmän kehitysvaiheeseen eivätkä valmiin jakelun levittämiseen osastoille.
Käytettävissä olevien tietojen perusteella piirrettiin seuraava kaavio:
Kun tiedät, kuinka kauan jakeluiden luomiseen kuluu ja kuinka paljon aikaa kuluu kuhunkin niistä, voit helposti laskea koko DevOps-putken (koko sykli) läpikäymisen kokonaiskustannukset.
Tässä ovat DevOps-mittarit, joihin Ivan päätyi:
- Luotujen jakelujen määrä
- Osuus jakeluista, jotka "tulivat" osastolle ja "läpivät" osastolla
- Jalustalla vietetty aika (seisontajakso)
- Täysi sykli (kokonaisaika kaikille seisoille)
- Työn kesto
- Katkos seisokkien välillä
- Seisokki töiden julkaisujen välillä samalla osastolla
Toisaalta mittarit luonnehtivat DevOps-putkea ajallisesti erittäin hyvin, toisaalta niitä pidettiin hyvin yksinkertaisina.
Tyytyväinen hyvin tehtyyn työhön Ivan piti esityksen ja meni esittelemään sitä johdolle.
Hän tuli takaisin synkänä ja kädet alhaalla.
"Tämä on fiasko, veli", ironinen kollega hymyili...
Lue lisää artikkelista "'.
Lähde: will.com