Почему украинские DevOps-инженеры зарабатывают $5000, зачем они нужны бизнесу и как ими стать

Олег Миколайченко – DevOps-инженер, сооснователь сообщества Kyiv DevOps Community, ведет DevOps-дайджесты на DOU.UA и самый большой Telegram-канал о DevOps в Украине.

В колонке для MC.today Олег рассказывает о карьере инженера DevOps, анализирует зарплаты, объясняет, за что же бизнес готов платить таким специалистам более $5000, и делится советами, как начать зарабатывать больше.

Друзья, мы в редакции mc.today мечтаем публиковать ваши истории. С вами приключилось что-то странное и необычное на работе, в поездке, прямо на улице? Расскажите об этом нам, отправив письмо на news@mc.today.

Как инженеры DevOps экономят деньги компаниям

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

Хороший инженер помогает двигаться продукту быстро (выкатывать новую версию по 10 раз в день, например), а когда ему никто не мешает – оптимизировать инфраструктуру и деньги компании.

Когда меня просят привести пример, как DevOps помог бизнесу, я всегда рассказываю историю инженера, который за 2 месяца перенес всю инфраструктуру приложения с искусственным интеллектом на новый тип серверов. Новый тип серверов был с видеокартами, поэтому специфические вычисления начали отрабатывать в десятки раз быстрее, как результат – уменьшение количества серверов. Стоимость инфраструктуры для бизнеса снизилась с $120000 до $20000, то есть в шесть раз.

Второй пример – DevOps-инженер пришел в стартап на этапе валидации (валидация – доказательство того, что требования конкретного пользователя, продукта, услуги или системы удовлетворены – прим. ред.) гипотезы, вся инфраструктура – два сервера, их программисты настраивали руками. Внезапно стартап выстрелил, а инфраструктура не справлялась – старые подходы в стиле «заказать сервер, зайти на него, установить приложение» не работали под нагрузкой и давлением пользователей. Инженер решил автоматизировать создание серверов и переехать в дешевое облако, закончил как раз перед «черной пятницей». Компания продолжила существовать за счет того, что успела заработать в этот день.

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

Я встречал три типа DevOps-инженеров:

1. Продвинутые программисты, которым пришлось настраивать процессы сборки и развертывания приложения на различных окружениях. Следующий шаг – программист понимает, что ему интересно разбираться, как же его приложение работает в реальном «боевом» окружении, и приходит к вопросам о том, как его масштабировать и делать отказоустойчивым. В результате он получает экспертизу на стыке Dev и Ops.
2. Продвинутые системные администраторы, которые отказались от привычной модели «работает – не трогай», пробовали автоматизировать рутинные действия и (самое главное!) коммуницировали с программистами. Принято считать, что до DevOps-методологии между отделами эксплуатации и разработки была война. Потому что бизнес ставил для каждого из отделов разные, конфликтующие цели и задачи. И те, кто отказался от привычной модели взаимодействия и начал разбираться вместе с программистами, как же оно работает, тоже получили экспертизу на стыке Dev и Ops.
3. Новички, которые сразу запрыгнули в DevOps-специализацию. Эти ребята вовремя осознали, что направление популярное и востребованное, и учились сразу в нужном векторе. У таких ребят меньше всего опыта в IT (т. к. направление молодое, в Украине ему чуть более 5 лет), но в результате их экспертиза максимально заточена под рынок. Это самые универсальные ребята, которые выросли уже на правильной почве: им не нужно тянуть за собой багаж старых стереотипов, но часто им как раз и не хватает «боевого» опыта.

Моя карьера соединила в себе второй и третий подходы: я начинал с полностью автоматической установки Windows по сети на несколько компьютеров и менял картриджи в принтерах.

В какой-то момент мне показалось, что лазить под столами бухгалтеров и подключать мышки – это не то, чем бы хотелось заниматься. И после анализа рынка я понял: с моими знаниями логичнее всего будет перейти в магический и непонятный DevOps. Это были еще те времена, когда вакансий почти не было и никто не понимал, что такое DevOps. С этого и начался мой путь.

Как начинающему инженеру пройти первое собеседование

В начале карьеры это самая стрессовая ситуация из возможных. Как правильно проходить собеседования – это огромная тема для отдельной статьи. Мне в свое время стало понятно, что на собеседовании нужно продавать: продавать свой опыт, свои навыки и подходы. Резюме не продает – оно декларирует набор технологий, показывает, «к чему придираться», и «есть ли там те слова, которые нужны нам».

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

В результате я накидал несколько слайдов о текущей инфраструктуре: где тут моя работа и чем это полезно. В первой итерации (итерация в программировании — в широком смысле — организация обработки данных, при которой действия повторяются многократно, не приводя при этом к вызовам самих себя — прим. ред.) это были скриншоты графиков и разные технические термины. Результат получился отличный: любые чек-листы и заготовленные вопросы на собеседовании терялись, оппонент интересовался, что и как работает, и начинал спрашивать по презентации. Как тут сделал? Почему? Что в результате? И я плавал в тихом океане своих экспертиз.

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

Сейчас я осознаю, что это очень сильный подход.

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

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

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

Сочное мясо: сколько платят DevOps-инженерам?

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

• Junior DevOps Engineer – $300 – $1500
• Middle DevOps Engineer – $1500 – $3500
• Senior DevOps Engineer – $3500+

