🥇DevOps metrikas – no kurienes ņemt datus aprēķiniem

Godīgi sakot, Ivans bieži smejās par kolēģu centieniem no uzraudzības nodaļas. Viņi ieguldīja milzīgas pūles, lai īstenotu metriku, ko pasūtīja uzņēmuma vadība. Viņi bija tik aizņemti, ka nevēlējās neko darīt citiem.

Bet vadībai vienmēr šķita par maz – tā nepārtraukti pasūtīja arvien jaunas un jaunas metriku, ļoti ātri pārtraucot izmantot jau izstrādātās.

Pēdējā laikā visi runāja par LeadTime – biznesa funkciju piegādes laiku. Metrika parādīja traku skaitli – 200 dienas vienas uzdevuma piegādei. Kā visi izsaucās, elpoja un pacēla rokas pret debesīm!

Pēc kāda laika troksnis pamazām rimās, un no vadības saņemts pasūtījums izveidot vēl vienu metriku.

Ivanam bija pilnīgi skaidrs, ka arī jaunā metrika klusi nobeigsies tumšajā stūrī.

Patiesībā, domāja Ivans, skaitļa zināšana neizsaka pilnīgi neko. 200 dienas vai 2 dienas – nav nekādas atšķirības, jo pēc skaitļa nav iespējams noteikt cēloni un saprast, vai tas ir labi vai slikti.

Tas ir tipisks metriku slazds: šķiet, ka jaunā metrika atklās būtību un izskaidros kādu noslēpumu. Visi uz to cer, bet kaut kā nekas nenotiek. Tāpēc, ka noslēpumu jāmeklē nemaz ne metriku!

Ivans to bija pieredzējis. Viņš saprata, ka metrikas ir vienkārši parasta koka liniņa izmēriem, un visus noslēpumus jāmeklē ietekmes objektā, proti, tajā, kas veido šo metriku.

Interneta veikalam ietekmes objekts būs tā klienti, kas nes naudu, bet DevOps komandām – komandas, kas veido un izplata izplatījumus, izmantojot konveijera sistēmu.

Kādā reizē, ērti iekārtojoties ērtā krēslā hallē, Ivans nolēma rūpīgi padomāt, kā viņš gribētu redzēt DevOps metriku, ņemot vērā, ka ietekmes objekts ir komandas.

DevOps metriku mērķis

Ir skaidrs, ka visiem gribas samazināt piegādes laiku. 200 dienas – tas, protams, nav pieņemami.

Bet kā, tā ir jautājums?

Uzņēmumā strādā simtiem komandu, un katru dienu caur DevOps konveijera sistēmu iziet tūkstošiem izplatījumu. Faktiskais piegādes laiks izskatīsies kā sadalījums. Katrai komandai būs savs laiks un savas īpašības. Kā starp šo jucekli var atrast kaut ko?

Atbilde radās pati par sevi – jāatrod problēmu komandas un jāsaprot, kas ar tām notiek un kāpēc tas ilgstoši notiek, bet no «labajām» komandām jāmācās, kā visu darīt ātri. Un tam nepieciešams izmērīt laiku, ko komandas pavada katrā DevOps stendā:

«Sistēmas mērķis būs komandu atlase pēc laika, kas pavadīts stendos, t.i., visbeidzot mums jāsaņem komandu saraksts ar izvēlēto laiku, nevis skaitli.

Ja mēs uzzināsim, cik laika kopumā tērēts stendam un cik laika ir iztērēts dīkstāvē starp stendiem, tad mēs varēsim atrast komandas, piezvanīt tām un detalizētāk izprast cēloņus un tos novērst,» – domāja Ivans.

Kā aprēķināt piegādes laiku DevOps

Lai veiktu aprēķinu, bija jāiedziļinās DevOps procesā un tā būtībā.

Uzņēmumā tiek izmantots ierobežots skaits sistēmu, un informāciju var iegūt tikai no tām, un nekur citur.

Visi uzdevumi uzņēmumā tika reģistrēti Jira. Kad uzdevums tika uzsākts, tam tika izveidots zars, bet pēc realizācijas tika veikts komits BitBucket un Pull Request. Ja PR (Pull Request) tika apstiprināts, automātiski tika izveidots izplatījums un saglabāts Nexus krātuvē.

Pēc tam izplatījums tika izvērsts vairākos stendos, izmantojot Jenkins, lai pārbaudītu uzstādīšanas pareizību un veiktu automātiskos un manuālos testus:

Ivans uzrakstīja, no kurām sistēmām kādu informāciju var iegūt, lai aprēķinātu laiku stendos:

No Nexus – izplatījuma izveides laiks un mape, kurā atradās komandas kods
No Jenkins – uzsākšanas laiks, truksmju ilgums un katras darba rezultāts, stenda nosaukums (darba parametros), posmi (darba soļi), saite uz izplatījumu Nexus.
Jira un BitBucket Ivans nolēma konveijerā neiekļaut, jo tās vairāk attiecās uz izstrādes posmu, nevis uz gatavā izplatījuma izlaidi stendos.

Pamatojoties uz pieejamo informāciju, tika izveidota šāda shēma:

Zinot, cik laika tiek tērēts izplatījumu izveidei un cik laika tiek iztērēts katram no tiem, var viegli aprēķināt kopējās izmaksas visā DevOps konveijerā (pilns cikls).