🥇Метрики DevOps – откъде да вземем данни за изчисления

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

А ръководството все не стигаше, постоянно задавайки нови метрики, много бързо забравяйки за направените преди това.

В последнее време все обсъждали LeadTime – времето за доставка на бизнес функции. Метриката показа шокираща стойност – 200 дни за доставка на една задача. Как всички ахкаха, охкаха и вдигаха ръце към небето!

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

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

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

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

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

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

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

Целта на метриките DevOps

Е разбираемо, че всички искат да намалят времето за доставка. 200 дни – това, разбира се, е неприемливо.

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

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

Отговорът сам се появи – необходимо е да се намерят проблемните екипи и да се разбере какво се случва с тях и защо отнема толкова много време, а от "добрите" екипи да се научи как всичко да се прави бързо. За целта е нужно да се измери времето, прекарано от екипите на всеки от стендовете DevOps:

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

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

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

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

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

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

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

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

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

На базата на наличната информация беше изготвена такава схема:

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