Перейти к основному содержимому

Дорожная карта развития платформы (development roadmap) — путь от архитектурного baseline к промышленной зрелости

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

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

Этот документ задаёт каноничный путь развития vitiana-api-platform от уже собранного архитектурного и документного baseline до промышленной зрелости. Документ является development-картой, не маркетинговым timeline и не staffing-планом.

Дорожная карта построена по ступеням зрелости (maturity stages), а не по календарному графику. Это сделано намеренно: для платформы верхнего уровня (top-tier global travel platform) реальный прогресс определяется не количеством прошедших месяцев, а прохождением архитектурных и операционных гейтов (gates). Календарный timeline, привязанный к фиксированным месяцам, противоречит правилу 00000 — платформа главенствует над поставщиками — и закону «развитие, не деградация» (см. Развитие без деградации).

Тезисное обоснование​

Тезис 1. Roadmap по ступеням зрелости, не по календарю.

Альтернативы: (а) календарный timeline с фиксированными датами; (б) гибрид «стадии + ориентировочные даты»; (в) story-based roadmap (как «когда пользователь сможет X»).

Trade-off: календарный timeline даёт ясное обещание стейкхолдерам, но создаёт давление публиковать недозрелые контуры. Hardcoded даты неминуемо устаревают и превращаются в источник дезинформации. Story-based подходит для product roadmap, но не для платформенной архитектуры. Stages model даёт ясные критерии готовности (gates) без иллюзорной точности дат — это canonical pattern для платформ верхнего уровня (Stripe, Twilio, Cloudflare публикуют платформенные roadmap именно как maturity stages).

Тезис 2. Каждая стадия имеет explicit gate to exit, без которого нельзя двигаться дальше.

Альтернативы: (а) переход по решению product owner; (б) переход по календарному triggers; (в) свободный переход без gates.

Trade-off: gates требуют дисциплины и формальной проверки готовности — это замедляет переход между стадиями. Однако без gates стадии превращаются в формальность, реальное состояние расходится с заявленным, накапливаются скрытые долги. Gates — это та же логика, что в Модели SLA и дежурств (sla-and-on-call-model.md): без объективных метрик невозможно объяснить, что считать выполненным.

Тезис 3. Roadmap привязан к infrastructure phases roadmap, но не идентичен ему.

Альтернативы: (а) единая дорожная карта развития платформы и инфраструктуры; (б) полностью независимые roadmap; (в) infrastructure roadmap как часть development roadmap.

Trade-off: единая roadmap проще навигационно, но смешивает инженерную зрелость (что должно работать) с инфраструктурной зрелостью (где это работает). Эти оси развиваются с разной скоростью: infrastructure phases определяются объёмом нагрузки (фазы 1–4 OVHcloud в scaling-and-packaging-roadmap.md), а development stages — зрелостью функциональных контуров платформы. Зависимость есть (стадия 4 development обычно соответствует фазе 2–3 infrastructure), но не жёсткая. Раздельные карты с явными перекрёстными ссылками — лучшая практика верхнеуровневых платформ.

Тезис 4. Сквозные workstreams не привязаны к стадиям.

Альтернативы: (а) каждая активность жёстко привязана к стадии; (б) сквозные workstreams как «полностью отдельный roadmap»; (в) сквозные workstreams внутри каждой стадии повторяются.

Trade-off: жёсткая привязка приводит к тому, что documentation governance, risk register, decision trace, capacity planning либо запаздывают, либо не делаются вовсе. Сквозные workstreams должны вестись непрерывно на всех стадиях, иначе платформа накапливает технический и документный долг.

Тезис 5. Roadmap — живой документ, обновляется при каждом завершении стадии и при материальном изменении архитектуры.

Альтернативы: (а) roadmap — фиксированный one-shot документ; (б) roadmap обновляется по календарю (например, ежеквартально); (в) roadmap пересоздаётся при каждой смене стратегии.

Trade-off: фиксированный roadmap быстро устаревает; календарное обновление формально, но не реагирует на реальность; пересоздание разрушает преемственность. Update-on-event-or-stage-change поддерживает roadmap в актуальном состоянии без излишней нагрузки. Старые версии архивируются (правило feedback_no_destruction в memory) для аудитного следа.

