Почему вам кажется, что DevOps не работает, и как это исправить

Декабрь 16, 2021

Концепция DevOps появилась в 2009 году, но тема не теряет актуальности и сегодня. Каждая компания хочет нанять штатного DevOps специалиста и внедрить в процесс разработки практики DevOps. И все же многие инженеры признаются, что DevOps не работает в их компании и не помогает, а только усложняет их жизнь.

Может, есть причина, по которой DevOps эффективен в одних компаниях и становится обузой в других? Давайте узнаем!

Содержание

1. Движущая сила DevOps
2. ТОП-10 типичных ошибок применения DevOps
   1. Использование Scrum для микроменеджмента
   2. Использование не унифицированной среды исполнения
   3. Тестирование только «оптимистичного варианта» и «чистых данных»
   4. Излишнее тестирование
   5. Превращение DevOps инженера в слабое звено
   6. Введение DevOps без Agile
   7. Игнорирование безопасности
   8. Постановка разных целей для команд
   9. Использование только универсальных инструментов
   10. Превращение DevOps в путь без цели
3. Самая большая ошибка 一 не использовать DevOps

Движущая сила DevOps

Чтобы понять, почему DevOps эффективен, давайте сначала рассмотрим случаи, в которых он не работает. Мнений о бесполезности DevOps много, включая следующие:

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

Таким образом, нужно иметь четкое представление о DevOps перед разбором ошибок его применения. Мы полагаем, что DevOps 一 это союз людей, процессов и продуктов, обеспечивающий непрерывную поставку ценности конечным пользователям. Ключевые слова 一 «непрерывный» и «ценность».

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

Поэтому всю дальнейшую информацию в этой статье рассматривайте через призму следующего принципа: помните о конечной цели и внедряйте практики DevOps в соответствии с ней! Нет универсального рецепта применения DevOps, подходящего каждой компании. Создавайте собственные процессы, отходите от сухих абстрактных формулировок. Будьте креативными и всегда помните о том, что ваша задача 一 обеспечение заказчиков ценным продуктом.

Давайте обсудим типичные ошибки, допускаемые разработчиками при внедрении DevOps. Или свяжитесь с нашими инженерами, и они поделятся с вами собственным опытом применения DevOps в разработке на Java.

ТОП-10 типичных ошибок применения DevOps

Использование Scrum для микроменеджмента

Scrum — это прекрасная практика для автоматизации процессов и один из важнейших компонентов успешного применения DevOps. Но часто ее используют не по назначению, а для микроменеджмента, выбирая некоторые ценности Scrum и игнорируя остальные. Помните, эти ценности включают не только приверженность и концентрацию, но и открытость, уважение и смелость, и работают они только вместе!

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

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

Использование не унифицированной среды исполнения

«На моем компьютере все работало» 一 эту фразу никому не хочется услышать. Чтобы избежать такой ситуации, используйте единую среду исполнения, которая работает на десктопах, серверах, встроенных устройствах, в облаке и т.д. Это упростит решение задач, связанных с безопасностью, развертыванием и тестированием.

Более того, практики DevOps подразумевают большой объем тестирования и разные способы развертывания, включая Github-репозитории и прочие. Поэтому применение унифицированного рантайма обеспечивает плавный и непрерывный рабочий процесс. Внедрение патчей безопасности также упрощается.

Наконец, такая среда исполнения, как Axiom JDK , имеет дополнительные преимущества, например, инструменты для создания легковесных контейнеров, микросервисов и нативных образов.

Чтобы узнать больше о нашей унифицированной среде исполнения, скачайте документ «7 причин для перехода с Oracle JDK на Axiom JDK», в котором описаны все важные отличия и преимущества.

Тестирование только «оптимистичного варианта» и «чистых данных»

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

Также не забывайте, что вашему ПО придется работать с «битыми» данными, например, выданными каким-нибудь скриптом, и оно должно с этим справляться.

Излишнее тестирование

