Дорожная карта инфраструктурного масштабирования и упаковки вычислений (OVHcloud baseline)

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа

Этот документ фиксирует полный путь развёртывания и масштабирования вычислительной инфраструктуры платформы vitiana-api-platform в экосистеме OVHcloud — от стартовой минимальной конфигурации до зрелой многорегиональной системы.

Документ определяет:

• какую инфраструктуру заказывать на старте разработки и почему именно её;
• как меняется упаковка вычислений (compute packaging) от виртуальных машин (VPS) к выделенным серверам (bare metal) и многорегиональному развёртыванию;
• какие конкретные триггеры (метрические, доменные, регуляторные) запускают переход между фазами;
• приблизительные расходы на инфраструктуру по фазам в долларах в месяц и в год;
• какие управляемые сервисы OVHcloud (managed PostgreSQL, Object Storage, Managed Kubernetes Service, Managed Kafka и другие) подключаются на каждой фазе.

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

Связь с правилами и опорными документами

Этот документ построен от правил:

• Правило 00000 — платформа задаёт каноничную модель, инфраструктура подчиняется доменной архитектуре, поставщики не диктуют выбор железа.
• Современные лучшие практики (modern best practices) — паттерны облачных платформ верхнего уровня (Stripe, Cloudflare, Snowflake, Algolia).
• Эластичное масштабирование и упаковка по фазам (elastic scaling and packaging) — auto-scaling как baseline; упаковка через 4 фазы с триггерами.
• Развитие, не деградация (growth not degradation) — каждый переход между фазами — расширение, не миграция; никаких заглушек.
• Тезисное обоснование (thesis-based justification) — каждое решение содержит цели, тезисы поддержки, отклонённые альтернативы, принимаемые компромиссы.

Опорные документы платформы:

• Архитектурная основа платформы vitrip.store — общая ось развития платформы.
• Бизнес-сервисы (Business Services) — сервисная декомпозиция, которой подчиняется упаковка.
• Развёртывание и эксплуатационная модель (Deployment And Operating Model) — концептуальные контуры исполнения (execution contours).
• Технологический фундамент реализации (Implementation Technology Baseline) — рекомендуемый стек.
• Слой хранения и жизненный цикл данных (Storage Layer) — классы хранения (storage classes).
• Каноническая модель хранения (Database Schema) — постоянная модель данных.
• Событийная шина и асинхронная дисциплина (Eventing And Queue Baseline) — асинхронная координация.
• Наблюдаемость и реагирование на инциденты (Observability And Incident Response) — операционная видимость.
• Релизы и совместимость (Release Engineering And Migrations) — релизная дисциплина.
• Дорожная карта развития (Development Roadmap) — этапы зрелости платформы.

Главные принципы инфраструктурного решения

Принцип 1. Инфраструктура подчиняется домену, не наоборот

Архитектура платформы (каноничная доменная модель — canonical domain model, контракты поверхностей взаимодействия — surface contracts, политики истины — truth policies) — первична. Инфраструктура выбирается так, чтобы максимально дёшево и безопасно поддерживать домен на текущей фазе зрелости и не блокировать переходы между фазами.

Из этого следуют выводы:

• стартовая конфигурация — минимально достаточная для разработки (development), не «инвестиция в будущее»;
• фазы переключаются по достижению измеримых триггеров, не по календарю;
• ни одна инфраструктурная единица не цементируется как окончательная.

Принцип 2. OVHcloud как первичная среда упаковки, без замыкания (without vendor lock-in)

OVHcloud выбран как первичная экосистема упаковки вычислений по следующим тезисам:

• управляемые сервисы (managed services — PostgreSQL, Kafka, Object Storage, Kubernetes) реализованы по открытым стандартам (PostgreSQL вместо проприетарного Aurora, S3-совместимое объектное хранилище вместо проприетарного формата, стандартный Kubernetes API вместо EKS-специфичных расширений);
• частная сеть (vRack) объединяет VPS, Public Cloud и Bare Metal в единое адресное пространство, что позволяет плавную миграцию между типами упаковки без переделки сетевой архитектуры;
• датацентры в Страсбурге (Strasbourg, SBG), Варшаве (Warsaw, WAW), Франкфурте (Frankfurt, FRA) покрывают целевую географию первой волны (Восточная Европа + Казахстан) с правильной юрисдикцией для соответствия GDPR;
• цена входа (entry cost) для виртуального сервера (Virtual Private Server, VPS) — около 20 долларов в месяц при сроке оплаты вперёд на 12 месяцев (upfront 12 months);
• бесплатный сетевой трафик и API-вызовы для объектного хранилища (Object Storage) в Европе и Канаде — существенное ценовое преимущество против AWS/GCP;
• платформа не привязывается жёстко к OVH: managed PostgreSQL, S3-совместимое хранилище и стандартный Kubernetes легко мигрируются на AWS/GCP/Hetzner при необходимости.

Принимаемые компромиссы: OVHcloud имеет более узкий каталог сервисов по сравнению с AWS (нет аналога DynamoDB, нет аналога Lambda на текущий момент). Это соответствует нашему принципу не использовать проприетарные сервисы; компромисс приемлем.

Принцип 3. Виртуальные ресурсы → выделенные → многорегиональные (по триггерам)

Стратегия упаковки вычислений (compute packaging) разворачивается через 4 фазы:

1. Bootstrap (фаза запуска) — виртуальный сервер + управляемые базовые сервисы (managed services).
2. Service isolation (изоляция сервисов) — выделенные серверы (bare metal) для разных контуров исполнения (execution contours).
3. Workload-specific packaging (упаковка под профиль нагрузки) — выделенная инфраструктура под конкретные профили (latency-sensitive, throughput-heavy, financially-critical, machine learning serving).
4. Multi-region и dedicated infrastructure (многорегиональная и выделенная под клиента инфраструктура) — глобальное присутствие, выделенные пулы для премиум-клиентов.

Каждая фаза описана ниже с триггерами входа и выхода.

Принцип 4. Управляемые сервисы (managed services) первичны для всего, что не является основной ценностью платформы

Базы данных, очереди, поиск, объектное хранилище — берутся как managed-сервисы у OVHcloud. Своя ценность платформы — каноничная модель, бизнес-логика, контракты, а не самостоятельное администрирование PostgreSQL.

Тезисы:

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

Исключение: при достижении масштаба, где managed-сервис становится явно дороже self-hosted (фаза 3 и далее), отдельные сервисы могут быть перенесены в self-hosted на bare metal в рамках того же vRack.

Часть 1. Анализ экосистемы OVHcloud

1.1. Линейки compute (вычислительных ресурсов)

Виртуальные серверы (Virtual Private Server, VPS)

Линейка VPS 2026 содержит 6 моделей:

Модель	vCore	RAM	NVMe	Полоса (bandwidth)	Цена от
VPS-1	4	8 GB	75 GB SSD	400 Mbps	$6.46/мес
VPS-2	6	12 GB	100 GB NVMe	1 Gbps	$9.99/мес
VPS-3	8	24 GB	200 GB NVMe	1.5 Gbps	$19.97/мес
VPS-4	12	48 GB	300 GB NVMe	2 Gbps	$36.98/мес
VPS-5	16	64 GB	350 GB NVMe	2.5 Gbps	$54.82/мес
VPS-6	24	96 GB	400 GB NVMe	3 Gbps	$73.10/мес

Включено по умолчанию во все модели:

• защита от распределённых атак отказа в обслуживании (anti-DDoS infrastructure);
• автоматическое ежедневное резервное копирование (daily automatic backup) с хранением 24 часа;
• неограниченный сетевой трафик (только полоса ограничена);
• быстрое масштабирование одним кликом (1-click scaling) между моделями.