Главная архитектурная ось — что roadmap должен сохранять​

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

  • supplier reality (внешняя реальность поставщиков) — точка входа данных, не архитектурный ориентир (правило 00000);
  • canonical and governed model — нормализованная и управляемая каноничная модель Vitiana;
  • integrity-gated publishable offer state — контролируемая публикация предложений;
  • offerable operational state — операционное состояние пригодное к выдаче;
  • channel-aware commercial interpretation — коммерческая интерпретация по каналам;
  • quote as commercial promise — коммерческая фиксация (Quote);
  • booking as transactional commitment — транзакционное обязательство (Booking);
  • post-booking operational reality — операционная реальность после продажи;
  • settlement-relevant downstream financial reality — финансовая реальность для взаиморасчётов;
  • partner clearing and tenant-specific enablement reality — партнёрские расчёты и тенантная специфика;
  • tour composition and proposal publication — сборка туров и публикация предложений (Tour Builder).

Эта ось зафиксирована в Архитектурной основе платформы (overview/index.md) и Операционной оси (overview/operational-spine.md). Roadmap обязан сохранять её на каждой стадии.

Критические запреты roadmap​

Дорожная карта не должна:

  • обещать жёсткие месячные сроки без реальной implementation breakdown;
  • фиксировать окончательный технологический стек до завершения implementation-level решений;
  • подменять roadmap hiring-планом (это отдельный документ — team-and-staffing-plan.md);
  • выдавать ранние спекулятивные business numbers (MRR, customer count, revenue) за подтверждённый operating baseline;
  • смешивать «архитектурно нужно» и «точно будет в первой поставке»;
  • цементировать одного поставщика как primary mainstream supplier (нарушение правила 00000);
  • откладывать data infrastructure / DR / observability / governance на «после launch» (нарушение принципа first-class data infrastructure);
  • считать платформу production-capable до прохождения gate стадии 4.

Текущий статус платформы​

На момент 27.04.2026 проект уже прошёл значительную часть пути.

Уже собран архитектурный и документный baseline:

  • зафиксирована архитектурная ось (overview/index.md);
  • собрана каноничная доменная модель;
  • описаны tenancy, identity, access boundaries;
  • описана семантика offer, quote, booking;
  • выделены commercial-model, partner-finance-and-clearing, post-booking-lifecycle, offer-pricing-booking-semantics;
  • выделены tenant-configuration-and-enablement, api-metering-and-usage-governance, offer-integrity-and-publication-control;
  • выделен tour-builder-domain (core, не optional);
  • выделен data-governance-and-matching;
  • собран execution-layer по deployment, settlement-and-reconciliation, observability-and-incident-response, release-engineering-and-migrations.

Дополнительно с 25.04.2026 собраны 16 ключевых документов:

Доменные дополнения:

Операционные дополнения:

Архитектурные правила (development):

  • Закон 00000 — платформа главенствует над поставщиками;
  • Современные лучшие практики верхнеуровневых платформ;
  • Эластичное масштабирование и упаковка по фазам;
  • Развитие без деградации;
  • Тезисное обоснование архитектурных решений.

Это означает, что roadmap не начинается с «сначала придумать архитектуру». Базовая архитектурная плотность достигнута — основной риск сместился в сторону implementation discipline, controlled execution, сохранения связности при переходе от документации к реальной системе и удержания принципа платформы поверх поставщиков.

Стадии зрелости — обзор​

СтадияНазваниеГлавный фокусТекущий статус
0Архитектурный baselineКаноничная архитектура, документы, правилав основном пройдена
1Implementation baselineПеревод архитектуры в executable designначало
2Controlled internal platformВнутренний реальный operating loopпредстоит
3Controlled external betaОграниченный внешний контур (agency + partner)предстоит
4Production-capable baselineЗрелые операционные контуры под реальной ответственностьюпредстоит
5Controlled scale and product expansionУправляемое масштабирование без размывания ядрапредстоит
6Multi-region and enterpriseГлобальное присутствие и enterprise-readinessпредстоит

Стадии не имеют hardcoded дат. Переход — по достижению gate to exit, не по календарю.