Тестирование 一 палка о двух концах. Чрезмерное тестирование тоже плохо. Хотя лишней защиты не бывает, время и ресурсы не бесконечны. Лучший подход к тестированию ПО 一 выяснить, какой уровень отказа допустим в вашей системе и работать над достижением этой цели. Конечно, все зависит от ПО, которое вы разрабатываете. Например, основной продукт нашей компании 一 Java рантайм, поэтому мы не упускаем ни одной уязвимости, потому что это повлияет на работу наших заказчиков. Таким образом, наше тестирование направлено на достижение высокой безопасности. Определите ключевые компоненты вашего ПО и тестируйте их для достижения допустимого отказа. Если вы увлечетесь чрезмерным тестированием, вы рискуете остановить инерцию движения DevOps процессов.

Превращение DevOps инженера в слабое звено

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

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

Введение DevOps без Agile

DevOps позволяет наладить тесное сотрудничество между командами разработчиков и специалистов по обслуживанию, тем самым обеспечивая непрерывное развертывание. Технология Agile основана на взаимодействии заказчиков и разработчиков для создания высококачественного продукта. Хотя эти подходы направлены на разные области производства, их можно объединить для достижения общей цели, а именно скорости и качества релизов.

Быстрый вывод на рынок некачественного продукта не делает его лучше, а практики DevOps только усугубят ситуацию. Так что не внедряйте DevOps, пока ваш продукт не будет работать.

Игнорирование безопасности

Безопасность 一 один из главных коммерческих аргументов на рынке, и DevOps помогает повысить привлекательность продукта. Постоянно обнаруживаются новые уязвимости, и устранить их помогают регулярные обновления ПО, надежная техподдержка и патчи безопасности. По данным Института DevOps (сайт на английском языке), DevSecOps является важнейшим трендом, получившим 56% голосов в категории инструментов автоматизации.

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

Постановка разных целей для команд

Соперничество между отделами или командами 一 обычное дело, но особенно часто оно наблюдается в IT сфере. DevOps предназначен для укрепления связей между отделом разработок и отделом обслуживания, но если перед командами поставить разные цели, вряд ли они будут работать в атмосфере сотрудничества.

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

Использование только универсальных инструментов

Желание скопировать чужие успешные стратегии по внедрению DevOps вполне естественно. «Работает у них, сработает и у нас», верно?

К сожалению, нет.

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

Очень легко угодить в ловушку инструментов, используемых по умолчанию. Например, во многих крупных компаниях каждый комплект разработки ПО должен быть утвержден руководством, прежде чем он будет внесен в список возможных инструментов. Такая практика не всегда применима. В качестве альтернативного варианта найдите технологии и практики, которые вам гарантированно помогут, и проследите, чтобы они использовались не только для создания прототипов, но в реальном производстве. Ваши разработчики и менеджеры потом скажут вам спасибо.

Превращение DevOps в путь без цели

Люди не любят инновации, особенно когда речь идет об изменении их рабочего процесса. Как говорится, работает 一 не трогай. Проблема в том, что даже при внедрении новых методов они иногда становятся чистой формальностью без определенной цели.

Практики DevOps тоже могут стать жертвой такого подхода. Вот как можно этого избежать:

• Вы должны понимать свои цели и как их можно достичь с помощью DevOps;
• Члены команды тоже должны понимать эти цели. Объясните им как можно подробнее, зачем вы вносите изменения, выслушайте их мнение, скорректируйте нововведения при отсутствии эффекта;
• Поощряйте коммуникацию между командами;
• Сосредоточьтесь на автоматизации процессов, инструментов и тестирования;
• Помните, сами по себе инструменты 一 ничто без практик DevOps.

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

Самая большая ошибка 一 не использовать DevOps

Внедрение философии DevOps в компанию 一 трудоемкий процесс, иногда он связан с ошибками, включая описанные выше. Но это не значит, что вам не следует ее внедрять только потому, что ее уже используют ваши конкуренты. При правильной реализации DevOps становится полезным инструментом, который улучшит разработку ПО, сократит цикл релизов и развертываний, повысит эффективность написания кода и поможет в достижении целей. Мировая статистика DevOps за 2021 год (на английском языке) говорит о том, то этот подход не только процветает, но и открывает новые возможности для разработчиков ПО по всему миру.

Так что научитесь любить и уважать DevOps, и он ответит вам взаимностью!