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

Операционная ось (ось 5) — масштабирование, надёжность, наблюдаемость, релизы, инциденты

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

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

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

Документ читается после главной архитектурной оси (overview/index.md), манифеста переосмысления (overview/platform-vision-and-manifest.md), дорожной карты инфраструктурного масштабирования (operations/scaling-and-packaging-roadmap.md).

Дорожная карта инфраструктурного масштабирования содержит детальную раскладку по 4 фазам с приблизительными расходами. Этот документ описывает операционные принципы и контуры на верхнем уровне архитектуры.

Главные принципы операционной оси​

Принцип 1. Эластичность как baseline​

Платформа проектируется как эластично самомасштабирующаяся система (elastically auto-scaling system) с самого первого документа. Это не "оптимизация на потом", а baseline.

Что включает с нулевого дня:

  • Горизонтальное масштабирование (horizontal scaling) как первичный путь для всех stateless-контуров;
  • Авто-масштабирование (auto-scaling) на основе метрик нагрузки — процессор, память, отставание очередей, частота запросов, задержка p95/p99, доменные метрики (активные quote, ожидающие bookings, давление на поставщиков);
  • Изоляция контуров исполнения с независимым масштабированием;
  • Гарантированная мощность для премиум-партнёров (capacity envelope per tenant tier);
  • Дисциплина обратного давления на асинхронных очередях для предотвращения каскадных сбоев;
  • Грациозная деградация (graceful degradation) при перегрузке — не отказ, а понижение качества (читать продолжает работать, новый booking — отложен с retry-after).

Принцип 2. Фазовая упаковка вычислений с триггерами​

Стратегия упаковки вычислений (compute packaging) разворачивается через 4 фазы с явными триггерами перехода. Полная карта — в operations/scaling-and-packaging-roadmap.md.

Краткая суть:

ФазаДлительностьГлавная упаковка
1 Bootstrap0-12 месVPS-3 + managed PostgreSQL + Object Storage + vRack
2 Service isolation12-24 месBare Metal Advance × 3 + Managed Kafka + OpenSearch + Managed Kubernetes
3 Workload-specific24-36 месBare Metal Scale + Eco Rise + Managed Enterprise + AI Platform
4 Multi-region и dedicated36+ месMulti-region + 3-AZ Paris + edge computing

Триггеры — метрические и доменные, не календарные. Каждый переход — расширение, не миграция.

Принцип 3. Управляемые сервисы (managed services) первичны​

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

Тезисы:

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

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

Принцип 4. Открытые стандарты, без замыкания на провайдере​

Все технологические выборы — по открытым стандартам:

  • PostgreSQL (стандарт), не Aurora/Spanner;
  • S3-совместимое объектное хранилище, не проприетарный формат;
  • Kafka, не Kinesis;
  • Kubernetes API, не EKS-специфичные расширения;
  • Redis-совместимый Valkey, не проприетарный;
  • OpenAPI / AsyncAPI — стандартные контрактные форматы.

Это позволяет в фазе 4 рассмотреть многооблачную (multi-cloud) стратегию для отдельных нагрузок.

Принцип 5. План восстановления (disaster recovery, DR) с явными целями​

DR не «когда-то напишем», а first-class part архитектуры:

  • RTO (Recovery Time Objective) — целевое время восстановления;
  • RPO (Recovery Point Objective) — допустимая точка потери данных;
  • Geo-redundant backup в фазе 4;
  • Restore drills — регулярные упражнения по восстановлению.

Конкретные RTO/RPO targets — в operations/disaster-recovery-and-capacity.md фазы 6.

Принцип 6. Наблюдаемость как продукт (observability as product)​

Observability — не «логи в файлах», а полноценный продуктовый компонент платформы:

  • Метрики (metrics) — operational и доменные;
  • Трассировки (traces) — распределённые traces для отладки кросс-сервисных взаимодействий;
  • Логи (logs) — структурированные, с корреляцией через trace IDs;
  • Дашборды (dashboards) — для команд и для tenants;
  • Alerting — на основе метрик и доменных условий;
  • Tenant-facing analytics — partner-facing dashboards как часть Professional/Enterprise tiers.

Принцип 7. Инцидент-менеджмент как формальный процесс​

