(Time-To-Market).
Навіть у вихідні він думав про метрики: «Ну й що, що я виміряю час? Що воно мені дасть?
Справді, що дасть знання часу? Припустимо, постачання займає 5 днів. І що далі? Це добре чи погано? Навіть якщо це погано, то треба якось зменшувати цей час. Але як?
Ці думки не давали йому спокою, але рішення не надходило.
Іван розумів, що підійшов до самої суті. Численні графіки метрик, бачені ним до цього, давно переконали його, що стандартний підхід не спрацює, і що якщо просто побудувати графік (), користі від нього буде нуль.
Як же бути?…
Метрика це як звичайна дерев'яна лінійка. Виміри, зроблені з її допомогою, не скажуть причини, чому вимірюваний предмет саме тієї довжини, що вона показав. Лінійка просто покаже його розмір і не більше. Вона не філософський камінь, а просто дерев'яна дошка, якою вимірюють.
«Щур з нержавіючої сталі» його улюбленого письменника Гаррі Гаррісона завжди казала: думка має досягти дна мозку і там відлежатися, тому безрезультатно промучившись кілька днів, Іван вирішив зайнятися іншим завданням.
Через пару днів, читаючи статтю про інтернет-магазини, Іван раптом зрозумів, що величина грошей, яку отримує інтернет-магазин, залежить від того, як поводяться відвідувачі сайту. Саме вони, відвідувачі/клієнти, віддають магазину свої гроші та є їх джерелом. На підсумкову величину коштів, одержуваних магазином, впливають зміни у поведінці клієнтів, ні щось інше.
Виходило, що зміни вимірюваної величини треба було проводити тих, хто це значення формує, тобто. зміни кількості грошей інтернет-магазину треба було проводити поведінка клієнтів цього магазину, а зміни часу поставки в DevOps треба було проводити команди, які цей час «створюють», тобто. використовують DevOps у своїй роботі.
Іван зрозумів, що метрики DevOps мають репрезентувати зовсім не графіки. Вони повинні являти собою інструмент пошуку «видатних» команд, що формують підсумковий час постачання.
Ніяка метрика ніколи не покаже причину, чому та чи інша команда довго постачала дистрибутив, думав Іван, адже насправді причин може бути мільйон і маленький візок, і вони цілком можуть бути не технічними, а організаційними. Тобто. максимум, що можна розраховувати отримати від метрик - це показ команд та їх результатів, а потім все одно доведеться в ці команди йти ногами і з'ясовувати, що в них трапилося.
З іншого боку, у компанії Івана існував стандарт, який зобов'язує всі команди перевіряти збірки на кількох стендах. Команда не могла перейти на наступний стенд доти, доки не буде пройдено попередній. Виходило, що якщо уявити процес DevOps як послідовність проходження стендів, то метрики могли б показувати час, що витрачається командами цих стендах. Знаючи стенд та час команди, можна було конкретніше говорити з нею про причини.
Не довго думаючи Іван підняв телефонну трубку і набрав номер людини, яка добре знається на нутрощах DevOps:
— Денисе, підкажи, будь ласка, а чи можна якось зрозуміти, що команда пройшла той чи інший стенд?
- Звичайно. Наш Jenkins відкидає прапор, якщо збірка успішно розкотилася (пройшла перевірку) на стенді.
- Супер. А що таке прапор?
- Це звичайний текстовий файлик типу "стенд_OK" або "стенд_FAIL", який каже, що збірка пройшла або не пройшла стенд. Ну, ти зрозумів, так?
- В принципі так. Він пишеться в ту саму папку у сховищі, де лежить збірка?
- Так
— А що буде, якщо складання не пройшло стенду? Чи потрібно робити нове складання?
- Ага
— Ну, дякую. І ще питання: я правильно розумію, що як дата проходження стенду я зможу використовувати дату створення прапора?
- Абсолютно!
- Супер!
Натхненний, Іван поклав слухавку і зрозумів, що все стало на свої місця. Знаючи дату створення файлу складання та дати створення прапорів можна було з точність до секунди порахувати, скільки часу команди витрачають на кожен стенд і зрозуміти, де вони витрачають найбільше часу.
«Розуміючи, де йде найбільше часу, ми точково знайдемо команди, підемо до них і прокопаємо проблему». Іван усміхнувся.
На завтра він поставив собі завдання накидати архітектуру системи, що промальовується.
Далі буде ...
Джерело: habr.com