🔴 Disaster Recovery Plan: мини разбор от «зачем» до «как проверять»
Что такое DR-план и зачем он нужен
DR-план (Disaster Recovery Plan), или если на *птичьем* «План ОНиВД» (Обеспечения Непрерывности и Восстановления Деятельности) — это документ, который отвечает на один вопрос: «Когда всё сломается — кто, что и в каком порядке делает?»
Это не просто инструкция по бэкапам как в песенке НТР. Это полноценный операционный документ с ролями, контактами, сценариями, триггерами и процедурами эскалации.
Две метрики, которые определяют всё
Прежде чем писать план, нужно ответить на два вопроса:
RTO — Recovery Time Objective — сколько времени допустимо на восстановление. Максимум, сколько система может лежать.
RPO — Recovery Point Objective — на сколько назад можно откатиться. Допустимый объём потери данных.
Классы критичности
Не все системы одинаково важны:
- Mission Critical — падение = катастрофа, полный тест DR ежегодно, эскалация если не восстановили за 72 часа
- Business Critical — существенный ущерб, полный тест не реже раза в год
- Business Operational / Office Productivity — менее критично, тест раз в 2 года
Структура плана
1. Общие положения — идентификатор системы, класс критичности, RTO/RPO, сценарии утраты непрерывности и стратегии реагирования на каждый.
2. Команда и ресурсы — Координатор + Заместитель (минимум 2 человека с мобильными контактами), плюс внутренние ресурсы (железо, бэкапы, дистрибутивы) и внешние поставщики с режимом доступности.[^1]
3. Порядок реагирования — цепочка:
Триггер обнаружен →
Информирование Координатора →
Принятие решения об активации →
Оповещение команды (≤15 минут) →
Пошаговое выполнение стратегии → Подтверждение восстановления
4. Эскалация — если стратегия не сработала. Для Mission Critical: 72 часа не восстановились — обязательная эскалация. В рабочее время — руководителю РГ, в нерабочее — дежурному департамента. Лучше сразу.
Как тестируют DR-план
По итогам — Протокол испытаний с фактическими vs плановыми показателями и списком проблем.
Актуализация: план — живой документ
Бэкапов много не бывает. Но только если они актуальные и проверенные.
- Изменения вносятся в день выявления любых изменений в команде или инфраструктуре
- Плановая актуализация — не реже **раза в 2 года**
- После утверждения — рассылка всем участникам в течение 2 рабочих дней
- Новые сотрудники знакомятся с планом в день приёма на работу
Чеклист: есть ли у тебя нормальный DR-план
Все сломалось, а план «дружит» с тобой как такса — кусает именно тогда, когда не ждёшь. Проверяй заранее.
- [ ] Определены RTO и RPO для каждой критичной системы
- [ ] Описаны конкретные сценарии с триггерами обнаружения
- [ ] Есть Координатор и Заместитель с актуальными контактами
- [ ] Прописаны пошаговые стратегии с ответственными на каждом шаге
- [ ] Последний полный тест — менее года назад (для критичных систем)
- [ ] План обновлялся после последних изменений в инфраструктуре
- [ ] Все участники ознакомлены с актуальной версией
Если отметил меньше 5 пунктов — у тебя не DR-план, а документ надежды.
Вывод: DR-план работает только если его регулярно тестировать и обновлять. Потому что читать документ с нуля в 3 ночи при падении прода — это не восстановление, это паника с бумажкой в руках.
Совет от автора: напиши свой DR план на домашнюю инфру, добавь туда стратегии и сценарии с командами по восстановлению. Поверь, пригодиться, а потом еще за курсач засчитают в шараге/универе. Шаблончик потом можно переиспользовать
Бонус, кто дочитал [клик]
❤ Поддержать 💬 Канал & Чат 📺 RUTUBE 📺 YouTube