Платные опции для VPS:

• расширенное автоматическое резервное копирование (Premium Automated Backup) — $3.70/мес, хранение 7 дней, тройное копирование, расписание;
• ручной снимок состояния (Manual Snapshot) — $0.60/мес;
• внешнее хранилище (External Storage) — от $2.45 за 50 GB до $245 за 5 TB в месяц;
• дополнительный IP-адрес (Additional IP) — $2.39 за IP в месяц, до 16 IP, с гео-привязкой;
• балансировщик нагрузки (Public Load Balancer) — $22.99/мес.

Бюджетные выделенные серверы (Eco line — Rise)

Линейка Rise (бывшие Kimsufi/SoYouStart переименованы в Eco):

Модель	CPU	RAM	NVMe	Полоса	Цена от
RISE-S	AMD Ryzen 7 (8 ядер)	64 GB	512 GB NVMe	до 3 Gbps публичная, 1 Gbps приватная	$77/мес
RISE-M	средний уровень	до 64-128 GB	до 1 TB NVMe	до 3 Gbps	средняя
RISE-L	расширенный	128 GB	до 1.5 TB NVMe	до 3 Gbps	средняя
RISE-XL	AMD EPYC Turin (48 ядер)	128 GB	1.92 TB NVMe	до 3 Gbps	$354/мес

Особенности Eco:

• неограниченный входящий и исходящий трафик;
• частная сеть (vRack) на части моделей;
• более низкий уровень соглашения об уровне обслуживания (Service Level Agreement, SLA) по сравнению с основными линейками bare metal;
• хорошая цена за вычислительные ресурсы для пакетных нагрузок (batch workloads), приёма данных от поставщиков (ingestion), повторного воспроизведения событий (replay).

Промышленные выделенные серверы (Bare Metal Dedicated)

Полная линейка bare metal:

Линейка	Цена от	RAM	Полоса	SLA	Включён vRack
Advance	$107/мес	до 576 GB	3-5 Gbps	99.95%	да
Scale	$437/мес	до 1.5 TB	5-25 Gbps guaranteed	99.99%	да, поддерживает 3-AZ Paris
High Grade	$1,121/мес	до 2 TB	10-25 Gbps	99.99%	да, hot-swap дисков
Game	$166/мес	для игр и стриминга	средняя	средняя	нет
Storage	договорная	оптимизированы под HDD-хранилище	средняя	средняя	да

Применимость к нашей платформе:

• Advance — фаза 2 (изоляция сервисов): универсальные машины для разных контуров (canonical core, ingestion, financial-critical).
• Scale — фаза 3 (упаковка под профиль нагрузки): production-grade ядро с гарантированной полосой и развёртыванием в 3 зонах доступности (3-AZ).
• High Grade — фаза 4: выделенные пулы для премиум-клиентов с самыми строгими требованиями.
• Game — не применима, оптимизирована под другой профиль.
• Storage — фаза 3-4 для архивных снимков поставщиков и холодного хранилища (cold archive).

1.2. Управляемые сервисы (Public Cloud)

Управляемые базы данных (Managed Databases)

OVHcloud предлагает managed-сервисы для:

• PostgreSQL — основная реляционная база данных платформы. Используется для каноничной модели, транзакционных данных бронирований, журналов соответствия (governance log).
• MySQL — альтернативная реляционная СУБД, не используется в нашей архитектуре.
• MongoDB — документная база, не используется.
• Valkey — форк Redis для кэша и быстрого изменчивого состояния (volatile state).

Тарифы:

• Essential — стартовый, около $35-50 в месяц для минимальной конфигурации (2 vCore, 4 GB RAM, 80 GB);
• Business — production tier, около $200-400 в месяц для конфигурации с репликами на чтение (read replicas);
• Enterprise — критическая нагрузка, многорегиональное развёртывание, $1000+ в месяц.

Аналитика и стриминг

• Managed Kafka — событийная шина для доменных событий (domain events). Применяется на фазе 2 при вынесении событий в отдельный кластер.
• Managed ClickHouse — аналитическая база для журналов потребления (usage metering), агрегированных метрик. Применяется на фазе 3.
• Managed OpenSearch — поисковая проекция (search projection) каноничного инвентаря. Применяется на фазе 2-3.
• Managed Grafana — дашборды, применяется с фазы 1 (доступен бесплатно как часть стандартного мониторинга).

Хранилища

• Object Storage — S3-совместимое объектное хранилище. Тарифы: Standard, High Performance, Cold Archive. Бесплатный сетевой трафик и API-вызовы в Европе и Канаде.
• Block Storage — постоянные диски с высоким количеством операций ввода-вывода (high IOPS).
• File Storage — управляемое файловое хранилище для контейнеров.
• Cold Archive — экономичное долгосрочное хранение для журналов соответствия и архивных снимков поставщиков.

Контейнерная оркестрация и compute instances

• Managed Kubernetes Service (MKS) — управляемый Kubernetes. Контрольная плоскость (control plane) бесплатна, плата только за рабочие узлы (worker nodes).
• Compute Instances — виртуальные машины Public Cloud. Семейства: B3 (универсальные), C3 (оптимизированные под процессор), R3 (оптимизированные под память).
• Cloud GPU — для обучения моделей машинного обучения (machine learning training) и инференса (inference). Применяется на фазе 3.

Сетевые сервисы

• Private Networks — частные сети внутри Public Cloud.
• vRack — кросс-продуктовая частная сеть, объединяющая VPS, Public Cloud, Bare Metal.
• Public Load Balancer — балансировщик нагрузки, применяется на фазе 2 при появлении нескольких узлов одного контура.
• Floating IPs — плавающие IP-адреса для отказоустойчивости.

Сервисы машинного обучения (AI services)

• AI Training — обучение моделей.
• AI Deploy — развёртывание моделей в продакшен.
• AI Endpoints — готовые API для общих задач (классификация, эмбеддинги, генерация).
• AI Notebooks — среды для исследовательской работы.

Применяются на фазе 3 при появлении полноценного слоя машинного обучения (ranking, dynamic pricing, anomaly detection).

1.3. География датацентров

OVHcloud располагает 46 датацентрами на 4 континентах, 31 локальной зоной (Local Zones) и 44 точками присутствия (Points of Presence).

Релевантные регионы для платформы Vitiana:

Регион	Код	Применение
Strasbourg (Страсбург)	SBG	Основной регион для разработки и продакшен ядра. Низкая задержка (latency) до Украины, Чехии, Польши. EU-юрисдикция, GDPR-совместимость
Warsaw (Варшава)	WAW	Резервный регион для UA/PL. Используется для обучения восстановлению после аварии (disaster recovery) на фазе 2. Точка транзита трафика из Казахстана
Frankfurt (Франкфурт)	FRA	Альтернативный EU-регион для дополнительной избыточности на фазе 3-4
Roubaix (Рубе)	RBX	Резервный регион, основной для французского трафика
Gravelines (Гравелин)	GRA	Резервный регион
London (Лондон)	LON	Регион для британской юрисдикции (post-Brexit), может использоваться для отдельных юридических контуров на фазе 4
Paris (Париж)	DC	Единственный регион OVHcloud с развёртыванием в 3 зонах доступности (3-AZ deployment), доступен для Bare Metal Scale/High Grade. Используется на фазе 4 для критического booking-ядра
Beauharnois (Бохарнуа, Канада)	BHS	Регион для географической избыточности резервных копий и архивов на фазе 4

Триггер выбора региона: на фазе 1-2 — Страсбург. Перенос в Варшаву — при появлении регуляторных требований к локализации данных партнёров из Польши/Украины. Многорегиональность — фаза 4.

Часть 2. Стартовая конфигурация (фаза Bootstrap)

2.1. Цели стартовой конфигурации

Стартовая конфигурация (Tier 0) поддерживает следующие задачи:

• разработка каноничной доменной модели платформы (canonical domain model) — чисто документная работа на текущий момент, но требует среды для прототипов;
• перевод первой реализации приёма данных от поставщика Stuba (которая уже работает в home-to-go-api) к каноничной модели через адаптер ingestion;
• подготовка прототипа подключения второго поставщика (HomeToGo) для проверки независимости каноничной модели от структур поставщиков;
• развёртывание прототипа партнёрского API (Partner API) для первых интеграционных тестов;
• развёртывание прототипа Tour Builder с модульным API.

Стартовая конфигурация не предназначена для production-нагрузки внешних клиентов. Это среда разработки и тестирования.

2.2.0. Минимальный старт (без управляемых сервисов Public Cloud)

До запуска полной стартовой конфигурации (Tier 0, секция 2.2) возможен ещё более экономный вариант — когда вместо управляемых сервисов Public Cloud (managed PostgreSQL, managed Grafana, и так далее) разворачивается всё своё в Docker на главной dev-ноде. Этот вариант называется «Минимальный старт» и описывает реальное операционное состояние первого месяца разработки, когда платформа ещё не нагружена даже прототипом и платных сервисов Public Cloud не требуется.

Что покупается в Минимальном старте

Только два пункта, оба фиксированной цены без зависимости от потребления:

Позиция	Цена в месяц	Цена в год	Назначение
VPS-3 (2026) в Страсбурге	$19.97 (при оплате на 12 месяцев вперёд)	$239.64	Главная dev-нода. Каноничный core, среда сборки, контейнеры с PostgreSQL/Redis/OpenSearch/Grafana в Docker
Premium Automated Backup для VPS-3	$3.70	$44.40	Защита dev-данных и кода. Обязательно
Итого Минимальный старт	~$23.67	~$284	Двукратная экономия относительно Tier 0

Что бесплатно в Минимальном старте

• vRack (приватная сеть) — бесплатен всегда, не входит в управляемые сервисы Public Cloud, активируется в личном кабинете отдельно. Подключает VPS-3 в приватную сеть для будущих сервисов.
• Сам Public Cloud Project — регистрируется бесплатно, активирует стартовый кредит. Списания нет, пока не запущены платные управляемые сервисы. Сам факт существования проекта ничего не стоит.
• Стартовый кредит $200 — лежит на проекте до 12 месяцев, не сгорает по времени до этого срока. Не списывается, пока не активирован какой-либо платный управляемый сервис Public Cloud.
• Object Storage в пределах бесплатного уровня (free tier) — несколько гигабайт хранилища и трафик внутри Европейского Союза бесплатно. Достаточно для прототипных артефактов сборки и сырых данных от первого поставщика.
• Managed Grafana в пределах бесплатного уровня — до 5 пользователей, до 10 дашбордов, базовые алерты. Достаточно для команды одного-двух разработчиков на стадии прототипа. Альтернатива: свой Grafana в Docker на VPS-3, если ожидается превышение лимитов.

Что разворачивается в Docker на VPS-3

Все остальные базовые сервисы запускаются как контейнеры на главной dev-ноде:

• PostgreSQL 18 — каноничный store для прототипа архитектуры, отдельная база от текущей apivitianadb. Бэкап через pg_dump по cron, кладётся в Object Storage.
• Redis — кэш и временные структуры данных.
• OpenSearch или Elasticsearch open-source — поисковая проекция прототипа (если нужна на этапе).
• Grafana — собственный экземпляр без лимитов бесплатного уровня.
• Каноничный core на Go (или другом выбранном языке) — собственно прототип платформы.

24 ГБ оперативной памяти VPS-3 достаточно для одновременной работы PostgreSQL (4–8 ГБ под нагрузкой прототипа), Redis (512 МБ — 1 ГБ), OpenSearch (4–6 ГБ), 2–3 контейнеров Go-сервисов (по 200–500 МБ), инструментов разработки и среды сборки.

Когда переходить от Минимального старта к Tier 0

Переход в Tier 0 (с подключением Managed PostgreSQL Essential и оплатой свыше $63–83 в месяц) запускается при появлении любого из следующих триггеров:

• Размер базы прототипа превышает 20–30 ГБ — управление бэкапом своими руками становится тяжёлым.
• Команда разрабочиков вырастает до 3+ человек — нужна общая база с правами доступа, репликами для разработки.
• Регулярные интеграционные тесты с реальными данными от двух поставщиков — нагрузка превышает разумную для VPS-3.
• Появление первого внешнего тестового партнёра — требуется хотя бы один уровень изоляции БД от dev-машины.
• Деградация задержки PostgreSQL в контейнере на VPS-3 при росте размера индексов и числа соединений.

До этих триггеров Минимальный старт остаётся достаточным.

Тезисное обоснование Минимального старта

Тезис 1. На стадии Bootstrap главная работа — проектирование документации и прототипирование каноничной модели, не нагрузочное тестирование. Для этой работы достаточно собственной базы в Docker.

Тезис 2. Стартовый кредит $200 даётся на 12 месяцев и не сгорает раньше. Лучше потратить его в середине первого года, когда станет ясно, какой именно управляемый сервис нужен, чем «слить» его в первый месяц на сервис, который ещё не используется по назначению.

Тезис 3. Свой PostgreSQL в Docker — это легитимная стартовая практика для архитектурного прототипа, не «деградация». Переход на Managed PostgreSQL по триггеру — это расширение возможностей, не миграция данных (схема прототипа всё равно перепроектируется к моменту перехода).

Тезис 4. Минимальный старт даёт экономию ~$700–1000 в год относительно Tier 0. На стадии Bootstrap это разница между «быстро ставим» и «думаем над каждой подпиской». Архитектор должен думать над архитектурой, не над подписками.

Тезис 5. vRack уже включён бесплатно с VPS-3 — это значит переход к Tier 0 не требует переделки сетевой архитектуры. Когда Managed PostgreSQL станет нужен, он подключается в тот же vRack, к которому уже подключён VPS-3.

Принимаемые компромиссы Минимального старта

• Нет автоматического бэкапа PostgreSQL. Ручной pg_dump по cron в Object Storage. На стадии прототипа приемлемо.
• Нет автоматического failover. Если контейнер PostgreSQL упал — поднимается вручную из бэкапа. На стадии прототипа приемлемо.
• Нет репликации. Чтение и запись через один экземпляр. На стадии Bootstrap нет нагрузки, требующей чтения с реплики.
• Ограничение по оперативной памяти 24 ГБ на VPS-3 — серьёзная боевая база захочет 32–64 ГБ. Триггер перехода в Tier 0.
• Самоадминистрирование PostgreSQL — обновления, настройка, мониторинг через свои руки. Часть архитектурной работы на стадии Bootstrap.

2.2. Состав стартовой конфигурации (Tier 0)

Позиция	Конфигурация	Цена в месяц	Цена в год	Назначение
VPS-3 (2026) в Strasbourg	8 vCore, 24 GB RAM, 200 GB NVMe, 1.5 Gbps, anti-DDoS, daily backup	$19.97 (upfront 12 mo)	$239.64	Главная нода разработки. Каноничный core (Go), Redis локально, оркестрация, среда сборки (build environment), обработка прототипов
Premium Automated Backup для VPS-3	хранение 7 дней, тройное копирование, расписание	$3.70	$44.40	Защита dev-данных и кода. Обязательно
Public Cloud Project (стартовый кредит $200)	при регистрации	бесплатно (на старте $200 кредита)	покрывает первые 1-2 месяца	Доступ к managed PostgreSQL, Object Storage, MKS, vRack, Grafana
Managed PostgreSQL Essential	2 vCore, 4 GB RAM, 80 GB SSD, регион Strasbourg	$35-50 (начиная с 2-го месяца после кредита)	$420-600	Каноничный store для прототипа архитектуры. Отдельная база от текущей apivitianadb
Object Storage Standard	bucket, ~10 GB на старте, бесплатный трафик и API в EU	$5-10	$60-120	Хранение сырых данных от поставщиков (supplier raw payloads), снимков (snapshots), артефактов сборки, PDF-экспортов
vRack	частная сеть между VPS-3 и Public Cloud	бесплатно	бесплатно	Безопасное соединение всех компонентов
Managed Grafana	базовый тариф для дашбордов	бесплатно	бесплатно	Наблюдаемость с первого дня

Итого Tier 0 (после исчерпания стартового кредита): $63-83/мес = $764-1003 в год.

Если включить страховую опцию резервного копирования:

Опция	Цена в месяц	Цена в год
Backup для Managed PostgreSQL (включён в тариф)	0	0
Cold Archive для журналов соответствия (governance log)	$2-5	$24-60

2.3. Тезисное обоснование выбора VPS-3 как главной dev-ноды

Цель

Запустить разработку зрелой архитектуры платформы Vitiana при минимальных операционных и финансовых издержках на стартовую инфраструктуру.

Тезисы поддержки

1. 8 vCore + 24 GB RAM покрывают одновременно: PostgreSQL-клиент (без локальной полной БД, БД вынесена в managed), Redis локально, 3-5 контейнеров Go-сервисов прототипа, инструменты разработки, среду сборки. Это не production-нагрузка, это рабочая станция для архитектора и первой команды разработки.
2. 200 GB NVMe даёт запас под две полные копии тестовой базы данных, локальные образы контейнеров, артефакты сборки, журналы.
3. 1.5 Gbps неограниченного трафика превышает реальную потребность фазы Bootstrap в десятки раз. Запас на нагрузочные тесты приёма данных от поставщиков.
4. Защита от DDoS включена бесплатно — базовая защита для первых внешних тестов партнёрского API.
5. vRack включён — критическое преимущество. VPS-3 на старте подключается к vRack; при переходе на фазу 2 (Bare Metal Advance) этот VPS остаётся в той же приватной сети как dev-нода без переделки сетевой архитектуры.
6. Цена 19.97/мес при оплате вперёд на 12 месяцев — на фоне инфраструктурных бюджетов современных платформ — пренебрежимо мало. Менее 250 долларов в год за полноценную dev-среду.
7. Виртуализация позволяет быстрое масштабирование одним кликом между моделями линейки 2026 — переход VPS-3 → VPS-4 (если временно нужна большая RAM) занимает минуты без миграции данных.

Альтернативы и почему они отклонены

VPS-1 (4 vCore / 8 GB / 75 GB / $6.46/мес). Слишком тесно. Локальная пара Go-сервисов плюс инструменты разработки уже выходят за 8 GB RAM. Отклонено.

VPS-2 (6 vCore / 12 GB / 100 GB / $9.99/мес). Пограничный вариант. 12 GB RAM заставит постоянно выбирать между запуском компонентов. Создаёт операционные ограничения. Отклонено.

VPS-4 (12 vCore / 48 GB / 300 GB / $36.98/мес). Избыточен для дева на старте. Дополнительные 24 GB RAM не используются. При переходе к фазе 2 цель — bare metal, не VPS-4. Отклонено как промежуточная избыточность.

Eco RISE-S ($77/мес, AMD Ryzen 7 8 ядер, 64 GB RAM, 512 GB NVMe). Соблазнительно по цене за 64 GB RAM и физический процессор. Но: выделенное железо требует самостоятельной настройки резервного копирования, нет включённого vRack на всех моделях, и выделенное железо нужно только когда упёрлись в накладные расходы виртуализации (virtualization overhead). На старте это преждевременная оптимизация (см. правило роста, не деградации — growth not degradation). Отклонено.

Bare Metal Advance ($107/мес). Это уже фаза 2. Преждевременно. Отклонено.

Сразу Managed Kubernetes с 3 узлами Compute Instances B3 ($150-200/мес). Преждевременная контейнеризация. На старте достаточно одной VPS с docker-compose или native Go-процессами. Контейнерная оркестрация добавляется при появлении нескольких узлов. Отклонено.

Принимаемые компромиссы

• 24 GB RAM — это dev-уровень. PostgreSQL под нагрузкой захочет 32-64 GB. Компромисс снимается тем, что серьёзная база вынесена в Managed PostgreSQL (Public Cloud), а VPS-3 — рабочая станция, не БД-сервер.
• Premium Backup стоит дополнительные $3.70/мес. Без него — только 24-часовое резервное копирование. Для критического слоя обязательно купить премиум-вариант.
• Одна зона доступности (single AZ). Нет геоизбыточности на старте. Это нормально для фазы Bootstrap; восстановление после аварии (DR) и многорегиональность вынесены в фазу 4.
• Виртуальный процессор (vCore). Производительность ниже выделенного. Для разработки приемлемо; для производственного критического пути — нет.

Связь с другими решениями

Опирается на:

• правило 00000 (платформа сама решает, как масштабироваться, поставщики не диктуют);
• эластичное масштабирование и упаковка (фаза Bootstrap определена в feedback_elastic_scaling_and_packaging.md);
• развитие, не деградация (VPS-3 — не заглушка, а полноценная dev-нода с миграционным путём через vRack).

Поддерживает:

• разработку первых архитектурных документов (этот документ — пример, который сам себя подтверждает);
• прототип каноничной доменной модели;
• первый адаптер приёма данных от поставщика, переводящий Stuba-формат в каноничный.

Современные практики, на которых основано

Stripe, Twilio начинали с одной EC2-нодой и подключали managed-сервисы по мере зрелости. Cloudflare и Algolia используют тот же подход «виртуальный compute для control plane, выделенное железо для data plane». VPS-3 + Managed PostgreSQL Public Cloud — это тот же паттерн.

2.4. Что не заказывается на старте

Следующее не покупается в Tier 0 и появляется только при достижении соответствующих триггеров фазы 2:

• Bare Metal Advance ($107+) — преждевременно. Триггер: реальная нагрузка приёма данных от двух поставщиков плюс начало интеграционных тестов с реальными партнёрами.
• Bare Metal Scale ($437+) — фаза 3 минимум.
• Bare Metal High Grade ($1,121+) — фаза 4.
• Eco Rise — рассматривается как пул работников (worker pool) для тяжёлых задач приёма данных на фазе 2-3.
• AI Training/Deploy — фаза 3 (после оформления слоя машинного обучения).
• Развёртывание в 3 зонах доступности (3-AZ Paris) — фаза 4.
• Managed Kafka — фаза 2 (при появлении нескольких контуров, генерирующих доменные события).
• Managed OpenSearch — фаза 2 (при появлении поисковой проекции).
• Public Load Balancer ($22.99/мес) — фаза 2 (при нескольких узлах одного контура).
• Cloud GPU — фаза 3.

Часть 3. Фаза 1 — Bootstrap

3.1. Описание фазы

Цель фазы: доказать жизнеспособность ядра, приёма данных, путей offer/quote/booking. Подготовить прототипы новых документных доменов. Подключить второго поставщика как тест на независимость каноничной модели от структур поставщиков.

Длительность ориентировочно: 6-12 месяцев с момента запуска разработки.

Состав инфраструктуры (Tier 0 + расширения):

Базовый Tier 0 (см. часть 2). Дополнительно по мере необходимости:

• Второй VPS-3 в Warsaw для упражнений по восстановлению после аварии (DR drills) и тестирования многорегиональной репликации — $19.97 + $3.70 backup = $23.67/мес.
• Managed Kubernetes Service control plane (бесплатно) + первый рабочий узел B3-8 на 8 vCore/30 GB — около $80-120/мес. Появляется, когда количество контейнеризованных сервисов перестаёт умещаться на одной VPS.

3.2. Расходы фазы 1

Минимальный сценарий:

Позиция	$/мес	$/год
VPS-3 + Premium Backup в Strasbourg	23.67	284
Managed PostgreSQL Essential	35-50	420-600
Object Storage Standard (~10-50 GB)	5-15	60-180
Cold Archive (журналы соответствия)	2-5	24-60
Итого минимум	66-94	788-1124

Расширенный сценарий с DR и MKS:

Позиция	$/мес	$/год
Tier 0 минимум	66-94	788-1124
Второй VPS-3 в Warsaw	23.67	284
MKS control plane	0	0
Первый worker B3-8	80-120	960-1440
Итого расширенный	170-238	2032-2848

Диапазон расходов фазы 1: от $800 до $2900 в год. Это сопоставимо со стоимостью одного дня старшего инженера, что подтверждает принцип «инфраструктура подчиняется домену».

3.3. Триггеры выхода в фазу 2

Переход в фазу 2 запускается при достижении любого из следующих условий:

Триггеры производительности:

• Регулярное превышение использования CPU/RAM на VPS-3 при штатной нагрузке: устойчиво более 70% за 7 последовательных дней при отсутствии искусственных нагрузочных тестов.
• Задержка на 95-м процентиле (latency p95) на dev-API превышает порог приемлемого для нагрузочных тестов: устойчиво более 500 мс при типичных запросах поиска.

Триггеры доменные:

• Подключён реальный поток данных от второго поставщика (HomeToGo) в production-режиме, проверяющий независимость каноничной модели.
• Первые внешние партнёры активировали API-доступ (даже на бесплатном уровне) с регулярным трафиком (более 1000 запросов в день суммарно).
• Запущен production-режим хотя бы одного из основных контуров: ядро каноничного inventory, поиск, или прототип бронирования (booking commit).
• Полная цепочка от приёма данных от поставщика до публикации предложения партнёру (full ingestion → publication chain) работает на реальных данных.

Триггеры финансовые:

• Первый платный партнёр API подписан и платит за доступ.
• Объём ежемесячных бронирований через платформу превышает порог окупаемости минимальной production-инфраструктуры.

Триггеры регуляторные:

• Появляется обязательство по соответствию нормативам (compliance) — например, обработка данных польских граждан требует выделенной обработки.

Триггеры операционные:

• Команда расширилась до 5+ инженеров, и одна dev-нода становится узким местом совместной работы.

Часть 4. Фаза 2 — Service isolation (изоляция сервисов)

4.1. Описание фазы

Цель фазы: разделить контуры исполнения по операционному профилю. Контуры с разными требованиями к задержке, пропускной способности, надёжности — на разной инфраструктуре. Запустить production-режим для агентского контура и бета-режим для партнёрского API.

Длительность ориентировочно: 12-24 месяца от старта (то есть фаза 2 длится примерно 6-12 месяцев).

Контуры исполнения, разделяемые на этой фазе:

1. Контур чувствительный к задержке (latency-sensitive): поиск (search), партнёрский API (Partner API), агентский интерфейс (agency surface), шлюз API (API gateway). Требование — стабильная задержка p99 на пользовательских запросах.
2. Контур интенсивный по пропускной способности (throughput-heavy): воркеры приёма данных от поставщиков (Rust ingestion workers), пайплайны нормализации и матчинга. Требование — высокая пропускная способность, не критична задержка.
3. Контур чувствительный к воспроизведению (replay-sensitive): изолированный пул для повторного воспроизведения событий после изменения логики нормализации, без влияния на живой трафик.
4. Контур финансово-критический (financially-critical): инициирование бронирования (booking commit), генерация событий взаиморасчётов (settlement event generation), журнал соответствия (governance log). Требование — повышенная надёжность, изолированные ресурсы.
5. Контур внутреннего управления (internal control): governance review, поддержка операторов, интерфейс администратора. Меньшая нагрузка, но требует изоляции от внешнего трафика.

4.2. Состав инфраструктуры фазы 2

Позиция	Конфигурация	Назначение	$/мес
Bare Metal Advance #1 в Strasbourg	базовый тариф, 64-128 GB RAM, 2× NVMe, 3 Gbps, vRack	Контур чувствительный к задержке (поиск, API gateway, партнёрский API)	107-180
Bare Metal Advance #2 в Strasbourg	базовый тариф, 64-128 GB RAM, 2× NVMe, vRack	Контур интенсивный по пропускной способности (приём данных, нормализация)	107-180
Bare Metal Advance #3 в Strasbourg	базовый тариф, 64 GB RAM, vRack	Контур финансово-критический (бронирование, взаиморасчёты, журнал соответствия)	107-150
Managed PostgreSQL Business	8 vCore, 32 GB RAM, 500 GB SSD, читающие реплики (read replicas)	Каноничный store с разделением чтения и записи	250-450
Managed Kafka (стартовый кластер)	3 брокера, базовая конфигурация	Доменные события и асинхронная координация	200-400
Managed OpenSearch (минимальный)	3 узла, базовая конфигурация	Поисковая проекция каноничного inventory	250-400
Object Storage	расширенный объём, ~500 GB	Хранение сырых данных, снимков, журналов соответствия	25-50
Cold Archive	для журналов соответствия и архивов	Долгосрочное retention для соответствия	5-15
Public Load Balancer	1 балансировщик	Распределение трафика на узлы	22.99
Managed Kubernetes	control plane бесплатно, 3-5 рабочих узлов B3	Контейнерная оркестрация для гибких сервисов	240-600
VPS-3 dev-нода	продолжает работать как dev	Разработка, не production	23.67
VPS-3 в Warsaw	DR-узел	Упражнения по восстановлению, multi-region staging	23.67
Premium Backup для всех	premium тарифы для критических узлов	Защита данных	30-50

4.3. Расходы фазы 2

Минимальный сценарий:

Категория	$/мес	$/год
Bare Metal Advance × 3	321-510	3852-6120
Managed PostgreSQL Business	250-450	3000-5400
Managed Kafka	200-400	2400-4800
Managed OpenSearch	250-400	3000-4800
Object Storage + Cold Archive	30-65	360-780
Public Load Balancer	22.99	276
Managed Kubernetes (3-5 worker B3-8)	240-600	2880-7200
VPS dev + DR + резервные копии	80-110	960-1320
Итого минимум	1394-2562	16728-30696

Диапазон расходов фазы 2: от $17 000 до $31 000 в год. Это уже промышленная инфраструктура для production-режима первой команды партнёров и собственных каналов.

4.4. Триггеры выхода в фазу 3

Триггеры производительности:

• Один партнёр стабильно создаёт нагрузку, влияющую на задержки других партнёров (нарушение принципа справедливого распределения, fair-share).
• Конкретный поставщик стабильно создаёт пики приёма данных (ingestion peaks), которые мешают сборке предложений (offer assembly).
• Объём событий взаиморасчётов превышает обработку базового кластера и требует выделенных мощностей.

Триггеры доменные:

• Приём данных от 5+ поставщиков с разными соглашениями об уровне обслуживания.
• Появление премиум-партнёров, требующих гарантированной полосы и изолированных мощностей.
• Запуск слоя машинного обучения (recommendation, ranking, dynamic pricing, anomaly detection) с реальной production-нагрузкой.

