Олег Миколайченко – последние статьи и новости

Олег Миколайченко – DevOps-инженер, сооснователь сообщества Kyiv DevOps Community, ведет DevOps-дайджесты на DOU.UA и самый большой Telegram-канал о DevOps в Украине. В колонке для MC.today Олег рассказывает о карьере инженера DevOps, анализирует зарплаты, объясняет, за что же бизнес готов платить таким специалистам более $5000, и делится советами, как начать зарабатывать больше. Друзья, мы в редакции mc.today мечтаем публиковать ваши истории. С вами приключилось что-то странное и необычное на работе, в поездке, прямо на улице? Расскажите об этом нам, отправив письмо на news@mc.today. Олег Миколайченко: выступление на DevOpsStage Как инженеры DevOps экономят деньги компаниям DevOps инженер – это универсальный солдат в команде программистов: настроит сборку приложения, развернет инфраструктуру в облаке, сделает ее масштабируемой и повторяемой. Хороший инженер помогает двигаться продукту быстро (выкатывать новую версию по 10 раз в день, например), а когда ему никто не мешает – оптимизировать инфраструктуру и деньги компании. Когда меня просят привести пример, как DevOps помог бизнесу, я всегда рассказываю историю инженера, который за 2 месяца перенес всю инфраструктуру приложения с искусственным интеллектом на новый тип серверов. Новый тип серверов был с видеокартами, поэтому специфические вычисления начали отрабатывать в десятки раз быстрее, как результат – уменьшение количества серверов. Стоимость инфраструктуры для бизнеса снизилась с $120000 до $20000, то есть в шесть раз. Второй пример – DevOps-инженер пришел в стартап на этапе валидации (валидация – доказательство того, что требования конкретного пользователя, продукта, услуги или системы удовлетворены – прим. ред.) гипотезы, вся инфраструктура – два сервера, их программисты настраивали руками. Внезапно стартап выстрелил, а инфраструктура не справлялась – старые подходы в стиле «заказать сервер, зайти на него, установить приложение» не работали под нагрузкой и давлением пользователей. Инженер решил автоматизировать создание серверов и переехать в дешевое облако, закончил как раз перед «черной пятницей». Компания продолжила существовать за счет того, что успела заработать в этот день. Вход в специализацию тернист и сложен: к сожалению, невозможно прочитать книгу «Как выучить DevOps за 21 день» и стать успешным инженером. Во-первых, потому что такой книги не существует и существовать не может. Во-вторых, потому что DevOps-методология базируется на двух специализациях: программировании и администрировании. Это значит, что нужно глубоко разбираться в обеих областях одновременно. Я встречал три типа DevOps-инженеров: Продвинутые программисты, которым пришлось настраивать процессы сборки и развертывания приложения на различных окружениях. Следующий шаг – программист понимает, что ему интересно разбираться, как же его приложение работает в реальном «боевом» окружении, и приходит к вопросам о том, как его масштабировать и делать отказоустойчивым. В результате он получает экспертизу на стыке Dev и Ops. Продвинутые системные администраторы, которые отказались от привычной модели «работает – не трогай», пробовали автоматизировать рутинные действия и (самое главное!) коммуницировали с программистами. Принято считать, что до DevOps-методологии между отделами эксплуатации и разработки была война. Потому что бизнес ставил для каждого из отделов разные, конфликтующие цели и задачи. И те, кто отказался от привычной модели взаимодействия и начал разбираться вместе с программистами, как же оно работает, тоже получили экспертизу на стыке Dev и Ops. Новички, которые сразу запрыгнули в 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, но я предлагаю рассмотреть немного детальнее и проанализировать, как соответствовать такому вознаграждению. Немного подробнее про зарплаты DevOps-инженеров (нажмите, чтобы открыть доп.информацию)Мало кто знает, но результаты опросов хранятся на 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 Я не буду останавливаться на каждой из технологий, а сделаю более высокоуровневый обзор. Давайте рассмотрим основные моменты и разделим всю экспертизу на части. Разработка: нужно понимать, как работает приложение, понимать принципы и шаблоны разработки, уверенно себя чувствовать в написании кода и его сопровождении. Хорошо стремиться к идеалу: в концепции SRE это значит, что инженер может разобраться в приложении, исправить нюанс реализации, улучшить стабильность, применяя определенные практики. Администрирование: нужно понимать, как приложение должно работать под нагрузкой, на большой распределенной инфраструктуре, видеть потенциальные проблемы и решать их до проявления в «боевой» среде. Также важно понимать, как и когда применять различные инструменты, где и на каком уровне лучше решать возникшую проблему. Архитектура: нужно уметь абстрагироваться от текущей реализации и подниматься на несколько ступеней выше. Инженер, претендующий на высокий уровень вознаграждения, должен демонстрировать уверенные знания в области дизайна и построения архитектуры — просто грести веслом и делать задачи по описанию уже не получится. Исправление проблем (troubleshooting): нужно уметь быстро и качественно ориентироваться в новых частях инфраструктуры, понимать, откуда растут ноги в возникших авариях, и уметь разбираться тогда, когда «‎люди бідкаються, а влада розводить руками». Нужно уметь работать в условиях отсутствия документации, плохо спроектированной архитектуры, неочевидных зависимостей и прочего. Нужно знать, понимать и уметь очень много. Если вы можете разобраться в новом приложении, ссылку на которое вам выслали 10 минут назад, все в порядке. Если вы сразу видите проблемы реализации, что нужно поправить и улучшить, вообще супер. Если при этом вы можете донести обратную связь так, чтобы никто не обиделся, — добро пожаловать к нам в команду. Инженер с зарплатой в $3500 имеет право спокойно и не спеша, качественно делать свою часть стены кирпичного дома. DevOps-инженеру с зарплатой $5000+ необходимо видеть весь дом в целом, определять проблемные места и понимать, зачем вообще этот дом нужен (большая цель, которая важна для бизнеса). Что учить, а что не нужно В этом мне помогла строка поиска по вакансиям: если технология или подход встречался в нескольких вакансиях, я ее учил или, по крайней мере, уделял внимание. Если не находил – пропускал и двигался дальше. Такой подход работает и сейчас, смотрите: Эти два инструмента решают одну бизнес-задачу: конфигурировать серверы и приложения. Мне кажется, что лучше учить Ansible (всем остальным, очевидно, тоже). С другой стороны, для суперпродвинутых инженеров этот подход не подойдет: им нужно быть всегда на гребне волны и учить практики и инструменты еще до того, как их начнет требовать рынок. Но и тут есть модификация этого подхода: достаточно проанализировать ведущие конференции в специализации (за последние месяцы, разумеется) и выбрать самые трендовые технологии, о которых говорят докладчики. Например, KubeCon, AWS re:Invent, DevOps Days, Monitorama и другие. Суть абсолютно та же: чем чаще об этом говорят, тем большая вероятность того, что технология появится в вакансиях. Послесловие Я буду рад, если статья поможет вам стать более уверенными, увидеть новые пути развития или начать позиционировать себя по-другому. Мы с вами проанализировали рынок, разобрались с зарплатами и стали лучше понимать, как DevOps-инженеру зарабатывать $5000+. Мы прикоснулись к лайфхакам на собеседовании и наработали практику, как всегда оставаться инженером с самым трендовым набором технологий на рынке. Это тот путь, который мне пришлось пройти в одиночку для того, чтобы поделиться опытом с вами. Stay tuned for more!