Каковы некоторые методы измерения ROI для DevOps?

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

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

Примечание : это вопрос самоуверенного, и мой ответ также самоуверенный.

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

В качестве альтернативного подхода, мой опыт работы с бин-счетчиками заключается в том, что им не нужно - или не обязательно - знать общую картину, они просто хотят доказательства финансовой ответственности. Они хотят видеть тенденцию в правильном направлении.

Вот только несколько финансовых побед:

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

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

Ключевой метрикой для конвейера DevOps является время цикла (также называемое временем выполнения ). Это время, которое требуется для изменения (или запроса на изменение, отслеживая весь путь до появления идеи). Лучшая иллюстрация этой концепции, которую я знаю, из книги «Цель», в которой говорится об этом в производственном контексте.

Частота развертывания также полезна. Мы хотим, чтобы развертывания были частыми в конвейере DevOps. Не существует волшебного измерения «1 день хорош, 2 дня плох»; это будет нуждаться в историческом контексте вашего проекта, чтобы иметь смысл.

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

Между частотой и размером есть что рассказать. Наши релизы становятся все более редкими и крупными? Зачем? Они становятся меньше и чаще? Опять же почему?

Чтобы объяснить, насколько тренд частота / размер хорош, нам также понадобится Процент неудачных развертываний . Раскрытие «почему» в этих трех показателях расскажет вам многое о состоянии проекта.

Мой личный фаворит, хотя это показатель тщеславия, это время для тривиального развертывания . Если вы нашли наименьшую возможную вещь, которая стоит переместить весь сайт за ... возможно, опечатку на имя генерального директора ... как быстро вы могли бы перейти от панического телефонного звонка на развернутый сайт? Я говорю «тщеславие», потому что на самом деле оно не настолько предсказуемо, кроме того, что обсуждают другие метрики выше, но заставляет меня чувствовать себя хорошо, когда мне нравится значение.

Если мы войдем в мониторинге, есть куча разных вещей , которые мы можем отслеживать ... от всеохватывающих таких вещей , как « Uptime », действительно низкие вещи уровня , как время , затрачиваемого регенерацией пользовательского HTML на цикле запроса-ответ ... но они не являются специфическими для создания культуры DevOps.

Они не связаны напрямую с долларами ... для этого потребуется больше знаний о вашей организации, чем я могу предложить на таком форуме; но они являются ключом, чтобы НАЧАТЬ ответить на этот вопрос. Как только вы узнаете, что можете регулярно выпускать работу в производство как нештатное мероприятие, вы можете начать видеть, сколько усилий вы потратили раньше. Как учит книга «Цель» (о производстве конвейеров - это актуально), локальная оптимизация может выглядеть так, как будто вы экономите деньги, но, в конечном счете, она просто создает ценность, связанную с запасами (незадействованные функции).

Помимо этого совета, вы должны взглянуть на отчет о состоянии DevOps за последние несколько лет. Это полно измерений о реальных проектах, которые вы могли бы подражать.

Капитан очевиден: за счет сокращения времени выхода на рынок и дефектов на релизах.

Чтобы продвинуться на этом одном лайнере, обычно ловушкой является изменение организации без каких-либо ссылок.

Внедрение изменений в культуре или организации подразумевает некоторые затраты на обучение и ознакомление людей с этим новым методом, это требует затрат на обучение, но также подразумевает потерю производительности, так как люди на тренировке ничего не производят. Это инвестиционная часть культурных изменений.

Чтобы измерить рентабельность инвестиций, вы должны сначала найти некоторые соответствующие метрики, которые должны быть улучшены (понять, дорогостоящий, дорогой или источник потери прибыли). Это может привести к сокращению времени выхода на рынок, уменьшению количества исправлений после каждого выпуска, лучшему взаимодействию с клиентами в рамках вашего продукта. Соответствующие показатели будут сильно зависеть от вашего продукта (ов).

Измерение ROI (насколько быстро вы покрыли расходы на обучение) подразумевает, что вы можете фактически представить эволюцию этих метрик, поэтому, прежде чем вносить какие-либо изменения, вы должны определить эти метрики и измерить их объективным образом.
Как только у вас появится реальная эволюция, вы сможете определить, действительно ли вы улучшили что-то таким образом, чтобы покрыть расходы на обучение и стать более прибыльным, чем это было раньше.

Обычно ловушка заключается в том, чтобы задействовать изменения, прежде чем определить какие-либо метрики, и, таким образом, оценить рентабельность инвестиций по ощущениям, а не по фактическим данным.

Производительность может быть метрикой, но ее измерение, как правило, очень трудно сделать объективным образом и не должно быть первоклассной метрикой для такого рода исследований.

Опоздал на игру здесь, но думал, что я буду вмешиваться.

Вы не можете управлять тем, что не измеряете, поэтому для начала, вот ключевые метрики, которые должны отслеживать команды разработчиков:

• Время работы% : общее время% доступности = [общее время - время простоя] / [общее время]
• MTTR : среднее время до разрешения = [время простоя] / [# инцидентов]
• MTTA : среднее время подтверждения = [общее время подтверждения] / [количество инцидентов]
• MTBF : среднее время между отказами = [общее время - время простоя] / [количество инцидентов]

Эти метрики дают вам высокий уровень проверки работоспособности и помогают определить, куда вам нужно углубиться.

Взгляните на анимацию доски здесь для более глубокого взгляда на тему.

Как только вы знаете свои метрики, вы можете сравнить их с затратами времени простоя . Вы можете начать строить ROI вашей команды оттуда и установить некоторые количественные показатели для постоянного улучшения.