Инциденты — не «сегодня что-то сломалось, завтра разберёмся», а формальный процесс с:

  • Runbooks для топ-N сценариев — что делать при отказе поставщика, при stuck booking, при settlement discrepancy spike, при partner DDoS;
  • On-call rotation — дежурные с явной ответственностью и SLA;
  • Severity levels — Critical / High / Medium / Low с явными triggers и response times;
  • Incident commander role — кто принимает решения во время инцидента;
  • Post-mortem culture — анализ после каждого critical incident, blameless;
  • Communication protocols — как и когда уведомляется tenant о критических инцидентах.

Принцип 8. Релизная дисциплина (release engineering)​

Релизы — формальный процесс с:

  • Progressive delivery — feature flags, canary deployments, gradual rollout;
  • Contract testing — автоматическая проверка совместимости контрактов перед релизом;
  • Release gates — обязательные проверки перед production deployment;
  • Rollback capability — каждый релиз reversible;
  • Migration discipline — изменения схем БД через migration tools с возможностью rollback;
  • Compatibility windows — старые версии Partner API поддерживаются в течение явного срока после выхода новых.

Контуры исполнения (execution contours)​

Платформа разделяется на разные контуры исполнения с разными операционными требованиями. Каждый контур имеет свой профиль нагрузки, свои SLA, свои capacity targets.

Контур 1. Контур канонической и транзакционной истины (canonical and transactional truth)​

Что входит:

  • управляемая PostgreSQL с canonical entities;
  • transactional layer для bookings;
  • governance layer;
  • settlement-relevant traces;
  • partner clearing state;
  • tenant configuration.

Профиль:

  • low-volume, high-criticality;
  • read-heavy + occasional writes;
  • ACID semantics обязательны;
  • audit-grade durability;
  • backup и restore — приоритет.

SLA targets:

  • 99.9%+ uptime (Enterprise tier);
  • read latency <50ms p95;
  • write latency <200ms p95.

Упаковка по фазам:

  • Фаза 1: Managed PostgreSQL Essential.
  • Фаза 2: Managed PostgreSQL Business + read replicas.
  • Фаза 3: Managed PostgreSQL Enterprise + multi-region replicas.
  • Фаза 4: Multi-region active-passive + 3-AZ Paris для booking commit.

Контур 2. Контур исполнения предложений (offer/quote/commercial execution)​

Что входит:

  • сборка offer (offer assembly);
  • логика свежести и повторной проверки (freshness и revalidation logic);
  • создание quote (quote creation);
  • логика пересчёта (repricing logic);
  • применение коммерческой политики (commercial policy application);
  • решения о публикации (publication-safety decisions).

Профиль:

  • medium-volume, latency-sensitive;
  • read-heavy;
  • предсказуемая latency критична для UX;
  • replay-safe state transitions.

SLA targets:

  • p95 search latency <500ms (Enterprise tier);
  • p95 quote creation <1s (Enterprise tier);
  • explainable repricing outcomes.

Упаковка по фазам:

  • Фаза 1: на VPS-3.
  • Фаза 2: Bare Metal Advance #1 (latency-sensitive node).
  • Фаза 3: Bare Metal Scale в Strasbourg.
  • Фаза 4: Multi-region active-active.

Контур 3. Контур приёма данных от поставщиков (supplier intake and ingestion)​

Что входит:

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

Профиль:

  • high-volume bursts (при синхронизации поставщиков);
  • throughput-heavy, не latency-sensitive;
  • replayability обязательна;
  • isolation от других контуров (peaks не должны влиять).

SLA targets:

  • ingestion latency: minutes (не realtime);
  • replay capability: full;
  • supplier outage tolerance: yes.

Упаковка по фазам:

  • Фаза 1: на VPS-3 (lightweight).
  • Фаза 2: Bare Metal Advance #2 (ingestion node) с независимым масштабированием.
  • Фаза 3: Eco Rise XL для тяжёлых ingestion workers (cost-optimized для batch).
  • Фаза 4: Multi-region (если нужен distributed intake).

Контур 4. Контур доставки поверхностей (surface delivery)​

Что входит:

  • API gateway;
  • partner API surface;
  • agency surface;
  • B2C storefront surface;
  • internal operational surface;
  • Tour Builder closed surface.

Профиль:

  • high-volume, latency-sensitive;
  • read-heavy с интенсивным cache hit ratio;
  • стабильная latency критична для conversion (B2C) и UX.

SLA targets:

Упаковка по фазам:

  • Фаза 1: всё на VPS-3.
  • Фаза 2: Bare Metal Advance + Public Load Balancer.
  • Фаза 3: Bare Metal Scale + Multi-region для read paths.
  • Фаза 4: Multi-region active-active + edge compute через Local Zones.

Контур 5. Контур governance и operational control​

Что входит:

  • review queues;
  • mapping/review actions;
  • anomaly cases;
  • manual overrides;
  • reconciliation tools;
  • support и operational dashboards.

Профиль:

  • low-volume, human-paced;
  • low-latency не критична;
  • audit-grade обязателен.

SLA targets:

  • внутренний инструмент, не внешний SLA.

Упаковка по фазам:

  • Фаза 1: на VPS-3.
  • Фаза 2: на одном из Bare Metal Advance (вместе с другими внутренними сервисами).
  • Фаза 3: продолжает на shared infrastructure.

Контур 6. Контур наблюдаемости и восстановления (observability and recovery)​

Что входит:

  • metrics collection;
  • traces aggregation;
  • logs aggregation;
  • alerting;
  • dashboards;
  • replay tooling;
  • DR procedures.

Профиль:

  • continuous, infrastructure-grade;
  • isolated от operational paths (отказ observability не должен влиять на operational).

Упаковка по фазам:

  • Фаза 1: managed Grafana (бесплатно у OVH); базовые встроенные метрики.
  • Фаза 2: managed observability stack (Prometheus, Loki, Tempo paradigm); первые dashboards для tenant-facing.
  • Фаза 3: dedicated observability cluster; partner-facing dashboards в self-service portal.
  • Фаза 4: multi-region observability с federation.

Принципы надёжности​

Изоляция отказов (failure isolation)​

  • Каждый контур исполнения изолирован: отказ ingestion не влияет на canonical truth;
  • Cascading failures предотвращаются через дисциплину обратного давления (backpressure);
  • Circuit breakers на критических точках вызовов внешних систем (поставщиков, PSP).

Идемпотентность (idempotency)​

  • Все critical mutation-операции идемпотентны (booking create, payment commit, refund issue, settlement event posting);
  • Клиент может безопасно повторять операции при сетевых сбоях;
  • Idempotency keys обязательны для production-операций.

Устойчивость к воспроизведению (replay safety)​

  • Все consumers async events идемпотентны;
  • Replay events не создаёт duplicate side effects;
  • Consumer offsets отслеживаются явно.

Грациозная деградация (graceful degradation)​

При перегрузке или частичном отказе:

  • read paths продолжают работать (fallback к cache);
  • write paths могут быть отложены с retry-after;
  • non-critical features могут быть отключены через feature flags;
  • partner-facing communication: явный сигнал о деградации, не молчаливый отказ.

Восстановление после аварий (disaster recovery)​

  • RTO (Recovery Time Objective) — целевое время восстановления операций после catastrophic failure;
  • RPO (Recovery Point Objective) — допустимая точка потери данных;
  • Backup strategy — geo-redundant в фазе 4; daily local в фазе 1-2;
  • Restore drills — регулярные упражнения по восстановлению, не «один раз настроили и забыли».

Конкретные RTO/RPO per tenant tier — в operations/disaster-recovery-and-capacity.md фазы 6.

Принципы наблюдаемости​

Корреляция событий​

  • Все cross-service interactions переносят correlation IDs (request ID, session ID, tenant ID);
  • Distributed tracing через trace IDs;
  • Возможность пройти end-to-end путь любого запроса.

Структурированные логи​

  • Все логи — JSON или эквивалентный структурированный формат;
  • Обязательные поля: timestamp, severity, service name, trace ID, tenant ID (где применимо), message, context;
  • Logs aggregator с поиском и фильтрацией.

Метрики​

  • RED metrics (Rate, Errors, Duration) для каждого сервиса;
  • USE metrics (Utilization, Saturation, Errors) для инфраструктуры;
  • Доменные метрики — active quotes, pending bookings, supplier health, ingestion lag, settlement event lag.

Дашборды​

  • Operational dashboards — для on-call и DevOps команд;
  • Domain dashboards — для product-команд (booking funnel, partner usage, supplier health);
  • Tenant-facing dashboards — для партнёров (часть Professional/Enterprise tiers);
  • Executive dashboards — для бизнес-метрик.

Alerting​

  • Severity levels — Critical / High / Medium / Low;
  • Alert fatigue mitigation — alerts только на actionable signals, не на noise;
  • On-call routing — alerts маршрутизируются к ответственному дежурному;
  • Alert acknowledgment и escalation — формальный процесс.

