Задача По Метрикам Развертывания Перед Devops

TL;DR, как ты доказывать DevOps, в частности автоматизация развертывания, снижает вероятность неудачных изменений?

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

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

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

Итак, как доказать, что DevOps, в частности автоматизация развертывания, снижает процент неудачных изменений?

(PS пытался пометить это тегом «#devops-capability-model»)

#метрики

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

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

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

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

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

Обновлять:

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

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

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

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

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

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

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

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

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

TL;DR, как вы доказываете, что DevOps, в частности автоматизация развертывания, снижает процент неудачных изменений?

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

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