🥇Метрики 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 (пълен цикъл).