🤖 Что делает инженер MLOps 💻

📆 И как может выглядеть неделя

Раздел 1: Введение. Кто я и зачем этот пост в блоге?

Привет! Меня зовут Микико, и (на момент написания статьи) я возглавляю MLOps в Featureform.

До присоединения к Featureform я работал:

• Старший инженер MLOps в Mailchimp (Intuit)
• Специалист по данным в Teladoc
• Аналитик данных в Sunrun & WalkMe
• Гибридный аналитик данных / специалист по данным в Autodesk

И множество ролей в различных стартапах и малых и средних предприятиях.

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

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

И кто может обвинить их?!

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

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

Раздел 2: Кто такой инженер MLOps?

В этом посте Определение MLOps как можно проще я определил MLOps (или операции машинного обучения) следующим образом:

MLOps — это практика масштабируемого и надежного производства артефактов машинного обучения, где «артефакты» могут включать проекты, приложения, службы и конвейеры.

А потом отметил:

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

Команда MLOps — это группа лиц, занимающихся проектированием, разработкой и обслуживанием системы (или платформы) MLOps.

Как насчет инженера MLOps?

Раздел 3: Каковы их обязанности?

Основываясь на определениях, которые я дал, следует, что я определяю инженера MLOps как:

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

В более крупных и зрелых компаниях это НЕ сами разработчики моделей или производители моделей (однако всегда есть исключения).

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

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

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

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

В этом посте мы будем говорить о роли MLOps, как если бы это был более специализированный персонаж.

Большая часть того, что я отметил, по-прежнему применимо к гибридным ролям, но предполагается, что некоторые дополнительные задачи или обязанности не описаны ниже.

Раздел 4: Подробное распределение обязанностей

Общие ковши

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

• Разработка — создание, оптимизация, обслуживание и отказ от поддержки компонентов инфраструктуры, которые поддерживают разработку модели, производство и развертывание.
• Эксплуатация — обеспечение принятия и включения инструментов и процессов, предназначенных для облегчения работы групп специалистов по обработке и анализу данных, включая разблокировку проектов по мере необходимости или предложение поддержки в тех областях, где инструменты и средства автоматизации еще не созданы.

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

Хотя цель состоит в том, чтобы свести к минимуму операционную работу за счет автоматизации, на некоторых должностях соотношение работы «Разработка» и «Эксплуатация» составляет примерно 30 % против 70 % (особенно в командах с низким автоматизации), тогда как в других командах этот показатель был ближе к 60% против 40%.

Разбивка сегментов MLOps Dev + Ops

Давайте еще больше разберем обязанности и категории работы.

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

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

Ведро разработчиков

Некоторые примеры того, как выполняются эти действия или как они возникают на уровне платформы или инструмента:

• ➡️ Встреча с специалистами по науке о данных и разработке данных, чтобы выяснить, есть ли пробелы в нашем стеке MLOps, которые необходимо устранить с помощью новых инструментов, будь то с открытым исходным кодом или на базе облачных поставщиков. Это запускает процесс сбора требований, написания технической спецификации, создания POC, а затем тестирования и оценки инструмента перед выпуском для использования учеными данных.
• ➡️ Определение приоритетов и внедрение исправлений ошибок для наших текущих процессов и инструментов. Возможно, мы не закрепили конкретную версию для зависимости, и теперь это вызывает хаос у специалистов по данным. Возможно, мы не проверяли, есть ли у наших сред разработки проблемы с поддержкой графического процессора. Может быть, исходная зависимость в действительно популярной библиотеке данных была изменена, о ней не сообщили, и теперь у многих людей в Интернете возникают проблемы с использованием последней версии, и нам нужно в краткосрочной перспективе дать команде специалистов по обработке данных рекомендации.
• ➡️ Наконец-то добравшись до тех билетов, которые мы припарковали, потому что в то время они не были приоритетными, либо потому, что они были хорошими функциями, либо потому, что они не блокировали основную разработку. Возможно, специалистам по данным нужен другой инструмент для создания документации. Возможно, появились новые тестовые библиотеки, которые выглядели интересно и которые мы могли бы внедрить в наш процесс упаковки.

Ведро операций

Конкретные примеры того, как инженер MLOps может обеспечить поддержку на уровне рабочего процесса и процессов:

• ➡️ Консультации по проектам встроенных систем. Здесь команда MLOps выступает в качестве внутреннего консультанта по решениям, помогая специалистам по обработке и анализу данных выбрать правильный шаблон или архитектуру для своего пакета модели или конвейера.

Это также может включать (на примере GCP):

