Сценарии аварийного восстановления

1) Зачем нужен DR и какая цель

Disaster Recovery (DR) — это набор архитектур, процессов и тренировок для восстановления сервисов после катастроф (отказ датацентра/региона, утраты данных, массовых конфигурационных ошибок). Цель DR — выполнить целевые RTO/RPO при контролируемой стоимости и риске, сохранив доверие клиентов и соответствие регуляторике.

RTO (Recovery Time Objective): допустимое время простоя.
RPO (Recovery Point Objective): допустимая потеря данных (время с последней консистентной точки).
RLO (Recovery Level Objective): уровень функционала, который должен вернуться первым (минимально жизнеспособный сервис).

2) Классификация систем по критичности

Tier 0 (жизненно важное): платежи, логин, KYC, ядро транзакций — RTO ≤ 15 мин, RPO ≤ 1–5 мин.
Tier 1 (высокая): операционные панели, отчеты D-1 — RTO ≤ 1 ч, RPO ≤ 15–60 мин.
Tier 2 (средняя): бэк-офис, аналитика near-real-time — RTO ≤ 4–8 ч, RPO ≤ 4–8 ч.
Tier 3 (низкая): не критичные вспомогательные — RTO ≤ 24–72 ч, RPO ≤ 24 ч.

Каждому сервису присвоить Tier + целевые RTO/RPO в каталоге сервисов; решения и бюджеты сверять именно с ними.

3) Модель угроз и сценарии

Техногенные: отказ AZ/региона/провайдера, деградация сети/DNS, сбой БД/хранилищ, массовый баг релиза.
Человеческий фактор: ошибочные конфиги/IaC, удаление данных, компрометация ключей.
Природные/внешние: пожар/наводнение, перебои энергии, правовые блокировки.
Для каждого — оценить вероятность/импакт, привязать к DR-сценарию и плейбуку.

4) Паттерны архитектуры DR

1. Active-Active (Multi-Region): оба региона обслуживают трафик.

Плюсы: минимальные RTO/RPO, высокая устойчивость.
Минусы: сложность данных/консистентности, высокая цена.
Где: чтение-тяжелые, кэшируемые нагрузки, stateless-сервисы, multi-master DB (строгие правила конфликтов).

2. Active-Passive (Hot Standby): “горячий” пассив держит полностью разогретую копию.

RTO: минуты; RPO: минуты. Требует автоматизированного failover и репликации.

3. Warm Standby: часть ресурсов прогрета, масштабирование при аварии.

RTO: десятки минут; RPO: 15–60 мин. Экономичнее, но дольше.

4. Pilot Light: минимальная «искра» (метаданные/образы/скрипты) + быстрый разворот.

RTO: часы; RPO: часы. Дешево, подходит для Tier 2–3.

5. Backup & Restore: оффлайновые бэкапы + ручной прогрев.

RTO/RPO: часы–сутки. Только для низкой критичности и архивов.

5) Данные и согласованность

• Синхронная — почти нулевой RPO, но ↑латентность/стоимость.
• Асинхронная — лучше производительность, RPO > 0 (хвост журналов).
• Согласованность: выбирайте модель (strong/eventual/causal). Для платежей — строго, для аналитики — eventual.
• Срезы (snapshots): регулярно создавайте консистентные точки + храните журналы (WAL/redo).
• Кросс-регионные транзакции: избегайте 2PC; используйте идемпотентные операции, дели-и-повторяй (retry с дедупликацией), event sourcing.
• Очереди/шины: репликация/зеркалирование, DLQ, заказ и идемпотентность консьюмеров.

6) Сеть, трафик и DNS

GSLB/Anycast/DNS: политики failover/failback, низкие TTL (но не слишком), health-checks из нескольких регионов.
L7-маршрутизация: региональные карты, фича-флаги деградации (ограничение функций).
Private-links/VPN: резервные каналы к провайдерам (PSP/KYC/CDN).
Rate limiting: защита от шторма при восстановлении.

7) Stateful vs Stateless

Stateless переносится скриптом/автоскейлом; stateful требует согласованной стратегии данных (репликация, снапшоты, промоушен реплики, кворум).
Кэш/сессии: внешние (Redis/Memcached) с кросс-регионной репликацией или re-seed по журналам; сессии держать в токенах (JWT) или общем хранилище.

8) Триггеры и автоматизация DR

SLO-гардрейлы и кворум зондов → автоматический region-failover runbook.
Change freeze при аварии: блокируем нерелевантные релизы/миграции.
Infrastructure as Code: развертывание стенд-бай по манифестам, проверка дрейфа.
Промоушен роли: автоматический promote реплики БД + перевязка writers/секретов.

