«Если сидеть весь день в наушниках и пилить функционал, то медаль получат все, кроме тебя»: почему быть хорошим инженером недостаточно, если хочешь повышения
Карьера в IT никогда не бывает легкой и быстрой, особенно — в DevOps-специализации. Бытует мнение, что Junior DevOps не существует — виной всему очень высокий порог вхождения в область.
Сложностями в карьере и способами продвижения по карьерной лестнице с Highload поделился Олег Миколайченко — он развивает DevOps-сообщество в Украине, ведет Telegram-канал «ДевОпс Инженер», пишет статьи для MC.today и делает правильную инфраструктуру на должности Head of Infrastructure в компании SQUAD.
Мы обсудили с Олегом, как ему удалось стать Head of Infrastructure, а также попросили поделиться практическими советами, реальными успешными и провальными решениями. Ниже — его история.
Олег Миколайченко — Head of Infrastructure в компании SQUAD
Получить первую работу — самое сложное для инженера
Меня воодушевляла запутанная магия с OSI, TCP/IP, кучей разных протоколов и серверами. Поэтому с самого младшего возраста пытался создать сайт: сначала на конструкторах, потом на хостингах, локально поднимал Denver (Apache, Perl, PHP, MySQL и phpMyAdmin). Это были времена CMS Joomla, Drupal и прочих.
Первые деньги заработал, продавая ссылки для SEO с созданных сайтов.
Первую настоящую работу нашел еще в университете, на практике. Многие ребята на факультете приносили формальные справки, а я принял решение пройти собеседование на должность системного администратора, но пригласили только в Support Helpdesk (техническую поддержку).
Помню это событие, как сейчас. Прихожу, нервничаю, как-то 50/50 отвечаю на вопросы и получаю обратную связь в конце собеседования: «Ты, конечно, ничего не знаешь. Но если хочешь, можешь работать с нами без оплаты».
Конечно, я захотел! Сервера, виртуализация, ЦОДы, сетевое оборудование — меня зажигала каждая ситуация, когда я разбирался в чем-то новом или смотрел, как это делают опытные коллеги. Так я попал уже на оплачиваемую работу в IT for Business & Support Center с зарплатой в 6000 гривен.
Не опускать руки, следовать вектору и работать бесплатно
Мне кажется, что получить первую работу — самое сложное для инженера. Решения, которые в то время помогли мне очень сильно:
- готовиться к собеседованию: у меня была шпаргалка по всем примитивам на начинающую должность (OSI, TCP/IP, основные порты, команды в Linux, NAT);
- не опускать руки: стоит ли говорить, что первый десяток собеседований я с треском провалил 🙂 ;
- строго следовать выбранному вектору: я смотрел только в сторону серверов, инфраструктуры, сайтов, высоких нагрузок;
- неоплачиваемая работа в перспективной компании в начале карьеры: помните, что ваше преимущество — дешевизна и энергия.
Меня всегда очень удивляло, что люди в метро читают какую-то ненужную газету с новостями или слушают музыку. В метро шумно: музыку не послушаешь, а новости — бесполезны. Я старался всегда проводить время с пользой: читал техническую литературу, слушал подкасты, находил обучающие курсы и конвертировал их в формат видео 3gp (только такой можно было запустить на телефоне).
Дальше я уже начал удивляться на работе, когда понял, что большая часть моих коллег в свободное время играет в «Фермера» (популярную игру в соцсетях) и собирает виртуальные баклажаны. Мне это было дико и в то же время — появилось намного больше ресурсов.
Я мог официально тратить время на обучение, аргументируя это развитием решений для своей компании.
Я проходил курсы CCNA, CCNP (профильные курсы по сетям от Cisco) и MCSA, MCSE (курсы по серверным технологиям от Microsoft, но они практически не пригодились).
Секрет успеха №1: тратить максимальное количество времени на обучение и не искать отмазки.
В начальной стадии развития карьеры абсолютно все знания будут в той или иной степени полезны. Возвращаясь назад, могу дать рекомендацию себе прошлому: учить Linux настолько глубоко, насколько это возможно, ведь 95% интернета работает на его базе.
Пробовал автоматизировать мануальные развертывания и случайно выучил PowerShell
В какой-то момент я понял, что настраивать простые почтовые сервера на Zimbra, поднимать Active Directory, используя типичные наработки, становится неинтересно. В результате я попробовал автоматизировать мануальные развертывания и случайно выучил PowerShell. После того, как я добавил эту новую (по тем временам) технологию в LinkedIn, со мной связался рекрутер из компании BetLab и предложил пройти собеседование.
Оказалось, что у DevOps-команды осталось много PowerShell-автоматизации, они перевозят инфраструктуру с Windows Server на Linux и им нужна помощь.
Это был первый офис, где были крутые технологии, плюшки, корпоративы, отличная команда и сервера не в офисе, а в Германии. Я был счастлив.
Дальше начались профильные задачи и изучение концепций: CI/CD, методологии разработки, автоматизация, масштабирование, Python, первые контейнеры, управление конфигурациями и много очень интересных штук. Начали появляться первые митапы, IT-мир заговорил о DevOps, и методология плотно зашла на наш рынок. PowerShell к тому времени я удачно забыл, пересел на Linux и очень этому рад.
Секрет успеха №2: предсказать поведение рынка, выучить необходимую технологию, добавить ее в резюме и LinkedIn.
В моем случае знания были редкими, но потенциально нужными. Сегодня можно и нужно смотреть трендовые конференции: KubeCon, CNCF-митапы, Monitorama.
Новые разработки и бизнес
После запуска Vagrant как платформы для локальной разработки, автоматизации развертывания и масштабирования приложений, настройки мониторинга и сбора логов, я завел блог, где кратко описывал свои наработки. Этот блог прочитал хороший друг и пригласил на собеседование в стартап-акселератор P1K.
Вместе с мегакрутым CTO Егором Мельником (в народе — Егорыч) мы зарелизили несколько стартапов, задизайнили коробочное решение для быстрой проверки любой гипотезы или запуска MVP. Новая платформа включала все необходимые требования (сборка, развертывание) и позволяла бизнесу не терять драгоценное время.
Самый нагруженный сервис Unicheck крутился на десятках серверов в OVH и вырос на несколько порядков в технологическом плане.
Мы могли сидеть до 23:00 в офисе и пилить фичу или разбираться в проблеме.
Это и было катализатором самого продуктивного взаимодействия, ведь когда инженерная команда очень сильно интегрирована с бизнесом, любое решение моментально отражается на успехе всего проекта.
Мне кажется, что самое важное на этом этапе — чувствовать потребности бизнеса, проактивно предлагать решения, делать оптимизации и обязательно показывать графики. За графики бизнес готов кидать в монитор пачками денег, но нужно делать их полезными.
Почему быть хорошим инженером — недостаточно
Когда в P1K платформа стала на рельсы, мониторинг, логи и автоматизация работали как нужно — мне в личку написал рекрутер из MacPaw. В моем представлении, MacPaw — это остров всего самого лучшего, что есть в IT-мире.
DevOps-дайджесты моего авторства, которые нашел рекрутер из MacPaw, собрали более 120 000 просмотров
Конечно, я пришел, познакомился с отличной командой и компанией. В MacPaw было принято принимать очень качественные и взвешенные решения, поэтому мне пришлось сделать step back и повторить основы основ. Примерно в этот момент появился Kubernetes — главный оркестратор всех времен и народов, мы командой мигрировали сервисы компании в AWS EKS.
В сотрудничестве с MacPaw было много классного: например, свободный день, когда ты можешь делать что угодно полезное для компании. Также MacPaw инвестировала в публичный бренд, я увидел в этом перспективу, прошел курсы публичных выступлений и поехал с докладом о трендовом HashiCorp Vault на Highload Fwdays развивать публичный бренд компании.
Это был первый опыт публичных выступлений, который прошел с позиции поделиться знаниями, рассказать сообществу о полезных наработках и сделать вклад в индустрию.
На этом этапе я понял, что важно быть очень хорошим и технически подкованным инженером, но этого недостаточно.
Если сидеть весь день в наушниках и пилить функционал, то медаль получит лид, менеджер — все, кроме тебя.
Очень важно проводить демо, быть публичным, рассказывать о победах и продавать свои решения не только внутри компании, но и во внешнем мире.
Как я получил повышение
В AnchorFree я пришел на собеседование, потому что увидел на Kyiv Kubernetes Community отличный доклад Ярослава Молочко по Prometheus от DevOps Team Lead. Компания строила топ-1 VPN в мире, в каждом компоненте был highload и я попал на активную фазу упаковки сервиса в Docker и автоматического масштабирования.
У нас были knowledge sharing с офисом в Калифорнии, мы ездили туда обмениваться опытом и заряжаться успешным успехом. Рост компании выглядел нереально круто, пользователей становилось все больше и в пиковый момент их было около 760 миллионов — каждый день мы выдерживали больше 12 миллионов DAU.
Мне предстояло перевезти высоконагруженный биллинг из self-hosted датацентра в Сан-Диего в AWS. Это был личный проект нашего VP of Engineering, поэтому после завершения миграции без даунтайма я получил лычки и повышение. Вместе с напарником мы делали дизайн, архитектуру, MVP, первую итерацию, паковали и перевозили микросервисы, двигали огромную базу данных. Настраивали CDN, лендинги, ускоряли все, что можно, и развивали существующую систему.
Закатывать рукава и достигать результата
В процессе миграции я спроектировал решение коммуникации service-to-service на основе Envoy (service bridge от CNCF), оно отлично отработало в компании, и в результате появился доклад на DevOpsStage. Инженер очень быстро растет вместе с компанией, если компания находится на этапе активного роста.
После биллинга я занимался запуском двух новых направлений, начиная от дизайна и заканчивая реализацией, после чего компанию поглотила Pango, а потом — Aura.
Секрет успеха №3: брать на себя больше ответственности, показывать максимальное качество, закатывать рукава и достигать результата.
И еще: стать world-class-инженером можно только делая world-class-задачи.
Когда нужна команда
В какой-то момент пришло осознание, что мои 24 часа в сутки не масштабируются.
Я пришел к тому, что могу работать по 16-18 часов в сутки, но это — максимум.
Я никак не мог вместить все технические наработки в рабочий день, мне нужна была команда. Так больше не могло продолжаться, и решение было очевидным: для увеличения delivery и результатов нужно пробовать собеседоваться на позицию DevOps Team Lead.
Так и получилось в SQUAD — я пришел в команду, построил процессы, разобрался в технической реализации и повел за собой отличных ребят. У нас было несколько приоритетов: ускорение разработки (об этом можно почитать в материале на AIN.UA), усиление безопасности, миграция проектов и внедрение лучших технологических практик для построения конкурентного преимущества.
Производительность команды выросла, уровень технических решений взлетел, команда стала счастлива, и эти достижения помогли дорасти до Head of Infrastructure.
Это был очень сложный путь, но я уверен — его сможет пройти тот DevOps-инженер, который будет качественно подходить к работе, делать больше, чем нужно и показывать настоящие результаты. Дальше — больше!
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: