Проблема с показателями развертывания до DevOps

TL; DR, как вы доказываете, что devops, особенно автоматизация развертывания, улучшает частоту отказов изменений?

Мы все пытаемся собрать показатели для «сбоев развертывания», используя текущие (в основном, ручные) средства. К сожалению, «неудача» случается редко, верно? Потому что, когда что-то идет не так, команда собирается (как правило, с героизмом), чтобы решить проблему (как правило, разрешения, пропущенные конфиги, вы знаете тренировку). Итак ... когда мы спрашиваем, как прошло развертывание, ответ «это сработало».

Но интуитивно все мы знаем, что это не хорошо. В отчете о состоянии devops за 2017 год говорится, что «процент отказов изменений составляет около 31-45%» . Хотя это интуитивно звучит правильно, они отслеживаются как инциденты? Неа. Потому что они исправляются довольно быстро, обычно во время проверки. На самом деле гораздо реже откатывать развертывание.

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

Итак, как вы можете доказать, что devops, особенно автоматизация развертывания, улучшает частоту отказов изменений?

(PS попытался пометить это с помощью "# devops -ability-model")

Техника, которую мы использовали в прошлом в подобных ситуациях, заключается в том, чтобы получить «обязательство по управлению», которое налагает эти правила на каждого члена команды:

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

2. Обновления вручную в целевых областях развертывания по какой-либо причине больше не разрешены типичными членами команды (идентификаторами пользователей), которые раньше имели возможность (авторизованы) выполнять эти обновления. Вместо этого будут созданы НОВЫЕ (дополнительные) идентификаторы пользователей, которые будут иметь все необходимые разрешения для (все еще) выполнения таких ручных обновлений, когда это необходимо. Но чтобы действительно иметь возможность использовать эти новые идентификаторы пользователей (= выполнить вход с ними), член команды, который хочет выполнить вход с таким новым идентификатором пользователя, должен будет выполнить «какой-то» дополнительный шаг, чтобы получить доступ к паролю для такой новый идентификатор пользователя. В идеале этот дополнительный шаг также автоматизирован (используйте ваше собственное воображение, как он должен выглядеть), но если что-то не получается: просто свяжитесь (= электронная почта, вызов и т. Д.) С привратником необходимого пароля, в том числе «какая проблема у них есть» чтобы исправить "

3. Получить такого привратника на месте - непростая работа. И наибольшее сопротивление окажут ... члены команды (по разным причинам). Таким образом, вариация этих новых идентификаторов пользователей (как на предыдущем шаге) заключается в том, что каждый член команды получает дополнительный идентификатор пользователя (с паролем, который он сам решает), но с добавленной к нему дополнительной строкой: ему разрешено только выполнять войдите в систему с этим (дополнительным) идентификатором пользователя, если у него есть для этого веская причина. И каждый раз, когда они выполняют такой вход в систему, они должны подавать какой-то отчет о том, «какую проблему они исправили» (аналогично вашему вопросу).

С этими процедурами все, что осталось сделать, это периодически просматривать каждый из этих отчетов / причин, по которым было необходимо использовать такой специальный идентификатор пользователя, и задавать вопрос: « Можно ли что-нибудь сделать для дальнейшей автоматизации, чтобы дальше уменьшать необходимость в таком специальном логине? ».

Обновление :

Цитата из вашего дополнительного комментария ниже этого ответа:

Я считаю, что добавление искусственных барьеров для решения проблемы развертывания неэффективно.

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

• безопасность работы.
• плохие вещи / практики, которые они предпочитают скрывать.
• власть они не хотят терять.

В отчете о состоянии devops за 2017 год говорится, что «процент неудач изменений составляет около 31-45%». В то время как это звучит интуитивно правильно, они отслеживаются как инциденты? Неа. Потому что они исправляются довольно быстро, обычно во время проверки.

Проблема, которая быстро устраняется, все еще остается проблемой. Если вы не сообщаете об этом как таковом, это проблема.

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

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

Это разные вещи. Например, возьмите старую шутку о том, что QA приводит к ошибкам - «мой код был в порядке, пока QA не овладело им, а затем они сделали все эти ошибки!». Ошибки были там все время, но разработчик не знал о них. Целью рабочей группы должна быть реальная надежность , и руководство должно стимулировать ее. Это означает, что, если они проводят больше мониторинга, что приводит к обнаружению новых проблем, они должны быть вознаграждены, а не оштрафованы за последующее снижение показателей надежности.

TL; DR, как вы доказываете, что devops, особенно автоматизация развертывания, улучшает частоту отказов изменений?

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

Но принципы Devops - это не просто повышение надежности. Даже проектирование надежности сайта - это не просто повышение надежности. Скорее, вы хотите достичь надлежащего уровня надежности - то, что приносит пользу бизнесу, но не мешает развитию. И это поднимает реальный мотиватор в devops, который заключается в расширении возможностей изменения . Вы хотите, чтобы бизнес быстрее реагировал на рыночные стимулы, что происходит за счет уменьшения трения разработчиков, увеличения скорости развертывания, автоматизации ручных процессов и т. Д., Оставаясь в приемлемых пределах надежности. Это означает, что вам нужно измерить надежность, но вам также нужно измерить скорость, потому что ваша цель состоит в том, чтобы увеличить второе, сохраняя первое относительно статичным.