Satt að segja hló Ivan oft að tilgangslausri viðleitni samstarfsmanna sinna úr eftirlitsdeildinni. Þeir lögðu mikið upp úr því að innleiða mælikvarðana sem stjórnendur fyrirtækisins skipuðu þeim að ná. Þeir voru svo uppteknir að þeir vildu ekki að neinn annar gerði neitt.
En allt var ekki nóg fyrir stjórnendurna - þeir pöntuðu stöðugt fleiri og fleiri nýjar mælingar, hættu mjög fljótt að nota þær sem áður höfðu verið gerðar.
Undanfarið hafa allir verið að tala um LeadTime - tímann fyrir afhendingu viðskiptaeiginleika. Mælingin sýndi brjálaða tölu - 200 dagar til að skila einu verkefni. Hversu allir öskruðu og æstu og lyftu höndunum til himins!
Eftir nokkurn tíma dvínaði hávaðinn smám saman og stjórnendur fengu skipun um að búa til annan mælikvarða.
Það var Ivan alveg ljóst að nýi mælikvarðinn myndi alveg jafn hljóðlega deyja í dimmu horni.
Reyndar, hugsaði Ivan, að vita að númerið segir engum neitt. 200 dagar eða 2 dagar - það er enginn munur, því það er ómögulegt að ákvarða ástæðuna með tölunni og skilja hvort hún er góð eða slæm.
Þetta er dæmigerð gildra mæligilda: það virðist sem ný mæligildi muni segja tilveruna og útskýra eitthvert leyndarmál. Það vona allir svo mikið eftir þessu en einhverra hluta vegna gerist ekkert. Já, vegna þess að leyndarmálið ætti ekki að finna í mælingum!
Fyrir Ivan var þetta liðin áfangi. Hann skildi það fyrir mælingar, og öll leyndarmálin verða að leita inn , þ.e. er að þessi mælikvarði er myndaður.
Fyrir netverslun verða viðfangsefni áhrifa viðskiptavinir hennar sem koma með peninga og fyrir DevOps verða það teymin sem búa til og setja út dreifingu með leiðslu.
Dag einn, þegar hann settist niður í þægilegum stól í salnum, ákvað Ivan að hugsa vandlega í gegnum hvernig hann vildi sjá DevOps mælikvarða, með hliðsjón af þeirri staðreynd að hlutur áhrifa er teymi.
Tilgangur DevOps mælikvarða
Það er ljóst að allir vilja stytta afhendingartímann. 200 dagar er auðvitað ekkert gott.
En hvernig, það er spurningin?
Hjá fyrirtækinu starfa hundruð teyma og þúsundir dreifinga fara í gegnum DevOps leiðsluna á hverjum degi. Raunverulegur afhendingartími mun birtast sem dreifing. Hvert lið mun hafa sinn tíma og eigin einkenni. Hvernig geturðu fundið eitthvað í þessu rugli?
Svarið kom af sjálfu sér - við þurfum að finna vandamálteymin og finna út hvað er að gerast hjá þeim og hvers vegna það tekur svona langan tíma, og læra af „góðu“ teymunum hvernig á að gera allt fljótt. Og til að gera þetta þarftu að mæla þann tíma sem teymi eyða á hverjum DevOps básnum:
„Tilgangur kerfisins verður að velja lið út frá þeim tíma sem þau fara framhjá stúkunni, þ.e. Þar af leiðandi ættum við að fá lista yfir skipanir með völdum tíma, en ekki tölu.
Ef við komumst að því hversu miklum tíma var eytt í stúkunni í heildina og hversu mikill tími fór í niðurfellingu á milli áhorfenda, getum við fundið liðin, hringt í þau og skilið ástæðurnar nánar og útrýmt þeim,“ hugsaði Ivan.
Hvernig á að reikna út afhendingartíma fyrir DevOps
Til að reikna það út var nauðsynlegt að kafa ofan í DevOps ferlið og kjarna þess.
Fyrirtækið notar takmarkaðan fjölda kerfa og er einungis hægt að nálgast upplýsingar frá þeim og hvergi annars staðar.
Öll verkefni í fyrirtækinu voru skráð í Jira. Þegar verkefni var tekið að sér var búið til útibú fyrir það og eftir innleiðingu var skuldbundið til BitBucket og Pull Request. Þegar PR (Pull Request) var samþykkt var dreifing sjálfkrafa búin til og geymd í Nexus geymslunni.
Næst var dreifingunni rúllað út á nokkra bása með því að nota Jenkins til að athuga réttmæti útsetningar, sjálfvirkrar og handvirkrar prófunar:
Ivan lýsti úr hvaða kerfum hvaða upplýsingar er hægt að taka til að reikna út tímann á áhorfendapöllunum:
- Frá Nexus – Dreifingartími og nafn möppunnar sem innihélt skipanakóðann
- Frá Jenkins – Upphafstími, lengd og niðurstaða hvers starfs, heiti sýningarstaðar (í starfsbreytum), þrep (starfsskref), tengill á dreifingu í Nexus.
- Ivan ákvað að hafa ekki Jira og BitBucket í leiðslunni, vegna þess að þær tengdust frekar þróunarstiginu, en ekki því að rúlla út fullunna dreifingu á standum.
Á grundvelli fyrirliggjandi upplýsinga var eftirfarandi skýringarmynd teiknuð:
Með því að vita hversu langan tíma það tekur að búa til dreifingar og hversu miklum tíma er eytt í hverja þeirra, geturðu auðveldlega reiknað út heildarkostnað við að fara í gegnum alla DevOps leiðsluna (heila hringrás).
Hér eru DevOps mælingarnar sem Ivan endaði með:
- Fjöldi stofnaðra dreifinga
- Hlutur dreifinga sem „kom“ í básinn og „framhjá“ básnum
- Tími sem varið er á standinum (standarlotur)
- Heil lota (heildartími fyrir alla bása)
- Vinnutími
- Hlé á milli áhorfenda
- Niður í bili á milli ræsa starf á sama bás
Annars vegar einkenndu mælingar DevOps leiðsluna mjög vel hvað tíma varðar, hins vegar þóttu þær mjög einfaldar.
Ánægður með vel unnin störf flutti Ivan kynningu og fór að kynna hana fyrir stjórnendum.
Hann kom til baka myrkur og með hendurnar niður.
„Þetta er misskilningur, bróðir,“ brosti kaldhæðni samstarfsmaðurinn ...
Lestu meira í greininni “'.
Heimild: www.habr.com