Основные задачи
Надежная система восстановления после сбоя определяется двумя критическими метриками:
- RPO (Recovery Point Objective) — максимально допустимая потеря данных, измеренная в единицах времени
- RTO (Recovery Time Objective) — максимально допустимое время простоя перед восстановлением сервиса
Все архитектурные решения должны приниматься на основе этих целевых значений.
Архитектура развёртывания
- Используй active-active развёртывание в нескольких регионах, чтобы трафик обслуживался одновременно из нескольких регионов, исключая единую точку отказа
- Обеспечь независимость дата-центров, избегая общих доменов отказа — регионы не должны делить между собой сетевую инфраструктуру, энергоснабжение или инфраструктурные зависимости
Репликация данных
- Реализуй асинхронную кросс-региональную репликацию для постоянной синхронизации данных между регионами
- Установи чёткие допуски на задержку репликации в соответствии с твоими целевыми значениями RPO
Стратегия failover
- Автоматизируй failover с помощью глобальных балансировщиков нагрузки или DNS-маршрутизации (например,
Route 53 с проверками здоровья)
- Failover должен срабатывать автоматически без ручного вмешательства, минимизируя время восстановления
Бэкапы и восстановление
- Поддерживай регулярные процедуры резервного копирования с версионированными снапшотами, хранящимися в географически разнесённых локациях
- Документируй и тестируй процедуры восстановления, чтобы убедиться, что из бэкапов действительно можно всё поднять
Готовность к эксплуатации
- Веди подробные runbook'и, охватывающие все известные сценарии восстановления, чтобы любой инженер мог их выполнить в стрессовой ситуации
- Проводи регулярные учения по восстановлению после катастроф, чтобы убедиться, что процедуры failover, репликации и восстановления работают как ожидается
Ключевой принцип
Проектируй с расчётом на отказ — предполагай, что любой
регион, сервис или компонент в итоге выйдет из строя,
и автоматизируй восстановление до того, как это произойдёт.
Проактивное тестирование и автоматизация — вот что отличает теоретический DR-план от плана, который действительно работает в production.