План відновлення інфраструктури: 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