• Рефакторинг кода;
• Помощь в настройке GCP через Terraform;
• Помогая им разрабатывать тесты;
• Помогать им преодолевать любые трудности с Docker, Airflow, BigQuery и писать любые сценарии оболочки;
• Помогая им добавлять необходимые учетные данные в свои проекты.

Мы также можем помочь им ответить на такие вопросы, как

• «Это сверхсложный проект? Нужен ли ему другой инструмент, чем мы поддерживаем, например, Spark или Dataflow?»

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

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

• ➡️ Поддержка по вызову — в командах, которые, как правило, больше «ориентированы на обслуживание» (и по-прежнему отвечают за работу «разработчика»), получение сообщений об ошибках и проблемах может быть очень разрушительным и приводит к рекурсивному переключению контекста, прыжкам из одного огня. другому.

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

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

Раздел 5: Распределение обязанностей в течение недели

Как эти обязанности распределяются изо дня в день или из недели в неделю?

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

• Их общее рабочее время (40 часов+?)
• Их стаж (т. е. они управляют другими инженерами, возглавляют инициативы, наставничество и т. д.?)
• Командная культура (множество совещаний или много времени на раздумья?)
• Дополнительные обязанности помимо их роли инженера (присутствие на панелях по найму, хакатоны, участие в техническом блоге и т. д.)
• Зрелость цепочки инструментов и рабочих процессов.

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

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

Персона 1: старший инженер MLOps в официальной компании

Соответствующие факторы

Типы встреч

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

Повторяющиеся встречи:

• Встречи команды: обсуждение возникших проблем, вопросы, которые могут повлиять на нашу текущую дорожную карту, обновление времени ООО и обновление колоды хвастовства.
• 1–1: с менеджером и товарищами по команде — это очень важно, когда многие из нас находятся удаленно. И когда к команде присоединяются новые участники, я стараюсь, чтобы первые пару месяцев длились не менее 1 часа в неделю.
• Организационные собрания: новости мэрии, важные объявления компании.

Переменная или специальная:

• Индивидуальные проверки проекта: Когда проект находится в стадии разработки, мы обычно устраиваем 30-минутную проверку два раза в неделю (включая проект стажировки).
• Корпоративные мероприятия, такие как хакатоны и т. д.

Разбивка по времени

В расписании не изображено

• Любые специальные встречи или последующие действия;
• Время саморазвития;
• Специальное планирование: ежеквартальное планирование, ежемесячные отчеты;
• Исправление ошибок и время исправления;
• Ротации по вызову;
• Время на дорогу для личных встреч (как бы редко они ни случались).

Персона 2: Data + ML Engineer (от частичной до полной) при запуске

Соответствующие факторы

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

Основные различия между графиком, изображенным выше, и работой в качестве «специалиста по данным и машинному обучению» в стартапе, который создает свою платформу машинного обучения при создании основного продукта:

• Замените большинство совещаний на свободное время разработчиков — небольшая команда, поэтому все, что вам нужно сказать или попросить, вы сделаете автоматически;
• Меньше устаревшего кода или технического долга, потому что создание с нуля — меньше межфункционального времени;
• Никаких организационных собраний или обновлений;
• Регистрация в основном осуществляется через Интернет;
• Код отправляется как можно скорее;
• Вы тратите столько же времени на разговоры о продукте и потенциальных потоках монетизации, сколько и пишете код.

Разбивка по времени

Раздел 6: Закрытие

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

Прежде чем закончить, я хочу подчеркнуть несколько моментов:

• Заголовки. Заголовки — штука привередливая. Они предназначены для использования в качестве полезной эвристики, чтобы, когда кто-то спрашивает, что вы делаете на званом обеде, вы могли кратко перечислить множество обязанностей, задач и способов, которыми вы обеспечиваете ценность своей роли. Но, как и все эвристики, названия несовершенны. Они должны быть полезными, а не точными. Имейте это в виду, особенно когда вы встречаете инженеров MLOps со званиями и инженеров MLOps без.
• Внедрение. Зрелость и размер вашей организации и компании будут определять обширность и влияние ваших обязанностей. Специалисты по данным не являются монолитом, равно как и инженеры MLOps.
• Эволюция. Как и все роли, обязанности и роли MLOps будут продолжать меняться по мере изменения ландшафта.

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

Раздел 7: Основные ссылки и литература

Мои предыдущие работы о #MLOPsCareers

• 👩🏻‍💻 🔥Горячие моменты🔥 Мики на интервью MLE: Типы ролей и подготовка к собеседованию (Часть 1/2)
• 👩🏻‍💻 🔥Горячие моменты🔥 Мики на интервью MLE: лучшие советы и ресурсы (часть 2/2)
• Исследователям данных нужны MLOps; Почему я присоединился к Featureform

Соответствующие доклады и статьи о #MLOPsInAction

