DR-стратегии и RTO/RPO
1) Базовые принципы
1. Цели раньше средств. Сначала формулируем RTO/RPO и критичные сценарии, потом выбираем технологию.
2. Сегментация по важности. Не все сервисы требуют «золота»; делите по бизнес-критичности.
3. Данные — ядро DR. Консистентность, репликация, обнаружение порчи и точка восстановления важнее «железа».
4. Автоматизация и проверяемость. DR бессмыслен без IaC, регресс-тестов восстановления и телеметрии.
5. Учения и доказательства. План без регулярных «game day» — иллюзия готовности.
6. Безопасность и комплаенс. Шифрование, изоляция, WORM/immutable-бэкапы, DPA/юрисдикции.
2) Термины и соответствия
RTO — время от момента события до восстановления сервиса «в норме».
RPO — «возраст» последней здоровой точки данных при восстановлении.
RLO (Recovery Level Objective) — уровень функционала, который обязаны восстановить (минимально жизнеспособный сервис).
MTD (Maximum Tolerable Downtime) — порог, после которого бизнес несет неприемлемый ущерб.
RTA/RPA (Actual) — фактические время/точка восстановления из практик.
Связь: RTO ≤ MTD; RPA ≤ RPO. Разрыв между целями и фактом — предмет постмортема и улучшений.
3) Классы DR-стратегий (уровни готовности)
4) Сценарии, против которых защищаемся
Потеря региона/облака/ЦОД (электрика, сеть, провайдер).
Коррупция данных/ошибка оператора (удаление, «битые» реплики, логическая порча).
Вредоносное ПО/шифровальщик (ransomware).
Дефект релиза/конфигурации (массовый outage).
Крах зависимости (KMS, DNS, секреты, платежный провайдер).
Юридические события (блокировки, запрет вывоза данных из юрисдикции).
Для каждого сценария укажите RTO/RPO, уровень DR, плейбук, ответственных.
5) Стратегии данных (ключ к RPO)
5.1 Бэкапы
Полные + инкрементальные + журналы транзакций (для БД).
Иммутабельные/WORM-хранилища и оффлайн-копии («air-gapped»).
Каталог бэкапов с метаданными и криптоподписями; тестовые восстановление по расписанию.
5.2 Репликация
Синхронная (низкий RPO, ↑латентность, риск распространения порчи).
Асинхронная (низкое влияние на перф, RPO>0; сочетать с детектом порчи).
CDC (Change Data Capture) для потоковой репликации и реконструкции состояния.
5.3 Защита от логической порчи
Версионирование/«точки во времени» (PITR) с окном ≥ N дней.
Сигнатуры инвариантов (балансы, суммы, чексуммы) — ранний детект «битых» данных.
«Медленные» каналы репликации (delay 15–60 мин) как буфер против мгновенной порчи.
python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)6) Приложение, состояние, кэш
Стэйтлесс-слой — масштабируем и перезапускаем в любом регионе (образ/чарт/манифесты в Git).
Состояние (БД/кэши/кью): источник истины — одна из БД; кэши и индексы перегенерируемы.
Идемпотентность и re-drive — повторная доставка событий допустима; используйте outbox/inbox, дедуп и версии.
7) Сеть и входная точка
GSLB/DNS-фейловер: latency/health-based, короткие TTL в окно аварии.
Anycast/L7-прокси: единый IP, маршрутизация по здоровью регионов.
Региональные домены и политики юрисдикций (geo-pinning для PII).
Фейловер сертификатов/KMS: запасные цепочки, dual-key.
python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()8) Операционная модель и автоматизация
IaC/GitOps: инфраструктура второго региона = код, «однокнопочное» развертывание.
Policy as Code: гейт «нет DR-манифестов/бэкапов/алертов — нет релиза».
Runbooks: пошаговые инструкции и «красная кнопка», идентичные на оба региона.
Секреты: короткоживущие креды, федерация OIDC, план компрометации/отзыва.
rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}9) Учения и тесты (Game Days)
Таблица сценариев: потеря БД, «битые» данные, отказ KMS, падение региона, внезапный egress-лимит.
Частота: квартально для миссия-критичных; раз в полгода — для остальных.
Метрики учения: RTA/RPA vs цели, доля автоматических шагов, количество ручных вмешательств, ошибки плейбука.
Chaos-smoke в релизах: деградация зависимостей не должна «ломать» DR-пути.
T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements10) Плейбуки (канонический шаблон)
yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"11) Метрики наблюдаемости DR
Replica lag (сек.), RPO-drift (разница между целевым и фактическим RPO).
Restore SLI: время холодного/теплого восстановления по окружениям.
Coverage: % сервисов с плейбуками/бэкапами/PITR ≥ N дней.
Drill score: доля автоматических шагов, RTA распределение, частота ошибок.
Иммутабельность: % бэкапов в WORM/air-gapped.
Событийные метрики: длина очередей/скорость re-drive после фейловера.
12) Стоимость и компромиссы
CapEx/OpEx: теплый стенд дешевле Active/Active, но дороже Pilot Light.
Egress: межрегиональная/межоблачная репликация стоит денег; кэш/компрессия/локальные агрегаты.
RTO/RPO vs $: каждая «девятка» доступности и секунда RPO стоят кратно дороже — согласуйте с бизнесом.
Зеленые окна: batch-репликации — в дешевые/«зеленые» часы.
13) Безопасность и комплаенс
Шифрование «в покое» и «в транзите», раздельные KMS-домены по регионам.
Immutable-бэкапы, защита от ransomware: «3-2-1» (3 копии, 2 носителя, 1 оффлайн), MFA-delete.
Юрисдикции: geo-pinning для PII, локализация бэкапов, Legal Hold поверх TTL.
Доступы по времени: временные роли для DR-операций, журнал аудита.
14) Анти-паттерны
«Напишем план позже» — DR без учений.
Репликация без защиты от логической порчи — мигновенно размножит ошибку.
Один регион KMS/секретов — невозможен фейловер.
Бэкапы без регулярных восстановлений — «шредингеровский» DR.
Тесно связанные синхронные транзакции между регионами — каскадная латентность/падение.
Нет приоритизации: одинаковый DR-уровень для всего (дорого и бесполезно).
15) Чек-лист архитектора
1. Определены RTO/RPO/RLO по сервисам и сценариям?
2. Классифицированы данные: источник истины, PITR/окно, WORM/immutable?
3. Выбран уровень DR (Backup/Restore, Pilot, Warm, A/P, A/A) per-сервис?
4. Сеть: GSLB/Anycast, сертификаты/ключи с запасом, флаги «read-only»?
5. Приложение: идемпотентность, outbox/inbox, компенсирующие транзакции?
6. IaC/GitOps/Policy as Code: один клик на раскатку второго региона?
7. Учения: расписание, KPI RTA/RPA, пост-учебные действия?
8. Мониторинг: lag, RPO-drift, restore-SLI, drill-score, иммутабельные бэкапы?
9. Безопасность/комплаенс: KMS-домены, юрисдикции, Legal Hold?
10. Стоимость: бюджет egress, «зеленые» окна, экономически обоснованный уровень?
16) Мини-рецепты и скетчи
16.1 PITR для Postgres (идея):
bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...16.2 Защита от логической порчи (задержанная реплика):
yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption16.3 Переключение трафика (псевдо-API GSLB):
bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 10016.4 Проверка инвариантов после фейловера (псевдокод):
python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))Заключение
DR — это способность принимать технические и организационные решения быстрее, чем растет ущерб. Определите реалистичные RTO/RPO, выберите достаточный уровень готовности, автоматизируйте инфраструктуру и проверки, регулярно тренируйтесь и измеряйте фактические RTA/RPA. Тогда авария превратится не в катастрофу, а в управляемый инцидент с предсказуемым исходом.