Які основні показники ефективності (KPI) використовуються для вимірювання DevOps?

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

• Управління проблемами та інцидентами
• Управління потужностями
• Управління змінами та випусками

Щоб бути абсолютно зрозумілим, це функції, які раніше належали до операційної організації і тепер належать організації Agile / DevOps. Існують існуючі KPI, які керують поганою поведінкою:

• Час кореневого аналізу причин завершено:
  • Запускає неповні RCA лише для того, щоб їх вчасно ввести в систему.
• Тривалість виконання тесту:
  • Вимикає тривалі тести незалежно від їх ділової цінності.
• Середнє використання хмарних сервісів:
  • Заохочує перевиконання обчислювальних ресурсів, що призводить до повільного часу реагування

Які основні показники ефективності можна використовувати для заохочення доброї поведінки в програмі DevOps?

Я не думаю, що існують "універсальні" KPI DevOps. Наприклад, швидкість велика, якщо тільки вона не є ключовим рушієм для вашого бізнесу. Amazon багато піклується про швидкість, тому що вони мають масовий роздрібний продаж. Це менш важливо для невеликого додатка зі 100 користувачами.

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

Що вас хвилює?

• Якість
• Надійність
• Технічне обслуговування
• Швидкість
• Вдосконалення процесів
• Рівень обслуговування

Що підтримує зацікавлених сторін вашого бізнесу вночі? Що визначає, заробляєте ви в цьому кварталі гроші чи ні? У наведеному вище списку можуть бути деякі з цих речей, а можуть і не. Складіть свій список, а потім з’ясуйте, як узгодити стимули для кожного відділу для їх досягнення.

Стимули стимулюють поведінку, тому приймайте рішення спільно щодо SMART цілей. Виберіть два-три пункти зі свого списку штурмів та розпочніть цикл вимірювання / виправлення зворотного зв'язку для кожного. Не вибирайте занадто багато одразу - більше шансів на успіх, якщо зосередитися на двох-трьох речах.

У DevOps немає KPI . Це було б як запитати, що таке KPI любові. Але деякі з речей , які ви згадали ( Problem і управління інцидентами , Управління потужностями , управління змінами і Release ) є хороший KPI, деякі з яких засновані на теорії за DevOps.

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

Поширена проблема KPI - це коли він починається на півдорозі ланцюга. Наприклад, процес зміни та випуску часто починається з розробників і закінчується розгортанням. Цей процес виключав:

• Клієнт має проблеми
• Команда підтримки, яка виявляє проблеми
• Команда продуктів, що визначає проблему відставання
• Команда рішень, що налаштовують розгортання для замовника
• Замовник усвідомлює цінність рішення

Проблема полягає в тому, що вимірювання часу циклу самостійно може призвести до двох основних проблем:

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

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

Ще одна проблема KPI полягає в тому, що, починаючи і закінчуючи клієнта, він фактично не може виміряти цінність для клієнта. Хорошим прикладом може бути процес реагування на проблеми та випадки та MTTR (середній час на ремонт) як KPI. Чи впливає проблема навіть на когось? Яка цінність для клієнтів? Ви могли мати відмінний MTTR за 3 години за 100 випадків. Але якщо більшість із них були внутрішніми, без впливу або мінімального впливу на клієнтів, і вирішувалися за лічені хвилини, тоді як один великий інцидент із величезним впливом на споживача потребував 3-х днів для вирішення, вартість бізнесу нижча, ніж якщо б у вас був MTTR за 1 день, тому що ви ігноруйте більшість внутрішніх інцидентів, але ви відповіли на величезний інцидент із впливом на клієнта протягом 1 години.

ПРИМІТКА. Для внутрішнього замовника, у випадку бізнес-процесу команди підтримки, отримане значення - це не цінність роботи для внутрішнього замовника, а цінність, отримана бізнесом при розблокуванні внутрішнього замовника в його власному бізнес-процесі. Розблокування команди, яка є вузьким місцем у власному процесі, отримує більшу цінність, ніж розблокування команди, яка не є вузьким місцем або окремої людини. Усі KPI такої групи підтримки повинні включати вартість бізнесу у свій розрахунок.

1. Частота розгортання
2. Швидкість розгортання
3. Рівень успішності розгортання
4. Як швидко послугу можна відновити після невдалого розгортання
   І, нарешті,
5. Культура DevOps, яку насправді неможливо виміряти