Как составить план аварийного восстановления ИТ-системы

План аварийного восстановления ИТ-системы — это согласованный порядок действий при конкретном отказе. Его также называют DRP (Disaster Recovery Plan). Чтобы составить план, выберите критичную функцию и сценарий, задайте цели времени восстановления (RTO) и допустимого отката данных (RPO), назначьте ответственных, укажите ресурсы и инструкции восстановления. Отдельно опишите, как проверить данные и операцию, завершить временный режим и вернуться к штатной работе.

Начать можно с одного сценария и компактной карточки со ссылками на технические инструкции. План должен быть доступен при отказе основной среды. На выходе нужны проверяемые действия и критерии результата, список непроверенных условий и владелец актуализации. Сам документ не подтверждает готовность к аварии: эту готовность проверяют учениями.

Выберите сценарий

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

DRP одной системы не заменяет план непрерывности всей организации. Он также не заменяет расследование инцидента. При подозрении на компрометацию пригодность копии и безопасный порядок восстановления согласуют с ответственными за информационную безопасность.

Подготовьте основания

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

Определите момент решения

Сообщение поставщика «разбираемся» не определяет, сколько ещё может ждать ваша работа. В плане заранее фиксируют проверки и уведомления об отказе, признаки запуска резерва и момент пересмотра ожидания. Отдельно назначают ответственного за решение. При RTO в два часа нельзя потратить всё это время на ожидание: развёртывание, проверка данных и операции тоже должны укладываться в согласованные границы.

Запишите действия и условия

1. Ограничьте охват одним сценарием и определите, кто принимает решение о запуске плана.
2. Разложите восстановление по зависимостям. Вместо общего «поднять резерв» дайте ссылки на инструкции, входные условия и признаки успеха.
3. Согласуйте проверки и временную работу с владельцем процесса. Назначьте порядок связи, если основной канал недоступен.
4. Проверьте доступ к самому плану, назначьте учение и ответственного за исправление найденных пробелов.

Проверьте исполнимость

Сначала проведите разбор сценария с ответственными: понятно ли, кто решает, где взять доступы и когда остановиться. Затем выполните согласованную техническую проверку. Разбор за столом, восстановление копии и учение отказа площадки проверяют разные вещи; не отмечайте весь план проверенным по одному успешному действию.

Если отсутствует пригодная копия, недоступен ключ или проверка данных обнаружила расхождение, исполнитель записывает, что мешает продолжить, и обращается к ответственному за восстановление. Условия остановки защищают от перехода к следующему действию при неподтверждённом результате.

Учебный пример. Основная среда приёма заказов недоступна. Ниже — фрагмент заполненного плана, а не готовая инструкция для любой системы.

Числа в примере условные. Рабочие цели RTO/RPO переносят из карточки требований. Если неизвестно, доступен ли ключ расшифрования или сколько займёт сверка, это открытый пробел с владельцем и сроком проверки. Его нельзя заменить формулировкой «по необходимости».

Ошибки и ограничения

• План и контакты хранятся только внутри отказавшей системы.
• Технические команды есть, но отсутствуют условия их применения, остановки и подтверждения результата.
• Резерв зависит от той же службы входа, сети или ключей, что и основная среда.
• Возвращение интерфейса считают завершением восстановления без сверки данных.
• После смены версии, интеграций или состава команды документ не проверяют заново.

Кто подтверждает восстановление

Предположим, резерв запущен и страница заказов открывается, но новый заказ не сохраняется. Техническое действие выполнено, а восстановление работы ещё не подтверждено. Команда сохраняет сведения об ошибке и журналы событий, затем передаёт руководителю восстановления варианты дальнейших действий. Владелец процесса принимает работу после проверки данных и операции в согласованных границах.

На схеме два подтверждения сходятся в одном решении. Они могут проверяться последовательно или параллельно; одного успешного результата недостаточно. При отклонении отдельно согласуют исправление или допустимую временную работу.

Что должно остаться после учения

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

Начните техническую проверку с восстановления выбранной резервной копии. Сам план включите в комплект эксплуатационной документации. Если цели ещё не согласованы, сначала определите RTO и RPO.

Методические ориентиры — NIST SP 800-34 Rev. 1 ↗ и публичная область применения ISO/IEC 27031:2025 ↗. NIST адресован федеральным ИС США; здесь он используется как руководство по планированию, а не как обязательная норма для российского проекта. Конкретные обязательства определяют применимые требования и договоры.