TL; DR, как вы доказываете, что devops, особенно автоматизация развертывания, улучшает частоту отказов изменений?
Мы все пытаемся собрать показатели для «сбоев развертывания», используя текущие (в основном, ручные) средства. К сожалению, «неудача» случается редко, верно? Потому что, когда что-то идет не так, команда собирается (как правило, с героизмом), чтобы решить проблему (как правило, разрешения, пропущенные конфиги, вы знаете тренировку). Итак ... когда мы спрашиваем, как прошло развертывание, ответ «это сработало».
Но интуитивно все мы знаем, что это не хорошо. В отчете о состоянии devops за 2017 год говорится, что «процент отказов изменений составляет около 31-45%» . Хотя это интуитивно звучит правильно, они отслеживаются как инциденты? Неа. Потому что они исправляются довольно быстро, обычно во время проверки. На самом деле гораздо реже откатывать развертывание.
Таким образом, требуется дисциплина, чтобы точно сообщать о количестве отказов. Мы не заинтересованы в том, чтобы сообщать об этом, потому что мы хотим, чтобы все работало, и мы делаем все возможное, чтобы это произошло.
Итак, как вы можете доказать, что devops, особенно автоматизация развертывания, улучшает частоту отказов изменений?
(PS попытался пометить это с помощью "# devops -ability-model")
Ответы:
Техника, которую мы использовали в прошлом в подобных ситуациях, заключается в том, чтобы получить «обязательство по управлению», которое налагает эти правила на каждого члена команды:
Доступ к выполнению обновлений в целевых областях развертывания (т. Е. В производстве) ограничен выбранными автоматизированными системами, которые имеют соответствующие контрольные журналы (= ведение журнала) любого вида обновлений в областях, которыми они управляют.
Обновления вручную в целевых областях развертывания по какой-либо причине больше не разрешены типичными членами команды (идентификаторами пользователей), которые раньше имели возможность (авторизованы) выполнять эти обновления. Вместо этого будут созданы НОВЫЕ (дополнительные) идентификаторы пользователей, которые будут иметь все необходимые разрешения для (все еще) выполнения таких ручных обновлений, когда это необходимо. Но чтобы действительно иметь возможность использовать эти новые идентификаторы пользователей (= выполнить вход с ними), член команды, который хочет выполнить вход с таким новым идентификатором пользователя, должен будет выполнить «какой-то» дополнительный шаг, чтобы получить доступ к паролю для такой новый идентификатор пользователя. В идеале этот дополнительный шаг также автоматизирован (используйте ваше собственное воображение, как он должен выглядеть), но если что-то не получается: просто свяжитесь (= электронная почта, вызов и т. Д.) С привратником необходимого пароля, в том числе «какая проблема у них есть» чтобы исправить "
С этими процедурами все, что осталось сделать, это периодически просматривать каждый из этих отчетов / причин, по которым было необходимо использовать такой специальный идентификатор пользователя, и задавать вопрос: « Можно ли что-нибудь сделать для дальнейшей автоматизации, чтобы дальше уменьшать необходимость в таком специальном логине? ».
Обновление :
Цитата из вашего дополнительного комментария ниже этого ответа:
Правда, это добавляет дополнительный барьер, но я не уверен, что это «искусственно». Потому что, насколько мне известно, это единственный способ узнать о вещах, которые члены команды никогда не скажут, по следующим причинам:
источник
Проблема, которая быстро устраняется, все еще остается проблемой. Если вы не сообщаете об этом как таковом, это проблема.
Если ваша цель на самом деле заставить вещи работать, то вам нужно быть честным в отношении сбоев, чтобы вы могли предотвратить их в будущем. Похоже , команда здесь лежит (возможно, сами по себе, конечно , руководству) о неудачах , потому что их цель состоит в том, чтобы иметь вещи появляются работать.
Это разные вещи. Например, возьмите старую шутку о том, что QA приводит к ошибкам - «мой код был в порядке, пока QA не овладело им, а затем они сделали все эти ошибки!». Ошибки были там все время, но разработчик не знал о них. Целью рабочей группы должна быть реальная надежность , и руководство должно стимулировать ее. Это означает, что, если они проводят больше мониторинга, что приводит к обнаружению новых проблем, они должны быть вознаграждены, а не оштрафованы за последующее снижение показателей надежности.
Если вы пытаетесь мотивировать изменения в своей организации, то вам не следует пытаться что-либо доказать, а предоставить доказательства того, что другие организации говорят о своих собственных изменениях. Если вы пытаетесь измерить процессы, которые у вас уже есть, и оправдать их дальнейшее существование, то вам следует отслеживать стандартные показатели надежности, такие как среднее время восстановления (MTTR).
Но принципы Devops - это не просто повышение надежности. Даже проектирование надежности сайта - это не просто повышение надежности. Скорее, вы хотите достичь надлежащего уровня надежности - то, что приносит пользу бизнесу, но не мешает развитию. И это поднимает реальный мотиватор в devops, который заключается в расширении возможностей изменения . Вы хотите, чтобы бизнес быстрее реагировал на рыночные стимулы, что происходит за счет уменьшения трения разработчиков, увеличения скорости развертывания, автоматизации ручных процессов и т. Д., Оставаясь в приемлемых пределах надежности. Это означает, что вам нужно измерить надежность, но вам также нужно измерить скорость, потому что ваша цель состоит в том, чтобы увеличить второе, сохраняя первое относительно статичным.
источник