# 2. MLOps процессы и практики

MLOps расширяет идеи DevOps на системы с компонентами машинного обучения. Если в DevOps основным артефактом является код сервиса, то в MLOps добавляются данные, признаки и модели. Это приводит к усложнению контуров CI/CD, мониторинга и управления версиями: одно обновление данных может изменить поведение модели без изменения кода.

## Связь DevOps и MLOps

На концептуальном уровне MLOps можно рассматривать как надстройку над DevOps, которая добавляет:

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

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

## Управление данными и признаками

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

- **Контур сырого хранилища данных**. Сюда попадают исходные логи, события, выгрузки из систем. Важно обеспечить надёжное хранение, контроль доступа, минимально необходимую предобработку (очистка от очевидного мусора, соблюдение требований к приватности).
- **Контур подготовленных датасетов**. На основе сырья формируются согласованные датасеты для обучения, валидации и тестирования. Они описываются схемами, версиями и метаданными (происхождение, фильтры, временной диапазон).
- **Контур признаков**. Признаки могут использоваться многими моделями и командами. Архитектурно целесообразно рассматривать их как разделяемый ресурс с чёткими контрактами: определением семантики, механизмом вычисления, SLA по доступности.

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

## Управление экспериментами и обучением

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

Архитектурно обычно выделяются следующие элементы.

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

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

## CI/CD для ML-компонентов

Непрерывная поставка ML-моделей включает в себя не только сборку и доставку бинарных артефактов, но и работу с данными и экспериментами.

Концептуальная цепочка может включать:

1. **Сбор и проверку данных**. В рамках пайплайна проверяются схемы, распределения значений, наличие аномалий. При нарушении инвариантов пайплайн останавливается.
2. **Обучение и автоматизированную валидацию**. Модель обучается на новых данных, затем автоматически сравнивается с текущей продакшн-версией по ряду метрик. Решение о продвижении может приниматься по заданным правилам.
3. **Сборку артефактов инференса**. Формируется образ сервиса или пакет с моделью и её зависимостями, пригодный для развёртывания в целевой инфраструктуре.
4. **Развёртывание**. Используются паттерны, знакомые по DevOps: blue-green, канареечные релизы, постепенное переключение трафика.

Важно, что триггером нового цикла может быть как изменение кода, так и изменение данных или дрейф качества модели.

## Мониторинг и эксплуатация моделей

Эксплуатация ML-компонентов требует многослойного мониторинга.

- **Инфраструктурный уровень**: задержки ответов, частота ошибок, использование CPU/GPU/памяти, насыщение очередей.
- **Данные на входе**: распределения признаков, доля пропусков, изменение доли классов, сезонные эффекты. Отклонения от ожиданий могут свидетельствовать о проблемах в исходных системах или о невалидности предположений, принятых при обучении.
- **Выходы моделей**: распределение предсказаний, уверенность, частота применения fallback-логики. Здесь же отслеживаются бизнес-метрики, чувствительные к качеству модели (конверсии, доход, уровень удовлетворённости пользователей).

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

## Практики построения надёжных ML-конвейеров

На уровне архитектуры MLOps-практики сводятся к нескольким ключевым подходам.

- **Явная оркестрация пайплайнов**. Все шаги — от загрузки данных до выката модели — описываются в виде декларативных графов задач с возможностью аудита и повторного запуска.
- **Идемпотентность шагов**. Повторный запуск шага с теми же входами должен давать тот же результат. Это важно для восстановления после сбоев и для воспроизводимости экспериментов.
- **Разделение сред**. Для обучения, валидации и продакшн-инференса используются изолированные среды с контролем доступа и настройками, соответствующими их назначению.
- **Подход «данные и модели как продукт»**. Команды, отвечающие за датасеты, признаковые пайплайны и модели, предоставляют их как продукт с договорами об уровне сервиса, документацией и эволюцией интерфейсов.

Следование этим практикам позволяет встроить ML-компоненты в существующую инженерную культуру и обеспечить предсказуемость изменений.
