Куда с этими знаниями идти, чем заниматься в проекте и сколько зарабатывать, что говорить и спрашивать на собеседовании — рассказывает Александр Титов, управляющий партнер Express 42 и автор онлайн-курса «DevOps практики и инструменты».

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

DevOps — конкретная методика, культура создания цифрового продукта, когда все специалисты в команде участвуют в продакшене.

В классической корпоративной разработке все идет последовательно: программирование, тестирование и только потом эксплуатация, и скорость такого процесса от идеи до продакшена составляет 3 месяца. Для цифровых продуктов это глобальная проблема, потому что нельзя оперативно получать обратную связь от клиентов.

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

Что из этого подхода следует?


  • Нельзя нанять некоего «инженера», который придет и решит все проблемы с продакшеном. Применять методику должна вся команда.


  • DevOps — это НЕ следующая форма сисадмина, в которую можно проапгрейдиться. «DevOps-инженер» звучит примерно так же, как «Agile-разработчик».



  • Если в команде используют Kubernetes, Ansible, Prometheus, Mesosphere и Docker, это еще не значит, что там внедрены DevOps-практики.





Жизнь после DevOps уже не будет прежней


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

1. Самоопределение

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

2. Инструменты и практики

Студенты осваивают конкретные технологии с точки зрения DevOps-метода.

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

У нас в ходе курса вы погрузитесь в процесс разработки приложения, похожего на известный Reddit, вначале с его монолитного варианта, по шагам переходя к микросервисам. Шаг за шагом мы будем осваивать новые инструменты: Git, Ansible, Gitlab и закончим Kubernetes и Prometheus.

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

Что дают эти знания каждому из специалистов?


Сисадминам


Практики позволят отойти от администрирования в сторону создания continuous delivery pipeline и инфраструктурной платформы поставки ПО. Смысл в том, что он создает продукт — инфраструктурную платформу для разработчиков, которая помогает им быстро продвигать их изменения в продакшн.

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

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

Разработчикам


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

Тестировщикам


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

Вот и получается, что все три этапа происходят одновременно. Например, выглядеть это может так:

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

Когда запускается continuous integration, процессы идут одновременно. Сервис стартует, настраивается. Параллельно стартует докер-контейнер, проверяется, что он работает. Одновременно вся информация идет в систему логирования. И так на каждом этапе разработки — получается настоящая командная работа системных администраторов, разработчиков и тестировщиков.

Изучил DevOps, а что дальше?


Как известно, один в поле не воин. Если в вашей компании этот метод не используют, полученные навыки будут лежать без дела. Да и после знакомства с DevOps-подходами быть винтиком в корпоративной разработке, скорее всего, не захочется. Исключение может быть одно: вы в команде системный администратор и можете перестроить все процессы на новый лад. Тут стоит добавить, что есть куча компаний, который этот подход применяют, и они не задеты локдауном и ищут специалистов. Потому что DevOps это про создание онлайн-продуктов.
А теперь о приятном: владение практиками и инструментами DevOps — это примерно +30% к вашей стоимости на рынке труда. Зарплаты начинаются от 140 тыс. рублей, но определяются, естественно, вашей основной специальностью и функционалом.

Смотреть можно на вакансии с пометкой «с ориентиром на инфраструктуру», где есть автоматизация тестирования, разработка микросервисных приложений с использованием облачных технологий, вакансии инфраструктурных инженеров и всяческие упоминания DevOps. Просто помните, что каждая компания подразумевает под этим определением что-то свое — внимательно вчитывайтесь в описание.

За время запусков нашего курса ко мне пришел инсайт — очень многие люди после курса попадают в ловушку DevOps-инженера. Находят вакансию с вышеупомянутым названием, получают хороший оффер, а потом приходят на работу и понимают, что придется поддерживать трехстраничный баш-скрипт в Jenkins. А где же Kubernetes, ChatOps, канареечные релизы и вот это все? А ничего нету, потому что компании не нужен DevOps, как методология, а используются отдельные новшества.

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

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

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

Важно заметить, что истинную ценность Devops-практики приобретают только при наличии опыта в разработке/ администрировании/ тестировании. Только тогда знания будут не абстрактными, а обогатят специалиста (во всех смыслах). Поэтому идея «научиться девопсу с нуля» примерно тоже самое, что учиться «использованию объективов с нуля», если ты никогда не держал в руках фотоаппарат или не режиссировал съемки. Чтобы помочь сориентироваться, подходит ли вам курс, мы сделали вступительный тест, который проверит достаточный уровень знаний.

Думаю, одна из фишек курса — то, что за время обучения каждый студент определяет для себя, в какую сторону он хочет развиваться. Мы нередко наблюдаем переходы, когда разработчик становится инфраструктурным инженером, а администратор понимает, что ему интересно писать код — тогда он дополнительно изучает язык и дополняет его полученными DevOps-навыками. Поэтому мы особенно ждем тех, кто чувствует, что его карьера застряла на распутье. Курс стартует уже 28 мая, но присоединиться можно и спустя 2 недели после начала занятий. Посмотреть программу и пройти тест можно по ссылке. До встречи в OTUS!