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

> Источник: 404 Media. Канонический URL: https://404-media.ru/tehnologii/chek-list-gotovnosti-kompanii-k-avariynomu-vosstanovleniyu-it-servisov

Как за 30–60 минут оценить резервное копирование, резервную площадку, DR-план и способность компании восстановить критичные сервисы.

- Рубрика: Технологии (https://404-media.ru/tehnologii)
- Опубликовано: 2026-10-19T17:13:24+03:00
- HTML: https://404-media.ru/tehnologii/chek-list-gotovnosti-kompanii-k-avariynomu-vosstanovleniyu-it-servisov
- Markdown: https://404-media.ru/tehnologii/chek-list-gotovnosti-kompanii-k-avariynomu-vosstanovleniyu-it-servisov.md
- llms.txt: https://404-media.ru/llms.txt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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