DevOpsConf 2024 в Сколково: Будущее DevOps и MLOps на горизонте.

Этот год стал настоящим переломным моментом для DevOps-сообщества. Kubernetes уже не единственный герой дня, уступая место новым звездам: Platform Engineering, Безопасности, и самое главное, сфере Machine Learning. Было проведено несколько воркшопов, связанных с применением локальных LLM моделей, с некоторыми DevOps практиками и с проработкой soft-скилов внутри команд. Также нашлось и место для Fail-митапа, на котором множество спикеров из разных компаний рассказывали о своих крупных фейлах. Однако об этом говорить неприятно, поэтому все, что было на этом докладе, останется навсегда в зале 🤫

Мой доклад нашел место как раз в новой секции Big Data и Data Engineering и назывался “Как создать ML-платформу по выводу 💯 моделей в неделю”.
Я долго думал над этим названием, над тем, стоит ли делать его таким броским, однако все же остановился на таком. Как и упоминалось в предыдущем посте, этот доклад был некоторым продолжением с предыдущей конференции.

Вся структура доклада была построена на разграничении обязанностей между командами разработки и MLOps инженерами. Она питалась вопросом: А чем должен заниматься MLOps инженер? Первый блок был посвящен тому, как мы научились на лету распределять ресурсы для Jupyter ноутбуков. Как предоставить ноутбуки пользователям, основываясь на том, что MLOps инженеры должны прежде всего предоставлять среду для разработки, а уже опытные DS и DE будут ее использовать так, как им это необходимо, не зная всю инфраструктуру в целом. Второй блок представлял собой улучшенный подход в обучении и выкладке моделей по сравнению с предыдущим вариантом с конференции из прошлого поста.

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

Как только появится запись доклада на YouTube, я выложу ее в этой группе

#it_conferences

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

Набираем 10 🔥 под этим постом и я выкладываю рассуждения на тему NextOps в ближайшее время.

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

В первом посте мы окунемся в историю DevOps, попытаемся понять, с чего всё началось и как развивалась эта методология до сегодняшнего дня. В последующем материале я сфокусируюсь на анализе текущего состояния DevOps и попробую предугадать его будущее.

#interesting

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

С одной стороны, современные инструменты позволяют автоматизировать процессы и улучшить взаимосвязь между этапами создания продукта. С другой стороны, эти инструменты не всегда способны полностью разрешить проблемы в коммуникации между командами. Например, продукты типа Azure DevOps обещают решение всех проблем "из коробки". Но стоит ли полагаться на них полностью?

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

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

Оглядываясь на обширное исследование от компании Dora (DevOps Research and Assessment), которая была основана родоначальниками DevOps движения, можно найти множество примеров успешного применения методологии. Их анализ показывает, что успешное применение DevOps требует комплексного подхода, который включает не только технические аспекты, но и культурные изменения внутри организаций. Исследования Dora выделили ключевые аспекты, которые коррелируют с успешным внедрением DevOps-практик и позитивным влиянием на производительность организации.

Анализ Схемы DORA:
1. Технические Возможности: здесь рассматриваются элементы, такие как поддержание кода, непрерывная интеграция, автоматизация развертывания и прочие, которые создают основу для гибкой и эффективной инфраструктуры.
2. Доставка ПО и Производительность: эти показатели, включая время изменения, частоту развертывания, процент неудачных изменений и время восстановления после сбоев, напрямую связаны с качеством и эффективностью технических процессов.
3. Организационная Производительность: различают коммерческую и некоммерческую производительность, подчеркивая, что DevOps влияет на результаты независимо от целей организации.
4. Благополучие: важным элементом схемы является благополучие команд, включая снижение стресса при развертывании, уменьшение объема переделок и предотвращение выгорания. Это подчеркивает важность DevOps не только для процессов, но и для создания здоровой рабочей среды.

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

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

В следующем посте по этой теме я рассмотрю текущее состояние DevOps, обсудим тренды и новые роли в этой области 🔥

А с тем, чем для вас является DevOps поделитесь в комментариях под этим постом!

DevOps, MLOps и новые “модные” слова 🔥

Продолжая тему предыдущих постов, далее мы поговорим о современных трендах DevOps. Но сперва, давайте разберемся, в чем отличия новых популярных направлений.

Знаете ли вы разницу между DevOps и, например, MLOps, DataOps, Chaos Engineer? Если нет, то этот пост для вас.

На первый взгляд, все они кажутся разделенными направлениями, однако координальных отличий от типичного DevOps на самом деле нет. Это все те же специалисты, но с некоторыми новыми инструментами и новыми практиками.
MLOps, например, сосредоточен на моделях машинного обучения и данных. DataOps улучшает циклы обработки данных, а Chaos Engineer тестирует устойчивость систем к сбоям.
По сути своей, здесь изменяются лишь артефакты и упор на какую-то определенную часть цикла разработки.

Схема Патрика Дебуя (одного из родоначальников методологии DevOps) наглядно показывает этот момент. По оси X мы видим увеличение доли работы связанной с разработкой в пользу выкладки, а ось Y отражает, насколько "хайповым" является термин 😎

С одной стороны, такое разнообразие возникло из-за нечеткого определения DevOps. Однако с другой же, новые направления — не просто модные слова. Они отражают расширение DevOps в новые области, где традиционные методы уже не так эффективны.

А как вы думаете, какие направления станут ключевыми в ближайшем будущем? Делитесь в комментариях!

Трансформация DevOps: Путь к Platform Engineering и Аналитике 🚀

В мире DevOps наступает эра Platform Engineering — это не просто тренд, это эволюция методологии. DevOps-команды, превращаются в архитекторов платформ 👷‍♂️🏗, обеспечивая фундамент для своих разработчиков. Это направление получило широкое признание и стало темой обсуждения на многих конференциях, включая DevOps Enterprise Summit и DevOps Conf 🎤📈

Однако как упоминалось в предыдущих постах, прогресс не останавливается лишь на создании инструментов и платформ. Сейчас происходит также сдвиг фокуса с технических аспектов на процессы. Это еще раз подчеркивает, что суть DevOps не только в инструментах, но и в грамотно выстроенных внутренних процессах и командных взаимодействиях 👫🔄
Общение с организаторами и спикерами конференций, а также анализ докладов подтверждают эту тенденцию.

По диаграмме видно, что Platform Engineering набирает обороты. Кроме того очень сильно развивается область машинного обучения: об этом свидетельствуют такие тренды, как AI/MLOps, Data Mesh, Data Observability 🤖🔍
Это говорит о постоянной проработке новых направлений, в то время как традиционный “general” DevOps уступает место более специализированным дисциплинам.

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

А какие тренды DevOps заметили вы и как они влияют на вашу работу? 🤔💬

Специализация в DevOps: каждому своё ✂️🔧

Для многих людей DevOps инженеры - это специалисты, которые знают все и зарабатывают по "400к в секунду". Однако отвечать за все достаточно сложно. Более того становится непонятно, чем тогда должен заниматься специалист.

Растущая специализация ролей привносит порядок в хаос "знания всего". Ранее мы уже обсуждали новые направления, такие как MLOps, DataOps, и Chaos Engineering, которые показали нам разделение в мире DevOps.

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

🤖 MLOps инженеры углубляются в мир моделей и алгоритмов, облегчая работу Data Scientists и повышая качество и скорость разработки моделей ИИ в продакшене.

🔢 DataOps специалисты ставят своей целью оптимизацию потоков данных, что является краеугольным камнем в эпоху Big Data.

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

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

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

А как вы думаете, как это может повлять на создание продукта? Действительно ли качество проработки отдельных элементов всего процесса перекрывает траты на дополнительных специалистов? 📊🤔

#interesting

MLOps и преосмысление артефактов в эру BIG Data 🔥

В последнее время я активно погружаюсь в изучение и разработку MLOps систем, и хочу поделиться одной интересной идеей, которая может кардинально изменить ваш подход к процессу развертывания моделей машинного обучения 🚀

Отличие MLOps от традиционного DevOps заключается в том, что в центре внимания оказывается не просто код, а модель — многокомпонентный артефакт, требующий особого обращения. В MLOps главный артефакт — это уже не образ, а сама модель.
Это заставляет нас пересмотреть традиционные подходы к сборке и доставке 📦

Специфика работы с моделями машинного обучения позволяет нам экспериментировать не только с самими моделями, но и с методами их доставки. Один из таких экспериментов, который мы недавно провели с нашей командой, — использование tar.gz архивов для хранения всего необходимого окружения, взамен стандартным Docker образам.
И как оказалось это позволяет упростить и ускорить процесс доставки модели в продакшен.

Подход заключается в следующем:
1. Создание виртуального окружения, которое содержит все зависимости модели.
2. Упаковка этого окружения в tar.gz архив.
3. Загрузка архива в хранилище типа S3, откуда он может быть легко доставлен в любую точку.

Этот подход имеет ряд преимуществ перед традиционным использованием Docker-образов:
- Скорость: Сборка и загрузка архива занимает меньше времени, чем создание и распространение больших Docker-образов.
- Гибкость: Легкость изменения и обновления окружения без необходимости пересборки всего образа.
- Дебаг: Имея архив с окружением, при проблемах запуска модели, вы можете легко его скачать, например, в JupyterLab, создать на нем новое окружение и сразу же протестировать модель.

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

Поделитесь своим опытом и мыслями по этому поводу, ведь каждый новый подход может стать ключом к более эффективным решениям в будущем! 💬

#interesting

Привет всем!

Сегодня я в Москве на ML Meetup от команды VK Predict. Вот что нас ждет:

- 7 докладов на актуальные темы ML
- 2 доклада про MLOps
- целых 4 доклада о AutoML и автоматизации обучения моделей

Я выступаю вместе с коллегой с докладом "Переобучение моделей в проде с использованием AutoML". Подготовка идет полным ходом! Как только появится ссылка на онлайн-трансляцию, сразу поделюсь. Если трансляцию не найду, будет запись.

Следите за новостями!

Из новостей

Трансляции не было, ровно как и не будет записи 🥲
О том, что эта закрытая "вечеринка", я узнал только уже на месте. Однако 100% будет статья на хабре про доклад, с которым выступали. Так что ждем!

А так, классный митап. Послушал доклады про AutoML. Как оказалось понимание об этом у всех разное. У кого-то это автоматизация только лишь связки DS-DE, у кого-то переобучение моделей в целом.
Также посмотрел общие подходы в построению платформ по машинному обучению. В целом у всех сейчас используются плюс минус одни и те же стандарты.

🎯 Как эффективно искать работу: Важные аспекты, кроме зарплаты 🎯

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

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

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

2. Рабочий график и баланс 🕰️
Узнайте о рабочем графике, возможности гибкого времени и удаленке. У многих, особенно, кто совмещает работу и учебу, бывают периоды, когда нужно в течении рабочего дня куда-то срочно отъехать на несколько часов. Достаточно сложно одновременно находиться и в офисе и на экзамене, поэтому гибкий режим работы с удаленкой или гибридом, дают неплохие бонусы.

4. Команда и менеджмент 🤝
Исследуйте, с кем вам предстоит работать. Хорошая команда и поддерживающий менеджмент играют ключевую роль в вашей мотивации, которая дает возможность двигаться вперед и чувствовать удовлетворение от своего дела.

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

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

7. Корпоративная культура 🌟
Узнайте про корпоративы. Частые поездки на природу разрежает напряжение на работе и помогает сблизиться с коллегами.

8. Интерес и вызовы 🧠
Убедитесь, что работа вам интересна и представляет собой вызов. Пункт связан с первым. Интерес поможет вам оставаться мотивированными и с энтузиазмом приступать к новым задачам.

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

Помните, что выбор работы – это важный шаг, который влияет на ваше будущее и дает возможность роста и продвижения. Обдумывайте все аспекты и принимайте взвешенные решения. Удачи в поиске работы! 💼

Важность нетворкинга в вашей жизни 🌐

Во время отпуска, я решил почитать достаточно известную книгу Кейта Феррацци "Никогда не ешьте в одиночку" 📚, которая произвела на меня большое впечатление.
В последний день перед рабочей неделей, я посетил мероприятие Selectel DayOff 2024, проходившее 14 июля. И что меня удивило и порадовало – идеи, изложенные в недавней новой для меня книге, нашли своё отражение в одном из докладов трека "Про карьеру" на этом событии: “Человеку нужен человек. Как развивать карьеру с помощью нетворкинга” 🤝.

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