Триггеры регуляторные:

• Регуляторные требования к локализации данных (data residency) для отдельных стран — например, обязательство хранить данные польских граждан в польском датацентре.
• Сертификационные требования (SOC 2, ISO 27001) к выделенным контурам.

Триггеры финансовые:

• Объём бронирований превышает порог, при котором текущие шумные соседи (noisy neighbors) на shared-инфраструктуре стоят дороже выделенных пулов.

Часть 5. Фаза 3 — Workload-specific packaging (упаковка под профиль нагрузки)

5.1. Описание фазы

Цель фазы: оптимизировать стоимость и соглашения об уровне обслуживания через выделение специализированной инфраструктуры под конкретные профили нагрузки. Запустить полноценный слой машинного обучения. Развернуть инфраструктуру под премиум-клиентов.

Длительность ориентировочно: 24-36 месяцев от старта (фаза длится примерно 12-18 месяцев).

Профили нагрузки и их упаковка:

1. Тяжёлый приём данных (heavy ingestion, Rust workers) — переезжает на Eco Rise серверы или dedicated bare metal с оптимизацией под пакетную обработку. Стоимость на единицу пропускной способности — лучшая в линейке.
2. Чувствительное к задержке ядро (latency-critical core, Go services) — переезжает на Bare Metal Scale с гарантированной полосой, размещённый рядом с шлюзом для минимальной сетевой задержки.
3. Поисковый движок (search engine, OpenSearch) — выделенный кластер, возможно с многорегиональным развёртыванием для глобальной задержки.
4. Слой баз данных (database tier) — разделение по доменам: каноничный store, supplier trace, booking, governance. Возможно отдельные кластеры PostgreSQL для разных доменов.
5. Инференс машинного обучения (ML inference) — выделенная инференсная инфраструктура, потенциально с GPU-ускорением для дорогих моделей (например, эмбеддинги для семантического поиска, ранжирование).
6. Изоляция премиум-клиентов (premium tenant isolation) — выделенные пулы Bare Metal для крупных партнёров с гарантированной мощностью и изолированной сетью.

5.2. Состав инфраструктуры фазы 3

Позиция	Конфигурация	Назначение	$/мес
Bare Metal Scale в Strasbourg	до 1.5 TB RAM, 25 Gbps guaranteed, 99.99%, vRack, 3-AZ Paris	Чувствительное к задержке ядро (production-критическое)	437-900
Eco Rise XL в Strasbourg	AMD EPYC Turin 48 ядер, 128 GB, 1.92 TB NVMe	Тяжёлые ingestion workers, batch обработка	354
Eco Rise M-L (несколько)	средние конфигурации	Дополнительные ingestion и replay workers	100-250 каждый
Managed PostgreSQL Enterprise	16+ vCore, 64 GB+, многорегиональные реплики	Каноничный store с многорегиональной репликацией	800-1500
Managed Kafka Production cluster	dedicated, 6+ брокеров, многорегиональный	Production событийная шина	800-1500
Managed OpenSearch Production	dedicated, многорегиональный кластер	Поисковая проекция, многорегиональная	800-1500
Managed ClickHouse	для аналитики и журналов потребления	Хранилище данных для аналитики	500-1000
AI Training (Cloud GPU)	в зависимости от расписания обучения	Обучение моделей ранжирования и рекомендаций	500-2000
AI Deploy	инференс модели в продакшен	Серверы инференса	200-500
AI Endpoints	готовые API (эмбеддинги, классификация)	Готовые сервисы машинного обучения	100-300
Bare Metal Storage	оптимизированы под HDD-хранилище	Холодный архив сырых данных от поставщиков	200-400
Object Storage High Performance	для горячих данных	Производительное хранилище	100-300
Cold Archive расширенный	для долгосрочного retention	Архивы	50-150
Premium tenant pool	1-2 выделенных Bare Metal Advance/Scale для премиум-клиентов	Изолированные мощности для платящих партнёров	200-600
Public Load Balancer	несколько балансировщиков для разных контуров	Распределение трафика	70-150
Managed Kubernetes Multi-region	расширенный, более 10 рабочих узлов	Production контейнерная оркестрация	800-2000
VPS dev + staging	продолжают работать	Разработка	50-100

5.3. Расходы фазы 3

Базовый сценарий фазы 3:

Категория	$/мес	$/год
Bare Metal Scale + Eco Rise + premium pools	1500-2500	18 000-30 000
Managed PostgreSQL Enterprise	800-1500	9600-18 000
Managed Kafka + OpenSearch + ClickHouse	2100-4000	25 200-48 000
Слой машинного обучения (AI Training, Deploy, Endpoints, GPU)	800-2800	9600-33 600
Хранилища (Object, Block, Cold)	250-700	3000-8400
Балансировщики и сетевые сервисы	70-150	840-1800
Managed Kubernetes Multi-region	800-2000	9600-24 000
Резервные копии, dev, staging, мониторинг	100-200	1200-2400
Итого минимум	6420-13850	77 000-166 000

Диапазон расходов фазы 3: от $77 000 до $166 000 в год. Это уже инфраструктура полноценной B2B-платформы с собственным слоем машинного обучения, поддержкой нескольких премиум-партнёров и production-операциями.

5.4. Триггеры выхода в фазу 4

Триггеры регуляторные:

• Подтверждённые требования к локализации данных одновременно для нескольких независимых юрисдикций (EU + UA отдельно + KZ отдельно), требующие физически разделённых датацентров.
• Сертификационные требования enterprise-класса (ISO 27001, SOC 2 Type II, специфические местные стандарты).

Триггеры коммерческие:

• Подписание enterprise-контракта с партнёром, требующим выделенной инфраструктуры (dedicated infrastructure SLA).
• Объём входящего трафика превышает возможности одного региона.

Триггеры производительности:

• Глобальное распределение пользователей (партнёров и их конечных клиентов) требует низкой задержки в нескольких регионах одновременно.

Триггеры устойчивости:

• Бизнес-непрерывность требует geo-redundancy с контролируемым переключением (controlled failover).

Часть 6. Фаза 4 — Multi-region и dedicated infrastructure (многорегиональная и выделенная инфраструктура)

6.1. Описание фазы

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

Длительность ориентировочно: 36+ месяцев от старта.

Принципы упаковки:

1. Многорегиональное активно-активное (multi-region active-active) — для путей чтения (search, content, public API). Несколько регионов одновременно обслуживают трафик с маршрутизацией по близости.
2. Многорегиональное активно-пассивное (multi-region active-passive) — для путей записи (booking commit, settlement) с явной моделью согласованности (consistency model).
3. Выделенная инфраструктура для enterprise-клиентов — отдельный кластер, отдельная база данных, отдельное сетевое пространство.
4. Граничные вычисления (edge compute) — для регионов с высокой задержкой, если CDN-edge функции релевантны (например, для поверхностей поиска).
5. План восстановления после аварии (disaster recovery, DR) — с явными целями восстановления времени (RTO — Recovery Time Objective) и точкой восстановления (RPO — Recovery Point Objective), геоизбыточные резервные копии (geo-redundant backup).

6.2. Состав инфраструктуры фазы 4