Есть еще отдельный тип инженеров: job-hoppers. Это когда специалист ходит по собеседованиям и просит +$500 к своему последнему предложению. Такие инженеры умудряются просить до $7000 с очень посредственными знаниями, но платит ли им кто-то такие деньги долгосрочно, я не знаю.

Градация с приставками к должностям Junior/Middle/Senior абсолютно условная и чаще всего говорит о жестко ограниченном бюджете компании на вакансию и желании сэкономить. Например, часто встречается такая формулировка: ищем Middle на зарплату Middle, а в требованиях – опыт и знания для Senior. Неприятно.

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

Как правило, из этих 6+ лет действительно по специализации будут 4-5 в лучшем случае (отсылка к первой части, где я упоминал, что направление молодое, в Украине ему чуть более 5 лет), а весь остальной опыт – где-то рядом (в программировании или администрировании).

Медиана на этом графике абсолютно неинтересна, она столь же полезна, как средняя температура по больнице. Давайте смотреть на третий квартиль: это еще не самые высокие зарплаты, но достаточно приближенные к реальным. Получается, что инженер вполне может претендовать на $5000.

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

Как вырасти с $3500 на $5000+

Совет первый и фундаментальный: пробовать

Вы стоите ровно столько, сколько вам платят. Когда вы последний раз подходили к менеджеру с аргументированным предложением пересмотреть вознаграждение?

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

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

Совет второй: акцент на бизнес

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

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

Такой язык бизнес понимает. Например, формулировка «Мы переехали на Kubernetes» не вызовет никакой реакции или даже спровоцирует негативную из-за своей непонятности.

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

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

Совет третий: быть публичным

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

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

У какого больше вероятность получить предложение о сотрудничестве?

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

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

Без экспертизы это не работает

Все, что мы обсудили, не будет работать, если инженер не дотягивает в технологическом плане. Невозможно прыгнуть выше головы с ограниченным набором старых инструментов и подходов. Если решать новые проблемы бизнеса старым и неэффективным способом, то будет как в видео: «У тебя скучное лицо – тебе никто денег не даст».

Обязательная DevOps-экспертиза: версия CTO at SHALB

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

1. Разработка: нужно понимать, как работает приложение, понимать принципы и шаблоны разработки, уверенно себя чувствовать в написании кода и его сопровождении. Хорошо стремиться к идеалу: в концепции SRE это значит, что инженер может разобраться в приложении, исправить нюанс реализации, улучшить стабильность, применяя определенные практики.
2. Администрирование: нужно понимать, как приложение должно работать под нагрузкой, на большой распределенной инфраструктуре, видеть потенциальные проблемы и решать их до проявления в «боевой» среде. Также важно понимать, как и когда применять различные инструменты, где и на каком уровне лучше решать возникшую проблему.
3. Архитектура: нужно уметь абстрагироваться от текущей реализации и подниматься на несколько ступеней выше. Инженер, претендующий на высокий уровень вознаграждения, должен демонстрировать уверенные знания в области дизайна и построения архитектуры — просто грести веслом и делать задачи по описанию уже не получится.
4. Исправление проблем (troubleshooting): нужно уметь быстро и качественно ориентироваться в новых частях инфраструктуры, понимать, откуда растут ноги в возникших авариях, и уметь разбираться тогда, когда «‎люди бідкаються, а влада розводить руками». Нужно уметь работать в условиях отсутствия документации, плохо спроектированной архитектуры, неочевидных зависимостей и прочего.

Нужно знать, понимать и уметь очень много. Если вы можете разобраться в новом приложении, ссылку на которое вам выслали 10 минут назад, все в порядке. Если вы сразу видите проблемы реализации, что нужно поправить и улучшить, вообще супер. Если при этом вы можете донести обратную связь так, чтобы никто не обиделся, — добро пожаловать к нам в команду.

Инженер с зарплатой в $3500 имеет право спокойно и не спеша, качественно делать свою часть стены кирпичного дома. DevOps-инженеру с зарплатой $5000+ необходимо видеть весь дом в целом, определять проблемные места и понимать, зачем вообще этот дом нужен (большая цель, которая важна для бизнеса).

Что учить, а что не нужно

В этом мне помогла строка поиска по вакансиям: если технология или подход встречался в нескольких вакансиях, я ее учил или, по крайней мере, уделял внимание. Если не находил – пропускал и двигался дальше.

Такой подход работает и сейчас, смотрите:

Эти два инструмента решают одну бизнес-задачу: конфигурировать серверы и приложения. Мне кажется, что лучше учить Ansible (всем остальным, очевидно, тоже).

С другой стороны, для суперпродвинутых инженеров этот подход не подойдет: им нужно быть всегда на гребне волны и учить практики и инструменты еще до того, как их начнет требовать рынок. Но и тут есть модификация этого подхода: достаточно проанализировать ведущие конференции в специализации (за последние месяцы, разумеется) и выбрать самые трендовые технологии, о которых говорят докладчики.

Например, KubeCon, AWS re:Invent, DevOps Days, Monitorama и другие. Суть абсолютно та же: чем чаще об этом говорят, тем большая вероятность того, что технология появится в вакансиях.

Послесловие

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

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

Это тот путь, который мне пришлось пройти в одиночку для того, чтобы поделиться опытом с вами. Stay tuned for more!