Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part II

Продолжая первый пост про этот whitepaper, надо рассказать про capabilities ML платформ, которые нужны для того, чтобы выстроить хорошие MLOps процессы:
- Experimentation - совместное выполнение исследовательского анализа данных, создание архитектуры прототипов моделей и реализация процедур обучения
- Data processing - возможность обработки данных, что позволяют готовить и преобразовывать большие объемы данных в конвейерах непрерывного обучения
- Model training - возможность эффективно и экономично запускать мощные алгоритмы для обучения моделей машинного обучения
- Model evaluation - возможность оценки модели в интерактивном режиме во время экспериментов
- Model serving - возможность развертывать и обслуживать модели в продакшен
- Online experimentation - возможность провести онлайн-эксперименты, чтобы понять, как недавно обученные модели работают в продакшене по сравнению с текущими моделями (если таковые имеются) перед выпуском новой модели в производство
- Model monitoring - возможность мониторинга моделей позволяет отслеживать эффективность и результативность развернутых моделей для обеспечения прогнозируемого качества
- ML pipelines - возможность выстроить сложные пайпланы для тренировки и эксплуатации моделей в проде
- Model registry - централизованный реестр моделей (регистрация моделей, описание зависимостей, документации и метаданные, интеграция с экспериментами и мониторингом, а также раскаткой и откаткой моделей)
- Dataset and feature repository - хранилище наборов данных и фичей позволяют унифицировать определение и хранение данных для ML моделей. Наличие центрального хранилища свежих высококачественных данных обеспечивает возможность совместного использования, обнаружения и повторного использования.
- ML metadata and artifact tracking - хренение различные типов артефактов ML, что создаются в разных процессах жизненного цикла MLOps, включая включая описательную статистику и схемы данных, обученные модели и результаты оценки

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

P.S.
Конечно читая между строк этого документа можно понять, что внутри Google Cloud есть ML платфома со всеми этими возможностями, что позволяет из коробки выстроить MLOps ... если вы используете нужное облако:) Но это не умаляет хорошего описания фреймворка для MLOps, который приведен в этой статье

#ML #Devops #Data #AI #Software #Architecture #Processes

Инструменты надежности Такси \ Александр Фишер, Яндекс Такси

Интересное выступление Александра Фишера насчет процессов и инструментов по повышению надежности. Выступление короткое и состоит из шести частей
1. Такси и надежность
Вводная про критичность сервисов такси, профиль нагрузки, кратко про архитектуру, используемые технологии. Дальше про метрики надежности:
- Стандартные: SLO в девятках, MTTR (mean time to recovery)
- Интересные: MTTRC (mean time to root cause) - насколько быстро находится корневая причина сбоя, ROCOF (rate of occurrences of failures) - частотность сбоев
В общем, дальше посыл такой, что в следующих пунктах автор рассказывает про инструменты борьбы со сложностью
2. Хаос
Подход ребят в том, что они используют fault injection, где data plane этого хаоса реализован через lua скрипты для nginx, которые балансируют трафик, а также есть control plane для управления конфигурацией этих инжектированных ошибок. Этот инструмент позволяет
- Замедлять сервис (но укладываясь в propogation deadline)
- Моделировать метастабильное состояние сервиса, когда сервис упал под нагрузкой и встать не может, ждет он кто ему поможет:)
- Выдача 500 ошибок с заданным процентом
3. Срезание нагрузки: деградация, retries, limits
У ребята есть
- Gracefull degradation mode, где неосновной функционал можно отключить (это добавляет 20% мощности, но в планах 50%)
- Управление retries для решения проблемы амплификации запросов во время сбоев
- Есть классификация сервисов по уровням, где уровень зависит от критичности сервиса для возможности выполнить основную функцию (уехать на такси)
4. Виртуальные заказы
Рассказ про тестирование нагрузки на систему через моделирование нагрузки виртуальными заказами, которые позволяют проверить нагрузку не API endpoint, а холистически для всей системы. Крутой инструмент, который решает проблему проверки нелинейных зависимостей и непредсказуемого поведения реально сложной системы в зависимости от разного типа нагрузки.
5. Observability и eventboard
Тут автор показывает и рассказывает про дашборды для observability + интересный eventboard про события на проде, а также кнопку "откатить все за последние n минут", что помогает уменьшить MTTR (mean time to recover) и ускорить восстановление после сбоя.
6. Симуляция инцидентов
Тут идет рассказ про координаторов сбоев + про симуляцию сбоев и тренировки по устранению сбоев, что идут каждую неделю

Ну и в конце выступления автор рассказывает про экспериментальные инструменты
- Autorecovery - робот, что автоматически чинит инциденты (он пока в dry run работает и проходит обкатку)
- SRE GPT - инструмент для помощи в поиске root cause

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

#SRE #DistributedSystems #Reliability #Architecture #Software #Processes #Management

Как выглядит роль SDE в tech компаниях

Сегодня выступаю на нашем мероприятии для студентов из МФТИ, где я учился много лет назад.
У меня есть полчаса и я планировал обсудить кучу тем:
- Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:)
- Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов
- Как выглядит матрица компетенций для SDE в Tinkoff
- Как выглядит процесс роста сотрудников внутри (Tinkoff рост)
- И другие полезные мысли про саморазвитие и рост внутри компании:
-- Как использование Cynefin фреймворка
-- Как работать над сложной проблемой (и создавать артефакты RFC/ADR)
-- Как приоритизировать задачи используя матрицу Эйзенхауэра
-- Как работать со своей мотивацией
-- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon)
-- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее

Интересно, что многое из сегодняшнего доклада мы обсуждали с Алексеем Тарасовым в рамках выпуска Code of Leadership пару недель назад.

P.S. Материалы к выступлению

Материалы по процессам разработки
- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Архитектура в масштабе на ArchDays 2020
- Devops культура: мифы и реальность
- Про MLOps
- The State of Application Security 2023 • Sebastian Brandes • GOTO 2023
- Как RnD появляется в крупных ИТ-компаниях

Материалы по проектированию и system design
- Статья про System Design Interview в общем
- Статья про то, как мы оцениваем System Design Interview
- Статья о том, как подготовиться и пройти System Design Interview
- Публичное System Design Interview на C++ Russia 2022
- Публичное System Design Interview на конференции ArchDays 2022
- Статья со списком книг о проектировании программного обеспечения
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Software development engineers в tech компаниях

Вчера я выступал на конференции "IT PurpleConf" с докладом для студентов про современные ожидания от software development engineers в технологических компаниях. Само выступление в виде трансляции будет еще не скоро, поэтому я ближе к ночи записал выпуск подкаста и выложил на свой youtube канал TellMeAboutTech:) Подробнее про темы выступления во вчерашнем посте и там же есть список рекомендованных материалов.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Code of Leadership 9 - An Elegant Puzzle - System of Engineering Management (часть 1)

Девятый выпуск Code of Leadership посвящен обсуждению крутой книги "An Elegant Puzzle: Systems of Engineering Management", про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Саму книгу я обсуждаю с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

В этом выпуске только первая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за час мы успели поговорить про книгу в общем и обсудить полностью вторую главу и часть третьей главы книги:
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как драйвить технические миграции.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering