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

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

Олег Миколайченко: выступление на DevOpsStage

Как инженеры 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. Неприятно.

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

Статистика зарплаты на DOU для DevOps инженера с опытом 6+ лет

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

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

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

Мало кто знает, но результаты опросов хранятся на Github. Я отфильтровал для вас только DevOps Engineers, всего получилось 282 анкеты. Из них с зарплатой $3500+ – 76 анкет, с $5000+ – 26 анкет. Google Sheets с отфильтрованными данными доступны по ссылке.

Эти данные приближены к настоящим, но все же не настоящие. Реальные зарплаты несколько больше, потому что инженеры – занятые люди, да и делиться своей зарплатой не каждый захочет. Недавно в сообществе UkrOps спрашивали, кто из участников заполняет опросник. Оказалось, что их заполняют всего 30 % из опрошенных, и их преимущественно не заполняют инженеры, которые зарабатывают выше рынка «по понятным причинам».

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

И еще добавлю очевидную мысль: в опросе, который я анализирую, всего 282 анкеты. В то же время непонятно, сколько инженеров в сфере DevOps. Linkedin находит 8250 DevOps инженеров в регионе Украина, но реальное количество будет больше.

26 инженеров с зарплатой $5000 и больше

Давайте посмотрим на эти 26 VIP-анкет из всех 282 анкет:

• преимущественно хороший английский;
• неважен тип компании и размер;
• более чем четыре года опыта (снова отсылка к молодости направления).

На второй вкладке я подготовил фильтр с инженерами с зарплатой $3500 и больше. Если мы попробуем сравнить их со специалистами, которые зарабатывают $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!

Источник: MC.today