Как найти хорошего специалиста по DevOps, и почему процесс поиска может сильно затянуться

DevOps (сокращенно от development and operations) - это не какое-то конкретное направление деятельности. Это одновременно методология, культура и профессиональная философия. В ее основе лежит идея, что процесс разработки цифрового продукта - это единый цикл, который не должен разделяться на тестирование, оптимизацию и эксплуатацию.

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

В этой статье Дмитрий Меремьянин, CTO «Нетологии-групп», и другие эксперты рассказывают, какими ключевыми навыками должен обладать специалист по DevOps, на что работодателю обращать внимание при найме. Также авторы делятся опытом, как искали такого специалиста в «Нетологию-групп», и почему этот процесс сильно затянулся.

Каким должен быть DevOps-специалист

Специалист, работающий с development and operations, в первую очередь должен не только знать инструменты, связанные с инфраструктурой, но и разбираться в системном администрировании. Если у специалиста этой базы нет, то появляется вопрос: как он смог вырасти до инженера по DevOps без понимания самого основного?

По моему мнению, идеальный путь человека в DevOps — когда он сначала работает системным администратором и со временем сам понимает, какие «ручные» вещи можно автоматизировать. А после этого уже начинает пробовать и внедрять разные инструменты автоматизации в свои процессы. Так он развивает в себе эту культуру и вырастает в DevOps-инженера. Нельзя сказать, что такой путь априори правильный, но выглядит он сегодня логично, - считает Дмитрий Меремьянин.

По мнению Дмитрия Меремьянина, идеальный путь человека в DevOps начинается с работы системным администратором

Роман Гершкович, преподаватель «Нетологии», выделяет четыре качества, которые должны быть важны для руководителя при выборе специалиста:

1. Хорошая база и желание разбираться, как работают используемые компоненты.

На мой взгляд, основная сложность состоит в том, чтобы найти людей с хорошей базой. Сейчас доступно множество готовых модулей, «строительных блоков» для любого инструмента управления конфигурациями, которые позволяют быстро получить сложную по устройству систему. Многие специалисты научились пользоваться подобными высокоуровневыми инструментами, но на этом остановились, не стали углубляться в принципы и результат их работы. А ведь это нужно для многих проектов: чтобы поддерживать и эффективно эксплуатировать сложную систему, минимизировать downtime, обязательно как минимум знать базовые вещи по Linux — какими ресурсами ОС управляет, как оценить их утилизацию, потребности приложений, наличие ошибок, и как их дебажить, - объясняет Роман Гершкович.

2. Структурный подход к задачам.

Используя одни и те же инструменты, можно пойти по двум разным путям:
а) сделать удобную поддерживаемую структуру,
b) сделать бездумный copy-paste из мануала.

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

Основная сложность состоит в том, чтобы найти людей с хорошей базой, считает Роман Гершкович

3. Умение встроиться в действующую систему.

У каждой команды и продукта своя история, экспертиза и use-кейсы. Поэтому практически по любому компоненту современных систем невозможно дать единственно верную оценку. В каждом конкретном случае иметь вес будут разные аспекты. Человек, которого вы нанимаете, должен это понимать. Даже если он суперпрофессионал в конкретной области с собственным мнением, он должен хотеть встроиться в команду с ее текущими правилами. Желание все действующее переделать, снести и построить заново только потому, что он лучше разбирается в Х, а не Y — губительно, - уверен Роман Гершкович.

4. Желание человека постоянно развиваться

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

Настоящих специалистов, которые способны внедрять методологии DevOps в компанию, очень мало. Алексей Чувашов, CTO 65apps считает, что многие бывшие сисадмины просто учат новый и модный стек, но не пытаются понять процессы разработки и workflow задачи разработчиков. Еще меньше понимания у самих заказчиков или работодателей: зачем им нужен DevOps, какие задачи и потребности он должен закрывать.

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

Настоящих специалистов, которые способны внедрять методологии DevOps в компанию, очень мало, отмечает Алексей Чувашов

Как компаниям выбрать специалиста на development и operations

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

Подбирать специалиста нужно не только по бэкграунду, но и soft-skills, и духу, чтобы человек мог легко влиться в уже существующую команду. Если взять очень крутого, прокаченного, но замкнутого человека-«колючку», он практически не принесет пользы. Более того, такие люди все равно потом уходят. Поэтому лучше потратить больше времени на поиск, чем потом долго адаптировать человека или искать нового после его быстрого ухода.

