Как перейти в девопс из администрирования или разработки и чем там придётся заниматься15.07.2022 14:46

Привет, Хабр! В Слёрме есть карьерный канал, и нас регулярно просят разместить там вакансии с названием DevOps Engineer. При этом описания вакансий могут быть самыми разнообразными. Кому-то требуется решать платформенные задачи и проводить миграцию между площадками, кому-то — взаимодействовать с командой разработки и организовывать мониторинг приложений, а кому-то нужны навыки программирования на Python или Go. 

Мы решили разобраться, в чём всё-таки заключается работа девопс-инженера, и спросили об этом Виктора Попова, девопса в НЛМК IT. Виктор рассказал, какими путями приходят в девопс и чем там занимаются, почему всем нужны мидлы и что делать, если ты джун. Слово Виктору.

Про термин

Думаю, что многие читатели Хабра терпеть не могут термин «девопс-инженер», ведь никаких девопс-инженеров не существует и вообще девопс — это методология, а не человек. Но термина лучше индустрия так и не придумала, поэтому дальше словом девопс я буду называть совокупность инструментов, задач и методологий, ну, а девопс-инженер, это человек, работающий в этой сфере.

Три вида девопса

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

В первом случае девопсы — это платформенные инженеры. Люди, которые предоставляют что-то как сервис, например, кластера k8s. В целом это то, чем я занимаюсь сейчас. Это старые добрые сисадмины, которые просто переименовались, потому что сисадминам платят мало, а девопсам — много.  Мы крутим сервера, какие-то сервисы, просто они теперь не на виртуалках, а в контейнерах. Ну и пользователей стали любить чуть больше. Инструментарий и название изменились, суть — как будто бы нет. 

Второй вариант — это «продуктовый» девопс, люди, которые находятся внутри команды разработки. Они могут писать для разработчиков пайплайны, манифесты, собирать контейнеры, настраивать мониторинг. Это довольно распространённая, но, на мой взгляд, не самая хорошая практика. Гораздо лучше, когда все эти вещи автоматизируются системно на уровне компании.

В этом случае иногда бывает так: если разработчик чего-то не знает, значит, это к девопсу. Это может быть всё что угодно: какая-то база данных недоступна, электричество выключили в ЦОДе, кофе холодный в кофемашине — всё к девопсам. Это печальный пример отсутствия договорённостей кто за что отвечает.

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

А вообще, мне кажется, что, девопс-инженер — это человек, которому не всё равно. Если вспомнить происхождение термина DevOps, окажется, что у нас есть Dev, есть Ops, они раньше исторически между собой разговаривать не умели. Тут появился девопс, подружил всех, и люди просто начали разговаривать, взаимодействовать. Вот и как это уместить в должностную инструкцию с ограниченным функционалом?  

Почему всем нужны мидлы и что хотят работодатели от джунов

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

Большинство компаний хотят нанять мидла или сеньора, вакансий джунов сейчас мало, а конкуренция велика. Начинающему девопсу стало намного сложнее найти работу. По опыту могу сказать, что если мидл+ или сеньор сейчас захотят сменить компанию, за неделю они точно получат какой-нибудь оффер. За месяц — оффер, который их удовлетворяет. И это в «ленивом» режиме.

Для джуна всё намного сложнее. Вот и получается такой замкнутый круг: компании не берут джунов, потому что не хотят вкладываться в развитие, джуны не могут стать мидлами, поэтому мидлов и сеньоров не хватает. Вакансий мидл и мидл+ очень много.

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

Откуда приходят в девопс

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

Бывает, что программисту надоедает писать код, и он решает развиваться в смежном направлении. У этих людей есть классный бэкграунд именно в разработке, они подтягивают админскую часть и после этого довольно круто помогают с CI/CD процессами, с дебагом приложений, то есть с какими-то процессами вокруг разработки, потому что отлично понимают, как это устроено. 

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

И в первом, и во втором случае специалисты получают недостающие знания и развиваются дальше уже в девопсе.

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

Опыт и инструменты

Если говорить про инструменты, на сегодняшний день могу отметить следующее:

• Kubernetes;

• Helm;

• Nginx

• любой CI/CD-инструмент, например, GitLab;

• базовые знания Linux-администрирования;

• Bash или Python, хотя бы на уровне чтения чужих скриптов.

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

Хорошо бы, конечно, знать специфику языков программирования. Условно — понимать, как Java засунуть в контейнер и как Python. Что касается написания кода, самые востребованные для девопса языки — это Python  и Go. Автоматизацию сейчас в основном пишут на Python и знать его — крутой бонус. А операторы для k8s пишутся на Go, поэтому знание Go тоже в приоритете. Но в целом знание любого языка — это точно плюс. С другой стороны, если ты не умеешь писать — это не блокер. 

Про коммуникацию 

Кроме инструментов работа девопса, конечно, связана с коммуникацией. Я бы сказал, что для джуниор или мидл-специалиста примерно 70 процентов времени занимает работа руками, а 30 процентов — коммуникация. Самое плотное взаимодействие обычно с командами разработки и ИБ, это непосредственные рабочие связи. 

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

Аварии и мониторинг

Коммуникация — это всегда очень важно, методология DevOps вообще про то, чтобы договариваться. Это важно и когда всё работает, и когда всё пошло не по плану и ничего не работает. Тут подробно рассказывать не буду, но можно посмотреть мой доклад с HighLoad++ «Инциденты и коммуникация: что, как и зачем говорить, когда всё сломалось». Первоначально аварии — это вроде как про SRE, а не про девопс, но не так много компаний, где есть выделенная SRE-команда.

Когда случается авария, главное — просто брать и чинить. Другой вопрос в том, что надо чётко понимать, кто ответственный, в каком месте авария. Зоны ответственности, конечно, должны быть разделены до инцидента. Если авария в зоне ответственности девопс-инженера, он бегает и чинит, если это разработка выкатила что-то очень-очень плохое, и оно сломалось, тут уже как договоритесь. 

Что делать, если ты джун

Сейчас на рынке гораздо больше джунов, чем вакансий для них. Я не верю, что можно стать мидлом, просто сходив на курсы и ни дня не проработав по-настоящему. Курсы дают теоретические знания, но не дают реального опыта. Но они небесполезны. Это простой и быстрый способ научиться работать с инструментами.

Хорошо помогают выделиться на фоне других джунов и получить оффер ваши pet-проекты. Одно дело — ты приходишь и говоришь: «Вот моё резюме, я ничего не умею — возьмите меня». Таких тысячи. Другое дело, когда ты говоришь: «Смотрите, вот репозиторий, я поднял в облаке кластер. В этом кластере у меня демоприложение, вот CI/CD, а ещё тесты добавил». 

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

Ещё можно найти людей, которые занимаются девопсом в вашей компании и поговорить с ними, спросить: «Ребята, а подскажите, вот здесь у нас чем занимаются? Чему мне стоит поучиться и как это сделать на нашей инфраструктуре?». Это тоже даст практический опыт работы с инструментами.

Итого

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

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

Для тех, кто хочет научиться работать с девопс-инструментами

© Habrahabr.ru