Позиция	Конфигурация	Назначение	$/мес
Bare Metal High Grade в Paris (3-AZ)	до 2 TB RAM, 25 Gbps, 99.99%, hot-swap дисков	Production ядро критического booking-контура с развёртыванием в 3 зонах	1121-2500
Bare Metal Scale в Strasbourg	продолжают работать как region 2	Поддержка и резерв	437-900
Bare Metal Scale в Warsaw	Polish/Ukrainian compliance	Локализация данных для UA/PL юрисдикции	437-900
Bare Metal в Frankfurt	дополнительный регион EU	Geo-redundancy	437-900
Bare Metal в Beauharnois (Канада)	геоизбыточный backup, архив	DR-копии и cold archive в другом полушарии	437-900
Enterprise dedicated pool	по одному Bare Metal High Grade на премиум-клиента	Физическая изоляция	1121+ × N клиентов
Managed PostgreSQL Enterprise multi-region	реплики во всех релевантных регионах	Многорегиональная консистентность чтения	2000-5000
Managed Kafka Multi-region cluster	mirror-makers между регионами	Доменные события глобально	1500-3500
Managed OpenSearch Multi-region	реплики поисковой проекции	Глобальный поиск	1500-3500
AI ML Platform Enterprise	dedicated GPU pools, расширенное обучение	Ranking, dynamic pricing, anomaly detection	2000-5000
Object Storage Multi-region	репликация между EU и Канадой	Геоизбыточные сырые данные	200-500
Cold Archive Multi-region	долгосрочное хранение в нескольких регионах	Соответствие нормативам	100-300
Local Zones (edge)	для high-latency регионов	Граничные вычисления	200-500

6.3. Расходы фазы 4

Базовый сценарий (без enterprise-клиентов):

Категория	$/мес	$/год
Bare Metal Multi-region (Paris 3-AZ + Strasbourg + Warsaw + Frankfurt + Beauharnois)	2900-6100	35 000-73 000
Managed PostgreSQL Multi-region	2000-5000	24 000-60 000
Managed Kafka + OpenSearch Multi-region	3000-7000	36 000-84 000
AI ML Platform Enterprise	2000-5000	24 000-60 000
Хранилища Multi-region	300-800	3600-9600
Edge / Local Zones	200-500	2400-6000
Сетевые сервисы и балансировщики	200-500	2400-6000
Резервные копии, мониторинг, dev	200-400	2400-4800
Итого базовый	10 600-25 300	129 000-303 000

При добавлении enterprise-клиентов с выделенной инфраструктурой — каждый добавляет от $1500 до $5000 в месяц (от $18 000 до $60 000 в год) сверху, что полностью покрывается платой клиента за enterprise-уровень доступа.

Диапазон расходов фазы 4: от $130 000 до $300 000+ в год. Это инфраструктура зрелой глобальной B2B-платформы.

Часть 7. Сводная таблица по фазам

Фаза	Длительность от старта	Основная упаковка	$/мес	$/год	Триггеры выхода
Bootstrap (0-1)	0-12 мес	VPS-3 + Managed PostgreSQL Essential + Object Storage	66-238	800-2900	Нагрузка > 70% CPU/RAM, второй поставщик в production, первый партнёр API, команда 5+ инженеров
Service isolation (2)	12-24 мес	Bare Metal Advance × 3 + Managed Kafka + OpenSearch + MKS	1400-2600	17 000-31 000	Шумные соседи, ML-нагрузка, регуляторная локализация, 5+ поставщиков, premium-партнёры
Workload-specific (3)	24-36 мес	Bare Metal Scale + Eco Rise + Managed Enterprise + AI Platform	6400-13 900	77 000-166 000	Глобальное распределение пользователей, enterprise-контракт, geo-redundancy для бизнес-непрерывности
Multi-region (4)	36+ мес	Bare Metal Multi-region + 3-AZ Paris + Multi-region managed services + Edge	10 600-25 300 (+ enterprise pools)	130 000-300 000+	Дальнейшее расширение по странам, новые континенты, специальные регуляторные требования

Часть 8. Конкретный список действий на старте

8.1. Что заказать прямо сейчас

Действия в порядке выполнения в панели управления OVHcloud:

1. Зарегистрировать (или подтвердить) основной аккаунт OVHcloud.

2. Заказать VPS-3 (модель 2025 или 2026, эквивалентная):

   • Регион: Strasbourg (SBG).
   • Конфигурация: 8 vCore, 24 GB RAM, 200 GB NVMe, 1.5 Gbps unlimited bandwidth.
   • Тариф: оплата вперёд на 12 месяцев (upfront 12 months).
   • Операционная система: Debian 12 LTS или Ubuntu 24.04 LTS (выбирается командой; обе подходят).

3. Активировать опцию Premium Automated Backup для VPS-3 ($3.70/мес). Это обязательная защита dev-данных.

4. Создать Public Cloud Project в том же аккаунте:

   • При создании активируется $200 starter credit.
   • Регион проекта: Strasbourg (SBG).

5. Создать Managed PostgreSQL Essential в Public Cloud:

   • Тариф Essential, минимальная конфигурация (2 vCore, 4 GB RAM, 80 GB).
   • Регион: Strasbourg.
   • Имя инстанса: например, vitiana-canonical-dev.
   • Включить ежедневное резервное копирование (входит в тариф).

6. Создать Object Storage bucket:

   • Регион: Strasbourg.
   • Тип: Standard.
   • Имя: например, vitiana-supplier-traces-dev для сырых данных от поставщиков.
   • Создать второй bucket для артефактов и экспорта: vitiana-artifacts-dev.

7. Включить vRack:

   • В аккаунте → Network → vRack.
   • Создать новый vRack (бесплатно).
   • Прикрепить VPS-3 к этому vRack.
   • Прикрепить Public Cloud Project к этому vRack.
   • Прикрепить Managed PostgreSQL и Object Storage (через приватные эндпоинты в vRack).

8. Настроить Managed Grafana (бесплатно) для базовых дашбордов.

8.2. Чек-лист стартовой конфигурации

После выполнения шагов выше в аккаунте должны быть:

• VPS-3 в Strasbourg, активный, доступен по SSH.
• Premium Automated Backup активирован для VPS-3.
• Public Cloud Project с активным $200 кредитом.
• Managed PostgreSQL Essential инстанс, доступен из VPS через приватный эндпоинт vRack.
• Два Object Storage bucket в Strasbourg.
• vRack настроен, VPS и Public Cloud в одной приватной сети.
• Managed Grafana развёрнут.

8.3. Что делается на VPS-3 в первые 2 недели

Это пограничный список для команды разработки (формально — за пределами архитектурной документации):

• Установка Docker и docker-compose.
• Установка Go-toolchain (или будущий стек, если будет принято иное решение).
• Настройка SSH-ключей доступа для команды.
• Базовая настройка fail2ban, обновление системы.
• Настройка экспорта метрик в Managed Grafana.
• Первый прототип каноничной модели в виде Go-сервиса.
• Первый клиент Stuba для импорта данных в каноничную модель (через адаптер ingestion).

Часть 9. Развилки и открытые вопросы

9.1. Развилка: AWS/GCP/Hetzner вместо OVHcloud

OVHcloud выбран как первичная экосистема. Альтернативы:

AWS — самый широкий каталог сервисов, но:

• стоимость сетевого трафика и хранилища выше;
• проприетарные сервисы (DynamoDB, Lambda, Kinesis) создают замыкание;
• более сложная стоимостная модель.

GCP — хорошие managed-сервисы (особенно BigQuery, Spanner), но:

• меньшее присутствие в Восточной Европе;
• проприетарные сервисы аналогично AWS.

Hetzner — лучшая цена за выделенное железо, но:

• слабее managed-экосистема (нет аналога Managed PostgreSQL уровня Public Cloud OVH);
• меньше регионов.

Решение: OVHcloud как первичная среда. Открытая развилка: на фазе 4 рассмотреть многооблачную (multi-cloud) стратегию для отдельных нагрузок, если AWS/GCP даёт критическое преимущество (например, более развитый AI-стек). Эскалируется пользователю при появлении конкретного кейса.

9.2. Развилка: момент перехода на 3-AZ Paris

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