Стадия 0. Архитектурный baseline​

Смысл стадии​

Собрать каноничную архитектуру платформы, зафиксировать её в документах, установить архитектурные правила, по которым проектируются все последующие решения. Без этой основы implementation development превращается в хаотичное наращивание features без удержания truth boundaries.

Текущий статус​

В основном пройдена. Архитектурная ось зафиксирована, доменная модель собрана, правила (включая правило 00000) опубликованы, операционная зрелость документирована (runbooks, SLA, DR).

Что ещё нужно добить​

  • переписать clients.md (недо-связан с tenancy и api-as-product);
  • актуализировать deployment.md (добавить связи с runbooks, SLA, DR, capacity);
  • зафиксировать governance документации (documentation-governance.md);
  • зафиксировать team and staffing plan;
  • провести финальный docs_lint по всем reference- и operations-документам;
  • проверить diagram-layer на согласованность с обновлённым reference-ядром;
  • обновить main-findings.md как живой document перехода стадия 0 → стадия 1.

Gate to exit​

Из стадии 0 можно выходить только когда:

  • все ключевые reference- и operations-документы согласованы между собой и с правилом 00000;
  • нет явных противоречий между domain-model, commercial-model, payment-domain, booking-state-machine, multi-tenant-isolation-strength, api-contracts;
  • все 16 новых документов фаз 4–6 интегрированы в граф backlinks (docs_links — нулевая невязка);
  • старые документы (без новой архитектурной оси) переведены в *-old-YYYY-MM-DD.md со статусом Черновик;
  • documentation-governance и team-and-staffing-plan опубликованы;
  • archived документы не конкурируют с актуальным source of truth.

Стадия 1. Implementation baseline​

Смысл стадии​

Перевести собранную архитектуру в форму, пригодную для поэтапной инженерной реализации. На этой стадии проект ещё не должен притворяться production platform. Его задача — определить, как именно архитектурные документы становятся executable design.

Ключевые workstreams​

1.1. Bounded implementation design​

Определить:

  • какие release units существуют на первом implementation этапе (см. implementation-ready-breakdown.md);
  • где проходят первые code boundaries;
  • что реализуется как единый runtime unit, а что сразу должно быть отделено;
  • какие контуры нельзя объединять без operational риска;
  • какой technology baseline обслуживает разные execution contours без forced one-stack dogma.

1.2. Contract-ready decomposition​

Перевести архитектурные surface contracts в implementation-ready артефакты:

1.3. Persistent model hardening​

Довести до implementation качества:

  • schema decomposition;
  • migration sequencing;
  • audited storage classes (Tier 1/2/3/4 — см. disaster-recovery-and-capacity.md);
  • quote / repricing / settlement traces;
  • governance and review persistence.

1.4. Supplier execution design​

Определить:

  • initial supplier onboarding discipline (Stuba и HomeToGo как первые источники, не как mainstream — правило 00000);
  • intake modes;
  • replay strategy;
  • failure isolation;
  • normalization and mapping workflow;
  • publication gating и downstream invalidation logic.

1.5. Surface strategy​

Определить порядок surface rollout:

  1. internal operator surface;
  2. agency working surface;
  3. proposal/publication surface;
  4. partner API surface;
  5. опционально B2C surface.

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

1.6. Payment and booking minimum​

Привязка к новым доменам:

1.7. Observability and operability minimum​

Базовая обсервабилити для всех первых execution contours:

Обязательный результат​

После завершения стадии 1 у команды должны появиться:

  • implementation-ready decomposition;
  • initial contract package (OpenAPI + AsyncAPI skeletons + payload examples + schema drafts);
  • migration-ready persistent plan;
  • supplier onboarding baseline (для Stuba и HomeToGo как двух равноправных источников);
  • surface rollout order;
  • non-speculative delivery slices для первой implementation волны;
  • explicit version-evolution policy для async contracts;
  • retry/DLQ/replay matrix;
  • consumer и producer compatibility checklists;
  • bounded webhook payload examples для partner-facing async notifications;
  • payment intent prototype с поддержкой минимум одного PSP-адаптера;
  • booking state machine prototype с обработкой unknown_external_state;
  • базовая observability stack (Prometheus + Grafana + structured logs).

