Om eerlik te wees, het Ivan dikwels gelag vir die vergeefse pogings van sy kollegas van die moniteringsafdeling. Hulle het groot pogings aangewend om die maatstawwe te implementeer wat die maatskappy se bestuur hulle beveel het om te bereik. Hulle was so besig dat hulle nie wou hê dat iemand anders iets moet doen nie.
Maar dit was nie genoeg vir die bestuur nie - hulle het voortdurend meer en meer nuwe maatstawwe bestel en baie vinnig opgehou om te gebruik wat voorheen gedoen is.
Die afgelope tyd het almal gepraat oor LeadTime – die tyd vir aflewering van besigheidskenmerke. Die maatstaf het 'n mal getal gewys - 200 dae om een taak te lewer. Hoe het almal gejoel en geag en hul hande na die hemel opgesteek!
Na 'n ruk het die geraas geleidelik bedaar en die bestuur het 'n opdrag ontvang om 'n ander maatstaf te skep.
Dit was vir Ivan heeltemal duidelik dat die nuwe metriek net so stil in 'n donker hoekie sou sterf.
Inderdaad, het Ivan gedink, met die wete dat die nommer glad nie vir iemand iets vertel nie. 200 dae of 2 dae - daar is geen verskil nie, want dit is onmoontlik om die rede deur die getal te bepaal en te verstaan of dit goed of sleg is.
Dit is 'n tipiese strik van metrieke: dit blyk dat 'n nuwe metriek die essensie van bestaan sal vertel en een of ander geheime geheim sal verduidelik. Almal hoop so baie hiervoor, maar om een of ander rede gebeur niks nie. Ja, want die geheim moet nie in metrieke gevind word nie!
Vir Ivan was dit 'n geslaagde stadium. Hy het dit verstaan vir mates, en al die geheime moet in gesoek word , d.w.s. is dat hierdie maatstaf gevorm word.
Vir 'n aanlyn winkel sal die voorwerp van invloed sy kliënte wees wat geld inbring, en vir DevOps sal dit die spanne wees wat verspreidings skep en uitrol met behulp van 'n pyplyn.
Op 'n dag, terwyl hy in 'n gemaklike stoel in die saal gaan sit het, het Ivan besluit om noukeurig deur te dink hoe hy DevOps-statistieke wil sien, met inagneming van die feit dat die voorwerp van invloed spanne is.
Doel van DevOps-metrieke
Dit is duidelik dat almal afleweringstyd wil verminder. 200 dae is natuurlik nie goed nie.
Maar hoe, dit is die vraag?
Die maatskappy het honderde spanne in diens, en duisende verspreidings gaan elke dag deur die DevOps-pyplyn. Die werklike afleweringstyd sal as 'n verspreiding verskyn. Elke span sal sy eie tyd en sy eie eienskappe hê. Hoe kan jy iets tussen hierdie gemors vind?
Die antwoord het natuurlik ontstaan - ons moet die probleemspanne vind en uitvind wat met hulle aangaan en hoekom dit so lank neem, en by die "goeie" spanne leer hoe om alles vinnig te doen. En om dit te doen, moet jy die tyd wat spanne spandeer by elk van die DevOps-stalletjies meet:
“Die doel van die stelsel sal wees om spanne te kies op grond van die tyd wat hulle by die erwe verbykom, m.a.w. As gevolg hiervan, moet ons 'n lys van opdragte kry met die geselekteerde tyd, en nie 'n nommer nie.
As ons uitvind hoeveel tyd in totaal op die staanplek bestee is en hoeveel tyd aan stilstand tussen staanplekke bestee is, kan ons die spanne kry, hulle bel en die redes in meer besonderhede verstaan en hulle uitskakel,” dink Ivan.
Hoe om afleweringstyd vir DevOps te bereken
Om dit te bereken, was dit nodig om in die DevOps-proses en die essensie daarvan te delf.
Die maatskappy gebruik 'n beperkte aantal stelsels, en inligting kan slegs van hulle verkry word en nêrens anders nie.
Alle take in die maatskappy is in Jira geregistreer. Wanneer 'n taak aangeneem is, is 'n tak daarvoor geskep, en na implementering is 'n verbintenis tot BitBucket en Pull Request gemaak. Wanneer 'n PR (Pull Request) aanvaar is, is 'n verspreiding outomaties geskep en in die Nexus-bewaarplek gestoor.
Vervolgens is die verspreiding op verskeie staanplekke uitgerol deur Jenkins te gebruik om die korrektheid van die uitrol, outomatiese en handmatige toetsing na te gaan:
Ivan het beskryf uit watter stelsels watter inligting geneem kan word om die tyd by die erwe te bereken:
- Vanaf Nexus – Verspreidingsskeppingstyd en naam van die vouer wat die opdragkode bevat het
- Van Jenkins – Begintyd, duur en resultaat van elke werk, standnaam (in die posparameters), stadiums (werkstappe), skakel na die verspreiding in Nexus.
- Ivan het besluit om nie Jira en BitBucket by die pyplyn in te sluit nie, want... hulle was meer verwant aan die ontwikkelingstadium, en nie met die uitrol van die voltooide verspreiding op erwe nie.
Gebaseer op die beskikbare inligting, is die volgende diagram geteken:
As u weet hoe lank dit neem om verspreidings te skep en hoeveel tyd daaraan bestee word, kan u maklik die totale koste bereken om deur die hele DevOps-pyplyn (volle siklus) te gaan.
Hier is die DevOps-statistieke waarmee Ivan geëindig het:
- Aantal verdelings geskep
- Deel van verspreidings wat na die stalletjie "gekom" het en die stalletjie "passeer".
- Tyd spandeer op die staanplek (staansiklus)
- Volle siklus (totale tyd vir alle erwe)
- Werksduur
- Stilstand tussen staanplekke
- Stilstand tussen werkbekendstellings op dieselfde staanplek
Aan die een kant het die statistieke die DevOps-pyplyn baie goed gekenmerk wat tyd betref, aan die ander kant is dit as baie eenvoudig beskou.
Tevrede met die werk goed gedoen, het Ivan 'n aanbieding gemaak en dit aan die bestuur gaan voorlê.
Hy het somber en met sy hande omlaag teruggekom.
"Dit is 'n fiasko, broer," het die ironiese kollega geglimlag ...
Lees meer in die artikel "".
Bron: will.com