Чек-лист готовности компании к аварийному восстановлению ИТ-сервисов

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

Представленный чек-лист рассчитан примерно на 30–60 минут. Его можно использовать перед аудитом, запуском нового сервиса, изменением инфраструктуры или после инцидента. Оценка охватывает не только сохранность данных, но и способность вернуть в работу критичные ИТ-системы.

Критичность систем и целевые показатели восстановления

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

Для критичных систем определяют RTO и RPO. RTO показывает допустимое время восстановления, а RPO — объём данных, который допустимо потерять. Эти значения следует согласовать с владельцами бизнес-процессов и вывести из последствий простоя, а не выбирать формально или «по умолчанию».

Резервное копирование и защита копий

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

Как минимум одна копия должна находиться вне основной площадки. Дополнительная неизменяемая, офлайн или изолированная копия снижает риск потери данных из-за шифровальщиков, ошибок администраторов и других разрушительных действий. Практической базовой моделью считается схема 3-2-1-1-0: три копии, два типа носителей, одна копия вне площадки, одна неизменяемая копия и ноль ошибок при проверке.

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

Резервная площадка и сценарий переключения

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

Если для системы установлен RTO в несколько минут, необходимо проверить репликацию и её текущий лаг, сопоставив его с RPO. На резервной площадке заранее подготавливают сети, адресацию, маршрутизацию, firewall и NAT. Кроме того, нужен доступ к DNS, сертификатам, учётным записям, секретам и внешним интеграциям.

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

DR-план, роли и документация

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

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

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

Практические проверки

В течение последних 3–6 месяцев желательно проводить плановое переключение всех критичных систем на резервную площадку. Не реже одного раза в неделю следует проверять восстановление из бэкапа — например, файла, базы данных или сервера целиком. Не реже одного раза в месяц проводят тестовый запуск Recovery Plan без влияния на рабочую среду.

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

Такой тест должен подтверждать не только целостность резервной копии, но и способность команды восстановить сервис в пределах согласованных RTO и RPO.

Как оценить результат

Посчитайте количество выполненных пунктов чек-листа:

• 0–15 из 30 — высокий риск: восстановление после аварии, вероятно, займёт больше времени, чем ожидается.
• 16–24 из 30 — базовая защита есть, но DR-план требует доработки и обязательного тестирования.
• 25–30 из 30 — инфраструктура подготовлена к аварии; при этом тесты нужно регулярно повторять, а план — актуализировать.

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