RPO/RTO задают цели
Сколько изменений допустимо потерять и за какое время нужно вернуть сервис. Разница и пример расчёта →
ПРАКТИКА ВОССТАНОВЛЕНИЯ
DRP: как составить план аварийного восстановления
Кто принимает решение о восстановлении, что возвращать первым и как понять, что сервис снова работает? Ниже — структура плана для компании, пример зависимостей и заготовка для заполнения.
Редакция SecRadar · 6 октября 2026
Что такое Disaster Recovery Plan
DRP (Disaster Recovery Plan) — план возврата ИТ-сервисов к согласованной работе после серьёзного сбоя. В нём фиксируют условия запуска, ответственных, доступные ресурсы, порядок действий и критерии завершения. Наличие резервной копии ещё не описывает, как восстановить приложение вместе с его зависимостями.
В обзоре AWS аварийное восстановление рассматривается как организационный и технический процесс. Ниже — редакционная заготовка SecRadar для его планирования; это не обязательная форма документа и не инструкция к конкретному продукту.
DRP описывает действия
Кто запускает восстановление, откуда берёт данные, в каком порядке возвращает компоненты и кто принимает результат.
План непрерывности бизнеса шире ИТ-восстановления: он также описывает работу людей и процессов во время простоя. При атаке DRP согласуют с планом реагирования на инциденты; восстановление сервиса и расследование не подменяют друг друга.
Что включить в план аварийного восстановления
Начните с одного критичного сервиса. Следующая структура — рабочий список вопросов; названия ролей, сценарии и критерии необходимо адаптировать к вашей организации.
- Границы и сценарий. Название сервиса, пользователи, площадки, версии и объёмы. Отдельно рассмотрите потерю площадки, отказ компонента и повреждение данных.
- Условия запуска. Кто оценивает ситуацию, кто разрешает восстановление и кому передаётся решение при отсутствии основного ответственного.
- Связь и доступ. Контакты участников, резервный канал связи, доступная копия плана и порядок получения необходимых полномочий. Пароли и ключи в сам шаблон не записывайте.
- Цели и приоритет. Согласованные RPO/RTO, минимальная функциональность сервиса и приоритет относительно других систем.
- Зависимости и ресурсы. Идентификация, DNS, сеть, СУБД, ключи, копии, лицензии, вычислительные ресурсы и доступность специалистов.
- Порядок восстановления. Для каждого шага: исполнитель, предварительное условие, инструкция точной версии, ожидаемый результат и действие при ошибке.
- Приёмка. Контрольная операция пользователя, проверка данных и интеграций, фактические сроки и лицо, которое подтверждает готовность.
- Возврат к обычной эксплуатации. Что будет с временной площадкой, накопленными изменениями и резервным копированием. Опишите переход отдельно, чтобы избежать двух расходящихся рабочих копий.
Пример: восстановление сервиса обработки заказов
Учебный пример, не готовый план для любой организации. Пользователь должен открыть заказ, изменить его и получить подтверждение. Простого запуска виртуальной машины для такой приёмки недостаточно.
| Этап | Что проверить перед следующим шагом |
|---|---|
| Доступ и инфраструктура | Ответственные входят в среду, доступны сеть, имена и необходимые ресурсы. Способ входа не зависит от ещё не восстановленного приложения. |
| Данные | Выбрана доступная точка, восстановлена согласованная СУБД, проверены необходимые ключи и журналы. |
| Приложение и интеграции | Совместимы версии, заданы корректные адреса. Тестовые действия не уходят в реальные платежи и рассылки. |
| Приёмка | Контрольный заказ читается и изменяется, результат принят владельцем сервиса, отклонения записаны. |
Это пример зависимостей, а не обязательная последовательность для всех систем. Независимые работы могут выполняться параллельно; сроки считают по фактическому ходу восстановления, а не суммой пересекающихся этапов.
Чем восстановление после шифровальщика отличается от обычного сбоя
Последняя копия может содержать уже повреждённые данные, а прежние учётные записи и среда — оставаться скомпрометированными. До возврата сервиса нужно согласовать с командой реагирования пригодную точку и условия безопасного подключения восстановленных систем.
Руководство CISA #StopRansomware рекомендует учитывать приоритет критичных сервисов и не допускать повторного заражения восстановленной среды. В DRP зафиксируйте ответственного за эту проверку, зависимости сервисов и критерии допуска к работе. Это не инструкция по расшифровке файлов и не обещание восстановить любые повреждения.
Как проверить DRP до аварии
Сначала разберите сценарий с участниками: доступны ли контакты, полномочия и инструкции, понятны ли решения при ошибках. Затем выполните согласованное восстановление репрезентативного сервиса и проверьте пользовательскую операцию. Обсуждение плана не заменяет технический тест.
AWS Well-Architected отдельно рекомендует проверять реализацию аварийного восстановления и достижение RPO/RTO. Результат относится к проверенному объёму, нагрузке, ресурсам и сценарию.
- До проверки задайте критерии приёмки и условия остановки теста.
- Во время проверки фиксируйте этапы, решения, фактические отметки времени и ошибки.
- После проверки назначьте ответственных за отклонения и повторите неуспешные шаги.
- Пересматривайте план после изменений архитектуры, состава команды и важных зависимостей; периодичность учений согласуйте с владельцами процессов.
Шаблон плана аварийного восстановления
Заготовка содержит поля для одного сервиса: сценарий, ответственные, цели, зависимости, последовательность, приёмка и пересмотр. Заполняйте её вместе с владельцем сервиса и исполнителями; ссылки на закрытые инструкции храните по правилам вашей организации.
Для выбора средств используйте каталог систем резервного копирования и сравнение документированных возможностей. Функция продукта не подтверждает выполнимость всего плана — это проверяется восстановлением.
Источники и границы материала
Источники проверены 6 октября 2026 года: AWS: аварийное восстановление, AWS: проверка реализации DR, CISA: восстановление после ransomware. Структура шаблона и пример подготовлены редакцией SecRadar; они не являются испытаниями продуктов или требованиями российского регулятора. Методика проверки →