Технологический ландшафт для менеджера: микросервисы, данные и ML без иллюзий

← назад к разделу

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

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

Микросервисы, Kubernetes, CI/CD: что покупает бизнесспросят на собеседовании

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

Определения стоит знать из первоисточников. Микросервисный стиль по Льюису и Фаулеру - это подход, при котором одно приложение строится как набор небольших сервисов, каждый в своём процессе. Через год Фаулер ввёл понятие «надбавки за микросервисы»: они сами по себе добавляют сложность, поэтому их не стоит рассматривать, пока система не стала слишком сложной для монолита. Kubernetes в собственной документации - переносимая расширяемая платформа с открытым кодом для управления контейнерными нагрузками.

Для CI/CD у менеджера есть готовая линейка: показатели доставки DORA. Сейчас их пять: время прохождения изменения, частота выкаток, время восстановления после неудачной выкатки, доля неудачных изменений и доля выкаток с переделкой. Как их снимать в команде, разобрано в статье про метрики команды.

Подробнее: монолит или микросервисы, основы Kubernetes, принципы CI/CD.

Где живут данные: склад, озеро, lakehouseспросят на собеседовании

Здесь у менеджеров больше всего путаницы, потому что одно и то же слово «база» означает четыре разных мира.

Рабочая база приложения (OLTP). Короткие запросы по одной записи: оформить заказ, списать деньги. Её задача - быстро и надёжно обслуживать пользователей. Отчёты по ней строить можно, пока данных немного; потом тяжёлый отчёт начинает тормозить оформление заказов. Разница OLTP и OLAP подробно - в статье OLTP и OLAP.

Склад данных (DWH). Отдельная аналитическая база, куда регулярно сводят данные из всех рабочих систем: сайта, CRM, складского учёта, биллинга. Данные в нём приведены к единому виду, хранят историю и только дописываются. Для бизнеса склад это одна версия правды: выручка в отчёте финансов и в отчёте продаж считается одинаково. Схема заранее продумана под отчёты, поэтому добавить новый источник - это работа аналитика-инженера, а не вечер на выгрузку.

Озеро данных (data lake). В статье Армбраста и соавторов (CIDR 2021) озеро описано как дешёвое хранилище с файловым доступом, где данные лежат в общих, обычно открытых форматах вроде Apache Parquet. Туда складывают всё как есть, включая логи, тексты и картинки, а схему применяют при чтении. Плюс - дёшево и гибко. Минус там же назван прямо: проблема качества и управления данными переносится на потребителей. Без каталога и владельцев озеро за год превращается в болото, где никто не знает, какой файл актуален.

Lakehouse. В той же статье это система управления данными на дешёвом хранилище с прямым доступом, которая добавляет к нему привычные свойства аналитической СУБД: ACID-транзакции, версии данных, аудит, индексы, кеширование и оптимизацию запросов. Идея - не держать две копии (озеро плюс склад) с двумя конвейерами между ними. Авторы прямо называют проблемы двухуровневой схемы: устаревание данных, надёжность, полная стоимость владения, привязка к поставщику.

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

Потоковая обработка: когда «вчера» уже поздно

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

Бизнесу она даёт свежесть. Стоит она заметно дороже пакетной: брокер сообщений вроде Kafka, круглосуточное дежурство, сложная отладка, потому что события приходят с опозданием и не по порядку. Это подробно разобрано в статье потоковая обработка.

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

Жизненный цикл ML-моделиспросят на собеседовании

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

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

1. Данные. Есть ли данные с правильным ответом (разметкой) и сколько их? Можно ли их законно использовать: если там персональные данные, нужно основание и обезличивание, см. персональные данные и секреты.
2. Обучение. Какой простой базовый вариант мы пытаемся обогнать: правило, эвристика, ручная работа?
3. Проверка. На каких данных проверяли, похожи ли они на реальный поток, какой порог качества достаточен для бизнеса?
4. Выкатка. Как модель встаёт в продукт: онлайн-запрос, ночной пересчёт, подсказка оператору? Можно ли включить на 5% трафика и откатить?
5. Мониторинг. Как узнаем, что модель стала хуже, и кто за это отвечает?

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

Сколько стоит и сколько длится ML-проектспросят на собеседовании

Стоимость ML-проекта складывается не из модели, а из всего вокруг неё. В статье Скалли и соавторов «Hidden Technical Debt in Machine Learning Systems» (NIPS 2015) это главный тезис, а руководство Google по MLOps со ссылкой на неё формулирует: в реальной ML-системе код самой модели составляет лишь малую часть. Остальное - сбор и проверка данных, признаки, инфраструктура обучения, выдача, мониторинг.

Шаблон оценки, который стоит попросить у команды до старта:

Пример расчёта для понимания порядка. Допустим, рекомендательный блок для интернет-магазина: два инженера по данным на три месяца исследования, один бэкенд-разработчик на месяц встраивания, затем четверть ставки на сопровождение. Первый год - это не «три месяца проекта», а около семи-восьми человекомесяцев плюс вычисления. Если ожидаемый прирост выручки этот бюджет не окупает, проект не стоит начинать, как бы ни была интересна задача.

Со сроками главное правило: исследовательская фаза не оценивается как обычная разработка. Нельзя пообещать точность 90% к дате, потому что заранее неизвестно, есть ли в данных сигнал. Работает тайм-бокс: «за шесть недель выясняем, можно ли обогнать текущее правило хотя бы на N%; если нет - останавливаемся». Это обязательство на решение, а не на результат, как в статье про оценки и сроки.

