Ключевые выводы
- Hybrid CDP когда выбирать — модель, в которой часть данных и логики работают on-prem, а часть — в облачных сервисах поставщика; оптимальна для бизнесов в переходном состоянии
- Hybrid не лучше on-prem или SaaS «вообще» — у него свой узкий сценарий применения, в котором он значительно дешевле и быстрее
- Типовая архитектура: stateful-слой (профили, события, аудит) on-prem, stateless-сервисы (доставка, аналитика) в облаке
- Hybrid выигрывает для бизнесов с базой 2-7 млн профилей и compliance-требованиями уровня 152-ФЗ, но без необходимости полного цифрового суверенитета
- Эта модель сложнее в эксплуатации, чем чистые on-prem или SaaS — нужно поддерживать два контура и SLA на интеграцию между ними
Hybrid CDP когда выбирать — вопрос, который встаёт у CIO, когда чисто on-prem кажется слишком дорогим, а чистый SaaS не закрывает compliance-требования. Hybrid-модель часто выглядит как «лучшее из двух миров», но на практике это компромисс со своими сильными сторонами и ограничениями.
Эта статья — практический разбор сценариев, в которых hybrid CDP оправдан, и сценариев, в которых это путь к удвоению операционной сложности без реальной выгоды. На основе 8 hybrid-проектов 2024-2026 годов.
Что такое hybrid CDP
Hybrid CDP — это архитектура, в которой компоненты customer data платформы распределены между:
- On-prem контуром — собственная инфраструктура заказчика, обычно для критичных к compliance данных и функций
- Облачными сервисами — у CDP-вендора или у российского облачного провайдера, для функций, не требующих строгой изоляции
Граница между двумя контурами проходит по чувствительности данных и требованиям производительности. Простой пример: профили клиентов с персональными данными хранятся on-prem, а сервис доставки рассылок (без хранения долговременного состояния) работает в облаке.
Три типовые архитектуры hybrid CDP
Архитектура 1: данные on-prem, доставка в облаке
Самая распространённая модель. Профили, события, сегменты, аудит-следы хранятся в собственной инфраструктуре. Сервисы доставки коммуникаций (SMTP relay, push-сервис, SMS-провайдер) работают в облаке. Сегменты передаются в облачные сервисы по защищённому каналу.
Плюсы: соответствие 152-ФЗ за счёт хранения данных on-prem; минимальная нагрузка на on-prem инфраструктуру; гибкость в масштабировании каналов.
Минусы: нужна интеграция между двумя контурами; передача данных в облако (даже минимальная) требует юридического оформления; зависимость от облачного провайдера в части доставки.
Архитектура 2: ядро в облаке, чувствительные данные on-prem
Обратная модель. Основной CDP работает в облаке (SaaS-режим), но критичные к compliance данные (например, банковские реквизиты, биометрия) хранятся в собственном защищённом хранилище. CDP обращается к ним через защищённый API только при необходимости.
Плюсы: low time-to-value (быстрый старт за счёт облачного CDP); compliance закрыт за счёт изоляции критичных данных; меньше операционной нагрузки на DevOps заказчика.
Минусы: основная часть данных всё равно в облаке (соответствует ли это вашему compliance-профилю?); сложная архитектура изоляции отдельных полей; зависимость от вендора в части недокументированных интеграций.
Архитектура 3: dual-deployment с синхронизацией
Сложная модель, в которой две полноценные инсталляции — одна on-prem, одна в облаке — синхронизируются между собой. On-prem обрабатывает критичные сегменты и compliance-чувствительные сценарии, облачная — массовые каналы и low-priority кампании.
Плюсы: высокая отказоустойчивость; гибкость в распределении нагрузки; отказ от облачного контура при ужесточении compliance не критичен.
Минусы: самая дорогая модель (фактически две CDP-инсталляции); самая сложная в эксплуатации; требует зрелой команды DevOps и Data Engineers.
Сценарии, в которых hybrid CDP выигрывает
Сценарий 1: переходное состояние при миграции с SaaS на on-prem
Если бизнес растёт и SaaS становится дорогим, но команда ещё не готова к полному on-prem — hybrid даёт переход без скачка. Сначала выносится stateful-слой (хранение данных) on-prem, потом постепенно мигрируют функции доставки и аналитики.
Hybrid когда выбирать в этом сценарии: если рост базы клиентов 30-50% в год, и через 1-2 года вы точно перейдёте в on-prem масштаб.
Сценарий 2: compliance-требования по части данных
Если 152-ФЗ применим только к определённой категории данных (например, только к биометрии или только к банковским реквизитам), а остальные данные классифицируются как «не персональные» — hybrid позволяет изолировать чувствительную часть on-prem, оставив всё остальное в SaaS.
Сценарий 3: международный бизнес с локальными регуляторами
Для компаний, работающих в РФ и СНГ, локальные регуляторы могут требовать хранения данных конкретной юрисдикции на её территории. Hybrid позволяет: данные российских клиентов on-prem в РФ, данные клиентов из Казахстана — в KZ-облаке, данные европейских клиентов — в EU-регионе SaaS-вендора.
Сценарий 4: pilot с быстрым стартом и compliance-расширением
На этапе пилота — облачная CDP за 6-8 недель. После успеха пилота — постепенное вынесение чувствительных данных on-prem. Hybrid здесь работает как переходная архитектура между MVP и full-enterprise решением.
Сценарии, в которых hybrid не подходит
В трёх ситуациях hybrid становится плохим выбором:
- Полный цифровой суверенитет. Если задача — хранить и обрабатывать все данные внутри своего контура (банки top-30, гос-сектор, КИИ), hybrid не подходит даже частично. Любая передача данных в облако — уже компромисс. Только on-prem.
- Малый бизнес. Для базы менее 1.5 млн профилей операционная сложность hybrid-архитектуры не оправдывается. Чистый SaaS значительно проще и дешевле.
- Очень плотный engagement-слой с low-latency требованиями. Если каждый клик в мобильном приложении должен отрабатывать персонализацию за 100 мс, передача данных между двумя контурами создаёт latency-узкие места. Лучше — единый контур (либо on-prem, либо облако).
Стоимость hybrid-конфигурации
Сравнение трёх моделей для типового retail-проекта (3 млн профилей):
| Параметр | SaaS | Hybrid | On-prem |
|---|---|---|---|
| CAPEX (внедрение) | 0 ₽ | 10-15 млн ₽ | 22 млн ₽ |
| OPEX год 1 | 3.5 млн ₽ | 4.5-5.5 млн ₽ | 4.5 млн ₽ |
| OPEX год 2-3 | 4-5 млн ₽ | 5-6 млн ₽ | 4.5 млн ₽ |
| TCO 3 года | ~12 млн ₽ | ~25 млн ₽ | ~36 млн ₽ |
| TCO 5 лет | ~25 млн ₽ | ~38 млн ₽ | ~46 млн ₽ |
Hybrid дороже SaaS, но дешевле on-prem. На горизонте 5 лет hybrid экономит 8-12 млн ₽ относительно on-prem, но требует более сложной операционной модели. Подробнее о сравнении — в материале TCO on-prem CDP vs SaaS.
Ключевые риски hybrid-архитектуры
Риск 1: операционная сложность
Команде нужно поддерживать два контура с разными SLA, разными процедурами обновлений, разными методами мониторинга. Это требует выделенных ролей: DevOps по on-prem-части, integration engineer по связке двух контуров, ops-аналитик по облачной части. Минимум 2 FTE против 0.5-1 FTE для чистых SaaS или on-prem.
Риск 2: согласие на передачу данных третьим лицам
Любая передача данных в облако — это передача обработчику. В согласии на обработку ПДн должно быть прописано: какие данные передаются, какому именно облачному провайдеру, с какой целью. Если это не отражено — нарушение 152-ФЗ.
Риск 3: SLA на интеграцию между контурами
Канал между on-prem и облаком — критичная точка отказа. Если он недоступен (проблемы с провайдером, обрыв канала, перегрузка), часть функций hybrid CDP перестаёт работать. Нужны резервный канал, мониторинг качества и SLA.
Риск 4: vendor lock-in на облачной стороне
Если основная логика и сценарии хранятся в облаке у конкретного вендора, миграция к другому вендору становится сложным проектом — даже если данные у вас on-prem. Vendor lock-in перемещается с уровня данных на уровень бизнес-логики.
Decision matrix: выбор между моделями
| Параметр | SaaS | Hybrid | On-prem |
|---|---|---|---|
| База клиентов | до 5 млн | 2-7 млн | 5+ млн |
| Compliance | низкий | средний | высокий |
| Команда DevOps | не нужна | 1-1.5 FTE | 1-2 FTE |
| Time-to-value | 4-6 недель | 3-4 месяца | 5-7 месяцев |
| Гибкость кастомизации | низкая | средняя | высокая |
| Стоимость 3 года | ★ дешевле | ★★ средне | ★★★ дороже |
Чек-лист готовности к hybrid-архитектуре
Перед выбором hybrid-модели проверьте:
- [ ] У вас есть собственная инфраструктура или возможность развернуть on-prem-часть в colocation
- [ ] Есть выделенная команда DevOps (1+ FTE) с опытом эксплуатации stateful-сервисов
- [ ] Есть надёжный канал связи между on-prem и облаком (резервированный)
- [ ] Согласия на обработку ПДн допускают передачу данных облачному провайдеру (или их можно обновить)
- [ ] Compliance-команда оценила риски передачи в облако и согласовала их
- [ ] Юридический отдел готов к составлению договоров с облачным провайдером
- [ ] Есть бюджет на дополнительные 1-2 FTE для эксплуатации
- [ ] Бизнес готов к 3-4 месяцам внедрения вместо 6-8 недель SaaS-старта
Если на 2+ пунктов ответ «нет» — лучше остаться на SaaS или сразу переходить к чистому on-prem. Hybrid даст худшие результаты, чем оба варианта.
FAQ о hybrid CDP когда выбирать
Можно ли начать с SaaS, потом перейти в hybrid, потом в on-prem?
Да, но это три разных проекта. Каждый переход стоит 5-12 млн ₽ и занимает 4-6 месяцев. Если вероятна полная миграция в on-prem в горизонте 2 лет — рациональнее сразу делать on-prem, минуя hybrid. Hybrid оправдан только если вы планируете оставаться в нём 3+ лет.
Что значит «частично соответствует 152-ФЗ» для hybrid?
Это значит, что критичные данные (с прямой идентификацией субъекта) хранятся on-prem и не покидают контур, а агрегированные/обезличенные данные могут передаваться в облако. Граница «что считается ПДн» определяется юристами компании на основе целей обработки и характера данных.
Можно ли использовать иностранное облако для hybrid-части?
Для российских компаний с обработкой ПДн — нет. 152-ФЗ требует первичной обработки и хранения ПДн на серверах в РФ. Облачная часть hybrid должна быть у российского провайдера (Yandex Cloud, VK Cloud, MTS Cloud и т.п.). Использование иностранного облака допустимо только для агрегированных или обезличенных данных.
Кто отвечает за инциденты в hybrid-системе?
Это сложный вопрос для договоров. Обычно: вендор отвечает за SaaS-часть в рамках своего SLA; заказчик — за on-prem часть; интеграционный канал — общая ответственность с разделением SLA. Все эти границы должны быть зафиксированы в договоре, иначе при инциденте будут долгие выяснения, кто виноват.
Стоит ли выбирать hybrid просто чтобы «поэкспериментировать»?
Нет. Hybrid — самая сложная архитектура из трёх. Запускать её ради эксперимента — гарантированно получить переплату и операционные проблемы. Если хочется попробовать собственную CDP, лучше начать с MVP в облаке и через год оценить, есть ли реальные основания для перехода в hybrid или on-prem.
Что в итоге
Hybrid CDP когда выбирать — конкретный набор сценариев: бизнес в переходном состоянии, частичные compliance-требования, международная экспансия, поэтапный переход с SaaS на on-prem. Вне этих сценариев hybrid становится дорогим компромиссом без выгоды.
Архитектурно hybrid сложнее, чем чистые модели, и требует выделенных компетенций в DevOps и интеграции. Стоит на 60-90% дороже SaaS, но на 30-40% дешевле полного on-prem на горизонте 5 лет.
Готовы помочь оценить применимость hybrid к вашему профилю и спроектировать архитектуру — обсудим.