Принципы релизной дисциплины​

Progressive delivery​

  • Feature flags — новые features включаются для cohorts, не сразу для всех;
  • Canary deployments — новый код развёртывается на малую долю трафика, метрики мониторятся, постепенный rollout;
  • Gradual rollout — поэтапное расширение exposure;
  • Automatic rollback triggers — при деградации метрик автоматический откат.

Contract testing​

  • Pact-style contract testing — потребители (consumers) и поставщики (producers) контрактов прогоняют автоматические проверки совместимости перед merge;
  • Schema validation — изменения схем событий проверяются на breaking changes;
  • API versioning checks — изменения Partner API проверяются на совместимость с поддерживаемыми версиями.

Release gates​

Перед production deployment обязательны:

  • ✅ unit + integration tests passed;
  • ✅ contract tests passed;
  • ✅ schema migrations validated;
  • ✅ canary rollout successful;
  • ✅ no SLA degradation in canary metrics;
  • ✅ rollback plan documented.

Migration discipline​

  • Schema migrations через migration tools (Flyway, Liquibase, или эквивалент);
  • Backward compatible migrations обязательны для production deployments;
  • Forward compatibility — новый код работает с old schema до завершения migration;
  • Rollback capability для каждой migration.

Compatibility windows для Partner API​

  • Old version supported в течение явного срока после выхода новой;
  • Deprecation announcement заранее — партнёры получают webhook + email + announcement в console;
  • Migration guides доступны в documentation;
  • Tier-aware compatibility — Enterprise tier получает удлинённое compatibility window.

Принципы инцидент-менеджмента​

Severity levels​

SeverityTriggersResponse timeCommunication
Critical (SEV 1)Production down for ≥1 tenant; financial-critical contour broken; data loss risk<15 min acknowledge; <30 min responseStatus page + tenant notifications + executive team
High (SEV 2)Degraded service для multiple tenants; non-critical contour broken; not impacting financial truth<30 min acknowledge; <2 hour responseStatus page + affected tenants notifications
Medium (SEV 3)Single-tenant impact; degradation в feature без impact на core<2 hour acknowledge; <24 hour responseAffected tenant notification
Low (SEV 4)Cosmetic issues; minor бaги; не impacting usersnext business dayInternal tracking only

On-call rotation​

  • 24/7 coverage для Critical и High incidents (фаза 3+);
  • Business hours support для Medium и Low (фазы 1-2);
  • Primary + secondary on-call для каждой смены;
  • Escalation path — если primary не отвечает за N минут, эскалация к secondary, затем к incident commander.

Incident commander role​

  • Один человек — incident commander на каждом инциденте Critical/High;
  • Ответственность — координация response, коммуникация, принятие решений;
  • Не выполняет technical debugging — это делают engineers; commander координирует.

Post-mortem culture​

  • Blameless post-mortems — анализ системных причин, не индивидуальной вины;
  • Action items — конкретные шаги для предотвращения повторения;
  • Knowledge sharing — post-mortems публикуются для всей команды;
  • Pattern recognition — повторяющиеся проблемы → системные improvements.

Tenant communication​

  • Status page — публичная страница с текущим статусом сервисов;
  • Webhook notifications для tenants о критических инцидентах, влияющих на них;
  • Email notifications для Enterprise tier;
  • Post-incident report для Enterprise tier — детальный отчёт с timeline, причинами, action items.

Связь с другими осями архитектуры​

Связь с осью 1 (каноничная доменная)​

  • Booking — самый критический операционный домен (audit, recovery, SLA);
  • Governance — операционный процесс с человеком в цикле (human-in-the-loop);
  • Replay capability — для всех групп сущностей с persistent layer;
  • Failure recovery — booking lifecycle включает unknown_external_state как first-class.

Связь с осью 2 (поверхности взаимодействия)​

  • У каждой поверхности своё SLA;
  • B2C — самые жёсткие требования по latency и uptime;
  • Partner API — самые жёсткие требования по contract stability;
  • Internal — менее строгие SLA, фокус на функциональность.

Связь с осью 3 (платформа как продукт)​

  • SLA = коммерческое обещание тенанту, прямо зависит от tier;
  • Capacity envelopes per tier — операционная гарантия для Enterprise;
  • DR с RTO/RPO — обязательство Enterprise tier;
  • On-call rotation для Critical incidents — Enterprise tier.

