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

Deployment And Operating Model — Развёртывание и эксплуатационная модель

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

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

Этот документ фиксирует не набор готовых Kubernetes manifest-ов и не преждевременную уверенность в одной окончательной production-топологии.

Его задача — зафиксировать:

  • как платформа должна мыслить deployment как продолжение доменной архитектуры;
  • какие execution-contours реально должны существовать;
  • что является release unit, а что только runtime component;
  • как должны быть устроены environments, rollout discipline, recovery, observability и incident handling;
  • как production-shape должен эволюционировать от более простой формы к более зрелой без потери архитектурной оси платформы.

Этот документ следует читать как operations baseline, а не как “финальную инфраструктурную правду уже сегодня”.

Что нового в версии 3.0​

После Фаз 4–6 каноничной архитектуры платформы (25–27.04.2026) опубликованы 16 новых reference- и operations-документов, фундаментально влияющих на deployment-модель: программный интерфейс как продукт с tier-зависимыми SLA (api-as-product), статусная машина бронирования с обработкой unknown_external_state (booking-state-machine), платёжный домен с PSP-абстракцией и refund/chargeback workflow (payment-domain), сила тенантной изоляции (multi-tenant-isolation-strength) с тремя уровнями (logical / dedicated_compute / dedicated_infrastructure), runbooks инцидент-плейбуки, модель SLA и дежурств, восстановление после аварий и планирование ёмкости.

Версия 3.0 не переписывает execution contours, environment separation, deployment shape by maturity stages — концептуальная база версии 2.0 здоровая. Версия 3.0 расширяет связи с новыми документами, добавляет тезисное обоснование, вводит привязку deployment shape к infrastructure phases и формализует связь deployment ↔ runbooks ↔ SLA ↔ DR ↔ capacity как четыре столпа операционной зрелости.

Также версия 3.0 явно поддерживает правило 00000: deployment-модель не цементирует одного поставщика как primary mainstream, не создаёт captive integration в общем коде, не делает supplier-specific deployment isolation особым случаем.

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

Тезис 1. Deployment мыслится как класс операционной реальности, не как «список сервисов».