Gate to exit​

Нельзя выходить из стадии 1, пока не определены и не работают в dev/staging:

  • первый production-capable execution contour;
  • первая transaction-safe booking path (включая обработку unknown_external_state);
  • первая quote-safe commercial path с repricing;
  • первый clearing-safe partner path;
  • первая integrity-gated publication path;
  • migration and release discipline для этих путей;
  • observability minimum для диагностики реальных сбоёв;
  • backup и restore процедура для Tier 1 данных проверена.

Стадия 2. Controlled internal platform​

Смысл стадии​

Построить управляемую внутреннюю платформу, на которой уже можно безопасно проживать реальные supplier, offer, quote и booking сценарии — но ещё без преждевременного широкого внешнего обещания. Это стадия controlled internal reality, не public launch.

Capability targets​

2.1. Supplier and ingestion reality​

  • подключение ограниченного числа поставщиков (Stuba + минимум один второй, чтобы доказать canonical model работает);
  • intake в повторяемом режиме;
  • raw trace capture (Tier 3 — см. disaster-recovery-and-capacity.md);
  • нормализация в caнoничные сущности Vitiana (не в supplier-shaped поля);
  • canonical update;
  • review and anomaly workflow;
  • replay представительных сценариев.

2.2. Offer and quote reality​

  • offer assembly с media и content bundles (см. media-and-content.md);
  • freshness discipline;
  • channel-aware commercial interpretation;
  • quote fixation;
  • revalidation и repricing logic;
  • integrity gating и publication control;
  • publication gating при коммерческой или data inconsistency.

2.3. Booking and post-booking reality​

  • bounded booking flow;
  • booking state machine с 14 каноничными состояниями (см. booking-state-machine.md);
  • supplier-side confirmation handling;
  • failure и unknown_external_state recovery;
  • audit trail (Tier 1);
  • operator recovery path;
  • cancellations and amendments;
  • supplier-driven disruption handling;
  • partner clearing checks.

2.4. Payment reality​

  • PaymentIntent lifecycle для минимум одного PSP-адаптера (см. payment-domain.md);
  • refund flow;
  • chargeback handling baseline;
  • settlement events для одного юридического канала.

2.5. Tour Builder operational reality​

  • composition rules engine (см. tour-builder-operational-model.md);
  • saga для multi-component bookings;
  • drift detection и compensation;
  • draft/proposal lifecycle.

2.6. Governance reality​

  • human-in-the-loop review (см. data-governance-and-matching.md);
  • confidence-aware matching;
  • manual locks;
  • publication holds;
  • controlled correction flow.

2.7. Observability and release reality​

  • domain-chain observability;
  • incident triage по runbooks (см. runbooks-incident-playbooks.md);
  • on-call rotation минимум 2 человека (Primary + Secondary, см. sla-and-on-call-model.md);
  • release gates;
  • migration verification;
  • rollback / forward-fix discipline;
  • ежемесячные partial restore drills.

2.8. Tenant isolation baseline​

Обязательный результат​

После завершения стадии 2 платформа должна быть способна пережить ограниченную реальную эксплуатацию внутри controlled operational perimeter, обслуживая внутренний operator surface и максимум 2–3 пилотных агентств в режиме closed beta.

Gate to exit​

Нельзя выходить из стадии 2, пока не доказано, что система:

  • не теряет supplier trace ни при каких условиях;
  • не смешивает indicative price и quoted promise;
  • не теряет booking truth при сбоях;
  • не теряет settlement-relevant basis;
  • не допускает uncontrolled partner exposure;
  • не публикует externally offers без integrity discipline;
  • объясняет operator пути от supplier signal до booking или settlement consequence;
  • держит SLA Free tier (best-effort, см. sla-and-on-call-model.md);
  • проходит ежемесячный full restore drill;
  • IsolationBoundaryCheck не выявляет cross-tenant leaks за 30 дней.

Стадия 3. Controlled external beta​

Смысл стадии​

Открыть платформу наружу ограниченно и осознанно, не размывая truth boundaries и не обещая рынку больше, чем система действительно умеет держать.