Связь с осью 4 (данные и интеллект)​

  • Observability metrics — пересечение с data осью (operational metrics в analytical pipelines);
  • Anomaly detection в ingestion — operational use case ML;
  • Predictive scaling — основан на ML моделях из data оси;
  • Tenant-facing dashboards — partner-facing analytics product как часть Professional/Enterprise tiers.

Связь с осью 6 (реализация)​

Текущий home-to-go-api:

  • Использует managed PostgreSQL vitianaapipg.psql.tools — первая реализация канонического + транзакционного контура;
  • Не имеет multi-region;
  • Не имеет полного DR plan;
  • Не имеет formal incident management;
  • Не имеет 24/7 on-call.

Полная карта соответствия — в overview/relation-to-implementation-baseline.md.

Развёртывание оси по фазам​

Фаза 1 (Bootstrap, 0-12 мес)​

Что развёртывается:

  • managed PostgreSQL Essential, managed Object Storage, vRack;
  • managed Grafana для observability;
  • VPS-3 с базовой настройкой (fail2ban, обновления);
  • ручной incident management (один человек на on-call в business hours).

SLA: best effort. Tenants — Free tier и первые Starter tier (если уже есть).

Фаза 2 (Service isolation, 12-24 мес)​

Что развёртывается:

  • разделение execution contours на разные Bare Metal Advance nodes;
  • managed Kafka, managed OpenSearch, managed Kubernetes;
  • managed observability stack (Prometheus, Loki, Tempo paradigm);
  • formal release engineering — feature flags, contract testing, migration discipline;
  • formal on-call rotation (business hours);
  • runbooks для топ-5 сценариев;
  • status page;
  • tenant-facing dashboards (базовая версия).

SLA: Starter (99.0%) и Professional (99.5%) tiers introduced.

Фаза 3 (Workload-specific, 24-36 мес)​

Что развёртывается:

  • Bare Metal Scale для критического ядра;
  • multi-region read paths;
  • 24/7 on-call rotation;
  • runbooks для топ-15 сценариев;
  • formal post-mortem culture;
  • production-grade DR с regular drills;
  • AI-powered observability (anomaly detection, predictive alerting);
  • tenant-facing analytics product (Professional+ tiers);
  • partner-facing API uptime credits.

SLA: Enterprise tier introduced (99.9%+).

Фаза 4 (Multi-region, 36+ мес)​

Что развёртывается:

  • multi-region active-active для read paths;
  • multi-region active-passive для write paths;
  • 3-AZ Paris для booking commit;
  • dedicated infrastructure для Enterprise tenants;
  • edge compute через Local Zones;
  • multi-region observability с federation;
  • formal compliance audits (SOC 2 Type II, ISO 27001);
  • enterprise-grade DR с RTO < 1 hour, RPO < 15 minutes.

SLA: Enterprise tier achieves 99.99%+.

Углубление в документах нижних слоёв​

Эта ось верхнего уровня раскрывается детально в документах фазы 6:

ТемаДокумент
Runbooks для топ-N инцидентовoperations/runbooks-incident-playbooks.md
SLA-контракт и on-call modeloperations/sla-and-on-call-model.md
Disaster recovery + capacity planningoperations/disaster-recovery-and-capacity.md
Dispute и reconciliation operations (углубление)расширение operations/settlement-and-reconciliation.md

Уже существующие документы второго круга, релевантные оси:

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

Развилка 1. AWS/GCP/Hetzner в дополнение к OVHcloud​

OVHcloud — первичная экосистема. Открытая развилка: на фазе 4 рассмотреть multi-cloud для отдельных нагрузок (например, более развитого AI-стека). Эскалируется при достижении фазы 4.

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

3-AZ Paris доступен только в Париже у OVHcloud. Это привязывает критическое ядро к одному региону.

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

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

Эскалируется в фазе 3.

Развилка 3. Self-hosted vs managed для critical components​

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

Триггер пересмотра: когда стоимость Managed Enterprise превышает стоимость 2× Bare Metal с self-hosted и DBA.

Эскалируется в фазе 4.

Развилка 4. Cloud GPU vs dedicated GPU для ML​

OVHcloud Cloud GPU предлагает обучение и inference. На фазе 4 рассмотреть выделенные GPU-серверы для постоянного inference.

Эскалируется при достижении фазы 4.

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