Как Иван реализира метрики DevOps. Обект на влияние

Измина седмица, откакто Иван за първи път се замисли за метриките на DevOps и осъзна, че с тях трябва да управлява времето за доставка на продукта (Time-To-Market).

Дори през уикендите той мислеше за метриките: «И какво толкова, че ще измеря времето? Какво ще ми даде това?»

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

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

Какво да правим?…

Метриката е като обикновена дървена линийка. Измерванията, направени с нея, не казват причината, защо измерваният обект е точно с тази дължина, която показва. Линийката просто ще покаже размера му, и нищо повече. Тя не е философски камък, а просто дървена дъска, с която се измерва.

«Неръждаемата плъх» на любимия му писател Хари Харисън винаги казваше: мисълта трябва да достигне дъното на мозъка и там да почива, затова след безрезултатно мъчене няколко дни Иван реши да се захване с друга задача…

След няколко дни, четейки статия за интернет-магазини, Иван внезапно осъзна, че сумата пари, които получава интернет-магазинът, зависи от поведението на посетителите на сайта. Именно те, посетителите/клиентите, дават на магазина парите си и са техният източник. На крайния размер на финансовите средства, получавани от магазина, влияят измененията в поведението на клиентите, а не нещо друго.

Получаваше се, че за да изменим измерената величина, трябва да влияеме на тези, които я формулират, т.е. за да променим количеството пари на интернет-магазина, трябва да се намесим в поведението на клиентите на този магазин, а за да променим времето за доставка в DevOps трябва да влияеме на екипите, които «създават» това време, т.е. използват DevOps в работата си.

Иван осъзна, че метриките на DevOps не трябва да представляват просто графики. Те трябва да представляват инструмент за търсене на «изключителни» екипи, които формират крайното време за доставка.

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

От друга страна, в компанията на Иван имаше стандарт, задължаващ всички екипи да проверяват сборките на няколко стенда. Екипът не можеше да премине на следващия стенд, докато не е преминал предишния. Получаваше се, че ако представим процеса на DevOps като последователност от преминаване през стендовете, метриките можеха да показват времето, прекарано от екипите на тези стендове. Знаейки стенда и времето на екипа, можеше да се говори по-конкретно с него за причините.

Без да се замисля, Иван вдигна телефонната слушалка и набра номера на човек, който разбираше добре от вътрешностите на DevOps:

— Денис, можеш ли да ми кажеш, може ли да разберем, че екипът е преминал през този или онзи стенд?
— Разбира се. Нашият Jenkins слага флаг, ако сборката е преминала успешно (преминала проверка) на стенда.
— Супер. А какво означава флаг?
— Това е обикновен текстов файл, например „стенд_OK“ или „стенд_FAIL“, който казва, че сборката е преминала или не е преминала стенда. Правилно разбра, нали?
— В принципе да. Записва ли се в същата папка в хранилището, където е сборката?
— Да
— А какво ще стане, ако сборката не премине стенда? Нужно ли е да се прави нова сборка?
— Ага
— Добре, благодаря. И още един въпрос: правилно ли разбирам, че за дата на преминаване на стенда мога да използвам датата на създаване на флага?
— Абсолютно!
— Супер!

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

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

За утре той си постави задачата да начертае архитектурата на предстоящата система.

Продължението следва…

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