Как Олег Миколайченко развивает DevOps в Украине

  • 23 июля, 11:05
  • 4046
  • 0

Олег Миколайченко сформировал первую концепцию DevOps методологии в 12 пунктах “The DevOps Factors”, пишет статьи на DOU.UA, MC.TODAY и HIGHLOAD.TODAY, ведет сообщество Kyiv DevOps Community и организует DevOps Days Kyiv. Мы поговорили с Олегом, чтобы обсудить развитие DevOps культуры, сложности в управлении распределенной масштабируемой инфраструктурой и DevOps командами. 



Олег, ты прошел многое на пути Head of Infrastructure. Что было самым сложным на этом пути? 

Секрет успеха в старании и желании знать больше, приносить больше ценности и решать более сложные задачи. Это непрерывный продолжительный процесс. Постепенно уровень задач и ответственности повышается, технологическая сложность увеличивается - происходит рост.

Мне удалось поработать в отличных компаниях - Betlab, Unicheck, MacPaw, Aura, SQUAD - в каждой из них я встречал разные задачи и уникальные сложности в реализации. В конце-концов, после запуска нескольких продуктов с нуля я понял, что моей производительности не хватает, и она не масштабируется. Да, я мог работать по 16 часов в сутки, но это был максимум. 

Так я пришел к тому, что для реализации моих наработок, масштабируемости производительности и достижения более сложных бизнес приоритетов мне нужна команда. SQUAD (ex Ring Ukraine) пригласил меня как ведущего специалиста в области DevOps, и я чувствую большую поддержку внутри своей команды, и вижу огромные вызовы со стороны бизнеса. Я на правильном месте.  

 Расскажи о технологических вызовах в SQUAD. Компанию недавно поглотил Amazon, что изменилось с точки зрения технологий? 

Наша задача - ускорить процесс разработки в 10 раз. В стеке разработки платформы мы делаем акцент на Machine Learning пайплайнах, поэтому основная оптимизация касается именно MLOps. Другими словами, мы переосмысливаем концепцию работы с ML, меняем процессы и внедряем новые технологии.

Самое удачное решение для этого - KubeFlow. Представьте, что вы можете с легкостью строить пайплайны над абстракцией Kubernetes, передавать артефакты между этапами, гранулированное управлять доступом и это ваше, self-hosted решение. Масштабируемость по-умолчанию добавляет конкурентного преимущества, мы хотим распараллелить процесс обучения и получать результат в разы быстрее. 

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

Решение, которое я предлагаю для автоскейлинга - KEDA. По своей сути, KEDA - это event-driven автоскейлинг с множеством вариантов выбора источника для масштабирования. Мониторинг мы делаем на основе OpenTelemetry - самого трендового и эффективного, универсального формата для реализации метрик от Google. 

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

Я считаю, что knowledge sharing - это один из самых важных аспектов развития инженера. Делиться знаниями - это, вероятно, лучшее что может сделать DevOps для своей команды, компании и специализации. Подход “сформировать типичный bus-factor”, или "завязать все доступы и знания на себе" работает отвратительно, поэтому я стараюсь максимально поддерживать ребят, которые хотят делиться знаниями. Именно поэтому я присоединился к программному комитету DevOpsStage (комитет организует конференцию, подтверждает доклады, дает обратную связь по презентациям, утверждает расписание и несут ответственность за конференцию), и в этом году DevOps Days Kyiv 2021, собрал лучших докладчиков в Украине из локальных сообществ. 

Первый большой доклад на Highload Fwdays 2017 - актуальный и сейчас


Первый публичный доклад я сделал на Highload Fwdays в 2017 году, и я как сейчас помню - Всеволод Поляков в программном комитете конференции, я - с огромным желанием, несколько итераций правок презентации, подготовка - и, получилось! Для меня было огромным удивлением, что даже сейчас (через 5 лет) информация осталась частично актуальна, доклад смотрят, и просят “больше деталей”. 

