DevOps метрики - откъде да получите данни за изчисления

Честно казано, Иван често се смееше на напразните усилия на колегите си от мониторинговия отдел. Те положиха големи усилия, за да внедрят показателите, които ръководството на компанията им нареди да постигнат. Те бяха толкова заети, че не искаха никой друг да прави нищо.

Но това не беше достатъчно за ръководството - те постоянно поръчваха нови и нови показатели, много бързо преставайки да използват това, което беше направено преди това.

Напоследък всички говорят за LeadTime – времето за доставка на бизнес функции. Метриката показа луда цифра - 200 дни за изпълнение на една задача. Как всички охкаха и аахаха и вдигнаха ръце към небето!

След известно време шумът постепенно утихна и ръководството получи заповед да създаде друга метрика.

За Иван беше напълно ясно, че новата метрика също така тихо ще умре в някой тъмен ъгъл.

Наистина, помисли си Иван, знанието за номера не говори абсолютно нищо на никого. 200 дни или 2 дни - няма разлика, защото е невъзможно да се определи причината по числото и да се разбере дали е добро или лошо.

Това е типичен капан на метриките: изглежда, че нова метрика ще разкаже същността на съществуването и ще обясни някаква тайна тайна. Всички се надяват толкова много на това, но по някаква причина нищо не се случва. Да, защото тайната не трябва да се търси в метриките!

За Иван това беше преминат етап. Той разбра това метриките са просто обикновена дървена линийка за измервания и трябва да се търсят всички тайни обект на въздействие, т.е. е, че този показател се формира.

За онлайн магазин обектът на влияние ще бъдат неговите клиенти, които носят пари, а за DevOps това ще бъдат екипите, които създават и разпространяват дистрибуции с помощта на конвейер.

Един ден, седнал на удобен стол в залата, Иван реши внимателно да обмисли как иска да види показателите на DevOps, като вземе предвид факта, че обектът на влияние са екипите.

Цел на DevOps Metrics

Ясно е, че всеки иска да намали времето за доставка. 200 дни, разбира се, не са добри.

Но как, това е въпросът?

Компанията наема стотици екипи и хиляди дистрибуции преминават през конвейера DevOps всеки ден. Действителното време за доставка ще се покаже като разпределение. Всеки отбор ще има свое собствено време и свои собствени характеристики. Как можете да намерите нещо сред тази бъркотия?

Отговорът се появи естествено - трябва да намерим проблемните екипи и да разберем какво се случва с тях и защо отнема толкова време и да се научим от „добрите“ екипи как да правим всичко бързо. И за да направите това, трябва да измерите времето, прекарано от екипите на всеки от щандовете на DevOps:

„Целта на системата ще бъде да избира отбори на базата на времето, през което преминават трибуните, т.е. В резултат на това трябва да получим списък с команди с избраното време, а не число.

Ако разберем колко време е прекарано общо на трибуната и колко време е престояло между трибуните, можем да намерим екипите, да им се обадим и да разберем по-подробно причините и да ги отстраним“, смята Иван.

Как да изчислим времето за доставка за DevOps

За да го изчислим, беше необходимо да се задълбочим в процеса DevOps и неговата същност.

Компанията използва ограничен брой системи и информацията може да бъде получена само от тях и никъде другаде.

Всички задачи в компанията бяха регистрирани в Jira. Когато се поеме задача, за нея се създава клон и след изпълнението се извършва ангажимент към BitBucket и Pull Request. Когато PR (Pull Request) беше прието, разпространението беше автоматично създадено и съхранено в хранилището на Nexus.

След това дистрибуцията беше пусната на няколко щанда с помощта на Дженкинс за проверка на правилността на разпространението, автоматично и ръчно тестване:

Иван описа от кои системи каква информация може да се вземе за изчисляване на времето на трибуните:

• От Nexus – време на създаване на разпространението и име на папката, която съдържа командния код
• От Jenkins – Начален час, продължителност и резултат от всяка работа, име на щанд (в параметрите на работата), етапи (стъпки на работа), връзка към разпространението в Nexus.
• Иван реши да не включва Jira и BitBucket в процеса на подготовка, защото... те бяха по-скоро свързани с етапа на разработка, а не с пускането на готовата дистрибуция на щандове.

Въз основа на наличната информация беше начертана следната диаграма:

Знаейки колко време отнема създаването на дистрибуции и колко време се изразходва за всяка от тях, можете лесно да изчислите общите разходи за преминаване през целия конвейер на DevOps (пълен цикъл).

Ето показателите на DevOps, до които Иван стигна:

• Брой създадени дистрибуции
• Дял на дистрибуциите, които са „дошли“ до щанда и „преминали“ щанда
• Време, прекарано на стойка (цикъл на стойка)
• Пълен цикъл (общо време за всички стойки)
• Продължителност на работата
• Престой между трибуните
• Престой между пускането на работа на един и същ щанд

От една страна, показателите характеризират DevOps тръбопровода много добре по отношение на времето, от друга страна, те се считат за много прости.

Удовлетворен от добре свършената работа, Иван направи презентация и отиде да я представи пред ръководството.

Върна се мрачен и със спуснати ръце.

„Това е фиаско, брато“, усмихна се ироничният колега...

Прочетете повече в статията “Колко бързи резултати помогнаха на Иван".

Източник: www.habr.com