Совместный рабочий материал · продуктовая дифференциация

Deckhouse + ANG
От Managed Service
к Managed Data Product

Product differentiation roadmap: почему заказчик выбирает ANG поверх vanilla managed service — и почему это выгодно обеим сторонам партнёрства.

Vanilla Managed Service — когда заказчику нужен управляемый компонент.
ANG Managed Data Product — когда заказчику нужен измеримый и управляемый результат на данных.

Ключевой тезис для партнёрства Каждая vanilla-инсталляция Deckhouse — это воронка для upsell в ANG. Мы не конкурируем за базовый сервис — мы монетизируем его глубже. Результат закрепляется через SLA, политики и эксплуатационные процессы; «гарантированным» он становится там, где появляется договорной SLA.

02 · Коммерческая механикаexec

Почему связка выгодна обеим сторонам

Это не конкуренция продуктов, а механизм land-and-expand: vanilla открывает дверь, ANG наращивает глубину внедрения и общий чек.

Deckhouse получает

монетизация установленной базы

Более глубокую монетизацию installed base без роста стоимости привлечения
Рост среднего чека и переход в data-бюджет заказчика
Выше LTV: платформа данных живёт и расширяется годами
Больше повторных продаж и поводов для контакта с заказчиком
Переход от инфраструктурного диалога к бизнес-задачам данных

ANG получает

масштабируемый канал и промышленный runtime

Быстрый вход через готовый managed runtime — без строительства инфраструктуры
Масштабируемый канал: installed base Deckhouse как воронка
Промышленный Kubernetes-контур и сертификацию
Снижение собственной стоимости эксплуатации
Фокус инженерных ресурсов на data-продукте, а не на runtime

Deckhouse увеличивает охват и скорость входа.
ANG увеличивает глубину внедрения, средний чек и LTV заказчика.

03 · Сравнение уровней предложенияexec

Vanilla Managed Service vs ANG Managed Data Product

Vanilla — правильный базовый уровень: управляемый компонент с промышленной эксплуатацией. ANG — следующая ступень, когда компонент входит в промышленный data-сценарий.

Уровень	Vanilla Managed Service	ANG Managed Data Product
Что покупает клиент	Работающий управляемый компонент	Измеримый результат data-сервиса: витрина обновлена, отчёт готов, SLA выполнен
Установка	Оператор, валидированная конфигурация	+ профиль под data-сценарий: topology, retention, quotas под задачу
Эксплуатация	Upgrade, HA, backup, scaling	+ эксплуатация в терминах данных: свежесть, полнота, downstream-влияние
Безопасность	Инфраструктурный security-профиль, CVE	+ политики доступа к данным, классификация, аудит доступа к данным
Мониторинг	Инфраструктурные метрики компонента	Продуктовые метрики: data SLA, lag потребителей, устаревшие витрины
Data SLA	Не входит в scope компонента	SLA на свежесть и полноту данных как продуктовое обязательство
Оптимизация	Ресурсы кластера	Диагностика запросов, tiering, workload-профили с оценкой эффекта
Управление стоимостью	Стоимость инфраструктуры	Стоимость хранения, обработки и пайплайнов; рекомендации по снижению
Готовые сценарии	Заказчик собирает data-сценарий сам	Шаблоны пайплайнов, отраслевые схемы, типовые интеграции
Интеграция компонентов	Компоненты независимы	Компоненты работают как единая платформа с общими метаданными
Ответственность за результат	Компонент доступен и обновлён	Данные доставлены, качественны и пригодны к использованию — измеримо

Executive summary Vanilla отвечает за доступность компонента. ANG отвечает за результат на данных. Обе ступени нужны рынку — и продаются как единый путь роста заказчика.

04 · Модель дифференциацииexec

Пять уровней продуктового отличия

Каждый компонент платформы проходит пять уровней зрелости. Deckhouse особенно силён на уровнях 1–2 и в runtime-части уровня 3. ANG владеет data-частью безопасности и создаёт основную ценность на уровнях 4–5 — там, где компонент встречается с данными. Граница не абсолютная: часть функций — совместные.

УРОВЕНЬ 1 Deploy Deckhouse

Готовые профили, валидированные конфигурации, pre-flight validation, типовые topology, sizing presets

УРОВЕНЬ 2 Operate Deckhouse

Upgrade, backup, restore, scaling, HA, lifecycle, DR readiness, release compatibility

УРОВЕНЬ 3 Secure Deckhouse · Runtime Security ANG · Data Security

Runtime: TLS/mTLS, K8s RBAC, LDAP/AD, secrets rotation, CVE, сертификация.
Data: классификация данных, политики Ranger, row/column-level доступ, masking, аудит data-операций, владельцы data assets

УРОВЕНЬ 4 Observe ANG

Freshness, consumer lag, stale datasets, pipeline health, query cost, data SLA, затронутые downstream-объекты

УРОВЕНЬ 5 Optimize ANG

Sizing recommendations, storage tiering, оптимизация запросов, workload isolation, cost recommendations, controlled remediation

Deckhouse управляет жизненным циклом компонента.
ANG управляет результатом, который компонент создаёт для данных.

05 · Ownershipexec

Правило серой зоны: как делим спорные функции

Функции, затрагивающие и runtime, и data-логику, делятся по одному воспроизводимому правилу — двум вопросам.

Вопрос 1 → зона Deckhouse Managed Runtime

«Как компонент установить, обновить, масштабировать, восстановить или защитить в Kubernetes?»

Механика жизненного цикла — операторы, storage-интеграция, upgrade, backup-механизм.

Вопрос 2 → зона ANG Managed Data Product

«Как компонент используется в data-сценарии и влияет на SLA данных, стоимость, качество, lineage, бизнес-результат?»

Политики, экономика, диагностика на уровне данных, влияние на downstream.

Если функция затрагивает оба уровня — она совместная: Deckhouse отвечает за runtime-механику, ANG — за product logic. Интерфейс и ownership фиксируются в паспорте функции (приложение A), release plan согласуется через Product Council.

Kafka tiered storage

DeckhouseОператор, lifecycle, storage-интеграция с S3-слоем

ANGПолитики retention по топикам, экономический эффект, data-aware рекомендации на основе паттернов потребления

ClickHouse backup

DeckhouseМеханизм backup и restore

ANGПолитики, целевые RPO/RTO, проверяемое восстановление, связь с data SLA витрин

Airflow monitoring

DeckhouseСостояние runtime: scheduler, workers, база метаданных

ANGFreshness датасетов, pipeline SLA, влияние на downstream-витрины и отчёты

OpenSearch lifecycle

DeckhouseРаботоспособность и обновление сервиса

ANGLifecycle-политики, экономика шардов, retention в привязке к data-сценарию

06 · Текущая продуктовая основаexec

Продуктовая основа: подтверждённое и кандидаты

Здесь нет Unified Data Control Plane, Autopilot, Health Score или business-aware observability — эти функции честно размещены в волнах Development и Vision. Жёсткое правило: статус Shipping попадает в материалы для Фланта только после прохождения чек-листа приложения B. Всё, что чек-лист ещё не прошло, — Shipping Candidate.

Confirmed Shipping

Shipping

Интегрированный data-стек: ingestion, streaming, storage, compute, оркестрация
Lakehouse-контур: S3-совместимое хранение, SeaweedFS как выбранный S3-слой
Интеграция с Iceberg и Parquet
Типовые архитектурные конфигурации
Интеграция с Prometheus и Grafana, базовые alerts
Базовые сценарии управления и развертывания

Shipping Candidate

Верифицируется по чек-листу B

Единая ANG-консоль: зафиксировать, какие объекты управляются, а какие только отображаются
Готовые платформенные бандлы: подтвердить состав поддерживаемой сборки и upgrade path
Готовые связи между компонентами: подтвердить покрытие integration-тестами
Продуктовые dashboards: подтвердить наличие data-метрик, а не только инфраструктурных

До верификации эти пункты не демонстрируются заказчику как Shipping.

Сознательно не заявляем

Development / Vision

Health Score — Волна 1, поверх диагностики компонентов
Data-aware наблюдаемость — Волна 1; текущий мониторинг преимущественно инфраструктурный
Unified Data Control Plane, Autopilot, lineage — Vision

Границы v1

Без автоматического remediation, cost-модели, оценки безопасности и прогнозирования стека. Performance, configuration posture и cost — добавляются в v2 поверх работающего ядра

Измеримый эффект

Сокращение времени оценки состояния платформы и приоритизации работ [метрика — на discovery]

Зависимость от Deckhouse

Контракт на метрики и события runtime-слоя — согласуется через Product Council; источники — диагностические модули 1–4

Demo moment: «Availability — зелёный. Capacity Risk — жёлтый: диск Kafka. Data Freshness — красный: витрина продаж устарела на 3 часа → причина → действие». Один экран продаёт платформенность за 60 секунд.

Upgrade Pre-check

Проверка совместимости data-слоя перед обновлением: схемы, пайплайны, запросы. Runtime-механика — зона Deckhouse

Sizing Advisor

Рекомендации по ресурсам от фактической data-нагрузки, а не от шаблона

Managed Tiered Storage Profile

Политики tiering по топикам с оценкой экономии; механика — runtime-зона Deckhouse

Pipeline Templates

Типовые шаблоны: Kafka → ClickHouse, CDC → staging, S3 → Iceberg — конфигурацией, а не разработкой

Index Lifecycle Profiles

Готовые hot/warm/cold-профили OpenSearch под типовые сценарии логов и поиска

08 · Волна 2 Development / Nextexec

Платформа начинает управлять собой

Переход от Detect + Explain к Recommend + Simulate: рекомендации с оценкой эффекта до применения. Автоматические действия остаются за пределами Волны 2 — enterprise-заказчику нужен approval workflow, а не автопилот.

Governance и схемы

Topic Governance: владелец, SLA, классификация, схема — топик как data-asset
Schema Compatibility Guard: блокировка опасных изменений, влияние на потребителей
Workload Profiles ClickHouse: BI / ETL / ad hoc с изоляцией и приоритетами

Эксплуатация данных

ClickHouse Storage Policy Manager: hot/warm/cold-политики с прогнозом стоимости
Parts & Merge Monitor: защита от «too many parts», диагностика ingestion
Pipeline Health и Impact Analysis Lite: что сломается downstream при изменении
DR readiness dashboard: фактическая готовность резервного контура

Стоимость и события

Cost visibility: стоимость хранения, обработки и пайплайнов
Unified Alerts: единая маршрутизация вместо пяти каналов
Базовая корреляция событий между компонентами
Backup & Restore Center: политики и проверяемое восстановление

Ожидаемая ценность Волны 2 Меньше ручной эксплуатации и инцидентов · быстрее диагностика · ниже стоимость владения · предсказуемость data SLA как продуктовое свойство платформы.

09 · Волна 3 Visionexec

Устойчивое платформенное преимущество

Фичи отдельного компонента конкуренты со временем повторят. Устойчивое преимущество возникает между компонентами — и требует всего, что построено в Волнах 1–2.

Направления Vision

Unified Data Control Plane — все data-объекты, политики, SLA и стоимость из одной консоли
Unified Lineage: источник → topic → DAG → таблица → витрина → отчёт
Cross-component Incident Graph: «лаг Kafka задержал DAG, витрина не обновилась, SLA отчёта будет нарушен через 24 минуты» — один инцидент вместо пяти алертов
Data Product Factory: data-продукт целиком в один шаг — топики, пайплайны, таблицы, политики, дашборды
Data Platform Digital Twin: проверка отказов, нагрузки и стоимости на модели
ANG Autopilot и AI Copilot — поверх зрелой диагностики, с approval workflow

Почему это нельзя быстро повторить

Нужны накопленные метаданные и история эксплуатации реальных инсталляций
Нужна глубокая интеграция компонентов с общей моделью данных платформы
Нужны продуктовые модели, runbooks и накопленная экспертиза внедрений
Нужен единый UI и customer feedback loop на живых заказчиках
Каждая функция Vision — производная от Волн 1–2: без Data SLA и lineage не существует Incident Graph

Copilot — интерфейс поверх инженерного продукта, а не замена продукта. Read-only объяснения возможны раньше; действия — только после approval workflow.

1 · Detect2 · Explain → 3 · Recommend4 · Simulate → 5 · Approve6 · Act7 · Verify

Продуктовая лестница волн: Волна 1 — Detect + Explain, Волна 2 — Recommend + Simulate, Волна 3 — Approve + Act + Verify. Каждая ступень строится на данных и доверии, накопленных предыдущей. Именно эта лестница — технологическая основа будущего Autopilot.

10 · По компонентамexec

Killer features по основным компонентам

Приоритетные наборы Волн 1–2 для каждого компонента — и главный продающий тезис.

ANG Kafka

managed streaming data product

Consumer Lag Intelligence
Topic Governance
Managed Tiered Storage Profile
Schema Compatibility Guard
DR readiness dashboard

Тезис: не просто брокер сообщений — управляемый streaming data product с SLA и экономикой.

ANG ClickHouse

объяснимая аналитика

Query Doctor Lite
Storage Policy Manager
Parts & Merge Monitor
Workload Profiles
Materialized View Advisor Lite

Тезис: не просто быстрый OLAP — система, которая объясняет, почему запрос дорогой, и помогает сделать его быстрее и дешевле.

ANG Airflow

фабрика пайплайнов

Pipeline Templates
Data SLA
Pipeline Health Dashboard
Impact Analysis Lite
Certified DAG Templates

Тезис: не просто оркестратор задач — управляемая фабрика pipeline с ответственностью за свежесть данных.

ANG OpenSearch

наблюдаемость под контролем

Shard Health Advisor
Index Lifecycle Profiles
Observability Pack
Cost Guard
Anomaly-to-incident workflow — базовая версия

Тезис: не просто поисковый кластер — управляемый сервис наблюдаемости и аналитики с контролем стоимости и рисков.

11 · Приоритизацияexec

Как feature попадает в roadmap

Семь критериев по шкале 1–5. Оценки не выдуманы заранее — их выставляет Product Council совместно с Deckhouse; таблица ниже — рабочий шаблон первой сессии.

Feature	Commercial Impact выигрывает сделку?	Pain Frequency как часто болит?	Measurable Value эффект измерим?	Defensibility трудно повторить?	Cross-component Leverage усиливает платформу?	Demo Power эффект за 3–5 мин?	Delivery Feasibility 5 = легко и быстро	Score
ClickHouse Query Doctor Lite	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
Kafka Consumer Lag Intelligence	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
Airflow Data SLA	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
OpenSearch Shard Health Advisor	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
ANG Health Score v1	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
Topic Governance	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]
Pipeline Templates	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[1–5]	[Σ]

Формула первого этапа: Priority Score = сумма семи критериев, максимум 35. Все критерии оцениваются «чем выше — тем лучше»: сложность поставки учитывается как Delivery Feasibility, где 5 означает «легко и быстро». Веса критериев добавляются после первой продуктовой сессии, не раньше. Обязательные входные фильтры — независимо от суммы баллов, функция не попадает в Волну 1 без: доступных метрик и API · назначенного product owner · demo scenario · хотя бы одного потенциального pilot customer. Спорные оценки и ownership эскалируются в Product Council; итоговый Score — основа для release train, а не автоматическое решение.

Executive summary Roadmap управляется воспроизводимым scoring-механизмом, а не мнением самого громкого участника. Первая scoring-сессия — часть шага Product discovery.

12 · Роли в совместном roadmapexec

Кто что делает: Deckhouse, ANG, совместно

Разделение по правилу серой зоны — на уровне рабочих зон команд.

Deckhouse

Managed Runtime

Operators и lifecycle
Rootless / distroless, security baseline
Storage-интеграция
Upgrade- и backup-механика
Runtime observability

ANG

Data Product Layer

Product logic и data SLA
Диагностика и рекомендации
Governance и cost models
Data-aware UI
Cross-component workflows

Совместно

через Product Council

API contracts: metrics и events
Integration testing и release train
Reference architecture
Demo environment
Влияние на сертификацию

Deckhouse продаёт управляемую инфраструктуру.
ANG превращает её в измеримый результат для данных.

13 · План действийexec

Следующий шаг

Пять шагов от этого документа до продаваемого совместного предложения.

1

Product discovery

Подтвердить статусы Shipping по чек-листу приложения B · выбрать 5–7 главных болей · интервью с сейлами, пресейлом и заказчиками обеих сторон

2

Зафиксировать Волну 1

Четыре диагностических модуля: ClickHouse Query Doctor Lite, Kafka Consumer Lag Intelligence, Airflow Data SLA, OpenSearch Shard Health Advisor. Поверх них — ANG Health Score v1, агрегирующий их диагностику

3

Совместный backlog

Для каждой функции: product owner, runtime owner, dependencies, MVP scope, demo criteria, acceptance criteria, pilot customer, release target — по паспорту функции из приложения A

4

Пилот

Проверить функции Волны 1 на одном реальном заказчике или совместном демо-стенде

5

Packaging

Vanilla vs ANG battlecard · demo script · pricing logic · sales enablement · upgrade path vanilla → ANG. Коммерческая структура фиксируется до релиза Волны 1 — чтобы killer features не ушли автоматически в базовую лицензию

ANG Essentials

Базовый data-слой поверх vanilla: консоль, базовые дашборды, шаблоны

Observability Pack

Health Score, Data SLA, Lag Intelligence, freshness-контроль

Optimization Pack

Query Doctor, Shard Advisor, tiering-политики, sizing

Governance Pack

Topic Governance, классификация, Ranger-политики, аудит

Enterprise / Regulated

DR readiness, расширенный аудит, требования регуляторов

Состав пакетов — рабочая гипотеза без цен; распределение функций по пакетам утверждается вместе с pricing logic на шаге 5.

Приложение A · рабочий шаблонproduct view

Feature Passport

Каждая функция roadmap оформляется паспортом до включения в release train. Паспорт снимает споры об ownership до того, как они возникнут.

Feature name—

ComponentKafka / ClickHouse / Airflow / OpenSearch / cross-component

Customer painКакую боль решает, в формулировке заказчика

Источник сигналаКонкретный клиент / пресейл / инцидент / запрос продаж / конкурентный тендер / стратегическая гипотеза

User personaData-инженер / DBA / руководитель / ИБ

Vanilla limitationЧто не покрывает vanilla managed service

ANG valueИзмеримая ценность функции

StatusShipping / Development / Vision

Product ownerВладелец продуктовой логики — ANG

Runtime ownerВладелец runtime-механики — Deckhouse

DependenciesAPI, метрики, компоненты, команды

Required telemetryМетрики, логи, события, system tables, API Deckhouse — с частотой и сроком хранения

MVP scopeМинимальный демонстрируемый объём

Demo scenarioЧто показываем за 3–5 минут

Success metricКак измеряем эффект у заказчика

Pricing impactВходит в базу / модуль / влияет на тариф

Security impactНовые доступы, данные, поверхности атаки

Certification impactВлияние на сертифицированный контур

Support modelL1/L2/L3, зоны сторон

RisksТехнические и коммерческие

Release targetВолна / релизное окно

Зачем паспорт Ownership, зависимости и критерии успеха фиксируются до разработки — Product Council работает с одинаково оформленными фактами, а не с презентациями. Поле «Источник сигнала» отделяет реальные боли от гипотез продуктовой команды; «Required telemetry» для Health Score, Lag Intelligence, Query Doctor и Data SLA — основа технического соглашения с Deckhouse по метрикам и API.

Приложение B · контроль достоверностиproduct view

Shipping validation checklist

Функция получает статус Shipping только при выполнении всех пунктов. Если хотя бы несколько отсутствуют — статус Development. Наличие возможности в open-source компоненте не делает её Shipping-функцией ANG.

Работает в коде продукта
Доступна в поддерживаемой сборке
Есть UI или документированный API
Есть документация
Есть мониторинг функции
Есть upgrade path
Есть support owner
Есть тестирование
Есть demo scenario
Воспроизводима не только на одном внутреннем стенде

Правило Shipping означает, что ANG превратил возможность в поддерживаемую продуктовую функцию — а не что она теоретически возможна в open-source.

Приложение C · коммерческая траекторияexec

Vanilla → ANG: путь расширения заказчика

Тот же land-and-expand, что в разделе 08 основного дека партнёрства, — теперь на уровне продуктовых ступеней.

1

Vanilla managed component

Заказчик получает управляемый Kafka / ClickHouse / Airflow / OpenSearch от Deckhouse

2

Обнаружение data-потребности

Компонент входит в промышленный data-сценарий: SLA, стоимость, качество, интеграции

3

ANG diagnostic / assessment

Быстрая диагностика: Health Score, дорогие запросы, риски SLA — демонстрация ценности до покупки

4

Подключение product pack

Первый ANG-модуль поверх работающего vanilla-компонента

5

Расширение на несколько компонентов

Data SLA и наблюдаемость поверх стека, а не одного сервиса

6

Переход к ANG Data Platform

Единая платформа: пайплайны, Lakehouse, витрины, консоль

7

Governance, SLA и support

Политики доступа, аудит, продуктовые SLA, единое окно поддержки

8

Renewal и расширение

Долгосрочное сопровождение, новые сценарии, рост чека

Vanilla — точка входа. ANG — путь расширения.

Deckhouse + ANG От Managed Serviceк Managed Data Product