Кто такие DevOps и откуда они берутся порой не знают даже опытные рекрутеры. Кажется, что это человек, который умеет все. Мы поговорили с DevOps-инженером, чтобы разобраться в этой теме получше и узнать, как он позиционирует себя сам.
— Привет! Расскажи немного о себе?
— Я начал учиться в Переславле-Залесском на Информационных системах и технологиях, а затем переехал в Питер, и уже доучивался в ИНЖЭКОНе на Прикладной информатике в экономике. Если бы я пошел работать по профессии, то, наверное, сейчас бы был 1С-разработчиком. Но все сложилось немного иным образом. Первой работой, на которую я устроился в 2009 году, был интернет-провайдер, я тогда учился на 2 курсе. В процессе работы я понял, куда хочу развиваться, что 1С разработка не так увлекательна, и я хочу большего. Затем компанию купили, характер работы сильно изменился, появилась бюрократия, да и интересные задачи исчезли от слова совсем. А в 2016 году я перебрался из сетей в энтерпрайз и начал развиваться в направлении DevOps.
— В какой момент ты понял, что хочешь стать DevOps-инженером?
— С самого детства я, можно сказать, был в обнимку с компьютером. Я любил решать инженерные задачи, и у меня это хорошо получалось, а когда делаешь что-то хорошо — хочется делать это еще лучше. Так что решение было принято каким-то интуитивным образом.
Как я уже и говорил, изначально я не планировал становиться именно DevOps'ом, но со временем получилось так, что на мне остались только эти функции. Поначалу я занимался сопровождением релизного цикла софта, а позже уже более сложными вещами: строительством окружений, внедрением новых компонентов, AWS и т. д. Все проекты я показывал коллегам, документировал, автоматизировал.
Как я уже и говорил, изначально я не планировал становиться именно DevOps'ом, но со временем получилось так, что на мне остались только эти функции. Поначалу я занимался сопровождением релизного цикла софта, а позже уже более сложными вещами: строительством окружений, внедрением новых компонентов, AWS и т. д. Все проекты я показывал коллегам, документировал, автоматизировал.
— Кстати, часто слышу спорные утверждения насчет функционала DevOps-инженеров. Можешь рассказать, кто такой DevOps-инженер в глазах самого DevOps?
— Важно понимать, что кого бы вы не искали — системного администратора, разработчика, QA — это всегда будет инженер. И вообще, такой профессии, как «DevOps-инженер» на самом деле не существует. Им может стать любой инженер, если приложит усилия и разовьет свои навыки.
DevOps, в первую очередь — это набор практик, методик, процессов и «best practice», в меньшей степени — инструментарий. Если говорить в общем, то DevOps-инженер:
Таким образом, DevOps-инженер решает разноплановые задачи, например:
DevOps, в первую очередь — это набор практик, методик, процессов и «best practice», в меньшей степени — инструментарий. Если говорить в общем, то DevOps-инженер:
- Полностью погружен в текущий стек технологий проекта, чтобы разработчики не «писали в стол».
- Связывает разработку и реальный мир (то, как проект запускается, работает, поддерживается, какие инструменты для этого нужны).
- Помогает команде по всем остальным неясным вопросам.
Таким образом, DevOps-инженер решает разноплановые задачи, например:
- Как собирать софт чаще и быстрее?
- Как выпустить софт по всем окружениям в удобном, понятном и безопасном режиме?
- Как организовать мониторинг?
- Как организовать логирование?
— Расскажи про самые сложные моменты в своей работе? Возможно, у тебя были какие-то фейлы, а может наоборот — победы?
— Самая большая сложность в том, что DevOps-инженер — это специалист широкого профиля. Ты должен разбираться во всем: как работает твой продукт и его компоненты, как все собирается, тестируется, деплоится, какие есть окружения, кто их оунер. А еще предугадывать, какие особенности инструментария могут выстрелить, а какие могут выстрелить вам в ногу.
Также мне нужно много общаться и находить общий язык с разработчиками, QA, PM и т. д. Требуется немалое терпение и стрессоустойчивость, чтобы договориться со всеми сторонами, донести свои мысли и идеи, отстоять позицию.
Крупный фейл у меня произошел во времена работы на интернет-провайдера: у всех пользователей в Санкт-Петербурге отключился интернет на 6 часов. Каких-то значимых побед я не могу отметить. Наверное, победа — это когда команда разработчиков, используя твой инструментарий, штампует стабильные билды 70 раз в день. Тебя никто не отвлекает, и только встретив коллегу случайно в коридоре, ты узнаешь о последних новостях. Все идет по плану.
Также мне нужно много общаться и находить общий язык с разработчиками, QA, PM и т. д. Требуется немалое терпение и стрессоустойчивость, чтобы договориться со всеми сторонами, донести свои мысли и идеи, отстоять позицию.
Крупный фейл у меня произошел во времена работы на интернет-провайдера: у всех пользователей в Санкт-Петербурге отключился интернет на 6 часов. Каких-то значимых побед я не могу отметить. Наверное, победа — это когда команда разработчиков, используя твой инструментарий, штампует стабильные билды 70 раз в день. Тебя никто не отвлекает, и только встретив коллегу случайно в коридоре, ты узнаешь о последних новостях. Все идет по плану.
— Какие компании для тебя привлекательны в качестве работодателя?
— Когда я рассматриваю предложения, у меня есть первичный чек-лист:
Также у компании не должно быть «мутной истории». На моей памяти есть те, кто опорочил себя так или иначе, например, ЦРПТ, РКН, Revolute.
Когда этот этап пройден, я смотрю на технический стек и оцениваю интересность задач. Финальный фактор, вполне прозаичный, деньги. Чем больше — тем лучше. Кстати, на заметку, большинство работодателей не указывают зарплатную вилку, в силу своей вредности я тоже не указываю желаемый уровень заработной платы.
- Не государственная компания. В госпредприятие я не пойду по личным и политическим соображениям. Ожидаемо, что там царит бюрократия, и нет никакой гарантии, что ты будешь работать на людей, которые хоть что-то понимают в IT.
- Не криптостартап. В 2019 году? Это уже просто смешно.
- Не банк. По той же причине, что и в первом пункте.
Также у компании не должно быть «мутной истории». На моей памяти есть те, кто опорочил себя так или иначе, например, ЦРПТ, РКН, Revolute.
Когда этот этап пройден, я смотрю на технический стек и оцениваю интересность задач. Финальный фактор, вполне прозаичный, деньги. Чем больше — тем лучше. Кстати, на заметку, большинство работодателей не указывают зарплатную вилку, в силу своей вредности я тоже не указываю желаемый уровень заработной платы.
— Скажи, а помнишь самые классные собеседования, на которых ты был?
— Как-то раз я был на собеседовании, где меня спросили: «Как бы вы не стали строить CI/CD процесс?». Мне понравилось, что задавали много вопросов «от противного»: как не стоит делать и чем это грозит. Не было вот этой всей воды. Еще было классное собеседование в EPAM — техническое интервью, где меня гоняли «и в хвост, и в гриву». Вышел я с него подавленным. Мне показалось, что прошел я его плохо. Но мне сделали оффер через день. Я его не принял, искал в качестве запасного варианта.
— Сидишь ли ты в чатах, каналах, форумах? Подскажи, где крутой DevOps проводит большую часть времени в сети?
— Да, конечно. Я сижу во многих чатах русскоязычного DevOps-сообщества в Telegram: DevOps, Kubernetes, Ceph, ну и, естественно, DevOps DrinkUp :) На форумах почти на бываю. Вообще, все это сильно отвлекает и затягивает, поэтому стараюсь ограничивать свое время в чатиках.
— Как считаешь, какие проблемы сейчас на рынке DevOps-инженеров?
— Проблема, схожая со всем IT-рынком — кадровый голод: кандидатов очень много, но хороших мало. Плюс, как особенность российского рынка, компании ищут специалистов по скилам, а не по критерию «инженер/не инженер».
— А что скажешь об уровне заработной платы?
— Если брать, как пример, Senior DevOps-инженера из Санкт-Петербурга, он может рассчитывать на зарплату в 160-250 тысяч руб. Сумма зависит от компании. При этом вакансии висят открытыми по 3-4 месяца, потому что человека ищут по каким-то установкам: «Он должен был работать с определенным стеком технологий, потому что учиться новому некогда». Компании думают, что наняв такого человека, они приобретут палочку-выручалочку: релизы будут выходить в срок, тесты иметь 100% пасс-рейт, а продакшн станет нерушим, если перевести его на Kubernetes. Все это далеко не так. Многие компании не готовы к введению DevOps-практик из-за исторически сложившихся причин, менять процессы, выделять ресурсы разработчиков, чтобы, например, сделать приложение Cloud Native или увеличить покрытие тестами. Ведь DevOps — это не только инженер, но и то, как остальные команды и их менеджмент между собой взаимодействуют.
