План восстановления инфраструктуры: RPO, RTO и автоматизация

План восстановления инфраструктуры: RPO, RTO и автоматизация

Представьте: ночью падает primary-датацентр, клиенты не могут оформить заказ. Без проверенного DR-плана каждый такой инцидент — лотерея. Мы сталкивались с ситуациями, когда «DR-план» оказывался устаревшим на год, а runbook-и не работали. Поэтому строим процедуры, которые реально выполняются, с автоматизированными шагами и регулярными учениями. Инженеры с 10+ лет опыта в DevOps и SRE гарантируют, что ваш DR-план сработает в критический момент. Экономия времени при автоматизации DR может достигать 80% по сравнению с ручным восстановлением.

Почему RPO и RTO нужно согласовывать с бизнесом?

Прежде чем проектировать DR, нужно зафиксировать две метрики с бизнесом, а не угадывать их самостоятельно. RPO (Recovery Point Objective) — максимально допустимая потеря данных в единицах времени. Если RPO = 1 час, то при катастрофе можно потерять не более часа транзакций. Это диктует частоту бэкапов и необходимость синхронной репликации. RTO (Recovery Time Objective) — максимально допустимое время простоя. RTO = 4 часа означает, что через 4 часа после инцидента сервисы должны быть восстановлены. Это диктует модель DR-сайта (hot/warm/cold) и степень автоматизации failover.

Типичная ошибка: инженеры сами назначают RPO = 0 и RTO = 15 минут, не осознавая, что это требует синхронной репликации в real-time и горячего standby — то есть удвоения стоимости инфраструктуры. Бизнес может быть готов жить с RPO = 24 часа и RTO = 8 часов при существенно меньших затратах. Согласование этих цифр — первый шаг к реалистичному плану.

Как выбрать модель DR-сайта?

Выбор архитектуры зависит от RPO/RTO и бюджета. Для минимального RTO (< 1 минуты) нужен активный горячий standby с синхронной репликацией. Для RTO до 4 часов достаточно warm standby с асинхронной репликацией. Если бизнес готов ждать сутки — подойдёт cold standby с восстановлением из бэкапов. Сравним варианты в таблице:

Инвентаризация критических систем

DR-план начинается с классификации систем по уровням критичности:

Для каждой Tier 1 системы фиксируются: зависимости (что падает вместе с ней), владелец, процедура восстановления, контакты ответственных.

Архитектурные решения под RPO/RTO

PostgreSQL с репликацией и Patroni. Для RPO < 5 минут и RTO < 10 минут — streaming replication с автоматическим failover через Patroni:

# patroni.yml — конфиг для DR-кластера
scope: pg-production
namespace: /service/
restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.10:8008
etcd3:
  hosts:
    - 10.0.0.1:2379
    - 10.0.0.2:2379
    - 10.0.0.3:2379
bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576 # 1 MB — лаг репликации
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        hot_standby: "on"
        max_wal_senders: 10
        max_replication_slots: 10
        synchronous_commit: "on"
        synchronous_standby_names: "ANY 1 (replica-dr)"
postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.10:5432
  data_dir: /var/lib/postgresql/data
  pg_hba:
    - host replication replicator 10.0.0.0/24 md5
    - host all all 0.0.0.0/0 md5

Terraform для инфраструктуры как кода. DR-инфраструктура должна описываться в Terraform и храниться в Git. Terraform в 10 раз эффективнее ручного развёртывания при повторных запусках — это единственный способ гарантировать, что через год DR-сайт можно поднять за предсказуемое время:

# dr-site/main.tf
module "dr_vpc" {
  source = "../modules/vpc"
  cidr_block = "10.10.0.0/16"
  availability_zones = ["eu-central-1a", "eu-central-1b"]
  tags = {
    Environment = "dr"
    Tier = "1"
  }
}

module "dr_rds" {
  source = "../modules/rds"
  identifier = "prod-dr-replica"
  source_db_identifier = "prod-primary"
  # Read replica в DR-регионе — основа для failover
  replicate_source_db = "arn:aws:rds:us-east-1:123456789:db:prod-primary"
}

Nginx и балансировщики. DNS-failover через Route53 или Cloudflare: при недоступности primary endpoint трафик переключается на DR. Для RTO < 15 минут нужен active health check с TTL не более 60 секунд.

Структура DR-плана: что должно быть в документе

Хороший DR-план — это не описание архитектуры. Это пошаговые инструкции для человека, который звонит в 3 ночи после алерта. Структура:

1. Триггеры активации DR — конкретные условия, при которых начинается DR-процедура. Не «при значительных проблемах», а «основной сайт недоступен более 15 минут по результатам мониторинга Prometheus alertmanager alert DatabaseDown severity:critical».

2. Матрица ответственных — кто принимает решение об активации DR, кто выполняет, кто уведомляет бизнес.

3. Пошаговые runbook-и — для каждого Tier 1 сервиса отдельный runbook с командами, ожидаемыми результатами и точками проверки.

4. Процедура возврата — failback на primary после восстановления. Это часто забывают, а потом DR-сайт становится новым «primary» без документации.

5. Коммуникационный план — шаблоны уведомлений для клиентов, SLA-обязательства, контакты поставщиков (облако, хостинг, CDN).

Почему регулярные учения критически важны?

Без регулярных учений DR-план быстро устаревает. Даже идеально написанный документ не гарантирует, что команда сможет его выполнить под стрессом. Рекомендуется проводить учения не реже раза в квартал для Tier 1, ежемесячно — для самых критичных сервисов. Учения выявляют неактуальные runbook, изменения в инфраструктуре и пробелы в знаниях. После каждого учения план корректируется.

Что входит в работу

При разработке DR-плана под ключ мы предоставляем:

• Аудит текущей инфраструктуры и классификация систем по Tier
• Согласование RPO/RTO с бизнесом и фиксация в документе
• Проектирование архитектуры DR-сайта (выбор hot/warm/cold)
• Настройка репликации, автоматизации failover и мониторинга
• Создание runbook-ов для всех критических сервисов
• Документирование процедур (триггеры, матрица ответственности, failback)
• Проведение первых учений и корректировка плана по результатам
• Обучение команды и передача доступов
• Поддержка в течение гарантийного периода после внедрения

Процесс разработки плана

Работа начинается с воркшопа с ключевыми стейкхолдерами: аудит критических систем, сбор RPO/RTO требований, инвентаризация зависимостей. Типичная длительность — 1–2 дня для небольшой инфраструктуры, неделя для сложной.

Следующий этап — gap-анализ: что из необходимого для DR уже есть, чего не хватает. Часто выясняется, что бэкапы есть, но нет процедуры их восстановления, или репликация настроена, но не тестировалась.

После — разработка и документирование процедур, настройка или доработка технических компонентов, первые учения.

Ориентиры по срокам

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Чтобы оценить проект, свяжитесь с нами — проанализируем вашу инфраструктуру и предложим оптимальное решение. Получите консультацию инженера с 10+ лет опыта в DevOps и SRE.

Официальная документация Patroni