Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS. Сегодня поговорим о том, существуют ли джуниоры в DevOps — и какими они должны быть. Содержание Какое место занимает отдел DevOps среди остальных разработчиков Где нужен джуниор-DevOps Каким должен быть джуниор-DevOps Опыт в Development и Operations Привычка автоматизировать и опыт CI/CD Общий кругозор и готовность развиваться Пример портрета джуниора-DevOps Заключение: кому стоит идти в DevOps? DevOps находится на стыке Development и Operations. Если команда Development прежде всего фокусируется на создании программного обеспечения, то команда Operations — на том, чтобы это ПО надёжно и эффективно работало в реальных условиях. DevOps же старается сделать эти процессы более связанными и гармоничными.  Вот некоторые задачи и проблемы, которые решает девопсер: Самая важная задача — постепенное развитие архитектуры CI/CD Неэффективные ручные процессы развертывания Определение узких мест в инфраструктуре и их оптимизация Получается, что DevOps существует поверх архитектуры и сервисов других разработчиков. Поэтому в начале должно появиться что-то, что можно автоматизировать. Чтобы понять и тех и других, нужен достаточно широкий кругозор. И здесь мы приходим к вопросу: может ли существовать DevOps-специалист уровня джуниор? Команда разработки должна вырасти хотя бы до пяти-семи человек, чтобы понадобился один DevOps-специалист. Если разработчиков меньше, задумываться об оптимизации процессов может быть рано. В небольших компаниях нужен один супер-инженер, который разбирается во всём и может настроить инфраструктуру в одиночку. Очевидно, что джуниор-DevOps на такую позицию не подходит, потому что ему ещё учиться и учиться. Когда появляется приличная DevOps-команда, отлаженные процессы CI/CD и системы мониторинга, компания может внедрить начинающего девопсера с опытом на стыке разработки и администрирования. Он может внедрять уже отлаженные процессы, в которых в целом разбирается. Джуниор-DevOps берёт на себя понятную часть работы и под небольшим контролем будет её выполнять.  Так мы получаем три критерия компании, в которой нужен джуниор-девопсер: Наличие опытной команды DevOps инженеров Наличие у нее налаженных процессов внедрения, подходов к CI/CD, мониторингу В компании ещё не налажено всё на 100%, появляются новые области архитектуры, которые надо автоматизировать по уже существующим шаблонам Вывод: новички в DevOps нужны там, где есть большое количество уже отлаженных задач по автоматизации и настройке инфраструктурных инструментов. После того, как опытные специалисты отладили один процесс, джун под присмотром сеньора может внедрять его самостоятельно. Поначалу новичок в DevOps не знает, как правильно и лучше, поэтому ему обязательно нужен ментор. Наставник знакомит джуниора с лучшими практиками и стандартами, помогает корректировать ошибки и ставить цели в развитии. Подробнее про культуру наставничества можно почитать в статье «Добрый ментор»: часть 1 и часть 2. Кроме делегирования рутинных задач, новички-девопсеры могут приносить такую же пользу, как и в любой другой разработке: Закрытие старых долгов по мониторингу. Для джуниора это точка развития: решая подвисшие алерты и добавляя новые метрики, он сможет познакомиться со всеми системами — а вы закроете накопившиеся несрочные задачи  Обновление документации. Новички часто задают вопросы и ищут документацию, что может выявить пробелы и недостатки в существующих материалах Поддержание технологий на современном уровне. Джуниоры, активно изучающие новые технологии и методологии, могут стать источником свежих идей и практик В этом разделе расскажу про качества гипотетического джуна-девопсера, которые мы хотим видеть у кандидатов. Самое важное — иметь опыт на стыке. Поэтому будущий девопсер должен хотя бы немного уметь разрабатывать, чтобы мыслить как разработчик. При этом ему нужен стартовый опыт в развёртывании инфраструктуры для своих разработок. Этот кругозор может быть небольшим, возможно, студенческим или в пет-проектах, но он должен быть и там и там.  Иногда есть опыт в чём-то одном, и нужно прокачать вторую часть. Разработчик, которому надоело писать код, имеет хороший опыт в разработке, и ему нужно только подтянуть навыки администрирования. Админы умеют поддерживать сервис и инфраструктуру, и им остаётся погрузиться в процесс разработки, например написать какой-нибудь простейший API. Я пришёл в DevOps из бэкенда. В компании не было выделенной роли для администрирования инфраструктуры, и самый опытный бэкендер на своём проекте отвечал за свои CI/CD. В том числе и я отвечал за всю инфраструктуру своих проектов. С развитием компании мы отладили и собрали библиотеки по автоматизации рутинных процессов, накопили целые архитектуры инфраструктур. Мы поняли, что у нашей компании уже большая компетенция в DevOps, и мы можем делиться ей с другими компаниями. Мне было интересно заняться новым направлением, и я полностью переключился на руководство новым юнитом. Ещё через какое-то время мы проанализировали рынок и стали продавать DevOps-услуги другим компаниям. Кроме опыта на стыке, у девопсера должна быть привычка упрощать. Например, такой человек мог написать свой API и потом не просто один раз выложить код на сервера, а настроить автоматизацию, чтобы развёртывание происходило само после пуша в SCM-систему — Gitlab, GitHub, Bitbucket. Настоящий DevOps-инженер всегда автоматизирует процессы. В том числе развёртывание инфраструктуры — например, применяет Terraform для создания ресурсов в облаке, привязывает использование ansible к дополнительной установке пакетов на машины — и делает это через CI/CD. И так должно быть в любой области, которую видит и за которую отвечает DevOps-инженер. В начале развития компании у нас на старте проекта всегда был специалист, «главный разработчик», который раскладывал релиз. Он собирал все части проекта от других разработчиков в один пакет. Потом этот человек сам писал команды, чтобы разложить новый проект на все необходимые машины. За годы практики, ещё до открытия нового направления, у нас уже набралась хорошая экспертиза в настройке CI/CD, вплоть до динамических окружений у сложных сервисов. Если бы у нас самих не было привычки автоматизировать, вряд ли мы бы дошли до такого прогресса. В итоге мы получаем человека с определённым кругозором и подходом к работе. Будущий девопсер — не просто технически подкованный специалист, а человек на стыке двух больших направлений. Он всегда стремится к оптимизации процессов и видит возможность автоматизации там, где другие повторяют рутинные действия и не замечают, что процесс можно улучшить. Летом 2022 года на офлайн-мероприятии «День Техдира» мы вместе с коллегами из Selectel выступили с докладом, который потом переработали в серию статей. В первой из них можно прочесть, как развивалась 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 крайне важно сразу строить надёжную структуру, чтобы однажды не получилось так, что все временные некачественные подпорки слетели и начался один большой пожар. Здесь задачи должны быть чётко организованы в общий план, а система — методично улучшаться. Это не история про быстрый MVP на коленке. Если ваше призвание — DevOps, то вы не обходите важные моменты в задачах ради достижения сиюминутного результата. При этом в разработке такой подход может навредить бизнесу. В некоторых направлениях надо работать быстро. Например, у нас есть отдел рекламных спецпроектов, где в неделю может быть несколько запусков. Такие проекты обычно небольшого срока действия, часто приурочены к какой-то определённой дате, поэтому в разработке жёсткий фокус на получение готового приложения. Здесь DevOps-команда со своим вдумчивым и методичным подходом позволяет автоматизировать все процессы так, что разработке остаётся только концентрироваться на достижении быстрого результата. Если вы узнали в нашей статье себя, приходите к нам работать. Сейчас у нас открыто несколько DevOps-вакансий, в том числе  junior. Если чувствуете, что знаний не хватает, записывайтесь на наш курс, где мы рассмотрим самые важные концепции, необходимые для взаимодействия с кластерами Kubernetes, и научим применять эти знания на практике. Другие статьи про DevOps для начинающих: Сравнение Kubernetes с другими оркестраторами: Docker Swarm, Nomad, Openshift Как изучать Kubernetes джуну — и зачем Как деплоить приложение на Django в Kubernetes с нуля Другие статьи про DevOps для продолжающих: Как построить эргономичный мониторинг Зачем мы сделали собственный контроллер для копирования секретов в Kubernetes Как экономить ресурсы, затрачиваемые Kubernetes  Head of DevOps