Предупрежден – значит вооружен: как внедрять DevOps грамотно?
Если вы являетесь владельцем бизнеса или входите в топ-менеджмент компании, оптимизация бизнес-процессов и минимизация расходов – ваши ключевые приоритеты. На достижение этих целей в том числе влияет и методология DevOps. Однако, возможно вы слышали, что внедрение DevOps-инструментов своими силами довольно часто терпит неудачу. Именно поэтому многие компании, стремясь получить максимум пользы от этой практики, делегируют свои процессы DevOps на аутсорсинг.
При внедрении методологии DevOps собственными силами в большинстве случаев камнем преткновения становятся следующие проблемы:
● Непонимание того, что нужно делать;
● Отсутствие поддержки со стороны руководителей;
● Недоверие со стороны членов команды.
Мы проанализировали эти аспекты и рассказываем, как их избежать.
1. Непонимание, что именно необходимо делать
Когда компания хочет внедрить методы DevOps, она часто попадает в ловушку: медийные гуру, евангелисты и эксперты DevOps-консалтинга написали множество статей о том, что организациям жизненно необходимо разместить разработчиков, специалистов по обеспечению качества и системных инженеров в одной большой комнате и позволить им работать вместе, непрерывно обучая друг друга. Они также отмечают, что DevOps-инженер – это симбиоз Dev, QA и Ops, который одновременно может писать, тестировать и развертывать код.
Технический директор Amazon, Вернер Фогельс еще 15 лет назад предложил следующий подход: «вы построили – вы и запускаете». Однако, многие совершенно неверно интерпретируют эту цитату. Смешение функционала членов команд вовсе не приводит к повышению их результативности. Такая инициатива может привести только к разочарованию и падению производительности, после чего специалисты будут лишь вздрагивать каждый раз, когда услышат, что DevOps может быть максимально полезен.
Решение
В реальности не навыки, а цели и операционные задачи разработчиков, QA и Ops специалистов должны быть объединены и согласованы. Это позволит им быстрее достигать поставленных бизнес-задач. Реальные инженеры DevOps обсуждают, как приложение должно работать в производственной среде с разработчиками и QA.
Понимание лучших способов масштабирования, перезагрузки и обновления приложения определяют его архитектуру, что влияет на подходы к созданию и тестированию. В процессе непрерывного обсуждения разработчики пишут базу кода для автоматических модульных и интеграционных тестов, QA готовят высокоуровневые процедуры тестирования, а операторы пишут сценарии, которые автоматизируют большинство повторяющихся операций, таких как подготовка и настройка сред тестирования. Когда это выполнено, разработчики могут сами провести базовые тесты, просто запустив необходимые скрипты, что значительно ускоряет процесс. Таким образом, в реальной жизни концепция DevOps способствует эффективному взаимодействию и сотрудничеству между разработчиками, QA и Ops для обеспечения своевременной разработки программного обеспечения, а не смешению их функционала.
2. Ограничения и сопротивление со стороны руководства
Многие компании, даже те, которые правильно понимают значение DevOps, терпят неудачу в своих усилиях по цифровой трансформации. Среди ряда руководителей переход на использование инструментов DevOps воспринимается просто как очередная модная идея. Это означает, что само руководство недостаточно осведомлено об особенностях этого подхода, и если и готово довериться команде, то ожидает результатов «здесь и сейчас» и забывает о возможных рисках и сложностях на первых этапах.
Итак, компания начинает внедрять культуру DevOps, намечает дорожную карту, определяет желаемые результаты, назначает измеримые KPI, документирует все необходимые метрики. Единственный недостаток этого документа состоит в том, что он начинает рассыпаться на куски сразу же после первого препятствия, и руководство уже хочет отказаться от реализации этой инициативы.
Решение
Чтобы добиться успеха, внедрение DevOps практик и инструментов не должно встречать препятствий со стороны топ-менеджмента при первых сложностях или проблемах. Внедрение методологии должно быть – совместной или общей инициативой, основанной на потребностях и целях команд, которые действительно собираются ее реализовать.
Основная проблема этого подхода заключается и в том, что концепция DevOps представляет собой самоуправляемую культуру, которая требует довольно небольшого управленческого контроля. Многие руководители боятся отдать бразды правления группам своих сотрудников, которые становятся самодостаточными командами, способными принимать собственные операционные решения. Поэтому, либо топ-менеджмент компании дает свободу своим инициативным специалистам, либо теряет конкурентные преимущества из-за использования устаревших подходов, которые лишены гибкости.
3. Отсутствие доверия со стороны членов команды
Большинство команд привыкли работать так, как они привыкли. Они часто недовольны задачами и обратной связью, которую получают. Они устали решать одни и те же проблемы снова и снова – но на самом деле они ничего не хотят менять.
А теперь представьте, что вашим инженерам нужно трансформировать свои операции, начать сотрудничать с разработчиками и QA. А значит, делать больше и быстрее. Скорее всего волна недовольства будет и в командах QA и Dev. Кажется, что подобные инициативы изначально обречены.
Решение
Сопротивление со стороны членов команды можно преодолеть, продемонстрировав им, что инструменты DevOps на самом деле делают их жизнь проще.
Вместо того, чтобы снова и снова проверять одну и ту же незначительную ошибку интеграции, QA будет проводить дымовые и пользовательские приемочные тесты на промежуточном сервере. Вместо того, чтобы настраивать одни и те же испытательные машины или перезагружать один и тот же неисправный процесс в производстве снова и снова, инженеры Ops могут экспериментировать с реорганизацией систем, чтобы устранить узкие места в производительности и избавиться от этих утомительных повторяющихся инцидентов, не беспокоя разработчиков. Другими словами, у команд будет бо́льшая свобода действий и меньше головной боли.
Следуя описанным принципам, компании могут быть уверены, что путешествие в мир DevOps будет успешным. Этого легко добиться, если руководство возьмет правильный курс и обеспечит поддержку проекта, а также позволит своей команде учиться. Но если необходимо добиться результатов здесь и сейчас и времени на самостоятельное обучение команд нет, всегда можно сэкономить время и делегировать задачи поставщику услуг Managed DevOps. Таким образом, бизнес получит мгновенную поддержку команды профессионалов, а внутренняя команда оперативно освоит новую методологию.
Команда компании "Онланта"
