Godīgi sakot, Ivans bieži smējās par savu kolēģu no uzraudzības nodaļas veltīgajiem pūliņiem. Viņi pielika lielas pūles, lai ieviestu rādītājus, ko uzņēmuma vadība viņiem lika sasniegt. Viņi bija tik aizņemti, ka nevēlējās, lai kāds cits kaut ko darītu.
Bet vadībai ar to nepietika - viņi pastāvīgi pasūtīja arvien jaunus rādītājus, ļoti ātri pārtraucot izmantot to, kas tika darīts iepriekš.
Pēdējā laikā visi runā par LeadTime – biznesa funkciju piegādes laiku. Metrika uzrādīja traku skaitli – 200 dienas viena uzdevuma izpildei. Kā visi ūda un aahed un pacēla rokas pret debesīm!
Pēc kāda laika troksnis pamazām apklusa, un vadība saņēma rīkojumu izveidot citu rādītāju.
Ivanam bija pilnīgi skaidrs, ka jaunā metrika tikpat klusi nomirs tumšā kaktā.
Patiešām, Ivans domāja, numura zināšana nevienam neko nepasaka. 200 dienas vai 2 dienas - nav atšķirības, jo pēc skaitļa nav iespējams noteikt iemeslu un saprast, vai tas ir labs vai slikts.
Tas ir tipisks metriku lamatas: šķiet, ka jauna metrika pastāstīs esamības būtību un izskaidros kādu slepenu noslēpumu. Visi uz to tik ļoti cer, bet nez kāpēc nekas nenotiek. Jā, jo noslēpums nav jāmeklē metrikā!
Ivanam šis bija nokārtots posms. Viņš to saprata mērījumiem, un visi noslēpumi ir jāmeklē , t.i. ir tas, ka šī metrika ir izveidota.
Interneta veikalam ietekmes objekts būs tā klienti, kas ienes naudu, savukārt DevOps – komandas, kas izveido un izplata izplatīšanu, izmantojot konveijeru.
Kādu dienu, sēžot ērtā krēslā zālē, Ivans nolēma rūpīgi pārdomāt, kā viņš vēlas redzēt DevOps metriku, ņemot vērā to, ka ietekmes objekts ir komandas.
DevOps metrikas mērķis
Ir skaidrs, ka visi vēlas samazināt piegādes laiku. 200 dienas, protams, nav nekas labs.
Bet kā, tāds ir jautājums?
Uzņēmums nodarbina simtiem komandu, un tūkstošiem izplatījumu katru dienu tiek izmantots DevOps konveijerā. Faktiskais piegādes laiks parādīsies kā sadalījums. Katrai komandai būs savs laiks un savas īpašības. Kā jūs varat kaut ko atrast starp šo putru?
Atbilde radās dabiski – mums jāatrod problemātiskās komandas un jāizdomā, kas ar tām notiek un kāpēc tas prasa tik ilgu laiku, kā arī jāmācās no “labajām” komandām, kā visu izdarīt ātri. Un, lai to izdarītu, jums ir jāizmēra laiks, ko komandas pavada katrā DevOps tribīnē:
“Sistēmas mērķis būs komandu atlase pēc laika, kad tās iziet tribīnes, t.i. Rezultātā mums vajadzētu iegūt komandu sarakstu ar izvēlēto laiku, nevis skaitli.
Ja uzzināsim, cik daudz laika kopumā pavadīts tribīnē un cik daudz laika pavadīts dīkstāvē starp tribīnēm, varam atrast komandas, piezvanīt un sīkāk izprast iemeslus un tos novērst,” domāja Īvāns.
Kā aprēķināt DevOps piegādes laiku
Lai to aprēķinātu, bija jāiedziļinās DevOps procesā un tā būtībā.
Uzņēmums izmanto ierobežotu skaitu sistēmu, un informāciju var iegūt tikai no tām un nekur citur.
Visi uzdevumi uzņēmumā tika reģistrēti Jirā. Kad uzdevums tika uzņemts, tam tika izveidota filiāle, un pēc ieviešanas tika veikta apņemšanās BitBucket un Pull Request. Kad PR (Pull Request) tika pieņemts, izplatīšana tika automātiski izveidota un saglabāta Nexus repozitorijā.
Pēc tam izplatīšana tika izlaista vairākos stendos, izmantojot Jenkins, lai pārbaudītu izlaišanas pareizību, automātisko un manuālo testēšanu:
Ivans aprakstīja, no kurām sistēmām, kādu informāciju var ņemt, lai aprēķinātu laiku pie stendiem:
- No Nexus — izplatīšanas izveides laiks un tās mapes nosaukums, kurā bija komandas kods
- No Jenkins – katra darba sākuma laiks, ilgums un rezultāts, stenda nosaukums (darba parametros), posmi (darba soļi), saite uz izplatīšanu Nexus.
- Ivans nolēma neiekļaut Jira un BitBucket cauruļvadā, jo... tie vairāk bija saistīti ar izstrādes stadiju, nevis ar gatavās sadales izritināšanu uz stendiem.
Pamatojoties uz pieejamo informāciju, tika uzzīmēta šāda diagramma:
Zinot, cik ilgs laiks nepieciešams, lai izveidotu sadali un cik daudz laika tiek pavadīts katram no tiem, varat viegli aprēķināt kopējās izmaksas, kas saistītas ar visa DevOps konveijera (pilna cikla) iziešanu.
Šeit ir DevOps metrika, ko Ivans ieguva:
- Izveidoto sadalījumu skaits
- Izplatījumu daļa, kas “nonāca” stendā un “izturēja” stendā
- Statīvā pavadītais laiks (statīva cikls)
- Pilns cikls (kopējais laiks visiem stendiem)
- Darba ilgums
- Dīkstāves laiks starp tribīnēm
- Dīkstāves laiks starp darbu uzsākšanu tajā pašā stendā
No vienas puses, rādītāji ļoti labi raksturoja DevOps cauruļvadu laika ziņā, no otras puses, tie tika uzskatīti par ļoti vienkāršiem.
Gandarīts par labi padarīto darbu, Ivans uzstājās ar prezentāciju un devās to prezentēt vadībai.
Viņš atgriezās drūms un ar nolaistām rokām.
"Tas ir fiasko, brāli," ironiskais kolēģis pasmaidīja...
Vairāk lasiet rakstā "'.
Avots: www.habr.com