Куда с этими знаниями идти, чем заниматься в проекте и сколько зарабатывать, что говорить и спрашивать на собеседовании — рассказывает Александр Титов, управляющий партнер Express 42 и автор .
Привет! Хотя термин 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!
উত্স: www.habr.com