• Выступление Эмили Кертин в Data Council — Бывшая коллега рассказывает о потрясающей работе, которую она проделала в Mailchimp!
• Операции машинного обучения (MLOps): обзор, определение и архитектура — документ, в котором определяются различные компоненты системы MLOps и представлены некоторые взгляды на то, как она выглядит в настоящее время в отрасли.
• Внедрение машинного обучения: исследование с интервью — исследование с интервью, которое также включает интересные цитируемые комментарии, сделанные практиками из ряда различных компаний и отраслей.
• [Является ли инженер MLOps вещью? Мы спросили об этом 6 инженеров.

Узнайте больше о #MLOps With Me

• Обучение MLOps (постепенно) бесплатно с помощью сообщений в блогах и подкастов | by Mikiko Bazeley — я перечисляю некоторые из лучших подкастов, сообщений в блогах и твитов для новых и начинающих практиков MLOps.
• Что такое MLOps Series — я пытаюсь описать важные части MLOps для новых и начинающих практиков.
• Представляем (часть 1)
• Как можно проще определить MLOps (часть 2)
• Почему ML Ops имеет значение (часть 3)
• Части 4-6 скоро будут опубликованы!

Английская сторона #MLOPsCareers

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

• Стандартные архетипы | StaffEng
• Каждая общественная инженерная карьерная лестница

Раздел 8: Сноски

Предостережения о том, что такое MLOps Engineer

• В социальных сетях, таких как LinkedIn и Youtube, существует множество дискуссий о том, реальна ли роль «инженера MLOps» и насколько полезно иметь специализированную роль в компании, а также о том, действительно ли инженеры DevOps или специалисты по данным должны выполнять эту функцию. Большинство этих дискуссий (и флеймовых войн), как правило, игнорируют нюансы размера, зрелости и возраста компании, т. е. более крупные и старые компании, как правило, имеют более специализированные роли, а более мелкие компании — более общие роли.
• Существует также навязчивая фиксация на названиях. Кто-то инженер MLOps? ML-инженер? Специалист по данным с полным стеком? Моя цель не в том, чтобы погрузиться в кишащее аллигаторами болото таких дискуссий.
• Мои выводы основаны на моем конкретном опыте работы, обсуждениях, которые у меня были с рекрутерами и менеджерами по найму, объявлениях о вакансиях и опубликованных опросах.

Отношение инженера к «чертовой работе» или «ручному дерьму»

Я разговаривал со многими инженерами, которые считают, что шаблон встроенного инженера MLOps является анти-шаблоном (как и шаблон поддержки по вызову). Убеждение таково: «То, что можно автоматизировать, должно быть обязательно автоматизировано. А если это делается вручную, то это потому, что автоматика плохая». Теоретически я согласен с их позицией. На практике разные команды находятся на разных уровнях зрелости автоматизации. Стремитесь к автоматизации, но ожидайте некоторого уровня ручной поддержки, по крайней мере, до тех пор, пока автоматизация не будет встроена.

Дальнейшее объяснение службы поддержки MLOps по вызову

• Дежурство — это практика, при которой инженерам назначают быть доступными в течение определенного периода времени для устранения любых возникающих блокировщиков (обычно в производственной среде и в критически важных системах).
• Как правило, они являются первой линией защиты для службы поддержки. Они также обеспечивают первоначальную сортировку, чтобы понять, связана ли проблема с PEBCAK (проблема существует между стулом и клавиатурой) или из-за реальной ошибки, которую необходимо зарегистрировать и исправить в базовом инструменте и платформе.
• Инженеры MLOps могут быть назначены на дежурство в течение недели или даже дня, и расписание меняется внутри команды, если только команда не проводит какое-то специальное слежение за новыми сотрудниками в рамках их процесса адаптации.
• Во многих командах создается специальный канал Slack, где специалисты по данным могут задавать вопросы и получать помощь от всех глазных яблок MLOps, наблюдающих за каналом (а также от своих коллег по данным). Если им действительно нужна помощь, они также могут пометить инженера, назначенного дежурным, с ожиданием того, что SLA будет выполнено (т. е. они получат ответ через X раз).

Спасибо, что читаете вместе!

Ознакомьтесь со всеми другими моими сообщениями о #datascience, #mlops и #MLengineering здесь: MLOPs by Mikiko Bazeley

Хотите подключиться? Ищите меня в этих местах 👇

• LinkedIn: https://www.linkedin.com/in/mikikobazeley/
• YouTube: https://www.youtube.com/@Miki_ML
• Твиттер: https://twitter.com/BazeleyMikiko
• Мастодонт: https://data-folks.masto.host/@mikiko
• Подстек: https://mikikobazeley.substack.com/