1. Проактивность. Важно быть проактивным в установлении контактов, инициируя встречи и знакомства самостоятельно. Это ключ к успешному нетворкингу, так как ожидание, что кто-то сам подойдёт, редко приносит результаты.
2. Искренность и взаимопомощь. Успешный нетворкинг строится на искренних и взаимовыгодных отношениях. Проявление подлинного интереса к людям и готовность помогать им являются основой для долгосрочных связей.
3. Долгосрочные отношения. Быстрые и поверхностные знакомства редко приводят к значительным результатам. Важно строить долгосрочные отношения, основанные на доверии и уважении, и поддерживать уже существующие контакты.
4. Взаимная выгода. Наверное, самый важный и одновременно не сразу понятный пункт, который лучше изучить, прочитав книгу. Нетворкинг должен приносить пользу обеим сторонам. Успешные отношения строятся на принципе взаимной выгоды, где обе стороны помогают друг другу достигать своих целей.
Здесь стоит исходить из идеи “Чем я могу помочь тебе?”, нежели, “Что ты можешь для меня сделать?”.
Простыми словами, при одинаковой данной моральной установке с собеседником, вы сможете улучшать друг друга в разных аспектах, не упираясь в барьеры по типу “Я тебе помог, теперь твоя очередь”.

Посетив мероприятие и вспомнив идеи из книги, я еще раз убедился, что нетворкинг – это мощный инструмент для развития карьеры и личностного роста 🚀

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

#it_conferences

🛠️ Мануал по Agile: как количество людей влияет на производительность

Многие слышали о методологии Agile и имеют общее представление о том, что это такое. Если открыть учебники или статьи на Хабре про Scrum, часто можно увидеть, что оптимальный размер команды составляет около 8 человек. Но что происходит, если команда начинает расти?

💻 Работая в IT, я прошел через множество команд и различные этапы их развития. И хочу поделиться интересным наблюдением — как рост команды влияет на производительность.

Когда я начинал, мне посчастливилось работать в небольшой команде из 3 DevOps-инженеров. У нас было много преимуществ: мы работали быстро, решения принимались мгновенно, и каждый знал, кто за что отвечает.
Единственный минус — не всегда хватало рабочей силы для выполнения всех задач.

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

⚠️ Однако, в какой-то момент мы решили еще больше расширить команду, чтобы охватить еще больший объем задач. И это стало нашей ошибкой. Мы столкнулись с неожиданными проблемами: количество встреч резко возросло, многие члены команды перестали понимать, кто чем занимается, и эффективность снизилась. Появилось множество ненужных встреч и синков. Время, затрачиваемое на обсуждения, увеличилось — на примере дейликов большее количество человек стало тратить больше времени на высказывания и обсуждения.

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

🤔 Какие же выводы можно сделать из этой истории?

1. Коммуникационные барьеры. В малых командах информация передается быстрее, решения принимаются оперативно. С увеличением числа участников растет количество коммуникационных каналов, что замедляет процесс согласования.

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

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

4. Принцип Брукса. Фредерик Брукс писал в своей книге "Мифический человеко-месяц", что добавление новых сотрудников к запаздывающему проекту делает его еще более запаздывающим. Этот принцип актуален и сегодня, особенно в контексте чрезмерного расширения команды.

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

А что вы думаете на этот счет? Какие меры принимались у вас в командах для повышения производительности?

💊 JupyterHub на стероидах: реализация KubeFlow-фич без масштабных интеграций

Долго думал над названием, так как было много интересных вариантов. Но если коротко — вчера вышла моя новая статья на Хабре, основанная на выступлении на DevOps Conf 2024.

В статье я рассказываю, как легко настроить динамическую аллокацию ресурсов Kubernetes в JupyterHub, а также внедрить полезные функции, такие как права доступа на основе групповой политики. Кроме того, вы найдете советы по сборке Jupyter/JupyterLab образов.

В конце статьи также есть ссылка на GitHub репозиторий, который можно запустить, следуя инструкции в readme.

Читать статью