Аварийное восстановление для облачной инфраструктуры:
пошаговое руководство
Планирование аварийного восстановления терпит неудачу двумя предсказуемыми способами: команды либо пропускают его полностью («разберёмся, если случится»), либо чрезмерно усложняют его, выходя за пределы их операционной способности поддерживать. План DR, который нельзя выполнить под давлением, — не план DR. Это документ. Данное руководство охватывает три уровня DR, как выбрать правильный для каждой системы и как выглядит работающая программа DR на практике.
RTO и RPO: два числа, которые определяют все решения
Целевое время восстановления (RTO) — максимально допустимое время простоя: сколько времени ваш бизнес может выдержать при отключении данной системы. Целевая точка восстановления (RPO) — максимально допустимая потеря данных: насколько старой может быть самая свежая резервная копия при восстановлении. Это бизнес-решения, а не технические. RTO 4 часа для внутреннего отчётного дашборда разумно. RTO 4 часа для системы обработки платежей — вероятно, нет.
Для количественного определения требований RTO оцените стоимость одного часа простоя каждой системы: потерянная выручка, нагрузка на поддержку, штрафы SLA, которые вы должны своим клиентам, и репутационные издержки. Сравните эту цифру с ежемесячной разницей стоимости между уровнями DR.
Три уровня DR
Уровень 1: резервное копирование и восстановление
-
Как работает — Регулярные резервные копии, хранящиеся в отдельном месте. При катастрофе — восстановление из последней резервной копии в новую среду.
-
RTO — Часы (зависит от размера резервной копии). Не подходит для систем, где часы простоя неприемлемы.
-
RPO — Равно частоте резервного копирования. Ежедневные копии = до 24 часов потери данных. Почасовые = до 1 часа.
-
Подходит для — Сред разработки, staging, внутренних инструментов, приложений с низким трафиком.
Уровень 2: тёплый резерв
-
Как работает — Вторичная среда работает с пониженной мощностью в отдельной зоне или регионе, с репликацией БД, поддерживающей её почти актуальной. Переключение — повышение резерва и перенаправление трафика.
-
RTO — 15–60 минут. Наиболее распространённый производственный уровень.
-
RPO — Минуты (зависит от отставания репликации). При синхронной репликации RPO может приближаться к нулю.
-
Подходит для — Производственных веб-приложений, БД для клиентских систем, API, генерирующих выручку.
Уровень 3: горячий резерв / active-active
-
Как работает — Полная реплика работает живой, обслуживая реальный трафик. Отказ одного сайта не вызывает видимого пользователям простоя.
-
RTO — Секунды. Ноль для пользователей, уже подключённых к выжившему сайту.
-
RPO — Практически ноль при синхронной репликации.
-
Подходит для — Систем уровня 1: обработка платежей, банковские ядровые системы, любое приложение, где секунды простоя вызывают прямые финансовые потери.
Построение и тестирование плана DR
План DR имеет семь компонентов: (1) определить охват, (2) картировать зависимости, (3) назначить RTO и RPO для каждой системы, (4) выбрать уровень DR, (5) написать runbook — пошагово, с оценками времени, (6) тестировать ежегодно как минимум, (7) проводить постмортем после каждой реальной активации.
Тестирование — часть, которую большинство команд пропускают, и она важнее всего. Настольное упражнение — когда команда проходит через runbook и выявляет пробелы — занимает полдня и дёшево находит проблемы. Живое учение DR — реальное переключение на резерв — занимает целый день и подтверждает, что план реально работает. Проводите настольные упражнения ежеквартально и живые учения ежегодно.