Возможные первые внешние контуры​

Порядок определяется не «где проще сделать UI», а где ниже риск для платформы:

  1. internal operator and agency working surface (для уже подключённых пилотных агентств);
  2. proposal and communication surface;
  3. bounded partner integration surface (B2B API tier Starter — см. api-as-product.md);
  4. broader client-facing surfaces только при достаточной publication discipline.

Ключевые workstreams​

3.1. Agency beta​

Проверить:

3.2. Partner beta (B2B API)​

Проверить:

  • contract clarity;
  • rate и scope control;
  • version discipline;
  • publication rules;
  • compatibility handling;
  • partner-visible repricing и error semantics;
  • API metering и quota enforcement (см. api-metering-and-usage-governance.md);
  • partner sandbox + certification flow (см. api-as-product.md).

3.3. Financial and operational beta​

Проверить:

  • settlement events;
  • reconciliation queues;
  • discrepancy aging;
  • refund / cancellation handling;
  • operator ownership и escalations;
  • service credits flow для tenant Starter (см. sla-and-on-call-model.md);
  • chargeback workflow.

3.4. Search and discovery​

Проверить:

  • search projections с многоязычными запросами;
  • ranking policy с честными signals (без captive boost для одного поставщика — правило 00000);
  • faceting и filtering;
  • search freshness SLI.

3.5. Data and analytics beta​

Обязательный результат​

После завершения стадии 3 должен существовать ограниченный, но честный внешний operating loop:

  • платформа что-то реально обещает (Free + Starter SLA tiers);
  • может объяснить это обещание;
  • может довести обещание до booking и post-booking reality;
  • может увидеть и обработать финансовые и операционные последствия;
  • может выпускать service credits при breaches;
  • партнёры могут самостоятельно onboard через sandbox;
  • analytics доступна обеим сторонам.

Gate to exit​

Из стадии 3 можно выходить только если:

  • external surfaces не ломают internal truth discipline;
  • quote/booking/settlement цепочка наблюдаема и аудируема;
  • support и operations умеют сопровождать beta без archeology;
  • release changes не разрушают compatibility и financial trace;
  • SLA Free и Starter (95%) держатся за 90 дней без серьёзных breaches;
  • партнёрский self-service onboarding работает (хотя бы один партнёр прошёл от sandbox до production без ручных вмешательств).

Стадия 4. Production-capable baseline​

Смысл стадии​

Сделать платформу пригодной не просто для демонстрации и ограниченного beta use, а для устойчивой эксплуатационной жизни под реальной коммерческой ответственностью. Это не означает «сразу массовый рынок», но означает, что базовые operational contours достаточно зрелые для коммерческих SLA Professional (99%).

Ключевые направления​

4.1. Reliability hardening​

  • stronger failure isolation (cross-AZ replication для Tier 1);
  • queue discipline (DLQ для всех async channels);
  • capacity envelopes (см. disaster-recovery-and-capacity.md);
  • degradation modes (graceful degradation для пиков);
  • supplier outage handling (один поставщик недоступен — платформа продолжает работать с остальными);
  • state recovery practice;
  • SLA Professional (99%) держится за 180 дней.

4.2. Financial hardening​

  • reconciliation completeness;
  • settlement trace durability;
  • correction event discipline;
  • refund/amendment robustness;
  • finance-support-operational ownership clarity;
  • partner clearing с явной liability chain (платформа → supplier, client → платформа, downstream client → client);
  • chargeback win rate более 50% при защищаемых случаях.

4.3. Contract hardening​

  • explicit version policy;
  • deprecation policy с минимум 6 месяцев notice;
  • backward-compatible evolution discipline;
  • managed и external surface separation;
  • partner certification обязателен для production access.

4.4. Security and governance hardening​

  • stronger actor и tenant isolation;
  • secret и credential discipline (Vault + automated rotation);
  • data retention discipline (Tier 1: 7 лет, Tier 2: 90 дней, Tier 3: 1–2 года);
  • audit-readiness sensitive контуров (SOC 2 Type 1 готовность);
  • publication control maturity;
  • GDPR data subject rights (доступ, исправление, удаление, портирование).