Альтернативы: (а) deployment по микросервисам (один сервис — один deployment); (б) deployment по командам (Conway's law); (в) deployment по execution contours (классам операционной реальности — transactional / commercial / ingestion / surface / operational).

Trade-off: вариант (а) приводит к over-fragmentation на ранних стадиях (один deployment per documented domain × 30 = огромная operational нагрузка); вариант (б) — фрагментация по случайным организационным границам, не по архитектурным; вариант (в) — каноничная декомпозиция, согласованная с rollout risk и SLA. Это масштабируемое решение, согласованное с современными лучшими практиками платформ верхнего уровня (Stripe — payments / dashboards / connect; Twilio — voice / messaging / verify).

Тезис 2. Deployment shape эволюционирует по фазам инфраструктуры, не имитирует hyperscale-topology раньше времени.

Альтернативы: (а) сразу финальная multi-region active-active топология; (б) фиксированная одна форма от bootstrap до scale; (в) фазированный путь.

Trade-off: вариант (а) экономически неоправдан на bootstrap (платформа без выручки не может финансировать 2x инфраструктуры); вариант (б) приводит к необходимости полностью переписать deployment к фазе 3, что блокирует развитие; вариант (в) — путь по 4 фазам packaging согласно scaling-and-packaging-roadmap.md. Это согласовано с правилом «развитие без деградации» — каждая фаза расширяет, не переписывает.

Тезис 3. Deployment связан с runbooks, SLA, DR, capacity как четыре столпа операционной зрелости.

Альтернативы: (а) deployment самодостаточен; (б) deployment + observability достаточно; (в) deployment как часть единой операционной модели с runbooks / SLA / DR / capacity / observability / release engineering.

Trade-off: вариант (а) приводит к появлению инцидентов без runbooks и SLA без metric-источников; вариант (б) даёт visibility, но не операционные процедуры; вариант (в) — каноничная связь, где deployment производит структуру, на которую опирается каждый из остальных столпов:

  • runbooks применяются к конкретным execution contours (это требует deployment-модели);
  • SLA измеряется per surface (это требует surface delivery contour);
  • DR процедуры восстанавливают конкретные runtime units (это требует release unit decomposition);
  • capacity planning форсастит загрузку конкретных runtime classes (это требует execution contours).

Тезис 4. Tenant isolation level влияет на deployment shape.

Альтернативы: (а) единый deployment для всех тенантов; (б) deployment per tenant; (в) deployment shape соответствует isolation tier (logical / dedicated_compute / dedicated_infrastructure).

Trade-off: вариант (а) экономичен, но не поддерживает enterprise-клиентов с требованием физической изоляции; вариант (б) дорог и не масштабируется; вариант (в) — каноничный путь: logical tenants живут в shared infrastructure, dedicated_compute получают выделенные namespace/cluster, dedicated_infrastructure получают выделенный регион/окружение. Это согласовано с multi-tenant-isolation-strength.md.

Тезис 5. API tier (Free / Starter / Professional / Enterprise) влияет на deployment guarantees.

Альтернативы: (а) одинаковые deployment гарантии для всех tier; (б) tier влияет только на rate limits; (в) tier влияет на rate limits, SLA, isolation, capacity reservations, DR.

Trade-off: вариант (а) не поддерживает коммерческую дифференциацию (зачем платить за Enterprise если он получает то же что Starter?); вариант (б) частично работает, но не объясняет почему Enterprise SLA 99.9% — Enterprise tier обязан получить deployment-уровневые гарантии. Вариант (в) — каноничная связь deployment ↔ API tier, где tier задаёт capacity reservations, isolation level, DR class, rollout sequence. Это согласовано с api-as-product.md и sla-and-on-call-model.md.

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

Архитектурная основа​

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

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

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

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

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

Что Исправляет Новый Подход​

Предыдущая версия документа слишком рано фиксировала:

  • Kubernetes как уже окончательно выбранную форму запуска;
  • конкретные размеры кластера и конфиги как будто они уже обоснованы production workload-ом;
  • готовые manifests как будто доменная и execution-модель уже стабилизированы;
  • monitoring stack и CI/CD как будто они уже детализированы до уровня внедрения.

Для текущей зрелости проекта это слишком рано.

Новый подход исходит из другой логики:

  1. сначала определить, что именно нужно эксплуатировать;
  2. затем определить, какие execution-contours критичны;
  3. затем определить environments, release units и recovery rules;
  4. только потом детализировать конкретную платформу запуска: Kubernetes, Nomad, managed containers или иная форма.

При этом после сборки текущего reference-layer уже допустимо зафиксировать не final stack, а recommended technology baseline, который сейчас описан в Implementation Technology Baseline — Рекомендуемый технологический фундамент реализации.

Главный Принцип Deployment​

Платформа должна развёртываться не вокруг “списка сервисов”, а вокруг разных классов operational reality:

  • canonical and transactional truth;
  • supplier intake and ingestion processing;
  • offer / quote / commercial execution;
  • booking and downstream settlement-sensitive events;
  • client and partner-facing surfaces;
  • governance and operational control;
  • observability and recovery.

Если deployment-model не различает эти execution-contours, то:

  • нельзя честно проектировать rollout risk;
  • нельзя отделить high-risk transactional path от менее критичных read surfaces;
  • нельзя выстроить incident response;
  • нельзя масштабировать систему по реальной operational нагрузке.

Execution Contours Платформы​

На текущем этапе platform runtime следует мыслить как набор execution-contours.

1. Core Transactional Contour​

Содержит:

  • canonical persistent model;
  • identity / tenancy backbone;
  • booking state;
  • quote fixation, если она audit-significant;
  • governance decisions;
  • settlement-relevant traces.

Для него критичны:

  • strong durability;
  • migration discipline;
  • rollback safety;
  • auditability;
  • strict backup and recovery posture.

2. Offer And Commercial Execution Contour​

Содержит:

  • offer assembly;
  • freshness and revalidation logic;
  • quote creation;
  • repricing logic;
  • commercial policy application;
  • publication-safety decisions, если они завязаны на commercial state.

Для него критичны:

  • predictable latency;
  • safe cache invalidation;
  • replay-safe state transitions;
  • explainable quote/repricing outcomes.

3. Supplier Intake And Ingestion Contour​

Содержит:

  • supplier connectivity;
  • batch and API intake;
  • raw trace capture;
  • normalization;
  • matching and mapping;
  • governance handoff;
  • downstream invalidation and repricing signals.

Для него критичны:

  • replayability;
  • throughput isolation;
  • quarantine and review paths;
  • supplier-specific failure tolerance.

4. Surface Delivery Contour​

Содержит:

  • partner-facing APIs;
  • agency-facing working surfaces;
  • B2C or client-facing surfaces;
  • proposal publication surfaces.

Для него критичны:

  • contract stability;
  • surface-specific scaling;
  • publication honesty;
  • scoped access and rate control.

5. Operational Control And Observability Contour​

Содержит:

  • operational consoles;
  • review queues;
  • booking exception handling;
  • diagnostics;
  • tracing, metrics, logs and alerting;
  • incident response support.

Для него критичны:

  • cross-system visibility;
  • low-friction access for responders;
  • correlation across booking, quote, supplier and governance flows;
  • recoverability and replay tooling.

Release Units And Runtime Units​

Одна из главных ошибок ранних infra-документов — путать domain service, deployable unit и runtime process.

Domain Service​

Это смысловой контур из Business Services — Сервисная декомпозиция платформы.

Release Unit​

Это то, что реально versioned, tested and rolled out as one change boundary.

Runtime Unit​

Это отдельный process/container/pod/task, который может быть частью release unit, но не обязан совпадать с доменным сервисом.

Практический Вывод​

На первом production-capable этапе платформа не обязана иметь:

  • один микросервис на каждый домен;
  • отдельный deployment для каждого документа reference-layer;
  • fully split infra topology.

Но она обязана уже сейчас сохранить возможность:

  • отделить ingestion-heavy paths от transactional core;
  • отделить partner/public surfaces от internal operations;
  • отделить background processing from user-facing latency-critical flows.

Environments​

Платформе нужны как минимум следующие environments.

1. Local Development​

Нужен для:

  • domain and API iteration;
  • fixture-based supplier simulation;
  • local replay of ingestion cases;
  • contract and schema validation.

Не должен притворяться полной production-копией.

2. Integration / Test Environment​

Нужен для:

  • cross-service contract checks;
  • migration testing;
  • replay of representative supplier traces;
  • booking-path dry runs;
  • quote/repricing scenarios;
  • security and scope testing.

3. Staging / Pre-Production​

Нужен для:

  • production-like rollout rehearsal;
  • load checks on critical flows;
  • observability validation;
  • incident playbook rehearsal;
  • release candidate validation.

4. Production​

Должен быть выстроен не вокруг “всё работает”, а вокруг:

  • protected truth stores;
  • safe rollout discipline;
  • observability-first operations;
  • bounded blast radius;
  • operational recovery.

Environment Separation​

Для всех environments должны быть разведены:

  • credentials and secrets;
  • supplier endpoints and supplier identities;
  • partner credentials;
  • object storage buckets;
  • webhook endpoints;
  • alerting channels;
  • operational datasets;
  • reconciliation and finance-relevant outputs.

Особенно важно:

  • не смешивать sandbox and production partner contracts;
  • не смешивать test quote/bookings with production traces;
  • не позволять supplier replay tooling случайно писать в production truth.

Deployment Shape By Maturity Stage​

Платформе нужна не одна “магическая” конечная инфраструктурная форма, а эволюционный путь.

Stage 1. Controlled Production Baseline​

Допустимо:

  • ограниченное число release units;
  • fewer deployables than domain contours;
  • managed relational database;
  • managed cache;
  • one primary runtime cluster or container platform;
  • explicit background worker layer.

Главное требование:

  • сохранить правильные boundaries, even if some are co-deployed.

Stage 2. Separated Critical Paths​

На этом этапе обычно отделяются:

  • ingestion-heavy workloads;
  • partner/public surface workloads;
  • latency-critical quote/booking flows;
  • operational consoles and tooling.

Stage 3. Mature Operational Segmentation​

На этом этапе уже разумно обсуждать:

  • finer runtime isolation;
  • read/write separation;
  • event-heavy dedicated processing;
  • more advanced autoscaling and cost-aware placement;
  • dedicated reconciliation / reporting workloads.

Практический Вывод​

Текущий документ не должен заставлять проект делать Stage 3 infrastructure while the platform is still stabilizing Stage 1 and Stage 2 semantics.

Data And State Deployment Requirements​

Persistent Truth Stores​

Должны иметь:

  • backup policy;
  • restore drills;
  • migration discipline;
  • audit-preserving change policy;
  • strict access control;
  • observability around latency, locks, storage pressure and replication.

Cache And Rebuildable State​

Должны иметь:

  • explicit TTL policy;
  • invalidation discipline;
  • warmup or lazy rebuild strategy;
  • graceful degradation on cache loss.

Supplier Trace And Replay State​

Должны иметь:

  • retention policy;
  • replay-safe tooling;
  • quarantine support;
  • traceability from raw payload to downstream consequence.

Quote And Commercially Significant State​

Должны иметь:

  • persistence grade aligned with quote promise;
  • repricing trace retention;
  • policy-trace durability;
  • separation from pure cache projections.

Booking And Settlement-Relevant State​

Должны иметь:

  • highest durability posture in the platform;
  • immutable or append-safe event history;
  • support for investigation and reconciliation;
  • recovery independent from cached projections.

Rollout Discipline​

Release process должен быть выстроен вокруг риска домена, а не вокруг удобства CI.

Перед Rollout Должно Быть Понятно​

  • затрагивает ли изменение booking path;
  • затрагивает ли оно quote / repricing semantics;
  • затрагивает ли supplier intake or matching behavior;
  • затрагивает ли tenant / access boundaries;
  • затрагивает ли publication-visible surfaces;
  • затрагивает ли settlement-relevant state.

Классы Rollout Risk​

Low-Risk​

  • content-only changes;
  • purely internal UI adjustments;
  • non-critical cache or presentation changes.

Medium-Risk​

  • search and offer projection changes;
  • partner-surface additive changes;
  • ingestion normalization changes with replay safety.

High-Risk​

  • quote semantics;
  • repricing logic;
  • booking lifecycle logic;
  • identity / access boundaries;
  • migrations on transactional truth;
  • settlement-relevant event handling.

Для High-Risk Rollouts Нужны​

  • staged rollout;
  • explicit rollback plan;
  • observability gates;
  • migration compatibility check;
  • owner-on-watch during rollout.

Migration And Compatibility Discipline​

Миграции нельзя считать purely technical appendix.

Schema Migrations​

Должны быть:

  • forward-safe;
  • rollback-considered;
  • compatible with running code during rollout window where possible;
  • checked against retention-critical data classes.

Contract Migrations​

Должны учитывать:

  • partner compatibility window;
  • agency workflow continuity;
  • quote and booking state continuity;
  • async consumer impact.

Ingestion Logic Migrations​

Должны учитывать:

  • replay consequences;
  • mapping drift;
  • governance queues;
  • repricing signal changes;
  • publication safety.

Observability Baseline​

Для платформы недостаточно “metrics + logs”.

Платформа Должна Наблюдать​

  • supplier intake health;
  • ingestion lag and replay pressure;
  • quote creation volume;
  • repricing frequency and causes;
  • booking submission and confirmation latency;
  • unknown external state volume;
  • governance queue growth;
  • settlement-relevant event generation health;
  • partner and agency surface error rates.

Минимальные Execution Signals​

  • correlation id across supplier → offer → quote → booking;
  • actor/tenant/workspace context where allowed;
  • surface identity;
  • supplier identity;
  • booking and quote lifecycle state;
  • retry / idempotency outcome;
  • publication state changes.

Логи, Метрики, Трейсы​

Должны быть связаны, а не существовать отдельно.

Особенно важно, чтобы incident responder мог пройти путь:

supplier signal → ingestion trace → offer/quote impact → booking consequence → operational action

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

Incident And Recovery Model​

Платформа должна заранее предполагать, что часть её реальности будет ломаться несимметрично.

Типовые Incident Classes​

  • supplier degradation;
  • stale or inconsistent offer state;
  • quote repricing surge;
  • booking timeout or unknown external state;
  • cache invalidation failure;
  • governance queue overload;
  • delayed settlement event generation;
  • broken publication pipeline for proposals or external surfaces.

Для Каждого Класса Инцидента Должно Быть Понятно​

  • что является source of truth during incident;
  • какой surface должен degraded gracefully;
  • какие действия безопасны;
  • где нужен manual hold or publication block;
  • как выглядит recovery and replay path;
  • кто operational owner.

Operational Control​

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

Должны Существовать Операционные Возможности​

  • replay ingestion case;
  • quarantine supplier source;
  • force revalidation or repricing candidate handling;
  • inspect quote and booking trace;
  • resume or compensate stuck booking flow;
  • block unsafe publication;
  • inspect settlement trace linkage;
  • manage partner credential or surface health emergency actions.

Security And Secret Handling​

Документ не фиксирует конкретный secret-manager как уже принятый стандарт. Но execution-model обязан требовать:

  • strict environment separation;
  • secret rotation policy;
  • supplier credential isolation;
  • partner credential isolation;
  • least-privilege operational access;
  • audit trail for sensitive operational actions.

Особенно важно разделять:

  • supplier access secrets;
  • partner-facing credentials;
  • internal operator access;
  • machine-to-machine runtime credentials.

CI/CD As Derived Discipline​

CI/CD должен следовать architecture and risk model, а не подменять её.

Pipeline Должен Уметь​

  • schema validation;
  • docs-linked contract validation;
  • migration checks;
  • replay-oriented ingestion checks;
  • quote/booking critical-path verification;
  • environment-aware rollout gating;
  • rollback or halt on critical signal breach.

Чего Pipeline Не Должен Делать​

  • автоматически выкатывать high-risk changes без operational visibility;
  • считать green unit tests достаточным условием для booking/quote changes;
  • скрывать migration risk behind one-click deployment optimism.

Что Пока Не Нужно Фиксировать Как Окончательное​

На этом этапе не нужно объявлять окончательно утверждёнными:

  • exact Kubernetes topology;
  • exact node counts and resource sizes;
  • exact mesh / ingress / gateway product choice;
  • exact monitoring vendor stack;
  • exact CI vendor or YAML shape;
  • exact repository split by deployables.

Все эти вещи важны, но они производны от runtime needs and operating model, а не заменяют их.

Что Этот Документ Требует От Следующего Слоя​

После фиксации operations baseline следующими сильными документами должны стать:

  • отдельный документ по observability and incident response;
  • отдельный документ по settlement / reconciliation / finance operations;
  • при необходимости отдельный document по release engineering and migration discipline;
  • затем уже более конкретный infrastructure shape, если платформа будет готова к этой детализации.

Связь deployment с инфраструктурными фазами​

Deployment shape привязан к 4 фазам инфраструктурного масштабирования (см. scaling-and-packaging-roadmap.md).

Phase 1 — Bootstrap (single-region, single-AZ)​

Deployment shape:

  • один runtime cluster (managed Kubernetes или managed containers, OVHcloud Public Cloud Eco);
  • managed PostgreSQL с automated backup;
  • managed object storage;
  • minimal background worker layer (отдельный namespace внутри одного кластера);
  • shared cache (managed Redis);
  • API gateway (managed или один runtime unit).

Что разделяется уже на Phase 1:

  • transactional core ↔ ingestion-heavy paths (отдельные namespaces);
  • partner/public surfaces ↔ internal operations (отдельные ingress);
  • background processing ↔ user-facing latency-critical flows (отдельные queues).

Что не делается на Phase 1:

  • multi-AZ failover (приходит на Phase 2);
  • workload-specific dedicated infrastructure (приходит на Phase 3);
  • multi-region (приходит на Phase 4);
  • dedicated infrastructure для отдельных тенантов (приходит на Phase 3+).

Phase 2 — Service isolation (single-region, multi-AZ)​

Deployment shape:

  • кластер с multi-AZ нодами;
  • PostgreSQL с streaming replication между AZ + automated failover (Patroni);
  • object storage с multi-AZ replication;
  • разделённые runtime classes для transactional / ingestion / surface delivery;
  • DLQ для всех async channels;
  • automated daily test restore в изолированный namespace.

Что появляется на Phase 2:

  • cross-AZ failover для Tier 1 данных (см. disaster-recovery-and-capacity.md);
  • automated rollback procedures;
  • automated chaos drills для critical paths;
  • separated namespaces для tier-зависимых tenants (logical isolation reinforced).

Phase 3 — Workload-specific packaging​

Deployment shape:

  • bare metal или dedicated compute для search workloads (memory-bound);
  • bare metal для PostgreSQL primary (IOPS-bound);
  • dedicated GPU pools для ML inference (см. ml-platform.md);
  • secondary region cold standby для Tier 1+2;
  • dedicated namespace per tenant Professional+ (см. multi-tenant-isolation-strength.md);
  • automated cross-region replication;
  • ежеквартальные region failover drills.

Что появляется на Phase 3:

  • tenant-aware deployment isolation (dedicated_compute tier);
  • workload-specific scaling policies;
  • secondary region для DR без active traffic.

Phase 4 — Multi-region active-active / dedicated infrastructure​

Deployment shape:

  • multi-region active-active или active-passive с горячим переключением;
  • distributed Postgres (CockroachDB или Yugabyte) или managed multi-master;
  • GeoDNS с автоматическим failover;
  • dedicated infrastructure per Enterprise tenant (отдельный регион или окружение);
  • regional data residency для регулируемых юрисдикций;
  • ежемесячные chaos drills (отключение целого региона);
  • multi-region observability stack.

Что появляется на Phase 4:

  • tenant-aware deployment в dedicated_infrastructure уровне;
  • regulatory data residency (GDPR data в EU regions, KZ data в KZ-region);
  • enterprise SLA 99.9% (см. sla-and-on-call-model.md) поддерживается deployment-уровнем.

Связь deployment с четырьмя столпами операционной зрелости​

Deployment-модель — фундамент, на который опирается каждый из четырёх столпов операционной зрелости. Эта связь обязательна для production-capable платформы.

Столп 1. Runbooks (см. runbooks-incident-playbooks.md)​

Каждый каноничный incident class из runbooks привязан к конкретным execution contours и runtime units. Без deployment-модели runbook не имеет адресата.

Связь:

  • Supplier degradation runbook → ingestion contour;
  • Stale offer state runbook → offer/commercial contour;
  • Quote repricing surge runbook → offer/commercial contour;
  • Booking timeout / unknown_external_state runbook → core transactional contour + booking-state-machine;
  • Cache invalidation failure runbook → surface delivery + offer/commercial contours;
  • Governance queue overload runbook → operational control contour;
  • Delayed settlement event runbook → core transactional contour;
  • Broken publication pipeline runbook → surface delivery contour.

Deployment-модель обязана обеспечить наблюдаемость на уровне execution contour, чтобы on-call мог идентифицировать конкретный сбой по runbook.

Столп 2. SLA (см. sla-and-on-call-model.md)​

SLA измеряется per surface, на основе SLI метрик, собираемых с конкретных runtime units. Без deployment-модели SLA не привязан к измеримой реальности.

Связь:

  • Availability SLI → измеряется per API surface (Surface Delivery contour) → определяет SLA tier (Free/Starter/Professional/Enterprise);
  • Latency p95 → измеряется per endpoint type → определяет capacity и instance sizing;
  • Webhook delivery → измеряется per webhook channel (Surface Delivery contour) → определяет retry policy;
  • Booking confirmation latency → измеряется per supplier-platform path (Core Transactional + Ingestion contours);
  • unknown_external_state ratio → измеряется на booking-state-machine → определяет threshold для critical alert;
  • Payment success rate → измеряется на PaymentIntent flow (Core Transactional contour);
  • MTTR → определяется by deployment shape (cross-AZ vs cross-region recovery);
  • Restoration success → определяется по DR drills.

Deployment-модель обязана выделить SLI-источники на уровне runtime units (Prometheus metrics, structured logs с surface_id и tenant_id).

Столп 3. DR (см. disaster-recovery-and-capacity.md)​

DR процедуры восстанавливают конкретные runtime units в конкретных recovery classes. Без deployment-модели DR-процедура не имеет объекта восстановления.

Связь:

  • Tier 1 (RTO 60м, RPO 5м) → core transactional contour (PaymentIntent, Booking, Refund, Chargeback, Settlement, User, Tenant, ServiceAccount, RevenueRecord, TaxRecord) → требует cross-AZ replication с Phase 2;
  • Tier 2 (RTO 4ч, RPO 30м) → offer/commercial + ingestion contours → требует daily snapshot с verification;
  • Tier 3 (RTO 24ч, RPO 1ч) → operational control contour (DWH, event stream, audit log) → может перевычисляться из source events;
  • Tier 4 (RTO 7д) → archived data → cold storage с replication.

5-шаговая процедура восстановления (см. disaster-recovery-and-capacity.md) — declared → point selected → restored to staging → smoke tests → promoted to production — требует:

  • ephemeral namespace для staging restore (deployment-feature);
  • blue-green switch или DNS update для promotion (deployment-feature);
  • canary rollout 1% → 10% → 50% → 100% (deployment-feature).

Deployment-модель обязана поддерживать ephemeral namespaces для restore drills и canary rollout primitives.

Столп 4. Capacity planning (см. disaster-recovery-and-capacity.md)​

Capacity planning форкастит загрузку конкретных runtime classes на конкретные периоды. Без deployment-модели capacity forecast не имеет адресата.

Связь:

  • Compute (CPU) → runtime units транзакционных и поисковых contours;
  • Database (CPU и storage) → managed PostgreSQL;
  • Object storage → media и content storage;
  • Bandwidth → API gateway + webhook delivery;
  • Cache memory → managed Redis;
  • Queue throughput → DLQ-aware async pipelines.

Прогноз peak loads (сезонный, региональный, партнёрский, маркетинговый, ad-hoc — см. disaster-recovery-and-capacity.md) реализуется через:

  • predictive provisioning (заранее увеличить deployment capacity за 14–30 дней до peak);
  • auto-scaling (deployment-feature: HorizontalPodAutoscaler, managed auto-scaling);
  • graceful degradation (deployment-feature: rate limiting, feature flags, cache-only mode).

Deployment-модель обязана поддерживать auto-scaling primitives и rate limiting / feature flag infrastructure.

Связь deployment с тенантной изоляцией​

Deployment-модель различает 3 уровня тенантной изоляции (см. multi-tenant-isolation-strength.md).

Уровень 1. Logical isolation (shared infrastructure)​

Deployment shape:

  • shared cluster, shared databases, shared cache;
  • tenant_id во всех запросах и записях;
  • IsolationBoundaryCheck автоматизирован (защищает от cross-tenant data leak);
  • shared rate limits на API gateway уровне.

Подходит для: Free, Starter, Professional tier.

Уровень 2. Dedicated compute​

Deployment shape:

  • shared databases, но dedicated compute namespace;
  • tenant-specific namespace в кластере (Kubernetes namespace или Nomad cgroup);
  • dedicated rate limits per tenant;
  • tenant-specific auto-scaling policies;
  • tenant-specific runbook applicability tags.

Подходит для: Professional tier (опционально), Enterprise tier (по запросу).

Уровень 3. Dedicated infrastructure​

Deployment shape:

  • полностью выделенная infrastructure (отдельный кластер или регион);
  • dedicated database instances;
  • dedicated object storage buckets;
  • custom DR class (может быть строже Tier 1 baseline);
  • regulatory data residency support.

Подходит для: Enterprise tier (mandatory для regulated клиентов).

Связь deployment с tier'ами API as Product​

Deployment-модель поддерживает 4 tier API as Product (см. api-as-product.md).

TierSLAIsolationCapacity reservationDR classRollout sequence
Freebest-effortlogicalshared (no reservation)Tier 1 (shared)last in canary
Starter95%logicalshared (priority queue)Tier 1мiddle in canary
Professional99%logical → dedicated_compute (опционально)reserved capacity per tenantTier 1 + DR drillsearly in canary
Enterprise99.9%dedicated_compute → dedicated_infrastructurededicated reservation + headroomTier 1 + custom RTO/RPOfirst in canary (или blue/green)

Каноничное правило: Enterprise tier получает first canary — это позволяет detect any regression до того, как она достигнет shared infrastructure для Free/Starter. Это противоположно интуитивной логике «Enterprise — последний в очереди для безопасности», но согласовано с Stripe / Twilio practices: Enterprise клиенты обычно интегрированы глубже, и регрессия у них раньше детектируется.

Текущий Практический Вывод​

Платформа vitrip.store уже не должна мыслить deployment как “поднять Kubernetes и разложить сервисы по pod-ам”.

Её deployment and operating model должен исходить из следующего:

  • разные классы truth требуют разной durability;
  • разные operational paths требуют разной isolation and rollout discipline;
  • quote, booking, ingestion and settlement flows требуют stronger observability than ordinary CRUD systems;
  • supplier reality должна быть replayable and governable;
  • production shape должна эволюционировать по стадиям зрелости, а не имитировать финальную hyperscale-topology раньше времени;
  • deployment shape привязан к 4 фазам инфраструктурного масштабирования и эволюционирует по триггерам, не по календарю;
  • deployment является фундаментом для четырёх столпов операционной зрелости (runbooks / SLA / DR / capacity);
  • deployment различает 3 уровня тенантной изоляции и 4 tier'а API as Product, с явной матрицей соответствий;
  • ни один поставщик не получает captive deployment isolation (правило 00000) — поставщики живут в общем ingestion contour равноправно.