Альтернативы:

• использовать 3-AZ Paris как основное production-ядро с фазы 3;
• использовать многорегиональное активно-активное развёртывание без 3-AZ (Strasbourg + Warsaw + Frankfurt) с собственной репликацией.

Решение: на фазе 4 — 3-AZ Paris для booking commit (критическая транзакционность), активно-активное многорегиональное развёртывание для путей чтения (поиск, контент). Открытая развилка: финальное решение зависит от метрик задержки между Paris и Восточной Европой на момент перехода в фазу 4.

9.3. Развилка: переход с managed на self-hosted PostgreSQL

Managed PostgreSQL OVHcloud — удобство, но не самая дешёвая опция при больших объёмах.

Триггер пересмотра: когда стоимость Managed PostgreSQL Enterprise превышает стоимость 2× Bare Metal с самостоятельной репликацией PostgreSQL и оплатой работы DBA (Database Administrator).

Решение: не пересматривать на фазах 1-3. Открытая развилка для фазы 4 — эскалируется пользователю.

9.4. Развилка: Cloud GPU vs собственные GPU-ноды для машинного обучения

OVHcloud Cloud GPU предлагает как обучение, так и инференс.

Триггер пересмотра: когда регулярные GPU-нагрузки (постоянный инференс высокочастотных моделей) делают Cloud GPU дороже выделенного GPU-сервера.

Решение: на фазе 3 — Cloud GPU для обучения, инференс — на CPU где возможно, на отдельных GPU-инстансах где обязательно. Открытая развилка для фазы 4 — рассмотреть Bare Metal с GPU.

Часть 10. Связанная документация

• Архитектурная основа платформы vitrip.store
• Развёртывание и эксплуатационная модель (Deployment And Operating Model)
• Технологический фундамент реализации (Implementation Technology Baseline)
• Слой хранения и жизненный цикл данных (Storage Layer)
• Каноническая модель хранения (Database Schema)
• Событийная шина и асинхронная дисциплина (Eventing And Queue Baseline)
• Бизнес-сервисы (Business Services)
• Наблюдаемость и реагирование на инциденты (Observability And Incident Response)
• Релизы и совместимость (Release Engineering And Migrations)
• Дорожная карта развития (Development Roadmap)

Часть 11. Что нужно сделать дальше после этого документа

После принятия этой дорожной карты пользователем — следующие шаги в порядке зависимости:

1. Заказать стартовую конфигурацию по части 8.
2. Создать документ operations/initial-infrastructure-setup.md — фактическая запись развёрнутой инфраструктуры (что заказано, какие IP-адреса, какие endpoints, как соединено в vRack). Этот документ обновляется при каждом изменении инфраструктуры.
3. Обновить reference/implementation-technology-baseline.md — добавить раздел про OVHcloud-экосистему как первичную среду упаковки с условиями миграции.
4. Обновить operations/deployment.md — добавить связки с фазовой моделью этого документа.
5. Создать operations/disaster-recovery-and-capacity.md — план восстановления после аварии и планирование мощности (capacity planning), фазовый.
6. Создать operations/runbooks-incident-playbooks.md — операционные руководства, фазовые.

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

Уточнение (28.04.2026) — фаза 6 документы созданы, связи актуальны

Документ опубликован 26.04.2026 в Фазе 4 (инфраструктурная дорожная карта). На момент его публикации документы Фазы 6 (runbooks-incident-playbooks.md, sla-and-on-call-model.md, disaster-recovery-and-capacity.md) ещё не были созданы — упомянуты как «нужно создать». На 27.04.2026 все три документа Фазы 6 опубликованы.

Опубликованные документы Фазы 6

• ✅ operations/runbooks-incident-playbooks.md — 8 каноничных incident classes с детальными процедурами, эскалация, post-mortem culture;
• ✅ operations/sla-and-on-call-model.md — 5 каноничных сущностей SLA, 10 SLI metrics, 4 tier (Free/Starter/Professional/Enterprise), 5-уровневая on-call structure, service credits, burnout protection;
• ✅ operations/disaster-recovery-and-capacity.md — 4 recovery tiers, 5-шаговая процедура восстановления, 5 типов DR drills, capacity planning процесс.

Каноничные связи между этим документом и фазой 6

Capacity (этот документ) ↔ Capacity planning (DR document)

• этот документ определяет infrastructure shape per phase (Phase 1 OVH Public Cloud Eco → Phase 4 multi-region active-active);
• disaster-recovery-and-capacity.md определяет процесс capacity planning (ежемесячный мониторинг, ежеквартальный forecast, peak load handling) поверх этой инфраструктуры;
• target utilization (50-60% baseline + 30-40% headroom) — общая позиция в обоих документах;
• predictive provisioning lead time (1-4 недели для bare metal) — учитывается в обоих.

Phases (этот документ) ↔ DR / SLA tier (фаза 6)

Phase этого документа	DR posture (disaster-recovery-and-capacity.md)	SLA possible (sla-and-on-call-model.md)
Phase 1 (Bootstrap)	Tier 1 backup only (cross-AZ опционально)	Free best-effort
Phase 2 (Service isolation)	+ cross-AZ replication для Tier 1, automated daily test restore	Starter 95%
Phase 3 (Workload-specific)	+ secondary region cold standby для Tier 1+2	Professional 99%
Phase 4 (Multi-region active-active)	+ multi-region active-active, distributed Postgres	Enterprise 99.9%

Эта матрица выводима из обоих документов; зафиксирована для clarity.

On-call (этот документ упоминает как принцип) ↔ on-call structure (sla-and-on-call-model)

Этот документ упоминает «24/7 on-call rotation» как часть infrastructure scaling. Каноничная 5-уровневая структура (Primary → Secondary → Engineering Manager → Director/VP → CTO/CISO) — в sla-and-on-call-model.md. Также там burnout protection правила:

• not more than 1 неделя per engineer per 4-6 weeks (фаза 3+);
• not more than 1 неделя per SRE per 6-8 weeks (фаза 4+);
• mandatory time off, no-meeting day, sabbatical policy.

Runbooks (упомянуты как принцип) ↔ canonical 8 runbook classes

Этот документ упоминает «runbooks для топ-N сценариев». Каноничные 8 incident classes с runbooks — в runbooks-incident-playbooks.md:

1. Supplier degradation;
2. Stale offer state;
3. Quote repricing surge;
4. Booking timeout / unknown_external_state;
5. Cache invalidation failure;
6. Governance queue overload;
7. Delayed settlement event generation;
8. Broken publication pipeline.

Связи с другими фаза-зависимыми документами

• operations/deployment.md (Фаза 7 переработан, версия 3.0) — связь с infrastructure phases этого документа явно зафиксирована в секции «Связь deployment с инфраструктурными фазами»;
• reference/multi-tenant-isolation-strength.md (Фаза 5) — 3 уровня изоляции (logical/dedicated_compute/dedicated_infrastructure) зависят от phase: dedicated_infrastructure доступен только в Phase 4;
• reference/api-as-product.md (Фаза 4) — API tier model связан с phase: Enterprise tier с 99.9% SLA реалистичен только в Phase 3+;
• reference/economic-model.md (Фаза 4) — capacity costs per phase используются для unit-economics;
• reference/security-architecture.md (Фаза 10) — security posture усиливается per phase (mTLS — Phase 3+, full SOC 2 — Phase 4+, ISO 27001 — Phase 6).

Каноничный итог уточнения

Документы Фазы 6 (runbooks, sla, dr-capacity) опубликованы и готовы к использованию. Этот документ остаётся источником истины по infrastructure shape per phase; operational maturity per phase — в документах Фазы 6.

Уточнение выполнено через no-destruction.