4.5. Operational maturity​

  • incident playbooks для всех каноничных incident classes;
  • 5-уровневая on-call structure (см. sla-and-on-call-model.md);
  • post-incident analysis обязательный для всех major incidents;
  • release observation windows;
  • operational KPIs и service objectives;
  • ежеквартальный full restore drill;
  • ежеквартальный capacity forecast review.

4.6. Tour Builder maturity​

  • multi-component sagas работают без manual intervention в более чем 95% случаев;
  • drift detection и compensation автоматизированы;
  • partner-facing Tour Builder API доступен для tenant Professional+.

4.7. Tenant isolation maturity​

  • dedicated_compute доступен для tenant Professional;
  • IsolationBoundaryCheck отчёт квартальный;
  • CrossTenantAccess audit logs хранятся 7 лет.

Обязательный результат​

После завершения стадии 4 платформа имеет право считаться production-capable baseline:

  • держит SLA Professional 99%;
  • 50+ partner integrations в production;
  • SOC 2 Type 1 готовность;
  • финансовая и governance audit trail пригодны для разбора споров и corrective action.

Gate to exit​

Нельзя считать стадию 4 пройденной, пока:

  • platform core выдерживает реальные инциденты без потери truth;
  • booking и settlement paths переживают failures без manual chaos;
  • релизы выпускаются контролируемо;
  • operator model работает не только на happy path;
  • SLA Professional 99% удержан за 180 дней;
  • DR drills (полный region failover) проведены минимум 2 раза успешно;
  • SOC 2 Type 1 audit пройден.

Стадия 5. Controlled scale and product expansion​

Смысл стадии​

Масштабирование идёт только после доказанной состоятельности operational core. На этой стадии допустимо расширять supplier coverage, agency network, partner integration depth, channels, Tour Builder sophistication, аналитические и оптимизационные контуры.

Допустимые направления​

5.1. Supplier expansion​

  • новые supplier profiles (10+ поставщиков);
  • supplier-class-specific handling (B2B vs B2C, GDS vs direct, hotel vs tour operator);
  • broader geography (за пределы первой волны UA/CZ/PL/KZ);
  • richer coverage с preserved governance discipline;
  • ни один поставщик не получает structural priority (правило 00000).

5.2. Product expansion​

  • deeper tour composition;
  • richer proposal artifacts;
  • multi-component travel product (transfer + accommodation + activities + transport rental + insurance);
  • advanced commercial policies;
  • broader channel-specific offerings.

5.3. Analytics and optimization​

  • расширенные partner analytics dashboards;
  • ML-driven recommendations (см. ml-platform.md);
  • dynamic pricing policies;
  • ranking optimization через A/B (см. ab-testing-platform.md);
  • capacity и latency tuning;
  • decision support для operations и commercial teams.

5.4. Organizational scaling​

  • clearer ownership model;
  • stronger ops/finance/support separation;
  • release governance;
  • formal supplier и partner enablement processes;
  • SRE team появляется как отдельная функция (см. team-and-staffing-plan.md).

5.5. Infrastructure phase 3​

Переход на workload-specific packaging согласно scaling-and-packaging-roadmap.md — выделение специализированной инфраструктуры под профили нагрузки (search, ML, transactional).

Что нельзя делать на этой стадии​

Нельзя расширять scale ценой размывания уже собранного ядра. Если масштабирование:

  • ломает explainability цены;
  • ломает booking truth;
  • ломает settlement trace;
  • ломает publication honesty;
  • делает governance purely nominal;
  • создаёт captive integration для одного поставщика (нарушение правила 00000);

то это деградация под нагрузкой, не развитие платформы.

Gate to exit​

Стадия 5 пройдена, когда:

  • более 100 partner integrations в production;
  • более 10 поставщиков работают равноправно (никто не получает captive logic);
  • инфраструктура на phase 3 packaging;
  • ML-driven optimization показывает положительный ROI на A/B-экспериментах;
  • SOC 2 Type 2 готовность достигнута.

Стадия 6. Multi-region and enterprise​

Смысл стадии​

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

Capability targets​

6.1. Multi-region infrastructure​