Типичные ошибки менеджераспросят на собеседовании

ML ради ML. Задачу формулируют как «внедрить нейросеть», а не «сократить отток на 2%». Первое правило из Rules of Machine Learning Мартина Зинкевича: не бойтесь запускать продукт без машинного обучения. Если правило из трёх условий даёт 80% эффекта, начинать нужно с него, а модель строить потом, когда будет с чем сравнивать.

Нет данных. «У нас много данных» часто означает, что есть логи, но нет правильных ответов. Для модели оттока нужна история с отметкой, кто ушёл и когда; если её никто не собирал, первые месяцы проекта уйдут на сбор, и это надо назвать честно.

Нет метрики успеха. Второе правило Зинкевича: сначала спроектируйте и внедрите метрики. Команда меряет точность модели, бизнес ждёт деньги, и через полгода выясняется, что модель «хорошая», а выручка не изменилась. Метрику бизнеса и способ её проверить (обычно A/B-тест) фиксируют до старта.

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

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

Платформа впереди задачи. Покупают lakehouse, Kubernetes для обучения и feature store, а первой полезной модели ещё нет. Четвёртое правило Зинкевича: первая модель должна быть простой, а усилия идут на правильную инфраструктуру.

Вопросы команде перед решением

Шаблон на одну страницу, который можно приложить к записи решения (ADR):

Технология / проект: ...
1. Какую проблему бизнеса решаем, в цифрах сейчас: ...
2. Что изменится, в цифрах, и как измерим: ...
3. Что самое простое, что можно сделать вместо: ...
4. Стоимость: разовая ... / ежемесячная ... / люди ...
5. Кто владелец после запуска и кто дежурит: ...
6. Когда и по какому признаку остановимся, если не работает: ...
7. Что ломается, если технология откажет, и как откатиться: ...

Для ML добавьте ещё три строки: какие данные с разметкой есть, с каким базовым вариантом сравниваем, как заметим деградацию.

Глубже: уровни зрелости MLOpsрасширенное

Google определяет MLOps как инженерную культуру и практику, которая объединяет разработку ML-системы и её эксплуатацию, и описывает три уровня зрелости.

• Уровень 0, ручной процесс. Каждый шаг выполняют руками, выкатывают только сервис предсказаний, а не всю систему. Так начинают почти все, и для первой модели это нормально.
• Уровень 1, автоматизация конвейера. Цель - непрерывное обучение: модель регулярно переобучается на свежих данных автоматически.
• Уровень 2, автоматизация CI/CD конвейера. Сам конвейер обучения проходит автоматическую сборку, проверку и выкатку, чтобы команда могла быстро и надёжно менять его.

Вопрос менеджера здесь не «на каком мы уровне», а «какой нужен». Модель кредитного скоринга, которую пересматривают раз в квартал, может жить на уровне 0 с хорошим регламентом. Рекомендации, которые устаревают за неделю, без уровня 1 не работают.

Отдельно о дрейфе. Google описывает сигнал к переобучению как существенное изменение статистических свойств данных. На практике различают изменение входных данных (пришли другие клиенты) и изменение самой связи между входом и правильным ответом (те же клиенты стали вести себя иначе). Мониторить нужно и то и другое, а реагировать регламентом: кто смотрит, при каком пороге переобучаем, кто подтверждает выкатку новой версии. Сообщество ml-ops.org добавляет к этому версионирование кода, данных и модели вместе и реестр обученных моделей: без них нельзя ответить, на каких данных обучена модель, которая сейчас отвечает клиентам.

Глубже: скрытый долг ML-системрасширенное

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

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

Ещё одно следствие для потоковых данных. Джей Крепс в статье «Questioning the Lambda Architecture» (2014) критиковал схему, где одна и та же логика пишется дважды, для пакетной и потоковой обработки, и предложил пересчитывать всё одним потоковым заданием, перечитывая журнал событий с начала. Для менеджера это вопрос стоимости: две реализации одной логики - это двойной объём сопровождения и регулярные расхождения в цифрах.

Коротко

• Любую технологию раскладывайте на четыре строки: что даёт, сколько стоит каждый месяц, чем рискуем, как поймём, что сработало.
• Микросервисы, Kubernetes и CI/CD окупаются масштабом команд и частотой выпусков; без этого они чистая надбавка к стоимости.
• Склад даёт согласованные цифры, озеро - дешёвое хранение всего подряд, lakehouse пытается объединить их в одной копии данных.
• Потоковая обработка нужна, только если свежесть данных меняет решение; иначе хватает ночной выгрузки.
• ML-модель это код плюс данные, и она деградирует без падений; мониторинг и владелец после запуска обязательны.
• Код модели - малая часть ML-системы; основная стоимость в данных, встраивании и эксплуатации.
• Исследование оценивают тайм-боксом с точкой остановки, а не датой результата.
• Три главные ошибки: ML ради ML, нет данных с разметкой, нет бизнес-метрики успеха.

Что почитать дальше

• Монолит, модульный монолит, микросервисы - во что обходится отдельный сервис.
• Kubernetes: с чего начать - основные объекты и идея желаемого состояния.
• Принципы CI/CD - конвейер от коммита до прода.
• OLTP и OLAP - склад данных, ETL и столбцовое хранение.
• Потоковая обработка - CDC, окна и время событий.
• Деньги в облаке - как считать ежемесячную стоимость инфраструктуры.
• Технический долг - как переводить инженерные риски на язык бизнеса.