Кому не подходит DevOps

Популярная ошибка новичка: считать, что DevOps — это профессия. На самом деле, это философия и подход к разработке. Меня зовут Дмитрий Сорокин, я технический директор компании «Базис». Я и мои коллеги активно применяем методологию DevOps в управлении процессами разработки и готовы поделиться опытом, а заодно и своим взглядом на модную сейчас тематику.

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

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

DevOps: что это и зачем?

В доисторические времена – каких-то 15-20 лет назад – каждая группа внутри одного проекта работала отдельно: разработчики писали код, тестировщики проверяли его на ошибки, а администраторы занимались развертыванием готового продукта. Иногда они работали слаженно, а иногда – как на известной схеме:

Результаты такой работы часто не устраивали ни самих участников, ни владельцев воза.

А потом из обсуждения в Twitter родился DevOps. Как признавался автор термина Патрик Дюбуа, сам термин появился почти случайно — как удачное название для конференции DevOpsDays в 2009 году, и такой популярности он от этого сокращения не ожидал. Тем не менее, подход прижился, а термин DevOps сегодня является синонимом эффективного и интегрированного подхода к созданию ПО.

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

При внедрении DevOps традиционная структура ролей в IT-командах сохраняется, но меняются сами принципы взаимодействия: разработка, тестирование и развертывание превращаются в единый, непрерывный процесс, которым управляет отдельный специалист – DevOps-инженер. В результате, продукт быстрее выходит на рынок, быстрее обновляется, быстрее и безболезненнее отрабатываются ошибки. Также благодаря коммуникации между отделами становится глубже понимание клиентов, и появляются новые пути решения их запросов.

Итог – экономия времени, ресурсов и рост соответствия продукта требованиям рынка. Звучит, как сказка.

DevOps-инженеры: мы рождены, чтоб сказку сделать былью

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

Справиться с задачей способен DevOps-инженер — один из самых высокооплачиваемых IT-специалистов, способный не только работать с GitLab и контейнеризацией. В первую очередь, это человек-оркестр (и речь здесь не только про оркестрацию в Kubernetes), которые разбирается и в разработке, и в тестировании, и в человеческой психологии.

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

С технической стороны, DevOps-инженер настраивает инструменты для автоматизации, контейнеризации и оркестрации при использовании Kubernetes (если масштаб задач требует оркестрации). Но и без софт-скилов ему не обойтись: DevOps-инженеру необходимо координировать работу отделов, понимать их проблемы, находить простые и воспроизводимые решения для возможных конфликтов. Итогом становится более плотное взаимодействие отделов и коллективная ответственность их руководителей за общий результат труда.

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

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

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

Кому не подходит DevOps?

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

Несмотря на это, как это часто бывает с новомодными направлениями, внедрять DevOps кинулись все подряд. Например, прямо сейчас по запросу DevOps на одном известном ресурсе по поиску работы и сотрудников можно найти 5400 вакансий. Примерно такое же количество вакансий можно найти по запросу, например, QA или даже «системный администратор». Попробуем разобраться, кому точно не нужно пытаться внедрять DevOps:

• Маленькие стартапы на начальной стадии разработки. Если процессы начали сыпаться уже на пути к MVP, вероятно у вас есть более насущные организационные проблемы.
• Проекты с очень маленькими или одноразовыми задачами, для которых бессмысленно и нерентабельно внедрять автоматизацию.
• Компании, работающие с устаревшими технологиями, несовместимыми с DevOps. Также он не пригодится вашему проекту, если на нем требуется строгий контроль и соблюдение нормативных требований без возможности автоматизации. Например, если вы работаете в высокорегулируемых отраслях.
• Организации с ограниченным бюджетом, которые не могут позволить себе внедрение и поддержку DevOps-инструментов, а также расходы на обучение команды и организацию процессов.
• Компании с культурой, сильно отличающейся от принципов DevOps, где
  изменения культуры невозможны или крайне затруднены. Если корпоративная культура основана на жесткой иерархии и отделении обязанностей, внедрение культуры DevOps, основанной на сотрудничестве и открытости, может оказаться сложным.
• Проекты, зависящие от внешних контрактов, которые ограничивают гибкость и скорость разработки. Если нет потребности в непрерывной интеграции и доставке из-за специфики продукта.
• Компании, работающие в сферах с высокими требованиями к безопасности и где требуются индивидуальные решения без автоматизации.
• Проекты с крайне коротким жизненным циклом продукта, где время на внедрение DevOps превышает время разработки.
• Ситуации, когда IT-инфраструктура и процессы настолько малы или просты, что внедрение DevOps принесет больше сложностей, чем пользы.

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

Но не нужно забывать и про человеческий фактор. Есть команды, которые преследуют гибкие методологии, знакомы с методами контейнеризации и микросервисами, и в которых команды не прочь объединить работу с коллегами, «перейти в одну команду» и работать сообща. Но есть и те, кто этого сторонится. Можно услышать мнения, например, что Agile и Scrum в России не работают из-за менталитета. Те, кто привыкли работать консервативно, не хотят переходить на DevOps, и избегают всего, связанного с гибкими методологиями, вряд ли смогут извлечь максимальную выгоду из внедрения методологии.

Основные инструменты и технологии для DevOps

Может сложиться впечатление, что DevOps-инженер – это должность для «приятного парня» с техническим бэкграундом, задачи которого, в основном, сводятся к организации встреч и выслушиванию чужих жалоб. Это, мягко говоря, не так (хотя за все компании поручиться я не могу). DevOps-инженер решает большое количество прикладных задач, требующих серьезного практического опыта и экспертизы.

Базовым навыком для (будущего) DevOps-инженера, пожалуй, можно назвать умение работать с Git, контролировать выход версий и безопасно выкатывать обновления. Без этого никуда. В большинстве компаний от вас потребуют навыков работы с сборочным конвейером Jenkins. Если нужны метрики, то это Prometheus, Grafana или Zabbix. Все перечисленное запускается в контейнерах, а значит не обойтись без Docker или Cri-o. Наконец, доходим до оркестрации контейнеров, и тут Kubernetes – самый популярный инструмент, практически не имеющий альтернатив.

Если вы одна из тех команд, кто выбирает безопасную разработку и тесты безопасности внутри DevOps, то вам нужен DevSecOps. Т.е. DevOps-инженер с набором специфических навыков, ИБ-экспертизой и знанием инструментов безопасности.

Таким образом, DevSecOps не только расширяет границы традиционного DevOps за счет включения безопасности как первостепенной задачи, но и подчеркивает главную особенность DevOps-подхода: сотрудничество между максимальным количеством участников процесса разработки, поскольку к перечисленным мной выше участникам добавляется отдел ИБ.

Как развиваться в DevOps?

Для обучения подходит любой удобный лично вам способ. Кто-то лучше усваивает книги – обратите внимание на издательство O`Rilley («Kubernetes для DevOps» — отличное издание). Кто-то учится на курсах или по YouTube – тут фаворитов нет, но информации достаточно, особенно на английском. На русском есть, например, канал Андрея Созыкина.

Но и здесь нужно учитывать особенности специализации, и понимать, что скорее всего знания не удастся найти в одном месте. Нужно разобраться с Kubernetes-безопасностью? Читайте про нее. Нравится заниматься настройкой сбора и виртуализацией? И по этой теме легко найти много книг и курсов. Нужно подтянуть SQL? Проходите курс. Общий принцип: нужно что-то подтянуть – подтягиваешь. Поэтому важны самодисциплина и, можно сказать, любознательность.

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

P.S. Благодарю моего коллегу Филиппа Игнатенко, руководителя центра разработки платформенных сервисов «Базис», за объяснение нюансов практической стороны работы DevOps.