Disaster Recovery Plan: как подготовить и проверить план восстановления

Рабочий Disaster Recovery Plan — это не общий документ «в случае аварии», а проверяемая последовательность действий для восстановления конкретных сервисов в заданные RPO и RTO. В нём есть критерии запуска, зависимости, роли, технические шаги, коммуникации и доказательства успешного восстановления.

Резервные копии — только один ресурс плана. Если неизвестно, кто объявляет аварию, в какой последовательности поднимать системы и как проверить целостность данных, наличие backup не гарантирует возвращение бизнеса к работе.

Что входит в DR-план

DR-план отвечает на шесть практических вопросов:

1. Какие процессы и системы восстанавливать первыми?
2. Сколько данных допустимо потерять?
3. Сколько времени может не работать сервис?
4. Где находятся копии, конфигурации, секреты и резервные ресурсы?
5. Кто принимает решения и выполняет шаги?
6. Как доказать, что сервис не просто запущен, а пригоден для работы?

NIST SP 800-34 Rev. 1 предлагает структурный подход к contingency planning: анализ влияния, стратегии восстановления, разработка плана, тестирование, обучение и поддержание документа в актуальном состоянии. Это ориентир, который нужно адаптировать к архитектуре и применимым российским требованиям.

Начните с BIA, а не с перечня серверов

Business Impact Analysis связывает простой с последствиями. Опишите бизнес-процесс, владельца, пиковые периоды, зависимые системы, ручной обходной путь и влияние остановки во времени.

Приоритет	Пример процесса	Вопрос для плана
Критический	Авторизация, платёж	Как восстановить без нарушения целостности?
Высокий	Заказы, клиентские уведомления	Как обработать накопившуюся очередь?
Средний	Внутренняя отчётность	Допустим ли временный ручной процесс?
Низкий	Архивные сервисы	Можно ли отложить восстановление?

Не назначайте одинаковый приоритет всем системам. Это делает порядок действий бесполезным и завышает стоимость резервной площадки.

RPO и RTO должны быть согласованы

RPO задаёт допустимую потерю данных во времени. RTO задаёт допустимое время до восстановления функции. Их определяет владелец процесса вместе с IT, а не только администратор.

Проверьте непротиворечивость:

• частота копирования и репликации позволяет выполнить RPO;
• полное время обнаружения, решения, запуска и проверки укладывается в RTO;
• зависимые системы имеют не менее строгие цели;
• доступна нужная пропускная способность для восстановления;
• лицензии, DNS, сертификаты и секреты присутствуют на резервном контуре.

Основы RPO/RTO и различие между backup и высокой доступностью разобраны в статье о резервном копировании и отказоустойчивости.

Карта зависимостей определяет порядок

Сервис редко восстанавливается в одиночку. Приложение может зависеть от DNS, каталога пользователей, базы, очереди, хранилища, API партнёра и канала уведомлений. Зафиксируйте:

• техническую зависимость и владельца;
• допустимый режим деградации;
• способ проверки доступности;
• альтернативный маршрут;
• максимальное время ожидания.

Последовательность должна быть выражена как волны: базовая сеть и управление доступом, данные, общие платформы, критичные приложения, интеграции, некритичные сервисы. Если применяется IaaS, отдельно опишите границу ответственности провайдера и заказчика; сравнение моделей есть в материале IaaS или собственный дата-центр.

Структура исполнимого runbook

Для каждого сервиса создайте короткую инструкцию, которую способен выполнить дежурный специалист:

Условия запуска

• наблюдаемый симптом и источник подтверждения;
• критерий объявления аварии;
• лицо, которое разрешает переключение;
• риски продолжения работы в основном контуре.

Пошаговое восстановление

• точные команды или ссылки на автоматизацию;
• ожидаемый результат каждого шага;
• безопасная точка остановки;
• откат при ошибке;
• способ получить секреты без вставки их в документ.

Проверка

• технические health checks;
• контроль целостности и свежести данных;
• сквозная бизнес-операция;
• подтверждение владельца процесса;
• решение о возвращении трафика.

Возврат в основной контур

Failback часто сложнее failover. Нужно синхронизировать изменения, выбрать окно, исключить двойную запись и повторно проверить сервис.

Роли и коммуникации

Минимальный состав: incident commander, технические владельцы, координатор коммуникаций и представитель бизнеса. Один человек не должен одновременно выполнять все технические действия и согласовывать приоритеты.

Подготовьте шаблоны сообщений для сотрудников, клиентов и партнёров. В каждом обновлении указывайте подтверждённый эффект, текущую меру, время следующего сообщения и канал поддержки. Не обещайте срок восстановления до подтверждения командой.

Контакты и сам план должны быть доступны при недоступности основной корпоративной системы. При этом документ с сетевой схемой и процедурами доступа нуждается в контроле прав и версий.

Как тестировать DR-план

Используйте последовательное увеличение риска:

1. Tabletop: участники разбирают сценарий за столом.
2. Walkthrough: владельцы проходят runbook и проверяют доступы.
3. Component recovery: восстанавливается отдельная база или сервис.
4. Partial failover: часть реальной цепочки переключается на резерв.
5. Full exercise: выполняется согласованное восстановление критичного контура.

На учениях измеряйте фактические RPO/RTO, число ручных шагов, ошибки доступа, время принятия решения и полноту проверки. Успешный запуск виртуальной машины ещё не означает успешное восстановление процесса.

Свяжите учения с наблюдаемостью инфраструктуры: алерты должны обнаружить сценарий, а метрики и traces — подтвердить восстановление.

Типичные разрывы плана

• Резервная копия есть, но тест восстановления не проводился.
• Документ содержит имена людей вместо ролей и дежурных контактов.
• Секрет или MFA доступны только через отказавшую систему.
• План не учитывает накопившиеся сообщения и повторную обработку.
• Нет владельца решения о failover и failback.
• Зависимости имеют более слабые RTO, чем основной сервис.
• После изменения архитектуры runbook не обновлён.
• Восстановление проверяется только ping или HTTP 200.

Контрольный лист документа

• Область действия и версия.
• Владелец плана и дата следующего пересмотра.
• Критерии активации и завершения.
• BIA, приоритеты, RPO и RTO.
• Схема зависимостей и волны восстановления.
• Роли, контакты и правила эскалации.
• Runbook по каждому критичному сервису.
• Каналы внутренней и внешней коммуникации.
• Проверки целостности и бизнес-приёмки.
• История учений, замечания и корректирующие действия.

Пересматривайте план после серьёзной миграции, изменения схемы данных, провайдера, аутентификации или состава интеграций. При переносе нагрузки используйте общий план миграции в IaaS как источник актуальной карты и критериев приёмки.

CTA: «Лоджик Телеком» может помочь провести инвентаризацию зависимостей и подготовить программу DR-учений. Практичный первый шаг — восстановить один критичный сервис в изолированной среде и сравнить фактические показатели с заявленными RPO/RTO.