Чесно кажучи, Іван часто посміювався з марних зусиль колег з відділу моніторингу. Вони докладали величезних зусиль для реалізації метрик, які їм замовляло керівництво компанії. Вони були настільки зайняті, що нікому більше нічого не хотіли робити.
А керівництву все було мало - воно постійно замовляло нові метрики, дуже швидко перестаючи користуватися тим, що були зроблені раніше.
Останнім часом всі тільки й говорили про 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 (повний цикл).
Ось які DevOps-метрики вийшли у Івана в результаті:
- Кількість створених дистрибутивів
- Частка дистрибутивів, що «зайшли» на стенд і «пройшли» стенд
- Час, проведений на стенді (цикл стенду)
- Повний цикл (сумарний час по всіх стендах)
- Тривалість джобів
- Простий між стендами
- Простий між запусками джобів на одному стенді
З одного боку, метрики дуже добре характеризували конвеєр DevOps з точки зору часу, з іншого боку, вважалися дуже просто.
Задоволений добре виконаною роботою Іван склав презентацію та пішов представляти її керівництву.
Назад він виходив похмурий і з опущеними руками.
— Це фіаско, братику — усміхнувся іронічний колега…
Продовження читайте у статті «».
Джерело: habr.com