🥇DevOps mõõdikud – kust saada andmeid arvutusteks

Ausfadserd, Ivan naeris sagnvikas üle kolleegide pettumust valmistavaid pingutusi jälgimisosakonnas. Nad pingutasid tohutult, et rakendada metrikaid, mida ettevõtte juhtkond tellis. Nad olid nii hõivatud, et ei tahtnud enam kellelegi midagi teha.

Ja juhtkonnale ei piisatud kunagi – nad tellisid pidevalt uusi ja uusi metrikaid, lõpetades väga kiiresti varem loodud metrikate kasutamise.

Viimasel ajal räägiti ainult LeadTime'ist – ärifunktsioonide tarnimise ajast. Metrika näitas hullumeelset numbrit – 200 päeva ühe ülesande tarnimiseks. Kuidas kõik ohkasid, ohkasid ja tõstsid käsi taevapoole!

Mõne aja pärast mürin vaibus ja juhtkonnalt tuli tellimus veel ühe metrika loomise kohta.

Ivanile oli täiesti selge, et ka uus metrika sureb vaikides pimedasse nurkasse.

Tõepoolest, mõtles Ivan, numbrite teadmine ei ütle kellelegi midagi. 200 päeva või 2 päeva – vahet pole, sest numbrite põhjal ei ole võimalik põhjust määrata ja aru saada, kas see on hea või halb.

See on tüüpiline metrikate lõks: tundub, et uus metrika räägib elu olemusest ja selgitab mingit salajast saladust. Kõik loodavad sellele, kuid midagi ei juhtu. Just seetõttu, et saladust tuleb otsida sugugi mitte metrikatest!

Ivanile oli see juba möödanik. Ta mõistis, et metrikad on lihtsalt tavaline puust joonlaud mõõtmiste jaoks, ja kõik saladused tuleb otsida mõjuks olevast objektist, st sellest, mis seda metrikat kujundab.

Internetipoe jaoks on mõju objektiks tema kliendid, kes toovad raha, ja DevOps'i jaoks – meeskonnad, kes loovad ja levitavad distributsioone torustiku abil.

Ühel päeval, mugavas toolis vestibüülis, otsustas Ivan tõsiselt kaaluda, kuidas ta sooviks näha DevOps'i metrikaid, arvestades, et mõju objektiks on meeskonnad.

DevOps'i metrikate eesmärk

On selge, et kõik tahavad tarnimise aega vähendada. 200 päeva – see pole kindlasti normaalne.

Aga kuidas, see on küsimus?

Ettevõttes töötab sadu meeskondi ja päevas läbib DevOps'i torustikku tuhandeid distributsioone. Reaalne tarnimise aeg näeb välja nagu jaotumine. Igal meeskonnal on oma aeg ja omad eripärad. Kuidas sellise segaduse seest midagi leida?

Vastus tuli iseenesest – tuleb leida probleemsete meeskondade ja uurida, mis nendega juhtub ja miks see nii kaua kestab, ning „headelt“ meeskondadelt õppida, kuidas kõike kiiremini teha. Selleks on vajalik mõõta aega, mille meeskonnad veedavad igas DevOps seistes:

„Süsteemi eesmärgiks on meeskondade valimine seiste läbimise aja alusel, st lõpuks peame saama nimekirja meeskondadest, millel on valitud aeg, mitte number.

Kui me saame teada, kui palju aega kokku on kulutatud seistele ja kui palju aega on kulutatud seiste vahepealsetele seiskamistele, siis saame leida meeskonnad, helistada neile ja süvitsi uurida põhjuseid ning need kõrvaldada,” mõtles Ivan.

Kuidas arvutada DevOps-i tarnimise aega

Arvutamiseks tuli süveneda DevOps-protsessi ja selle olemusse.

Ettevõttes kasutatakse piiratud arvu süsteeme, ja teavet saab saada ainult neist ja mitte kuskilt mujalt.

Kõik ülesanded ettevõttes registreeriti Jira-s. Kui ülesanne võeti tööle, loodi selle jaoks filiaal, ja pärast teostamist tehti BitBucket-is commit ja Pull Request. Pull Request'i (PR) vastuvõtmise korral loodi automaatselt distributsioon ja salvestati Nexus-i salvestusse.

Seejärel rakendati distributsioon mitmetele seistele Jenkins-i abil, et kontrollida õiget rakendamist, automaatset ja käsitsi testimist:

Ivan kirjeldas, milliseid süsteeme ja millist teavet saab kasutada seisude aja arvutamiseks:

Nexus-ist – distributsiooni loomise aeg ja kausta nimi, kus meeskonna kood asus
Jenkins-ist – iga töö algusaeg, kestus ja töötulemused, seise nimi (töö parameetrites), etapid (töö sammud), ja link distributsioonile Nexus-is.
Ivan otsustas Jira ja BitBucket konveierisse mitte lisada, kuna need kuulusid enamasti arendusprotsessi etappi, mitte valmis distributsioonide seistes rakendamise etappi.

Käesoleval teave põhjal kirjutati välja järgmine skeem:

Teades, kui palju aega kulub distributsioonide loomiseks ja kui palju aega kulub igaühele, on lihtne arvutada kogu kulu kogu DevOps konveieri (täieliku tsükli) läbimiseks.