Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS. Сегодня поговорим о том, существуют ли джуниоры в DevOps — и какими они должны быть.
Содержание
Какое место занимает отдел DevOps среди остальных разработчиков
DevOps находится на стыке Development и Operations. Если команда Development прежде всего фокусируется на создании программного обеспечения, то команда Operations — на том, чтобы это ПО надёжно и эффективно работало в реальных условиях. DevOps же старается сделать эти процессы более связанными и гармоничными.
Вот некоторые задачи и проблемы, которые решает девопсер:
Самая важная задача — постепенное развитие архитектуры CI/CD
Неэффективные ручные процессы развертывания
Определение узких мест в инфраструктуре и их оптимизация
Получается, что DevOps существует поверх архитектуры и сервисов других разработчиков. Поэтому в начале должно появиться что-то, что можно автоматизировать.
Чтобы понять и тех и других, нужен достаточно широкий кругозор. И здесь мы приходим к вопросу: может ли существовать DevOps-специалист уровня джуниор?
Где нужен джуниор-DevOps
Команда разработки должна вырасти хотя бы до пяти-семи человек, чтобы понадобился один DevOps-специалист. Если разработчиков меньше, задумываться об оптимизации процессов может быть рано.
В небольших компаниях нужен один супер-инженер, который разбирается во всём и может настроить инфраструктуру в одиночку. Очевидно, что джуниор-DevOps на такую позицию не подходит, потому что ему ещё учиться и учиться.
Когда появляется приличная DevOps-команда, отлаженные процессы CI/CD и системы мониторинга, компания может внедрить начинающего девопсера с опытом на стыке разработки и администрирования. Он может внедрять уже отлаженные процессы, в которых в целом разбирается. Джуниор-DevOps берёт на себя понятную часть работы и под небольшим контролем будет её выполнять.
Так мы получаем три критерия компании, в которой нужен джуниор-девопсер:
Наличие опытной команды DevOps инженеров
Наличие у нее налаженных процессов внедрения, подходов к CI/CD, мониторингу
В компании ещё не налажено всё на 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-направления или разработчик с достаточно широкой подготовкой
Есть свои выложенные в интернете пет-проекты
Автоматизировал раскладку проекта
Это лишь один из примеров общего опыта, и у вашей компании, конечно, может быть свой подходящий вариант.
Технологические скилы. Нужно знание как минимум четырёх дисциплин:
Как минимум один runtime для своих приложений: Docker с docker-compose, Kubernetes, Hashicorp Nomad, Docker Swarm
Умение работать с CI/CD-системой: GitHub Actions, Gitlab, Jenkins
Умение организовать хотя бы поверхностную систему мониторинга: Prometheus, Grafana, Zabbix
Навык работы с Ansible/Puppet/Salt, умение описывать инфраструктуру
Всё, что идёт после этих четырёх основных шагов — их усложнения. Чтобы построить дальнейший план развития, можно воспользоваться одним из готовых роадмэпов.
Роадмэп по ссылке выше
Заключение: кому стоит идти в DevOps?
Мы считаем, что DevOps-инженеры уровня джуниор существуют. А как считаете вы? Поделитесь мнением в комментариях.
Это трудолюбивые и усидчивые ребята-перфекционисты, которые могут быстро решить задачу и сразу автоматизировать процесс на будущее. Если возникла проблема, девопсер не просто заткнёт её костылём, а найдёт продуманное решение, которое не стыдно применить на других проектах.
В DevOps крайне важно сразу строить надёжную структуру, чтобы однажды не получилось так, что все временные некачественные подпорки слетели и начался один большой пожар. Здесь задачи должны быть чётко организованы в общий план, а система — методично улучшаться. Это не история про быстрый MVP на коленке. Если ваше призвание — DevOps, то вы не обходите важные моменты в задачах ради достижения сиюминутного результата.
При этом в разработке такой подход может навредить бизнесу. В некоторых направлениях надо работать быстро. Например, у нас есть отдел рекламных спецпроектов, где в неделю может быть несколько запусков. Такие проекты обычно небольшого срока действия, часто приурочены к какой-то определённой дате, поэтому в разработке жёсткий фокус на получение готового приложения. Здесь DevOps-команда со своим вдумчивым и методичным подходом позволяет автоматизировать все процессы так, что разработке остаётся только концентрироваться на достижении быстрого результата.
Если вы узнали в нашей статье себя, приходите к нам работать. Сейчас у нас открыто несколько DevOps-вакансий, в том числе junior.
Если чувствуете, что знаний не хватает, записывайтесь на наш курс, где мы рассмотрим самые важные концепции, необходимые для взаимодействия с кластерами Kubernetes, и научим применять эти знания на практике.
Другие статьи про DevOps для начинающих:
Другие статьи про DevOps для продолжающих:
ky0
Devops-инженер начального уровня, на мой взгляд - это человек с нормальным багажом по низкоуровневой инфраструктуре и желанием развиваться в сторону соседней команды. Не только потому что надо само по себе, но и потому, что склад мышления понадобится админский, а не разработчицкий. Devops-инженеров, уходящих в разработку я видел, успешных обратных случаев существенно меньше.
С нормальным инфраструктурным багажом (сети, железо, линкус, базовые инструменты траблшутинга) можно начинать восхождение.
При наличии хорошего наставника можно проделать то же самое почти совсем с нуля, но сроки от интерна до джуна тут слабопредсказуемы.