Egia esateko, Ivanek sarritan barre egiten zuen jarraipen saileko bere lankideen ahalegin alferrikakoekin. Ahalegin handia egin zuten enpresako zuzendaritzak agindutako neurriak ezartzeko. Hain lanpetuta zeudenez ez zuten nahi beste inork ezer egin zezanik.
Baina ez zen nahikoa izan zuzendaritzarentzat - etengabe gero eta neurketa berri gehiago eskatzen zituzten, aurretik egindakoa erabiltzeari oso azkar utziz.
Azkenaldian, denek LeadTime buruz hitz egiten dute - negozio-eginbideak emateko garaia. Zenbaki zoro bat erakutsi zuen neurriak: 200 egun zeregin bat emateko. Nola denek oihu eta aah egiten zuten eta eskuak zerura altxatu zituzten!
Denbora pixka bat igaro ondoren, zarata pixkanaka itzaltzen joan zen eta zuzendaritzak beste metrika bat sortzeko agindua jaso zuen.
Ivanentzat guztiz argi zegoen metrika berria txoko ilun batean isilean hilko zela.
Izan ere, pentsatu zuen Ivanek, zenbakiak jakiteak ez dio inori ezer esaten. 200 egun edo 2 egun - ez dago alderik, ezinezkoa delako arrazoia zenbakiaren arabera zehaztea eta ona edo txarra den ulertzea.
Hau metrikaren ohiko tranpa bat da: badirudi metrika berri batek existentziaren funtsa esango duela eta sekretu sekreturen bat azalduko duela. Guztiek horrenbeste espero dute, baina arrazoiren batengatik ez da ezer gertatzen. Bai, sekretua ez litzatekeelako metriketan aurkitu behar!
Ivanentzat etapa gainditua izan zen. Hori ulertu zuen neurketak egiteko, eta sekretu guztiak bilatu behar dira , hau da. metrika hori eratzen dela da.
Lineako denda baterako, eragin-objektua dirua ekartzen duten bezeroak izango dira, eta DevOps-en kasuan, kanalizazio baten bidez banaketak sortu eta zabaltzen dituzten taldeak izango dira.
Egun batean, aretoko aulki eroso batean eserita, Ivanek DevOps-en neurketak nola ikusi nahi zituen arretaz pentsatzea erabaki zuen, eragin-objektua taldeak direla kontuan hartuta.
DevOps Metrics-en helburua
Argi dago denek entrega denbora murriztu nahi dutela. 200 egun, noski, ez dira ona.
Baina nola, hori da galdera?
Konpainiak ehunka talde enplegatzen ditu, eta milaka banaketa DevOps kanaletik pasatzen dira egunero. Benetako entrega-epea banaketa gisa agertuko da. Talde bakoitzak bere denbora eta bere ezaugarriak izango ditu. Nola aurki dezakezu ezer nahaspila honen artean?
Erantzuna modu naturalean sortu zen: arazo-taldeak aurkitu eta haiekin zer gertatzen ari den eta zergatik behar den hainbeste denbora jakin behar dugu, eta talde "onetatik" dena azkar nola egin ikasi behar dugu. Eta horretarako, taldeek DevOps stand bakoitzean igarotako denbora neurtu behar duzu:
Β«Sistemaren helburua harmailetatik igarotzen diren denboraren arabera taldeak hautatzea izango da, hau da. Ondorioz, komandoen zerrenda bat lortu beharko genuke hautatutako denborarekin, eta ez zenbaki bat.
Harmailan guztira zenbat denbora eman den eta harmailen arteko geldialdietan zenbat denbora eman den jakiten badugu, taldeak aurkitu, deitu eta arrazoiak zehatzago ulertu eta ezabatuko dituguΒ», pentsatu zuen Ivanek.
Nola kalkulatu DevOps-en entrega-denbora
Hori kalkulatzeko, DevOps prozesuan eta bere funtsean sakondu behar izan zen.
Enpresak sistema kopuru mugatu bat erabiltzen du, eta informazioa haietatik bakarrik lor daiteke eta inon ez.
Enpresako zeregin guztiak Jiran erregistratu ziren. Zeregin bat hartzen zenean, adar bat sortzen zen horretarako, eta inplementatu ondoren, BitBucket-en eta Pull Request-en konpromisoa egin zen. PR (Pull Request) bat onartzen zenean, banaketa automatikoki sortu eta Nexus biltegian gordetzen zen.
Ondoren, banaketa hainbat standetan zabaldu zen Jenkins erabiliz, zabalkundearen, proba automatikoen eta eskuzkoen zuzentasuna egiaztatzeko:
Ivanek deskribatu zuen zein sistematatik har daitekeen informazioa harmailetan denbora kalkulatzeko:
- Nexus-etik - Banaketa sortzeko ordua eta komando-kodea zuen karpetaren izena
- Jenkins-etik - Lan bakoitzaren hasiera-ordua, iraupena eta emaitza, standaren izena (lanaren parametroetan), faseak (lanaren urratsak), Nexus-en banaketarako esteka.
- Ivanek Jira eta BitBucket ez sartzea erabaki zuen, zeren... garapen fasearekin erlazionatuago zeuden, eta ez postuetan amaitutako banaketa zabaltzearekin.
Eskura dagoen informazioaren arabera, diagrama hau marraztu da:
Banaketak sortzeko zenbat denbora behar den eta horietako bakoitzean zenbat denbora ematen den jakinda, DevOps kanalizazio osoa (ziklo osoa) igarotzearen kostu osoa erraz kalkula dezakezu.
Hona hemen Ivanek lortutako DevOps neurketak:
- Sortutako banaketa kopurua
- Standera "etorri" eta standetik "pasatu" diren banaketen kuota
- Standean emandako denbora (stand-zikloa)
- Ziklo osoa (denbora osoa stand guztietarako)
- Lanpostuaren iraupena
- Harmailen arteko geldialdia
- Posta berean lanpostuak plazaratu arteko geldialdi-denbora
Alde batetik, metrikek DevOps kanalizazioa oso ondo ezaugarritu zuten denborari dagokionez, bestetik, oso sinpletzat jotzen ziren.
Ondo egindako lanarekin pozik, Ivanek aurkezpen bat egin zuen eta zuzendaritzari aurkeztera joan zen.
Goibel itzuli zen eta eskuak behera zituela.
"Hau fiasco bat da, ana", irribarre egin zuen lankide ironikoak...
Irakurri gehiago artikuluan "'.
Iturria: www.habr.com