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, ↑latentnost, ризик поширення псування).
Асинхронна (низький вплив на перф, 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. Тоді аварія перетвориться не в катастрофу, а в керований інцидент з передбачуваним результатом.