Короткий ответ

DRP Contoso — короткие планы на 3–5 критичных сервисов, не том «непрерывность бизнеса» на 80 страниц. Минимум: сценарии (потеря VM, потеря хоста, потеря площадки), порядок поднятия (обычно AD/DNS → инфраструктура → данные → приложения), RTO/RPO из owner, контакты, где backup, где офлайн-копия документа. Без регламента backup DRP — фантазия.

Не пишите план на все 40 систем в первый заход. AD, файлы, 1С, связь (VPN/почта), может быть СКУД/телефония — типичный набор SMB.

Симптомы и как отличить

Типичная картина:

  • пожар/залитие, спорят «с чего начать»;
  • 1С хотят restore раньше DNS;
  • телефоны в Confluence, Confluence в той же VM;
  • RTO «ну день», backup ночной, противоречие невидимо.

Отличия:

ДокументЗадача
Регламент backupчто копируется
Restore-тестумеем ли доставать
Rollback CHGоткат изменения
DRPкак собрать сервис после отказа уровня площадки/хоста

Возможные причины

  1. Кажется, что «маленькие, переживём».
  2. Страшно фиксировать RTO, которое не вытянуть.
  3. Нет owner сервисов.
  4. Backup не тестировали — стыдно писать шаги.
  5. Копипаст чужого DRP с банком и ЦОД, который не про Contoso.
  6. Редко: юристы хотят «сертифицированный BCP», IT бросает практический план.

Диагностика

Чеклист: для AD, файлов, 1С ответьте без старшего за 5 минут.

  1. Кто принимает решение «это катастрофа, не просто ребут».
  2. Где консоль backup, если HV01 мёртв.
  3. Порядок VM.
  4. Где break-glass, если AD мёртв.
  5. Кому звонить у провайдера/колокации.

Любой прочерк — писать DRP. Сверьте инвентарь:

Get-ADComputer -Filter {OperatingSystem -like '*Server*'} -Properties IPv4Address |
  Select-Object Name, IPv4Address

Список в голове Ивана Петрова ≠ приложение к DRP.

Проверьте доступность документа с телефона LTE (не корпоративный Wi‑Fi той же площадки).

Решение

Шапка на сервис (одна-две страницы)

  • Сервис, owner/deputy
  • Сценарии: VM down / host down / site down
  • RPO/RTO согласованные
  • Зависимости (AD, DNS, SQL, лицензии)
  • Источник backup, second copy
  • Шаги с номерами
  • Критерий «сервис принят бизнесом»
  • Коммуникации пользователям

Порядок типичный для Contoso HQ

  1. Безопасность людей и электричество/ИБП — не IT-героизм в дыму.
  2. Связь дежурных (телефон вне AD).
  3. DNS/AD (без этого 1С и шары часто бессмысленны).
  4. Гипервизор/хранилище.
  5. SQL / 1С.
  6. Файлы.
  7. VPN для удалённых.

Не копируйте порядок слепо: если 1С файловая на одном NAS без AD — свой порядок.

Сценарий «умер HV01»

  • Есть второй хост / можно восстановить VM куда.
  • Лицензии железа.
  • Сеть VLAN с схемы.
  • Не original overwrite поверх единственной копии без решения owner.

Сценарий «нет площадки»

  • Где offsite.
  • Какие сервисы не поднимаем (честный список).
  • Временный офис / облако — только если это реально куплено, не «придумаем в день X».

Связь с тестами

План без календаря restore гниёт. Первое учение — tabletop 1 час, второе — restore одного сервиса на изолированный хост.

Tabletop на час без геройства

Соберите Ивана Петрова, deputy, owner 1С, при необходимости главбуха. Сценарий: «HV01 не включается, СХД пищит». Идите по бумаге: кто звонит, где backup, куда restore, что не поднимаем. Секундомер на поиск контакта провайдера и пароля BMC в vault. Всё, что искали дольше трёх минут — дыра DRP.

Запишите решения, которые всплывут: «1С важнее файлов архива 2019», «почта может подождать 4 часа». Это и есть смысл DRP, не красивый логотип на обложке. Повторите tabletop после смены людей, не раз в пятилетку.

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

Как проверить, что проблема устранена

  • Есть 3–5 подписанных мини-планов.
  • Контакты проверены звонком.
  • Документ открывается без FILE01.
  • Tabletop проведён, замечания внесены.
  • Порядок восстановления не противоречит зависимостям (1С после SQL/AD).

Добавьте в DRP явную развилку: «AD жив / AD мёртв». Если каталог жив, не начинайте restore VM 1С как первый шаг. Если каталог мёртв, break-glass с консоли гипервизора и DSRM — до любых пользовательских сервисов. Путаница порядка — главная причина, почему «план есть, в аварии всё равно хаос». Пропишите, кто имеет право сказать «это disaster, не просто ребут HV01»: список из двух-трёх имён, не чат.

Если не помогло

  • Бизнес не даёт RTO: дайте два варианта стоимости (RTO 4 ч vs 24 ч) и заставьте выбрать.
  • Нет offsite: DRP сценария site down честно = «ждём железо N дней». Это тоже план, лучше вранья.
  • Слишком толстый документ: режьте до шагов, приложения — схемы и паспорта.

Профилактика

  • Обзор DRP после каждого серьёзного изменения топологии.
  • Смена owner = правка контактов в тот же день offboarding.
  • Мониторинг не заменяет DRP, но даёт раннее объявление сценария.
  • В общем регламенте эксплуатации — ссылка на место хранения DRP.

FAQ

DRP и BCP — одно?

BCP шире (офис, люди, поставщики). IT-DRP — как поднять системы. Начните с DRP, не ждите идеального BCP.

Нужен ли план на принтеры?

Нет в первой пятёрке. Если печать этикеток склада критична — тогда да, как сервис «печать склада».

Можно ли один DRP на всё?

Оглавление + приложения по сервисам. Один PDF-кирпич без якорей в 03:00 не читают.

Кто объявляет disaster?

Именной список: Иван Петров, deputy, руководитель. Не «кто первый запаниковал в чате».

Восстанавливать ли все VM?

Нет. Критичные по списку. Остальные — очередь или потеря допустима.

Нужны ли скриншоты консоли backup в DRP?

Один актуальный путь «как открыть restore», плюс текстовые шаги. Скрин 2019 года вреден.