🥇DevOps näitajad – kust võtta andmeid arvutuste jaoks

Tõtt öelda, Ivan naeris sageli oma kolleegide pettumust valmistavate pingutuste üle jälgimise osakonnas. Nad pingutasid kõvasti, et ellu viia mõõdikud, mida ettevõtte juhtkond tellis. Nad olid nii hõivatud, et ei soovinud mitte kellelegi muu jaoks midagi teha.

Ja juhtkonnale ei piisanud kunagi – nad tellisid pidevalt uusi ja uusi mõõdikuid, kiiresti lõpetades varasemate kasutamise.

Viimase aja teema oli kõikjal LeadTime – äriomaduste tarnimisaeg. Mõõdik näitas hullumeelset numbrit – 200 päeva, et tarnida üks ülesanne. Kuidas kõik ahhetasid, ohkasid ja tõstsid käsi taeva poole!

Mõne aja pärast vaikus tasapisi muutus ja juhtkonnalt tuli tellimus veel ühe mõõdiku loomise kohta.

Ivan mõistis täiesti, et ka uus mõõdik sureb vaikides tumedas nurgas.

Tõepoolest, mõtles Ivan, arvu teadmine ei ütle kellelegi midagi. 200 päeva või 2 päeva – ei ole mingit erinevust, sest numbritest ei saa tuvastada põhjust ja mõista, kas see on hea või halb.

See, seein', on, starin', even searchin', in metrics to find the essence of life and unlock some hidden mystery. Everyone hopes for that, but somehow nothing happens. That's because the secret isn't in the metrics at all!

For Ivan, this was a stage he had already passed. He understood that metrics are just a simple wooden ruler for measurements, and all the secrets must be found in the object of influence, that is, in what shapes that metric.

For an online store, the object of influence will be its customers who generate revenue, while for DevOps, it will be the teams that create and deploy distributions using the pipeline.

One day, sitting comfortably in a chair in the lobby, Ivan decided to thoroughly think about how he would like to see DevOps metrics, given that the object of influence is the teams.

The goal of DevOps metrics

It's clear that everyone wants to reduce delivery time. 200 days is certainly unacceptable.

But how, that's the question?

Ettevõttes töötab sadu meeskondi, ja läbi DevOps töölõiguga läbib tuhandeid jaotusi iga päev. Tootmise tegelik aeg näeb välja nagu jaotus. Igal meeskonnal on oma aeg ja omad eripärad. Kuidas sellisest segadusest midagi leida?

Vastus tuli iseenesest – tuleb leida probleemsed meeskonnad ja mõista, mis neil toimub ja miks see nii kaua kestab, ning headelt meeskondadelt õppida, kuidas kõik kiiresti teha. Selleks on vaja mõõta aega, mida meeskonnad igal DevOps etendusel veedavad:

Süsteemi eesmärgiks on meeskondade valimine etenduse läbisõidu aja järgi, st lõpuks peame saama nimekirja meeskondadest valitud ajaga, mitte lihtsalt numbri.

Kui me saame teada, kui palju aega on kokku kulutatud etendusele ja kui palju aega on kulutatud seiskumistele etenduste vahel, siis saame leida meeskonnad, neile helistada ja üksikasjalikumalt põhjusi uurida ning neid kõrvaldada,” mõtles Ivan.

Kuidas arvutada DevOpsi tarnimise aega

Arvutamiseks pidi süvenema DevOpsi protsessi ja selle olemusse.

Ettevõttes kasutatakse piiratud arvu süsteeme, ja teavet saab ainult nendest ning mitte kusagilt mujalt.

Kõik ettevõtte ülesanded registreeriti Jira-s. Kui ülesanne võeti tööle, loodi sellele haru, ning pärast elluviimist tehti BitBucketis commit ja Pull Request. PR-i (Pull Request) vastuvõtmise korral loodi automaatselt distributiiv ja salvestati Nexus-sse.

Seejärel jagati distributiiv mitmesugustes keskkondades Jenkinsiga, et kontrollida paigaldamise õigsust, automaatset ja käsitsi testimist:

Ivan kirjutas üles, millist teavet on võimalik millistest süsteemidest võtta, et arvutada aega keskkondades:

Nexusest – distributiivi loomise aeg ja kausta nimi, kus tiimi kood asus.
Jenkinsest – iga töö alustamise aeg, kestus ja tulemused, seina nimi (töö parameetrites), etapid (töö sammud), link distributiivile Nexus-s.
Jira ja BitBucket Ivan otsustas torusse mitte kaasata, kuna need kuulusid rohkem arendusfaasi, mitte valmis distributiivi keskkondades jagamise faasi.

Saadud teabe põhjal joonistati välja järgmine skeem:

Teades, kui kaua kulub distributsioonide loomisele ja kui palju aega nende igaühe jaoks kulub, on lihtne arvutada DevOpsi kogu konveieri (täiskatse) üldkulud.