Изображение от Kharnagy, совместно с помощью CC Attribution-Sharealike 4.0 Международная лицензия Анкет В отчете о состоянии DevOps Puppet 2021 подчеркивается, что DevOps в настоящее время цементируется как стандартная отраслевая практика, тогда как ранее это было продуктом «ярких, восторженных, и продуктивных сообществ, энергичных дискуссий и обмена методологиями». DevOps, ставшие учреждением, в некотором роде — отличная вещь, но это также делает его важным для команд, пытающихся включить практики DevOps, чтобы помнить, что DevOps не является (или, по крайней мере, не только) автоматизацией.
Как подчеркивает отчет: многие команды и компании используют высокий уровень автоматизации, но все еще не достигают цели DevOps, что является непрерывным производством. В отчете 2021 года указывается, что высоко развитая команда DevOps, использующая автоматизацию, может развернуть новые изменения программного обеспечения менее чем за час с очень низкой частотой отказов. Между тем, команды Miid-Evolution, которые часто сообщают о высоком уровне автоматизации, значительно отстают от этого, развертывая изменения в несколько дней или недель. Так почему же две высокоавтоматические команды могут отличаться так широко с точки зрения их способности развертываться?
Ответ — культура. Команда DevOps с высокой степенью развития не только об автоматизации процессов; Речь идет об устранении производственных препятствий. Автоматизация процессов, не внося изменения в то, как ваши команды общаются, — это просто перемещать контрольно -пропускные пункты.
Ключевым первым шагом к действительно эффективным DevOps является синхронизация групп по разработке и операциям-команды, которые в традиционной технической культуре являются силовыми-и на самом деле часто противоречат. Forte Group Указывает, что, как правило, команды разработчиков стимулируются, чтобы продвигать вещи вперед (привлечь свои результаты вовремя), а команды по обеспечению качества и системные администраторы стимулируются, чтобы минимизировать сбои (что часто означает отмену сроков сроков, чтобы сосредоточиться на качественном продукте). Чтобы создать культуру, в которой возможно непрерывное развитие, эти команды должны думать о своей работе как обмене цели. Кроме того, им нужно часто и эффективно общаться.
DevOps также требует перехода от одного большого результата в конце длительного периода разработки к небольшим, постепенному развертыванию, которое происходит регулярно и постоянно контролируется и скорректируется. Принцип CI/CD , требует большого сдвига в культуре компании. Хотя автоматизация является частью CI/CD (особенно, если непрерывное развертывание также является частью вашей структуры), принцип, который позволяет добиться успеха CI/CD, — это Способность совершать ошибки Анкет Ожидание определенного количества отказа и строительства по ошибке представляет собой большое изменение от попытки выпустить идеальный продукт, а затем назначить вину, когда продукт неизбежно не так идеально, как предполагалось. Эта модель выпуска вещей, если они находятся в исключительной погрешности, и тестирование их в полевых условиях может быть эмоционально сложной. Если это сработает, команды и менеджеры должны получить пользу не наказывать друг друга за неизбежные неудачи, которые являются частью этого итеративного процесса.
Эти изменения могут быть большим сдвигом для компании, которая обычно работает на более традиционной модели. Gartner, Inc утверждает, что лучше всего представить принципы DevOps нескольким избранным командам, чтобы позволить им моделировать поведение для остальной части компании позже. Они утверждают, что лидеры должны «сосредоточить свои усилия на первоначальной, маленькой [DevOps] команде, устанавливают необходимые ценности и поведение и приложить постепенные усилия по признанию и укреплению желаемых результатов до масштабирования. «Это предотвращает ситуацию, в которой генеральный директор налагает принципы DevOps на целую компанию сверху вниз, не тратя время, чтобы увидеть, как DevOps смешиваются в существующую культуру компании. Изменение стимулов и поведения менеджера требует времени, даже если все в реальной команде находятся на борту, а одна история успеха может стать точкой продажи для принятия принципов всей компании.
SO: если ваш генеральный директор ожидает, что стержень будет DevOps, не устанавливая четкий план того, как будут изменяться стимулы и общение, вполне вероятно, что ваша компания будет в большинстве, которые не получит правильных преимуществ от DevOps- -ПАСТЕРКИ, приемлемая маржа ошибок, эффективное использование автоматизации и сильное сотрудничество. Любой компании, которая собирается добраться до «высоко развитых» DevOps, должна будет изучить, что они вознаграждают и наказывают, и как команды разговаривают друг с другом.
Оригинал: «https://dev.to/run-x/devops-is-not-automation-2amo»