Переход на phase 4 packaging (см. scaling-and-packaging-roadmap.md):

  • multi-region active-active или active-passive с автоматическим failover;
  • distributed Postgres или managed multi-master;
  • GeoDNS с health checks;
  • regional data residency для регулируемых юрисдикций.

6.2. Enterprise tier​

  • SLA Enterprise 99,9% (см. sla-and-on-call-model.md);
  • dedicated_infrastructure уровень изоляции;
  • custom RTO/RPO по контракту (строже Tier 1 baseline);
  • SOC 2 Type 2 + ISO 27001;
  • dedicated customer success manager;
  • premium support 24/7;
  • on-call follow-the-sun (3 региона).

6.3. Compliance maturity​

  • GDPR + PSD2 + EU TOMS + Package Travel Directive — полное соответствие с регулярными аудитами;
  • AML / KYC procedures для финансовых потоков;
  • regulatory reporting автоматизирован.

6.4. Platform-as-platform​

  • partners могут разрабатывать собственные surfaces поверх Vitiana (white-label);
  • marketplace третьих интеграций;
  • открытое сообщество разработчиков.

Обязательный результат​

Платформа Vitiana функционирует как top-tier global travel platform с enterprise-readiness, multi-region отказоустойчивостью, compliance maturity и open ecosystem.

Gate to exit​

Стадия 6 — текущий горизонт. После её прохождения roadmap пересматривается с учётом новых стратегических развилок.

Сквозные workstreams​

Эти workstreams ведутся на всех стадиях параллельно.

S1. Documentation governance​

Документация обновляется вместе с платформой, не постфактум. Особенно критично для:

  • domain model;
  • contracts;
  • migrations;
  • settlement;
  • observability;
  • supplier onboarding;
  • operator playbooks.

Подробности — в documentation-governance.md.

S2. Risk register​

Живой список architectural и execution risks:

  • supplier dependency risk (любой поставщик может уйти — платформа должна продолжать работу);
  • pricing / quote drift risk;
  • booking state ambiguity (unknown_external_state — не теряется);
  • settlement discrepancy risk;
  • publication honesty risk;
  • release migration risk;
  • regulatory risk (GDPR breach, PSD2 violation);
  • security risk (data breach, credential leak);
  • operational risk (supplier outage, infrastructure failure);
  • финансовый risk (chargeback storm, fraud).

S3. Decision trace​

Ключевые архитектурные решения должны оставлять after-image в документации:

  • contract design choices;
  • storage class selection;
  • release discipline rules;
  • supplier onboarding decisions;
  • channel rollout sequencing;
  • commercial policy choices;
  • tenant isolation level decisions per partner;
  • DR strategy choices.

См. feedback_thesis_based_justification.md — каждое решение тезисно обосновано.

S4. Data infrastructure от нулевого дня​

Согласно правилу project_data_infra_commitment (зафиксировано в memory):

  • domain events закладываются с нулевого дня (см. data-platform-and-events-tracking.md);
  • DWH minimal viable schema появляется на стадии 2;
  • ETL streams развёрнуты к стадии 3;
  • ML feature store начинает работу на стадии 4 (см. ml-platform.md);
  • A/B testing активен с стадии 3 (см. ab-testing-platform.md).

S5. Capacity planning​

Согласно disaster-recovery-and-capacity.md:

  • ежемесячный capacity monitoring с стадии 1;
  • ежеквартальный capacity forecast с стадии 2;
  • proactive provisioning с стадии 3 (lead time для bare metal — недели);
  • AI-based prediction с стадии 5.

S6. DR readiness​

Согласно disaster-recovery-and-capacity.md:

  • backup для Tier 1 — обязательно с стадии 1;
  • partial restore drills — ежемесячно с стадии 2;
  • full restore drills — ежеквартально с стадии 3;
  • region failover drills — каждые 6 месяцев с стадии 5;
  • chaos drills — ежемесячно с стадии 6.
  • GDPR baseline — обязательно с стадии 1 (хранение данных, согласия, retention);
  • PSD2 SCA — с стадии 2 (для платежей в EU);
  • EU TOMS VAT — с стадии 3 (при коммерческой деятельности);
  • Package Travel Directive — с стадии 3 (если применимо к Tour Builder продуктам);
  • AML / KYC — с стадии 4;
  • SOC 2 Type 1 — стадия 4;
  • SOC 2 Type 2 — стадия 5;
  • ISO 27001 — стадия 6.

