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

Седмица премина, откакто Иван за първи път започна да размишлява за DevOps метрики и осъзна, че с тях трябва да управлява времето за доставяне на продукта. (Време до Маркет):

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

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

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

Какво да правя?…

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

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

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

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

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

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

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

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

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

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

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

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

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

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