Как стать автором
Обновить
67.08
KTS
Создаем цифровые продукты для бизнеса

Существуют ли джуниор-DevOps-инженеры и почему их ищут

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 11K

Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS. Сегодня поговорим о том, существуют ли джуниоры в DevOps — и какими они должны быть.

Содержание

Какое место занимает отдел DevOps среди остальных разработчиков

DevOps находится на стыке Development и Operations. Если команда Development прежде всего фокусируется на создании программного обеспечения, то команда Operations — на том, чтобы это ПО надёжно и эффективно работало в реальных условиях. DevOps же старается сделать эти процессы более связанными и гармоничными. 

Вот некоторые задачи и проблемы, которые решает девопсер:

  • Самая важная задача — постепенное развитие архитектуры CI/CD

  • Неэффективные ручные процессы развертывания

  • Определение узких мест в инфраструктуре и их оптимизация

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

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

Где нужен джуниор-DevOps

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

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

Когда появляется приличная DevOps-команда, отлаженные процессы CI/CD и системы мониторинга, компания может внедрить начинающего девопсера с опытом на стыке разработки и администрирования. Он может внедрять уже отлаженные процессы, в которых в целом разбирается. Джуниор-DevOps берёт на себя понятную часть работы и под небольшим контролем будет её выполнять. 

Так мы получаем три критерия компании, в которой нужен джуниор-девопсер:

  1. Наличие опытной команды DevOps инженеров

  2. Наличие у нее налаженных процессов внедрения, подходов к CI/CD, мониторингу

  3. В компании ещё не налажено всё на 100%, появляются новые области архитектуры, которые надо автоматизировать по уже существующим шаблонам

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

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

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

  • Закрытие старых долгов по мониторингу. Для джуниора это точка развития: решая подвисшие алерты и добавляя новые метрики, он сможет познакомиться со всеми системами — а вы закроете накопившиеся несрочные задачи 

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

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

Каким должен быть джуниор-DevOps

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

Опыт в Development и Operations

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

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

Я пришёл в DevOps из бэкенда. В компании не было выделенной роли для администрирования инфраструктуры, и самый опытный бэкендер на своём проекте отвечал за свои CI/CD. В том числе и я отвечал за всю инфраструктуру своих проектов.

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

Привычка автоматизировать и опыт CI/CD

Кроме опыта на стыке, у девопсера должна быть привычка упрощать. Например, такой человек мог написать свой API и потом не просто один раз выложить код на сервера, а настроить автоматизацию, чтобы развёртывание происходило само после пуша в SCM-систему — Gitlab, GitHub, Bitbucket.

Настоящий DevOps-инженер всегда автоматизирует процессы. В том числе развёртывание инфраструктуры — например, применяет Terraform для создания ресурсов в облаке, привязывает использование ansible к дополнительной установке пакетов на машины — и делает это через CI/CD. И так должно быть в любой области, которую видит и за которую отвечает DevOps-инженер.

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

За годы практики, ещё до открытия нового направления, у нас уже набралась хорошая экспертиза в настройке CI/CD, вплоть до динамических окружений у сложных сервисов. Если бы у нас самих не было привычки автоматизировать, вряд ли мы бы дошли до такого прогресса.

Общий кругозор и готовность развиваться

В итоге мы получаем человека с определённым кругозором и подходом к работе.

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

Летом 2022 года на офлайн-мероприятии «День Техдира» мы вместе с коллегами из Selectel выступили с докладом, который потом переработали в серию статей. В первой из них можно прочесть, как развивалась DevOps-автоматизация.

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

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

Пример портрета джуниора-DevOps

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

Общие требования:

  • Недавно выпустившийся студент IT-направления или разработчик с достаточно широкой подготовкой

  • Есть свои выложенные в интернете пет-проекты

  • Автоматизировал раскладку проекта

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

Технологические скилы. Нужно знание как минимум четырёх дисциплин:

  1. Как минимум один runtime для своих приложений: Docker с docker-compose, Kubernetes, Hashicorp Nomad, Docker Swarm

  2. Умение работать с CI/CD-системой: GitHub Actions, Gitlab, Jenkins

  3. Умение организовать хотя бы поверхностную систему мониторинга: Prometheus, Grafana, Zabbix

  4. Навык работы с Ansible/Puppet/Salt, умение описывать инфраструктуру

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

Роадмэп по ссылке выше

Заключение: кому стоит идти в DevOps?

Мы считаем, что DevOps-инженеры уровня джуниор существуют. А как считаете вы? Поделитесь мнением в комментариях.

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

В DevOps крайне важно сразу строить надёжную структуру, чтобы однажды не получилось так, что все временные некачественные подпорки слетели и начался один большой пожар. Здесь задачи должны быть чётко организованы в общий план, а система — методично улучшаться. Это не история про быстрый MVP на коленке. Если ваше призвание — DevOps, то вы не обходите важные моменты в задачах ради достижения сиюминутного результата.

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

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

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


Другие статьи про DevOps для начинающих:

Другие статьи про DevOps для продолжающих:

Теги:
Хабы:
+26
Комментарии 4
Комментарии Комментарии 4

Публикации

Информация

Сайт
kts.tech
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия