Які існують методи вимірювання рентабельності інвестицій для DevOps?

DevOps є складним і включає багато недетермінованих аспектів, таких як культура та процес.
Які існують способи вимірювання ініціатив DevOps для успіху?
Як довести бізнесу, що інвестиція, яку вони зробили, повертає (або економить) реальні долари?

Чудове запитання! Більшість із нас знають, що інвестування в практику DevOps - це дуже вартий пошук із безлічі причин; Однак ми часто не виправдовуємо DevOps за вплив лише на підсумковий рядок.

Зауважте : це щось із сумнівного запитання, і моя відповідь так само висловлена.

Тенсібай мудро запропонував знайти правильні показники, і він використав час для продажу в якості прикладу. Це чудовий підхід із великою картиною.

Як альтернативний підхід, мій досвід роботи з лічильниками бобів полягає в тому, що їм не потрібно - або обов'язково хочу - знати широку картину, вони просто хочуть підтвердити фіскальну відповідальність. Вони хочуть побачити тенденцію в правильному напрямку.

Ось лише кілька фіскальних виграшів:

• розрахувати економію витрат на сервері, використовуючи автоматичне масштабування в хмарі
• для сайтів, що приносять прибуток, екстраполюйте ціну за хвилину простою, а потім показуйте покращення в MTTI та MTTR
• знову ж таки, для сайтів, що приносять прибуток, оцініть економію ціни за хвилину, використовуючи високодоступну архітектуру на основі минулих інцидентів
• якщо ви покращили конвеєр побудови та розгортання, покажіть, що ви зменшили регресії та помилки у виробництві, викликані вже відстеженими помилками
• якщо ви вдосконалили тестові середовища для розробників, або навіть інструменти та конфігурацію на ноутбуках розробників, перегляньте історію фіксування, щоб побачити, чи нові інженери роблять свій перший внесок швидше після приєднання
• виконайте повне порівняння витрат між хмарою та попередньою програмою, як і нещодавно Gitlab , щоб виправдати ваші витрати на інфраструктуру (також заощадження!)

Показати, що ви обізнані з грошима і маєте кілька явних виграшів, часто достатньо. Я, звичайно, пропустив кілька очевидних прикладів; не соромтесь додавати коментарі нижче.

Ключовий показник для трубопроводу DevOps - це циклічний час (також його називають початковим часом ). Це час, який потрібен для зміни (або запиту на зміну, відстежуючи весь шлях до виникнення ідеї). Найкраща ілюстрація цієї концепції, яку я знаю, - із книги «Мета», яка розповідає про неї у виробничому контексті.

Частота розгортання також корисна. Ми хочемо, щоб розгортання були частими в трубопроводі DevOps. Немає магічного "1 день - хороший, 2 дня - погано"; для цього знадобиться історичний контекст для вашого проекту, щоб мати значення.

Розмір розгортання : вимірюється, однак ваші розробники вимірюють роботу - розповіді користувачів, сюжетні сюжети, кватлуа та ін. Знову ж таки, ви хочете побачити тенденції з часом, а не абсолютне значення.

Між частотою та розміром є історія. Чи стають наші випуски більш рідкісними та масштабними? чому? Вони стають меншими і частішими? Знову ж, чому?

Пояснюючи, чи хороша тенденція частоти / розміру, нам також знадобиться відсоток невдалої розгортки . Виявлення "чому" в цих трьох показниках багато розповість про стан проекту.

Мій особистий фаворит, хоча це метрика суєти, - Час тривіального розгортання . Якщо ви знайшли найменшу можливу річ, яку варто передислокувати на весь сайт ... можливо, помилка друку на ім'я генерального директора ... як швидко ви могли перейти від панічного телефонного дзвінка до розгорнутого сайту? Я кажу "суєта", тому що це насправді не те, що прогнозує поза тим, що обговорюють інші вище показники, але змушує мене почувати себе добре, коли мені подобається цінність.

Якщо ми переходимо до моніторингу, існує маса різних речей, які ми можемо відстежити ... від всеохоплюючих речей, таких як " Uptime ", до справді речей низького рівня, таких як час, витрачений на регенерацію користувацького HTML в циклі запиту-відповіді ... але вони не характерні для створення культури DevOps.

Вони не пов'язані безпосередньо з доларами ... для цього потрібно більше знань про ваш орган, ніж я можу запропонувати на такому форумі; але вони є ключем до ПОЧАТОК, щоб відповісти на це питання. Як тільки ви дізнаєтесь, що зможете регулярно випускати роботи у виробництво як подія, ви можете почати бачити, скільки зусиль ви витрачали раніше. Як вчить книга "Ціль" (про виготовлення трубопроводів - це актуально), оптимізація на місцевому рівні може виглядати, як ви економите гроші, але в кінцевому підсумку це просто створює цінність, пов'язану з інвентарем (нерозподілені функції).

Крім цієї поради, слід поглянути на звіт про стан справ DevOps за останні кілька років. Тут повно вимірювань реальних проектів, які можна наслідувати.

Капітан очевидний: скорочуючи час виходу на ринок та дефекти випусків.

Для розповсюдження цього одного вкладиша, звичайним підводним каменем є зміна організації без будь-яких посилань.

Залучення змін до культури або організації передбачає певні витрати на навчання та ознайомлення людей з цим новим методом, це означає витрати на навчання, але також означає втрату продуктивності, оскільки люди на сеансі поїздів нічого не дадуть. Це інвестиційна частина культурних змін.

Для вимірювання рентабельності інвестицій потрібно спочатку знайти деякі відповідні показники, які слід вдосконалити (зрозуміти дорого, або дорого, або джерело втрати прибутку). Це може бути коротший час виходу на ринок, менше виправлення після кожного випуску, краща взаємодія з клієнтами у вашому продукті. Відповідні показники будуть сильно залежати від ваших товарів.

Вимірювання рентабельності інвестицій (як швидко ви покрили витрати на навчання) означає, що ви можете фактично представити еволюцію цих показників, тому, перш ніж застосовувати будь-які зміни, ви повинні визначити ці показники та виміряти їх об'єктивно.
Після того, як у вас з'явиться реальна еволюція, ви можете сказати, чи вдосконалили ви щось, що покривало витрати на навчання та стало вигідніше, ніж було раніше.

Звичайна помилка полягає в залученні змін до того, як визначити будь-які показники і таким чином оцінити рентабельність інвестицій на відчуття, а не на фактичні дані.

Продуктивність може бути метрикою, але її вимірювання, як правило, дуже важко зробити об'єктивно, і не повинно бути показником першого класу для такого роду досліджень.

Пізно до гри тут, але думав, що я задзвонюся.

Ви не можете керувати тим, що не вимірюєте, так що для початку, ось основні показники, які команди, які слід відстежувати, повинні відстежувати реакцію на інцидент:

• Час пробігу% : загальний% доступного часу = [загальний час - час простою] / [загальний час]
• MTTR : середній час до вирішення = [час простою] / [# інциденти]
• MTTA : середній час для підтвердження = [загальний час для підтвердження] / [# інцидентів]
• MTBF : середній час між відмовами = [загальний час - час простою] / [# інцидентів]

Ці показники дають змогу перевірити стан ваших операцій на високому рівні та допоможуть визначити, де потрібно копатись далі.

Ознайомтеся з анімацією на дошці тут, щоб отримати більш поглиблений погляд на цю тему.

Після того, як ви дізнаєтесь про ваші показники, ви зможете зрівняти їх із витратами простою . Ви можете почати розробляти рентабельність інвестицій вашої команди і встановлювати деякі кількісні показники для постійного вдосконалення.