Роман Гершкович советует делать выбор человека исходя из общих целей компании на данный момент. На каждом этапе развития культуры DevOps оптимальное решение по уровню навыков сотрудников и их количеству в команде будет разным. Иногда лучше нанять одного senior-специалиста за большие деньги, чтобы он решил острые проблемы и повел команду за собой. А в какие-то моменты пара junior-инженеров на вырост будет очень кстати: сначала они принесут меньше пользы, но при правильном развитии будут очень перспективны для компании, смогут закрывать больше задач.

Если у вас есть отдел мониторинга и логов с высоконагруженным Jaeger, и вы хотите усилить команду именно в этом направлении, логично искать именно специалиста по Jaeger. Но когда вы ищете человека общего профиля в команду DevOps, не стоит делать поиск по ключевым словам: например, если вы живете в Azure, это не значит, что вам не подойдет специалист с опытом в GCP. Намного важнее поговорить с этим человеком и понять его базовые знания, установки, общее отношение к автоматизации и мониторингу, каких целей он добивался инструментами, с которыми работал, на каком уровне он ими овладел. Главное, чтобы вы совпадали по этим параметрам, а документация по Terraform читается одинаково везде, - поясняет Роман Гершкович.

Тем, кто проводит интервью специалистов, лучше подготовить общую для всех interview book и прописать в ней разделы с базовыми вопросами по программированию на уровне автоматизации, операционным системам, сетям, архитектуре распределенных приложений. Также стоит иметь тестовую виртуалку с набором сломанных сервисов, которую человек должен починить, чтобы продемонстрировать свои практические навыки, считает представитель компании. Здесь не стоит создавать дополнительных трудностей — общих вещей по типу сломанных прав на файловой системе, chattr +i, забитого по выводу df диска из-за удаленных файлов будет достаточно.

Почему в «Нетологию-групп» стали искать человека на DevOps

Компания состоит из четырех проектов: онлайн-школы для детей «Фоксфорд», «Нетологии» для обучения взрослых специальностям из сферы диджитал, EdMarket, университета профессий в онлайн-образовании и школы изучения английского языка Wordika.

Культура DevOps — методология, при которой отдел разработки тесно взаимодействует с отделом эксплуатации — зарождалась в компании эволюционно. В 2014 году она уже существовала в зачаточном состоянии, но были проблемы с инфраструктурой, многое не было автоматизировано и возникали ошибки, говорит Дмитрий Меремьянин.

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

В офисе «Нетологии»

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

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

В компании поставили перед собой следующие цели:

• обеспечить стабильную работу и постоянную поддержку инфраструктуры;
• кратно увеличить скорость релизных циклов — с двух недель до нескольких раз в день.

Выделили приоритетные задачи:

• автоматизировать развертывание серверного окружения с нуля;
• настроить мониторинг нашей инфраструктуры и приложения;
• запустить централизованный сбор логов;
• выстроить качественные процессы по CI и CD.

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

Как мы искали сотрудника на DevOps

Когда в «Нетологии» начали развивать культуру DevOps, то считали, что под эту роль отлично подойдет сильный системный инженер с навыками, помогающими использовать DevOps-практики, рассказывает Дмитрий Меремьянин. Например, с опытом системного администрирования, работы с инструментами автоматизации — Chef, Puppet или Ansible — пониманием сетевых технологий, а также знанием одного или нескольких языков программирования (Python или Ruby) для написания скриптов.

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

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

Были и другие истории: иногда на вакансию откликались люди с огромным опытом. Например, один из них привык работать с масштабом тысяч хостов и искал что-то не менее интересное.

Таким кандидатам наша компания не подходила — и мы, и они понимали, что у нас им станет со временем скучно, - отмечает Дмитрий Меремьянин.

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

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

С низов ИТ до DevOps-инженера

Вадим Князев, DevOps-инженер «Нетологии-групп»:

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

Вадим Князев говорит, что он начинал с самых низов ИТ-фирмы: сначала был оператором call-центра и помогал перезагружать роутеры. Образование у него непрофильное (инженер-физик), поэтому знаний в ИТ практически не было.

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

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

Работа разработчиком Владимиру Князеву казалась скучной

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

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

В «Нетологию-групп» он пришел уже на работающую инфраструктуру, нужно было только все поддерживать и развивать. Князев считает, что делать все с нуля гораздо проще, чем принимать то, что уже работает. Зачастую приходится изучать новые инструменты и подходы, которые были внедрены до тебя. Самой большой трудностью для него стал Kubernetes: «я много читал о нем, всегда хотел попробовать, но предыдущие проекты не позволяли его использовать. У меня был страх, что я не разберусь, но когда на собеседовании меня спросили «А не боишься, что не разберешься?», я ответил, что не боюсь. Пришлось разобраться».

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

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

Источник фото - «Нетология-групп»

Читайте также