Восстановление после аварий и планирование ёмкости (disaster recovery and capacity planning)

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

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

Этот документ задаёт каноничную модель восстановления после катастрофических сбоев (disaster recovery, DR) и планирования вычислительной ёмкости (capacity planning) платформы Vitiana. Документ закрывает третий столп операционной зрелости (наряду с runbooks-incident-playbooks и sla-and-on-call-model) и определяет: целевые показатели восстановления (RTO Recovery Time Objective и RPO Recovery Point Objective), стратегии резервного копирования (backup strategies), процедуры восстановления (restore procedures), регулярные учения (DR drills), модель планирования ёмкости (capacity model), процедуру масштабирования вперёд (forward provisioning) и обработку прогнозируемых пиковых нагрузок (peak load handling).

DR и capacity — это две стороны одной задачи: первое отвечает на вопрос «что делать, если ёмкость исчезла», второе — «что делать, если ёмкость заканчивается». Обе требуют упреждающего проектирования (proactive design), а не реактивных мер.

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

Тезис 1. DR — first-class часть архитектуры, не «когда-нибудь напишем».

Альтернативы: (а) ad-hoc восстановление через ручные действия команды; (б) надежда на отсутствие катастрофических сбоев; (в) полагаться на резервное копирование облачного провайдера без собственной верификации.

Trade-off: явная DR-стратегия требует регулярных учений (DR drills), стоит времени команды (estimated 4–8 человеко-часов на учение каждые 90 дней), требует резервной инфраструктуры (additional cost). Однако без неё первый же серьёзный сбой превращается в многочасовой простой с потерей данных и репутации; для платформы, которая предоставляет коммерческие SLA с финансовыми санкциями (см. Модель SLA и дежурств (sla-and-on-call-model.md)), это неприемлемо. Регулярные учения снижают MTTR (Mean Time To Recovery) с часов до десятков минут.

Тезис 2. Capacity planning — это непрерывная функция, а не разовое упражнение.

Альтернативы: (а) реактивное масштабирование при достижении пределов; (б) разовое планирование с фиксированными лимитами; (в) полагаться только на auto-scaling без долгосрочного прогноза.

Trade-off: непрерывное планирование требует наблюдаемости (observability) утилизации ресурсов, прогнозирования трафика, регулярных reviews. Однако реактивное масштабирование на платформе с долгим lead time для выделенной инфраструктуры (bare metal в OVHcloud — недели на провижионинг) приводит либо к деградации SLA в моменты роста, либо к избыточным расходам на «запас», который никогда не используется. Современные верхнеуровневые платформы (Stripe, Twilio) ведут capacity planning как операционный ритуал.

Тезис 3. Tiered RTO/RPO — разные классы данных требуют разных гарантий восстановления.

Альтернативы: (а) единый RTO/RPO для всей платформы (например, 1 час / 5 минут для всего); (б) минимизация RTO/RPO для всех данных (мажорная стоимость); (в) делегирование выбора отдельным сервисам без каноничной модели.

Trade-off: единые SLA по восстановлению либо избыточно дороги для analytical данных (которые можно перевычислить), либо недостаточны для transactional данных (где потеря 1 часа платежей = серьёзный финансовый и репутационный ущерб). Tiered модель (Tier 1: критические транзакционные, Tier 2: операционные, Tier 3: аналитические) позволяет выделить ресурсы там, где они действительно нужны, и сэкономить там, где они не критичны.

Тезис 4. Geo-redundant DR — это фаза 4, не фаза 1.

Альтернативы: (а) геораспределённая инфраструктура с нулевого дня; (б) DR в одном регионе всегда; (в) гибридная схема с partner cloud для DR.

Trade-off: геораспределённая инфраструктура с фазы 1 — экономически нецелесообразна (платформа на этапе bootstrap не генерирует достаточную выручку для покрытия 2x инфраструктуры). DR в одном регионе на фазе 4 (когда платформа обслуживает enterprise-клиентов с географическими и регуляторными требованиями) — становится недопустимой. Поэтапный переход (фаза 1: backup + restore в том же регионе; фаза 2: cross-AZ failover; фаза 3: secondary region cold standby; фаза 4: active-active multi-region) — следует за бизнес-ростом и регуляторными обязательствами. См. Дорожная карта масштабирования (scaling-and-packaging-roadmap.md).

Тезис 5. DR drills — обязательны и фиксируются как канонические события.

Альтернативы: (а) учения «по возможности»; (б) теоретический tabletop без реального восстановления; (в) учения только перед аудитами.

Trade-off: реальные DR drills (включая полное восстановление в изолированном окружении) — затратны (4–8 часов команды на цикл), требуют автоматизации, могут вскрывать проблемы в production runbooks. Однако только реальные учения проверяют, что процедуры действительно работают: tabletop показывает «как мы думаем, что сделаем», drill показывает «что реально происходит». Каноничные события (dr.drill.started, dr.drill.completed, dr.drill.failed) дают аудитный след для compliance (SOC 2, ISO 27001).

Каноничная модель — пять сущностей

Сущность 1. Класс восстановления (RecoveryClass)

Определяет уровень гарантий восстановления для класса данных или операций.

Каноничные атрибуты:

• class_id (tier_1_critical, tier_2_operational, tier_3_analytical, tier_4_archive);
• name (человеко-читаемое имя);
• rto_minutes (целевое время восстановления — Recovery Time Objective);
• rpo_minutes (допустимая точка потери данных — Recovery Point Objective);
• backup_frequency (continuous, every_5_minutes, hourly, daily, weekly);
• backup_retention_days (срок хранения резервных копий);
• geo_redundancy_required (true/false, для фазы 4);
• encryption_required (true/false);
• restore_test_frequency_days (как часто проводить учения по восстановлению).

Сущность 2. План резервного копирования (BackupPolicy)

Конфигурация резервного копирования для конкретного хранилища или сервиса.

Каноничные атрибуты:

• policy_id (UUID);
• target_resource (имя ресурса — БД, объектное хранилище, конфигурация);
• recovery_class_id (ссылка на RecoveryClass);
• backup_method (logical_dump, physical_snapshot, wal_streaming, object_replication, volume_snapshot);
• storage_location (где хранятся резервные копии — отдельный регион, отдельный провайдер, immutable storage);
• encryption_key_id (ID ключа шифрования);
• verification_enabled (автоматическая проверка восстанавливаемости);
• last_verified_at (последняя успешная проверка);
• created_at, updated_at.

Сущность 3. Точка восстановления (RecoveryPoint)

Конкретная резервная копия или точка во времени, доступная для восстановления.

Каноничные атрибуты:

• recovery_point_id (UUID);
• policy_id (ссылка на BackupPolicy);
• point_in_time (момент времени, к которому восстанавливает);
• size_bytes (размер резервной копии);
• storage_uri (URI хранилища — например, s3://...);
• checksum (контрольная сумма);
• verification_status (unverified, verified, corrupt);
• verified_at (момент успешной проверки);
• expires_at (момент истечения срока хранения);
• created_at.

Сущность 4. Учение по восстановлению (DRDrill)

Регулярное упражнение по восстановлению, проводимое для проверки готовности.

Каноничные атрибуты:

• drill_id (UUID);
• drill_type (backup_verify, partial_restore, full_restore, region_failover, chaos_drill);
• scope (что восстанавливается — конкретная БД, тенант, регион, всё);
• recovery_class_id (целевой класс восстановления);
• target_rto_minutes (целевое время в учении);
• target_rpo_minutes (целевая точка потери в учении);
• started_at (момент начала);
• completed_at (момент завершения);
• actual_rto_minutes (фактическое время восстановления);
• actual_rpo_minutes (фактическая точка потери);
• success (true/false);
• issues_found (массив найденных проблем);
• remediation_actions (план исправления);
• next_drill_due_at (когда следующее учение).

Сущность 5. Прогноз ёмкости (CapacityForecast)

Прогноз будущей загрузки для планирования инфраструктуры.

Каноничные атрибуты:

• forecast_id (UUID);
• forecast_period (weekly, monthly, quarterly, yearly);
• resource_type (compute, database, storage, bandwidth, cache_memory, queue_throughput);
• current_utilization_pct (текущая утилизация);
• projected_utilization_pct (прогнозируемая утилизация на конец периода);
• growth_drivers (массив факторов — например, «новый партнёр X», «сезонный пик»);
• recommended_action (no_action, monitor, provision_within_30d, urgent_provision);
• lead_time_days (срок выделения ресурсов);
• cost_estimate_usd (оценка стоимости);
• created_at, forecast_horizon_at.

Каноничные классы восстановления

Платформа Vitiana различает четыре класса данных с разными гарантиями восстановления.

Tier 1 — критические транзакционные данные

Что входит:

• Платежи и платёжные транзакции (payment_intent, payment_transaction, refund, chargeback);
• Бронирования и события статусной машины (booking, booking_state_transition);
• Партнёрские взаиморасчёты (partner_clearing_record, payout_batch);
• Идентичность и аутентификация (user, tenant, service_account);
• Финансовая отчётность (revenue_record, tax_record).

Целевые показатели:

• RTO (Recovery Time Objective) ≤ 60 минут;
• RPO (Recovery Point Objective) ≤ 5 минут;
• Backup: continuous WAL streaming + snapshot каждый час;
• Retention: 7 лет (регуляторное требование);
• Geo-redundancy: фаза 4 обязательна, фаза 3 рекомендуется;
• Encryption: at-rest + in-transit обязательно;
• Restore test: каждые 30 дней.

Tier 2 — операционные данные

Что входит:

• Каталог предложений (offer, offer_pricing_snapshot, quote);
• Поиск и индексы (search_projection, ranking_policy);
• Конфигурации тенантов (tenant_configuration, partner_contract);
• Уведомления и очереди (notification, webhook_delivery);
• Метрики потребления (metering_record, quota_state).

Целевые показатели:

• RTO ≤ 4 часов;
• RPO ≤ 30 минут;
• Backup: snapshot каждые 6 часов;
• Retention: 90 дней;
• Geo-redundancy: фаза 4 рекомендуется;
• Encryption: at-rest обязательно;
• Restore test: каждые 90 дней.

Tier 3 — аналитические данные

Что входит:

• Хранилище данных (data_warehouse);
• События и трекинг (event_stream, tracking_event);
• Журналы аудита (audit_log);
• Снимки A/B-экспериментов (experiment_assignment, exposure_event);
• ML feature store, model registry.

Целевые показатели:

• RTO ≤ 24 часа (можно перевычислить из source events);
• RPO ≤ 1 час;
• Backup: snapshot ежедневно;
• Retention: 2 года для аудита, 1 год для аналитики;
• Geo-redundancy: только архивная копия;
• Encryption: at-rest;
• Restore test: каждые 180 дней.

Tier 4 — архивные данные

Что входит:

• Архивные финансовые документы (старше 7 лет — для соответствия требованиям регуляторов);
• Архивные журналы аудита (старше 2 лет);
• Архивные медиа (media_asset с пометкой archived).

Целевые показатели:

• RTO ≤ 7 дней (cold storage);
• RPO ≤ 24 часа на момент архивирования;
• Backup: cold object storage с replication;
• Retention: 10 лет минимум;
• Geo-redundancy: обязательна (immutable storage);
• Encryption: at-rest обязательно;
• Restore test: каждые 365 дней.

Стратегии резервного копирования по фазам

Платформа разворачивает резервное копирование по четырём фазам, согласованным с Дорожной картой масштабирования (scaling-and-packaging-roadmap.md).

Фаза 1 — Bootstrap (single-region, single-AZ)

Подход: managed backup облачного провайдера + собственная верификация.

Конкретика для OVHcloud Public Cloud:

• PostgreSQL: managed automated backup OVHcloud + WAL-G в OVH Object Storage (отдельный bucket в том же регионе);
• Object Storage: incremental sync в отдельный bucket с версионированием;
• Конфигурации: GitOps репозиторий + branch protection;
• Секреты: HashiCorp Vault с automated snapshot.

Ограничения фазы 1: single-region — не выдерживает потерю всего региона. Это ожидаемо: фаза 1 рассчитана на bootstrap с минимальными расходами; geo-redundancy появляется в фазе 3.

Триггер перехода в фазу 2: появление tenant с SLA Professional (99%) + первые 10 платных партнёров.

Фаза 2 — Service isolation (single-region, multi-AZ)

Подход: cross-AZ replication для Tier 1 + automated restore drills.

Конкретика:

• PostgreSQL: streaming replication между AZ + automated failover (Patroni);
• Object Storage: multi-AZ replication;
• Backup verification: автоматический ежедневный test restore в изолированный namespace;
• Restore drill: ежемесячный partial restore для Tier 1.

Триггер перехода в фазу 3: контракт с tenant Enterprise (99,9%) или регуляторное требование geo-redundancy.

Фаза 3 — Workload-specific packaging (cross-region cold standby)

Подход: secondary region с cold standby для Tier 1 + Tier 2.

Конкретика:

• PostgreSQL: logical replication в secondary region (read-only standby);
• Object Storage: cross-region replication;
• DNS failover: automated через Cloudflare или аналог с health check;
• Restore drill: ежеквартальный full region failover в изолированном окружении.

Триггер перехода в фазу 4: мульти-региональное присутствие enterprise-клиентов или регуляторное требование data residency.

Фаза 4 — Multi-region active-active

Подход: active-active или active-passive с горячим переключением.

Конкретика:

• PostgreSQL: multi-master через distributed Postgres (CockroachDB, Yugabyte) или active-passive с автоматическим failover;
• Object Storage: multi-region replication с consistency гарантиями;
• Конфигурации и секреты: глобальная репликация Vault;
• DNS failover: GeoDNS с автоматическим переключением;
• Restore drill: ежемесячный chaos drill (отключение целого региона).

Процедура восстановления — каноничный алгоритм

Любое восстановление следует пятишаговому алгоритму.

Шаг 1. Объявление инцидента восстановления

Запускается через runbook (см. Runbook'и инцидент-плейбуки (runbooks-incident-playbooks.md)). Дежурный (on-call) объявляет инцидент через систему алертов; runbook автоматически создаёт incident_id.

Каноничное событие: dr.recovery.declared со ссылкой на incident_id, recovery_class_id, target_resource.

Шаг 2. Выбор точки восстановления

Через recovery_point_browser (внутренний интерфейс) дежурный выбирает RecoveryPoint, удовлетворяющий целевому RPO.

Правила выбора:

• Самая свежая verified точка, не старше RPO целевого класса;
• Если verified точка старше RPO — эскалация в Engineering Manager (см. on-call structure в SLA модели (sla-and-on-call-model.md));
• Точка должна пройти автоматическую проверку checksum перед запуском восстановления.

Каноничное событие: dr.recovery.point_selected с recovery_point_id, point_in_time, expected_data_loss_minutes.

Шаг 3. Восстановление в изолированный namespace

Восстановление никогда не идёт прямо в production — сначала в изолированный namespace для верификации.

Действия:

• Создать ephemeral namespace (Kubernetes namespace, отдельная БД, изолированная сеть);
• Запустить процедуру restore (restore_from_point);
• Дождаться завершения (мониторинг через restore_progress метрику);
• Запустить smoke-тесты восстановленного окружения (dr.smoke_test_suite);
• Зафиксировать actual_data_loss_minutes и actual_recovery_time_minutes.

Каноничные события: dr.recovery.restored_to_staging, dr.recovery.smoke_tests_passed или dr.recovery.smoke_tests_failed.

Шаг 4. Промоутинг восстановленного состояния в production

После прохождения smoke-тестов — промоутинг.

Действия:

• Перевод трафика с deprecated production на восстановленный namespace через blue-green switch или DNS update;
• Постепенное наращивание трафика (canary 1% → 10% → 50% → 100%);
• Мониторинг ключевых SLI (см. SLA модели (sla-and-on-call-model.md)) на каждом шаге;
• При деградации SLI — откат через runbook.

Каноничное событие: dr.recovery.promoted_to_production с traffic_percentage_at_completion.

Шаг 5. Постмортем и фиксация

После успешного восстановления — обязательный постмортем (post-mortem) в течение 5 рабочих дней.

Содержание постмортема:

• Хронология (timeline);
• Корневая причина (root cause analysis);
• Сравнение фактических RTO/RPO с целевыми;
• Action items (с responsible owner и due date);
• Обновление runbooks и DR-плана при необходимости.

Каноничное событие: dr.recovery.postmortem_completed со ссылкой на документ постмортема.

Учения по восстановлению (DR drills)

DR drills — обязательная регулярная активность, обеспечивающая работоспособность процедур.

Типы учений

Тип	Частота	Длительность	Кто проводит
backup_verify	автоматически ежедневно	5–15 мин	автоматизированный
partial_restore	ежемесячно	30–60 мин	дежурная команда
full_restore	ежеквартально	2–4 часа	команда платформы
region_failover	каждые 6 мес (фаза 3+)	4–8 часов	вся инженерная команда
chaos_drill	ежемесячно (фаза 4+)	1–2 часа	автоматизированный + on-call

Правила проведения

1. Учения проводятся в production-аналогичном окружении (не на dev). Это означает использование production-grade данных (анонимизированных или production replica), production-grade инфраструктуры.
2. Учения нельзя пропускать. Если запланированное учение сорвано — оно переносится на ближайший возможный день, не на «следующий цикл».
3. Результаты фиксируются в dr_drill_record со всеми атрибутами (фактические RTO/RPO, найденные проблемы, action items).
4. Найденные проблемы — обязательны к устранению до следующего учения. Если повторяющаяся проблема не устранена — эскалация в Director/VP Engineering.
5. Невыполнение учений = автоматическая деградация платформенных гарантий: tenant Enterprise теряет 99,9% SLA до восстановления операционной зрелости.

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

• dr.drill.scheduled (учение запланировано);
• dr.drill.started (учение началось);
• dr.drill.completed_successful (успешно завершено);
• dr.drill.completed_with_issues (завершено с найденными проблемами);
• dr.drill.failed (не выполнено);
• dr.drill.postponed (перенесено на другой день);
• dr.drill.action_item_resolved (problem from drill resolved).

Планирование ёмкости — каноничный процесс

Capacity planning — ежеквартальный ритуал с ежемесячным мониторингом и ad-hoc reviews при триггерных событиях.

Шаг 1. Сбор данных утилизации

Источники:

• Метрики облачного провайдера (CPU, memory, disk I/O, network);
• Метрики приложения (request rate, queue depth, cache hit ratio);
• Метрики бизнеса (количество тенантов, количество бронирований/мес, объём поисковых запросов);
• Метрики потребления API (см. API metering and usage governance (api-metering-and-usage-governance.md)).

Хранилище данных утилизации: DWH (capacity_metrics_fact table).

Шаг 2. Анализ трендов

Аналитический процесс (раз в месяц):

• Утилизация ресурсов на 30/60/90 дней;
• Прогноз роста (linear regression, seasonal decomposition);
• Идентификация «горячих точек» (resources с утилизацией более 70%);
• Идентификация «холодных точек» (resources с утилизацией менее 20% — кандидаты на оптимизацию).

Шаг 3. Прогноз и рекомендации

Каноничный документ: capacity_forecast_report (квартальный).

Структура:

• Текущая утилизация по категориям ресурсов;
• Прогноз на 90 / 180 / 365 дней;
• Драйверы роста (новые тенанты, сезонные пики, новые продуктовые фичи);
• Рекомендации с lead time и cost estimate;
• Risk register (что может пойти не так и когда).

Шаг 4. Provisioning

Действия по результату прогноза:

• no_action — мониторинг продолжается;
• monitor — установлен alert на дальнейший рост;
• provision_within_30d — заявка на выделение ресурсов в течение 30 дней;
• urgent_provision — заявка на немедленное выделение (эскалация в CTO).

Шаг 5. Постмониторинг

После выделения ресурсов:

• Подтверждение, что утилизация снизилась до целевых уровней;
• Обновление прогноза с учётом нового baseline;
• Постмортем при срочном provisioning (что упустили в плановом прогнозе).

Целевые уровни утилизации ресурсов

Платформа поддерживает целевые уровни утилизации, согласованные с фазами масштабирования.

Ресурс	Целевая утилизация (среднее за 7 дней)	Уровень тревоги (alert)	Уровень критичности (critical)
Compute (CPU)	50–60%	более 70%	более 85%
Database (CPU)	40–50%	более 65%	более 80%
Database (storage)	50–70%	более 80%	более 90%
Object storage	60–80%	более 85%	более 92%
Bandwidth	40–60%	более 70%	более 85%
Cache memory	50–70%	более 80%	более 90%
Queue throughput	40–60%	более 75%	более 90%

Обоснование headroom: платформа держит запас в 30–40% над текущей утилизацией для покрытия:

• Сезонных пиков (туристический сезон в Европе — летние месяцы);
• Спайков от больших партнёров (запуск маркетинговой кампании);
• Времени на provisioning новой инфраструктуры (для bare metal в OVHcloud — 1–4 недели);
• Внеплановых нагрузок (вирусные новости, события, акции).

Прогнозируемые пиковые нагрузки

Платформа должна явно прогнозировать пиковые нагрузки и заблаговременно выделять ресурсы.

Каноничные классы пиков

1. Сезонный пик (seasonal peak) — летний туристический сезон в Европе (июнь–август), новогодний сезон (декабрь–январь). Прогноз: x2–x3 от среднего за полгода.
2. Региональный пик (regional peak) — национальные праздники, школьные каникулы, события (Eurovision, спортивные чемпионаты). Прогноз: x1.5–x2 на регион.
3. Партнёрский пик (partner-driven peak) — запуск маркетинговой кампании крупного партнёра. Прогноз: x2 на конкретный API endpoint.
4. Маркетинговый пик платформы (platform-driven peak) — запуск новой продуктовой фичи vitrip.store, релиз. Прогноз: x1.5 на B2C поверхность.
5. Ad-hoc пик (unplanned spike) — вирусные события, новости. Прогноз: до x5 на короткий срок (часы).

Стратегия обработки

Стратегия обработки пиков построена на трёх уровнях:

Уровень 1. Предиктивный provisioning. Для прогнозируемых пиков (сезонные, региональные, партнёрские) платформа заранее (за 14–30 дней) увеличивает капасити. Источники прогноза: исторические данные DWH + календарь событий + партнёрские планы.

Уровень 2. Auto-scaling. Для коротких всплесков auto-scaling добавляет ёмкость в течение минут (для контейнерных сервисов) или часов (для managed databases). См. feedback_elastic_scaling_and_packaging.md.

Уровень 3. Graceful degradation. Для непрогнозируемых ad-hoc пиков, превышающих auto-scaling возможности, платформа активирует процедуры graceful degradation:

• Rate limiting на per-tenant уровне (бесплатные тенанты деградируют первыми);
• Отключение non-critical features (рекомендации, дополнительные обогащения);
• Замедление batch jobs (DWH ETL, ML training);
• Активация cache-only режима для search queries.

Полный список процедур degradation — в runbooks-incident-playbooks.md.

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

DR-стратегия зависит от уровня изоляции тенанта (см. Сила тенантной изоляции (multi-tenant-isolation-strength.md)).

Уровень изоляции	Стратегия восстановления	Особенности
logical (shared infrastructure)	Восстановление общей инфраструктуры — все логические тенанты восстанавливаются одновременно	RTO/RPO определяются классом данных, не тенантом
dedicated_compute	Восстановление выделенного compute namespace — изолировано от других тенантов	Возможно tenant-specific point-in-time recovery
dedicated_infrastructure	Восстановление полностью выделенной инфраструктуры — индивидуальный backup и restore plan	Custom RTO/RPO по контракту, может быть строже стандартного Tier 1

Каноничные события (DR and Capacity)

Все события публикуются в общем потоке (см. Первоначальная таксономия событий (initial-event-taxonomy.md)) с префиксом dr. или capacity..

DR события:

• dr.recovery.declared;
• dr.recovery.point_selected;
• dr.recovery.restored_to_staging;
• dr.recovery.smoke_tests_passed;
• dr.recovery.smoke_tests_failed;
• dr.recovery.promoted_to_production;
• dr.recovery.completed;
• dr.recovery.postmortem_completed;
• dr.backup.created;
• dr.backup.verified;
• dr.backup.expired;
• dr.backup.deleted;
• dr.drill.scheduled;
• dr.drill.started;
• dr.drill.completed_successful;
• dr.drill.completed_with_issues;
• dr.drill.failed;
• dr.drill.postponed;
• dr.drill.action_item_resolved.

Capacity события:

• capacity.forecast.created;
• capacity.forecast.updated;
• capacity.threshold.warning_triggered (alert level);
• capacity.threshold.critical_triggered (critical level);
• capacity.provisioning.requested;
• capacity.provisioning.completed;
• capacity.degradation.activated;
• capacity.degradation.deactivated.

Ответственность ролей

Роль	Ответственность
On-call engineer	Объявление DR-инцидента, выполнение runbook, эскалация
Engineering Manager	Принятие решения о выборе recovery point, координация во время инцидента
Director / VP Engineering	Эскалация при невозможности достичь RTO, коммуникация с stakeholders
CTO / CISO	Утверждение DR-плана, регуляторная отчётность, финальное решение по сложным trade-off
Platform team	Поддержание DR-плана, проведение учений, capacity planning
SRE team (фаза 3+)	Owner DR-плана, координация учений, capacity forecasting
Compliance officer (фаза 3+)	Аудит соответствия DR-плана регуляторным требованиям (SOC 2, ISO 27001)

Технологические выборы по фазам

Технология	Фаза 1	Фаза 2	Фаза 3	Фаза 4
Backup orchestration	OVH managed + WAL-G	Velero + WAL-G	Velero + WAL-G + cross-region	Multi-region tooling (Cohesity, Veeam)
PostgreSQL backup	OVH automated + WAL-G	Patroni + WAL-G + streaming	Logical replication + cross-region	Distributed Postgres (Cockroach/Yugabyte)
Object storage backup	OVH bucket replication	Cross-AZ replication	Cross-region replication	Multi-region with consistency
DNS failover	Cloudflare manual	Cloudflare automated	GeoDNS health check	Active-active с глобальной балансировкой
Capacity monitoring	Grafana + Prometheus	+ custom dashboards	+ capacity forecasting service	+ AI-based prediction
Chaos engineering	manual game days	+ monthly chaos drills	+ Chaos Monkey style	+ Gremlin или внутренний chaos platform

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

1. Multi-cloud DR. Должна ли платформа развернуть DR-копию на втором облачном провайдере (например, AWS как backup для OVHcloud) для защиты от провайдерских сбоев? Trade-off: дополнительная сложность и стоимость vs. защита от уровня риска «весь провайдер недоступен». Решение откладывается до фазы 4 при наличии enterprise-клиента, требующего multi-cloud.
2. Данные тенантов с региональными требованиями. Для тенантов с data residency требованиями (например, данные граждан ЕС не покидают ЕС) — DR-стратегия должна учитывать regulatory boundaries. Конкретная реализация — в фазе 3 при появлении enterprise-клиента.
3. Платный SLA по DR. Должна ли платформа предлагать enhanced DR (например, RTO 30 минут вместо 60 минут) как платную услугу для enterprise-клиентов? Trade-off: дополнительная выручка vs. операционная сложность tiered DR. Решение — в API as Product (api-as-product.md) при разработке Enterprise tier.
4. Архивная стратегия для платформенных данных. Для финансовых документов с retention 7+ лет — какой архивный storage используется (OVH Cold Storage, AWS Glacier, on-premise)? Решение — после консультации с compliance officer и финансовым аудитором.
5. Восстановление после программных ошибок. DR-план фокусируется на инфраструктурных сбоях. Для случаев программных ошибок (например, миграция, повредившая данные) — отдельная процедура «logical recovery» через point-in-time restore. Развёрнутый процесс — в фазе 2 после первого реального инцидента.

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

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

• Runbook'и инцидент-плейбуки (runbooks-incident-playbooks.md) — каноничные процедуры для инцидентов, в том числе DR;
• Модель SLA и дежурств (sla-and-on-call-model.md) — целевые SLA, влияющие на RTO/RPO; on-call structure для DR-инцидентов;
• Дорожная карта инфраструктурного масштабирования (scaling-and-packaging-roadmap.md) — фазы инфраструктуры, к которым привязаны DR-стратегии;
• Наблюдаемость и реагирование на инциденты (observability-and-incident-response.md) — мониторинг, метрики SLI, alerting;
• Релизы и совместимость (release-engineering-and-migrations.md) — связь релизной дисциплины с DR.

Связанные доменные документы

• Платёжный домен (payment-domain.md) — Tier 1 RTO/RPO для платёжного контура;
• Статусная машина бронирования (booking-state-machine.md) — критические транзакционные данные;
• Партнёрские взаиморасчёты (partner-finance-and-clearing.md) — финансовые данные с regulated retention;
• Сила тенантной изоляции (multi-tenant-isolation-strength.md) — DR-стратегии по уровням изоляции;
• Платформа данных и трекинг событий (data-platform-and-events-tracking.md) — Tier 3 RTO/RPO для аналитики;
• API as Product (api-as-product.md) — связь DR с tier-уровнем тенанта;
• API metering and usage governance (api-metering-and-usage-governance.md) — capacity input для прогнозов;
• Экономическая модель платформы (economic-model.md) — финансовые следствия DR-инвестиций.

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

• Первоначальная таксономия событий (initial-event-taxonomy.md) — события DR и capacity;
• Техническое задание для подрядчика (technical-specification-for-development-contractors.md) — § 3.16 операционная инфраструктура.

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

• Закон 00000 — платформа главенствует над поставщиками — DR задаётся платформой, не поставщиком;
• Современные лучшие практики верхнеуровневых платформ — Google SRE, AWS Well-Architected, Stripe DR practices как ориентиры;
• Эластичное масштабирование и упаковка по фазам — фазы DR совпадают с фазами инфраструктуры;
• Развитие без деградации — фазы DR — расширение, не миграция;
• Тезисное обоснование архитектурных решений — формат принятия решений по trade-off DR.