Անկեղծ ասած, Իվանը հաճախ էր ծիծաղում մոնիտորինգի բաժնի իր գործընկերների ապարդյուն ջանքերի վրա։ Նրանք մեծ ջանքեր գործադրեցին՝ իրականացնելու այն չափումները, որոնց հասնելու հանձնարարել էր ընկերության ղեկավարությունը: Նրանք այնքան զբաղված էին, որ չէին ուզում, որ ուրիշը որևէ բան անի։
Բայց դա բավարար չէր ղեկավարության համար. նրանք անընդհատ պատվիրում էին ավելի ու ավելի նոր չափումներ՝ շատ արագ դադարելով օգտագործել նախկինում արվածը:
Վերջերս բոլորը խոսում էին LeadTime-ի մասին՝ բիզնեսի հնարավորությունների մատուցման ժամանակի: Չափանիշը ցույց տվեց խելահեղ թիվ՝ 200 օր մեկ առաջադրանք կատարելու համար: Որքա՜ն էին բոլորը ծաղրում և աչք դնում և ձեռքերը բարձրացնում դեպի երկինք:
Որոշ ժամանակ անց աղմուկը աստիճանաբար մարեց, և ղեկավարությունը հրահանգ ստացավ ստեղծել մեկ այլ չափիչ:
Իվանի համար լիովին պարզ էր, որ նոր մետրիկը նույնքան հանգիստ կմեռնի մութ անկյունում:
Իսկապես, մտածեց Իվանը, քանի որ համարն իմանալը ոչ մեկին ընդհանրապես ոչինչ չի ասում: 200 օր, թե 2 օր - տարբերություն չկա, քանի որ հնարավոր չէ թվով որոշել պատճառը և հասկանալ՝ դա լավ է, թե վատ։
Սա չափումների տիպիկ ծուղակ է. թվում է, թե նոր չափանիշը կպատմի գոյության էությունը և կբացատրի ինչ-որ գաղտնի գաղտնիք։ Բոլորն այնքան հույս ունեն սրա վրա, բայց չգիտես ինչու ոչինչ չի ստացվում։ Այո, քանի որ գաղտնիքը չպետք է փնտրել չափումների մեջ:
Իվանի համար սա անցած փուլ էր։ Նա դա հասկացավ չափումների համար, և բոլոր գաղտնիքները պետք է փնտրել , այսինքն. այն է, որ այս մետրիկը ձևավորվել է:
Առցանց խանութի համար ազդեցության օբյեկտը կլինեն նրա հաճախորդները, ովքեր գումար են բերում, իսկ DevOps-ի համար՝ թիմերը, որոնք ստեղծում և տարածում են բաշխումներ խողովակաշարի միջոցով:
Մի օր, նստելով դահլիճում հարմարավետ աթոռին, Իվանը որոշեց ուշադիր մտածել, թե ինչպես է ուզում տեսնել DevOps-ի չափումները՝ հաշվի առնելով այն հանգամանքը, որ ազդեցության օբյեկտը թիմերն են։
DevOps Metrics-ի նպատակը
Հասկանալի է, որ բոլորը ցանկանում են կրճատել առաքման ժամանակը: 200 օրն, իհարկե, լավ չէ:
Բայց ինչպե՞ս, սա է հարցը։
Ընկերությունում աշխատում են հարյուրավոր թիմեր, և ամեն օր հազարավոր բաշխումներ անցնում են DevOps խողովակաշարով: Փաստացի առաքման ժամանակը կհայտնվի որպես բաշխում: Յուրաքանչյուր թիմ կունենա իր ժամանակն ու իր առանձնահատկությունները: Ինչպե՞ս կարող եք որևէ բան գտնել այս խառնաշփոթի մեջ:
Պատասխանը ծագեց բնականաբար. մենք պետք է գտնենք խնդրահարույց թիմերին և պարզենք, թե ինչ է կատարվում նրանց հետ և ինչու է դա այդքան երկար տևում, և սովորենք «լավ» թիմերից, թե ինչպես անել ամեն ինչ արագ: Եվ դա անելու համար դուք պետք է չափեք թիմերի ծախսած ժամանակը DevOps-ի յուրաքանչյուր կանգառում.
«Համակարգի նպատակն է լինելու թիմեր ընտրել՝ ելնելով տրիբունայից անցնելու ժամանակից, այսինքն. Արդյունքում մենք պետք է ընտրված ժամանակով հրամանների ցանկ ստանանք, այլ ոչ թե թիվ։
Եթե իմանանք, թե ընդհանուր առմամբ որքան ժամանակ է ծախսվել տրիբունաների վրա և որքան ժամանակ է ծախսվել տրիբունաների միջև, ապա կարող ենք գտնել թիմերին, զանգահարել նրանց և ավելի մանրամասն հասկանալ պատճառներն ու վերացնել դրանք»,- մտածեց Իվանը:
Ինչպես հաշվարկել առաքման ժամանակը DevOps-ի համար
Այն հաշվարկելու համար անհրաժեշտ էր խորանալ DevOps գործընթացի և դրա էության մեջ։
Ընկերությունն օգտագործում է սահմանափակ թվով համակարգեր, և տեղեկատվություն կարելի է ստանալ միայն դրանցից և ոչ մի այլ տեղից:
Ընկերության բոլոր առաջադրանքները գրանցվել են Ժիրայում։ Երբ առաջադրանքը ստանձնվում էր, դրա համար ստեղծվում էր ճյուղ, իսկ իրականացումից հետո հանձնում էր BitBucket-ին և Pull Request-ին: Երբ PR (Pull Request) ընդունվեց, բաշխումը ավտոմատ կերպով ստեղծվեց և պահվեց Nexus-ի պահոցում:
Այնուհետև, բաշխումը տարածվեց մի քանի ստենդների վրա՝ օգտագործելով Jenkins՝ ստուգելու տեղադրման, ավտոմատ և ձեռքով փորձարկման ճիշտությունը.
Իվանը նկարագրեց, թե որ համակարգերից ինչ տեղեկատվություն կարելի է վերցնել տրիբունաներում ժամանակը հաշվարկելու համար.
- Nexus-ից – Բաշխման ստեղծման ժամանակը և հրամանի կոդը պարունակող թղթապանակի անվանումը
- Jenkins-ից – Յուրաքանչյուր աշխատանքի մեկնարկի ժամանակը, տևողությունը և արդյունքը, դիրքի անվանումը (աշխատանքի պարամետրերում), փուլերը (աշխատանքի քայլերը), հղում դեպի Nexus-ի բաշխումը:
- Իվանը որոշել է չընդգրկել Jira-ին և BitBucket-ին, քանի որ... դրանք ավելի շատ վերաբերում էին զարգացման փուլին, այլ ոչ թե տրիբունաների վրա պատրաստի բաշխումը:
Առկա տեղեկատվության հիման վրա կազմվել է հետևյալ գծապատկերը.
Իմանալով, թե որքան ժամանակ է պահանջվում բաշխումներ ստեղծելու համար և որքան ժամանակ է ծախսվում դրանցից յուրաքանչյուրի վրա, կարող եք հեշտությամբ հաշվարկել DevOps-ի ամբողջ խողովակաշարով անցնելու ընդհանուր ծախսերը (ամբողջ ցիկլը):
Ահա DevOps-ի ցուցանիշները, որոնցով Իվանն ավարտեց.
- Ստեղծված բաշխումների քանակը
- Բաշխումների մասնաբաժինը, որոնք «եկան» տրիբունա և «անցան» տրիբունայով
- Ստենդի վրա անցկացրած ժամանակը (ստենդի ցիկլ)
- Ամբողջական ցիկլ (ընդհանուր ժամանակը բոլոր տրիբունաների համար)
- Աշխատանքի տևողությունը
- Հանգստի ժամանակ կանգառների միջև
- Միևնույն ստենդում աշխատանքի մեկնարկի միջև ընկած ժամանակահատվածը
Մի կողմից՝ չափումները ժամանակի առումով շատ լավ բնութագրում էին DevOps խողովակաշարը, մյուս կողմից՝ համարվում էին շատ պարզ։
Լավ կատարված աշխատանքից գոհ՝ Իվանը ներկայացրեց և գնաց այն ներկայացնելու ղեկավարությանը:
Նա վերադարձավ մռայլ և ձեռքերը իջեցրած։
«Սա ֆիասկո է, եղբայր,- ժպտաց հեգնական գործընկերը...
Կարդալ ավելին հոդվածում «.
Source: www.habr.com