S8. Diagram synchronization​

SVG, JPG и иные архитектурные схемы синхронизируются с текущим source of truth, не удерживают старую картину мира. После каждой стадии — diagram review.

Связь с infrastructure phases​

Development stages привязаны к infrastructure phases (см. scaling-and-packaging-roadmap.md), но не идентичны им.

Development stageInfrastructure phaseОбоснование
Стадия 0— (документная стадия)Архитектура; инфраструктура не нужна
Стадия 1Phase 1 (bootstrap, single-region single-AZ)Минимальная инфраструктура, OVH Public Cloud Eco
Стадия 2Phase 1 → Phase 2Cross-AZ replication для Tier 1
Стадия 3Phase 2 (single-region multi-AZ)Service isolation, Tier 1 защищён
Стадия 4Phase 2 → Phase 3Workload-specific packaging при росте до 50+ partners
Стадия 5Phase 3 (workload-specific)Полная packaging
Стадия 6Phase 4 (multi-region, dedicated)Enterprise + multi-region

Зависимость не жёсткая. Стадия 4 может потребовать перехода на Phase 3 раньше при появлении enterprise-клиента (опережающий триггер).

Приоритет следующего практического прохода​

После публикации этого roadmap следующий проход — стадия 1 implementation:

  1. опубликовать documentation-governance.md (закрытие стадии 0);
  2. опубликовать team-and-staffing-plan.md (закрытие стадии 0);
  3. провести финальный docs_lint (закрытие стадии 0);
  4. собрать implementation slices для первого release unit (вход в стадию 1);
  5. подготовить supplier onboarding playbook для второго supplier (доказательство правила 00000);
  6. развернуть Tier 1 backup и restore процедуру в dev окружении.

Открытые вопросы и развилки​

  1. Геополитический риск. Развёртывание в UA несёт повышенный operational risk. Стратегия: primary deployment в EU (CZ, PL), UA — как user-facing surface с edge presence; финансовая инфраструктура — за пределами UA. Решение фиксировано, требует регулярной переоценки.
  2. Выбор первого PSP. Развилка: Stripe (best-in-class, дороже) vs. адаптер под несколько PSP сразу (сложнее, дешевле в долгосрочной перспективе). Решение — на стадии 1 после анализа стоимости и lead time.
  3. Multi-cloud DR. Должна ли платформа использовать второй cloud provider (AWS как backup для OVHcloud) — решение откладывается до стадии 4 при появлении enterprise-клиента.
  4. Open marketplace timeline. Когда открывать маркетплейс третьих интеграций — на стадии 5 или 6? Зависит от зрелости partner self-service и экосистемного приоритета. Решение — в конце стадии 5.
  5. Geographic expansion sequencing. Первая волна (UA/CZ/PL/KZ) подтверждена. Вторая волна (DE/AT/RO/SK или EU broader vs. CIS) — решение по результатам стадии 4.

Краткий итог​

Правильный roadmap для vitiana-api-platform — не roadmap «от MVP к launch» в старом смысле. Это roadmap развития industrial platform верхнего уровня:

  • сначала удержать truth boundaries и канонические архитектурные правила (стадия 0 — в основном пройдена);
  • затем перевести архитектуру в implementation baseline (стадия 1 — следующий шаг);
  • затем доказать controlled internal viability (стадия 2);
  • затем открыть controlled external beta (стадия 3);
  • затем достичь production-capable baseline с реальными SLA и compliance (стадия 4);
  • затем масштабировать без размывания ядра (стадия 5);
  • затем выйти на multi-region и enterprise-уровень (стадия 6).

Каждая стадия имеет explicit gate to exit. Сквозные workstreams ведутся параллельно. Roadmap живой и обновляется при завершении стадий или при материальных архитектурных изменениях.

Связанная документация​

Опорные архитектурные документы​

Каноничная доменная модель​

Платформенные домены​

Операционные документы​

Архитектурные правила​

Документы развития​