9) Коммуникации и комплаенс

War-room: IC/TL/Comms/Scribe; интервалы апдейтов по SEV.
Статус-страница: география влияния, ETA, обходные пути.
Регуляторика: сроки уведомлений, безопасность данных, неизменяемое хранение evidence.
Партнеры/провайдеры: подтвержденные контакты, выделенный канал.

10) Тесты и учения DR

Tabletop: обсуждаем сценарий и решения.
Game Day (стейдж/прод-лайт): имитация отказа AZ/регионов, отключение провайдера, сброс DNS.
Restore-тесты: периодически восстанавливаем бэкапы в изоляции и валидируем целостность.
Chaos/Failure injection: контролируемые сбои сети/узлов/зависимостей.
KPI учений: достигнутые RTO/RPO, дефекты плейбуков, CAPA.

11) Финансы и выбор стратегии (FinOps)

Считайте $ за сниженный RPO/RTO: чем ниже цели — тем дороже каналы, лицензии, резервы.
Гибрид: Tier 0 — active-active/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
Данные дорогие: используйте холодные слои (архив/S3/GLACIER), инкрементальные снапшоты, дедупликацию.
Периодический ревью затрат и сертификатов/лицензий DR-инфры.

12) Метрики зрелости DR

RTO (факт) и RPO (факт) по каждому Tier.
DR Coverage: % сервисов с оформленным сценарием/плейбуком/тестом.
Backup Success & Restore Success: ежедневный успех бэкапов и проверенных восстановлений.
Time-to-Declare Disaster: скорость принятия решения о failover.
Failback Time: возврат к нормальной топологии.
Defect Rate Учений: найденные пробелы/учение.
Compliance Evidence Completeness: полнота артефактов.

13) Чек-листы

Перед внедрением DR

• Сервис-каталог содержит Tier, RTO/RPO, зависимости и владельцев.
• Выбран паттерн (AA/AP/WS/PL/BR) по Tier и бюджету.
• Соглашения о консистентности и репликации задокументированы.
• GSLB/DNS/маршрутизация и health-checks настроены и протестированы.
• Бэкапы, снапшоты, журналы изменений — включены, проверены на restore.
• Плейбуки DR и контакты провайдеров в актуальном виде.

Во время аварии (кратко)

• Объявить SEV и собрать war-room; заморозить релизы.
• Проверить кворум зондов; зафиксировать импакт/географию.
• Выполнить Failover Runbook: трафик, БД-промоушен, очереди, кэш.
• Включить degrade-UX/лимиты; публиковать апдейты по SLA.
• Собирать evidence (таймлайн, графики, логи, команды).

После аварии

• Наблюдать SLO N интервалов; выполнить failback по плану.
• Провести AAR/RCA; оформить CAPA.
• Обновить плейбуки, катализаторы алертов, тест-кейсы DR.
• Отчитаться перед стейкхолдерами/регуляторами (если нужно).

14) Шаблоны

14.1 Карточка DR-сценария (пример)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14.2 Runbook “Promote реплики БД” (фрагмент)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14.3 План учений DR (кратко)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Анти-паттерны

“Есть бэкапы” без регулярных restore-тестов.
Секреты/эндпоинты не переключаются автоматически.
Отсутствие идемпотентности → дубликаты/потерянные транзакции при повторной доставке.
Одинаковые конфиги для регионов без фича-флагов деградации.
Долгий Time-to-Declare из-за страха “ложной тревоги”.
Монорегиональные провайдеры (PSP/KYC) без альтернативы.
Нет плана failback — живем в аварийной топологии “вечно”.

16) Дорожная карта внедрения (6–10 недель)

1. Нед. 1–2: классификация сервисов по Tier, установка целевых RTO/RPO, выбор паттернов DR.
2. Нед. 3–4: настройка репликаций/бэкапов, GSLB/DNS, промоушен-процедур; плейбуки и runbook’и.
3. Нед. 5–6: первые DR-учения (tabletop→stage), фиксация метрик и CAPA.
4. Нед. 7–8: прод-лайт учения с ограниченным трафиком; автоматизация failover.
5. Нед. 9–10: оптимизация затрат (FinOps), перенос Tier 0 в hot/AA, регламент квартальных учений и отчетности.

17) Итог

Эффективный DR — это не только бэкапы. Это согласованная архитектура, автоматизация failover/failback, дисциплина данных (идемпотентность/репликация), тренировки и прозрачные коммуникации. Когда RTO/RPO реальны, плейбуки отработаны, а учения регулярны, катастрофа превращается в управляемое событие, после которого сервисы быстро и предсказуемо возвращаются к норме.