После этого делал доклады в Kyiv DevOps Community, ездил по приглашению в Одессу помогать делать Provectus DevOps митап. В результате, отлично подготовился и рассказал о самой полезной наработке в компании AnchorFree для service-to-service коммуникации - Envoy as TCP proxy на DevOpsStage 2019. Больше всего люблю вспоминать о этом докладе - он это было прорывное решения для компании, мы тогда поменяли все устаревшие HAproxy и стали лидерами рынка. 

 В 2021 году, в период карантина состоялся самый большой IT челлендж в Европе - DEV Challenge XVII, и там впервые появилась DevOps номинация. Почему ее не было раньше?  

Какое классное событие! Действительно, DEV Challenge XVII появился неожиданно и воодушевляюще на рынке DevOps  специализации: ведь это первая номинация "DevOps" на насколько большом хакатоне! 

Я думаю, что раньше этого небыло по нескольким причинам. В первую очередь, почти никто не понимал “что может сделать DevOps Engineer” на хакатоне, и какое ему дать задание, чтобы оценить результат. Во вторую очередь - это размытые граници специальности и ниши в прошлом. Пару лет назад мы наблюдали слишком большое распыление названий вакансий: SysAdmin/Infrastructure Engineer/Cloud Engineer/Platform Engineer/etc. На данный момент уже стало понятно, что DevOps очень плотно вошел в IT рынок, и можно пробовать агрегировать аудиторию и сообщества. 

Судьи DEV Challenge XVII: Олег Миколайченко и Вова Цап 

Это очень большая победа, потому что DEV Challenge - это самое больше европейское IT-соревнования, и раньше там были только номинации на бекенд, фронтенд, дизайн. А теперь есть номинация DevOps! Конечно, я поддержал такое событие всем, чем мог. Мне написала Евгения Беспалова, организатор DEV Challenge и предложила судить конкурс. Я подумал, что меня кто-то посоветовал, но оказалось, что помогла публичность и общий вклад в DevOps отрасль. Конечно, принял предложение судить DevOps номинацию. 

Соревнование состояло из нескольких этапов:

  1.  квалификация (несколько вопросов разной сложности - понять глубину и создать самую широкую воронку)
  2. онлайн раунд (сложное техническое задание)
  3. финал (продолжение технического задания)

Результаты нас удивили своим уровнем выполнения, и принесли свой вклад в open-source мир. 

 Регулярно выходят твои статьи на самых уважаемых IT ресурсах в Украине. В начале года тебя опубликовал The New Stack, раскажи об этом.  

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


Публикация на The New Stack 


Основываясь на своем опыте я увидел, что ко мне обращается большое количество стартапов, которым нужна качественная масштабируемая инфраструктура, но нет денег на дорогого DevOps инженера. Я аккумулировал свой опыт, и написал статью How to Create Scalable Infrastructure for a Startup with Only $20 in Your Pocket - она позволит команде программистов и стартаперов сделать все правильно и учесть все ошибки еще на старте. 

После успешной публикации на The New Stack эту статью перепечатали в популярном AIN.UA, SENIOR.UA и еще в нескольких отраслевых изданиях. 

Расскажи о The DevOps Factors. Многие используют эти правила в дополнение к 12 Factor-level app, так ли это задумывалось? 

The DevOps Factors - это переосмысленная методология DevOps в правилах, основанная исключительно на практическом опыте. Команда или организация может пройтись по чек листу из правил, поправить ошибки и декларировать использование DevOps у себя. Инженер может быть уверен что он действует правильно, если он нашел подтверждение в DevOps факторах. 

Я часто задавался вопросом, почему у Agile, Scrum, Kanban есть свои манифесты или наборы правил которые определяют методологию, а у DevOps - нет? В 2019 мы собрались с ребятами из сообщества, и определили DevOps факторы. Так появился The DevOps Factors. Если его использовать вместе с практиками из 12 Factor-level app, то уровень разработки вырастет еще сильнее. 


0 комментариев
Сортировка:
Добавить комментарий

IT Новости

Смотреть все