Если не сработал план B?
А если провалился план C?
Тогда приходит план D - и имя ему DRP
Disaster Recovery Plan (DRP) – это комплексная стратегия и набор технических решений для восстановления IT-инфраструктуры и данных после катастрофы, аварии или кибератаки. DRP позволяет минимизировать время простоя бизнеса, сократить финансовые потери и обеспечить бесперебойную работу критически важных систем
С появлением онлайн торговли стоимость выхода на рынок снизилась, появилась возможность создать свое маленькое онлайн-пространство в виде сайта и получить прибыль и гордый статус предпринимателя. Увеличивающаяся востребованность интернета заставила бизнес взглянуть в сторону онлайн-торговли. При этом высокая доступность выхода на рынок повысила конкуренцию среди продавцов и увеличила количество предложений для покупателей. Чтобы привлечь внимание покупателя, бизнес был вынужден придумывать все новые формы рекламы, повышать доступность своих сервисов, делать процесс покупок все более привлекательным и комфортным
Сейчас покупатель находится в самом привилегированном положении за всю историю – все сервисы: магазины, банки, сайты, приложения, доставки, такси, любой контент доступны 24 часа в сутки 7 дней в неделю. Бизнес получил до этого невообразимую возможность продавать вне рамок районов, городов, регионов и государств. География, объемы и интенсивность продаж выросла в разы
Бизнес разных уровней расцвел в онлайн-пространстве, но как мы знаем, с великой силой приходит великая ответственность. Ведь теперь, когда час недоступности может стоить миллионы, груз ответственности становится в миллион раз тяжелее
Здесь в игру вступает проактивный подход. Отказ – это просто вопрос времени. Любая система, даже (особенно) если она очень дорогая и кажется вам невероятно надежной, рано или поздно упадет. Чем больше компонентов, чем сложнее ваша система – тем выше риск отказа одной или даже нескольких ее частей.
Если отказ неизбежен, то возникает резонный вопрос: что можно сделать, чтобы снизить его эффект? Один из вариантов решения этой проблемы – это Disaster Recovery Plan (DRP)
Главной целью DRP является минимизация простоя бизнеса в случае краха системы при форс-мажоре. Для бизнеса отказ системы или ее компонентов, который влияет на функциональность сервиса – это всегда потерянная прибыль. DRP – это про готовность и умение работать с рисками
DRP помогает нам обеспечить бесперебойность работы критически важных компонентов и сократить финансовые потери из-за даунтайма
К сожалению, информационное пространство не отличается безопасностью. В интернете полно причин бояться за здоровье своей системы начиная от кибератак и заканчивая вирусами. Наличие DRP помогает спать чуть более крепко, зная, что в случае нападения какой-либо жути, у нас есть план Б
Основные принципы DRP
- Минимизация времени простоя – оперативное восстановление систем
- Приоритет критических сервисов – сначала восстанавливаются ключевые системы
- Гибкость – адаптация плана к разным типам угроз
- Автоматизация – использование скриптов и резервных систем
- Регулярное тестирование – постоянная проверка работоспособности плана
- Соответствие нормативным требованиям – выполнение требований законодательства
Существует несколько типов Disaster Recovery Plan'ов, которые различаются по техническим характеристикам, архитектурным решениям и уровню автоматизации.
Иметь план Б — это необходимая база, но при выборе типа DRP мы всегда должны находить баланс между стоимостью решения и стоимостью отказа. Нет смысла создавать дорогого монстра безотказности, когда стоимость его обслуживания будет стоить 20 дней работы сервиса. Подбор решения всегда индивидуален и должен актуализироваться с ростом бизнеса
Какие бывают DRP?
Горячее резервирование (Hot Site DRP)
полноценная дублирующая площадка, которая принимает нагрузку в случае сбоя
Плюсы
Минимальное время простоя
Высокая доступность
Возможность переключения на резерв в случае небольшой аварии (например неудачного деплоя)
Возможность принимать часть трафика и работа в active-active режиме в случае поддержки со стороны приложения
Минусы
Высокая стоимость эксплуатации
Простой вычислительных ресурсов
Холодное резервирование (Cold Site DRP)
площадка на которой есть данные (бекапы БД, кода, настроек и всего необходимого для развертывания) но нет инфраструктуры, ресурсы которой закупаются и разворачиваются при аварии, после чего площадка конфигурится и готова принимать нагрузку
Плюсы
В несколько раз дешевле горячего резервирования
Минусы
Долгое время восстановления, часто требует ручного развёртывания
Гибридные решения (Hybrid DRP)
комбинация горячего и холодного резервирования, когда инфраструктура развернута в минимальном объеме, но для полноценного обслуживания пользовательского трафика требуется масштабирование ресурсов
Плюсы
Стоимость меньше чем у полноценной площадки
Минусы
Требует больше времени на развертывание, чем горячий резерв
RTO (Recovery Time Objective) - Максимальное время простоя после аварии
RPO (Recovery Point Objective) - Максимально допустимая потеря данных (например, данные за последние 15 минут, 1 час, 24 часа)
MTTR (Mean Time to Recovery) - Среднее время восстановления после сбоя
MTBF (Mean Time Between Failures) - Среднее время между сбоями
Этапы разработки DRP
- Определение критически важных систем и данных
- Оценка возможных угроз (кибератаки, сбои оборудования, стихийные бедствия)
- Расчет потенциальных потерь от простоев
2. Определение требований к восстановлению
- Выбор Recovery Time Objective (RTO) – максимального времени восстановления
- Определение Recovery Point Objective (RPO) – допустимой потери данных
- Классификация данных по уровням важности
3. Выбор стратегии восстановления
- Локальные, облачные или гибридные решения
- Автоматизированные или ручные процедуры
- Организация резервных площадок (hot/cold sites)
4. Финансовые аспекты DRP
- Оценка стоимости простоя бизнеса (downtime cost)
- Оптимизация затрат на резервные системы – баланс между RTO/RPO и ценой решения
- Страхование рисков – некоторые компании страхуют свои IT-активы
5. Развертывание и разработка планов действий
- Развертывание DRP
- Пошаговое руководство по восстановлению систем
- Назначение ответственных лиц
- Создание инструкций для персонала
6. Тестирование и оптимизация
- Тестовое восстановление
- Имитация аварийных ситуаций
- Оценка скорости восстановления
- Внесение корректировок в планы
7. Обучение персонала
- Проведение тренингов
- Ознакомление сотрудников с планом действий
- Регулярные проверки готовности
8. Мониторинг и обновление DRP
- Обновление плана при изменении IT-инфраструктуры
- Улучшение стратегии на основе тестов
- Поддержание актуальности контактов и инструкций
- Важно хранить версии плана и фиксировать изменения
9. Автоматизация DRP
- Мониторинг с автоматическим уведомлением об аварии
- Скрипты для автоматического развертывания резервных серверов
- Использование автофейловера (автоматического переключения на резервные мощности)
10. Работа с человеческим фактором
- Четкое распределение ролей – кто отвечает за что при аварии
- Обучение сотрудников – не только технарей, но и бизнес-команды
- Документирование решений – фиксация всех шагов для анализа после инцидента
самые распространенные причины отказов
- Стихийные бедствия: пожары, наводнения, землетрясения
- Человеческий фактор: ошибки при проведении работ, ошибки в коде, забытые зависимости
- Кибератаки: шифрование, ransomware, диверсии
- Отключение электроэнергии: проблемы с питанием, отказы ДЦ
- Сбои техники: сбои железа, сетевые сбои, потеря связности
DRP это баланс между надеждами на лучшее и подготовке к худшему. Важно выдержать баланс между стоимостью и рисками. Представьте, что будет если ДЦ в котором живет ваша площадка внезапно больше нет, его съела Годзилла. Все сервера, данные и бекапы в нем больше не существуют
Есть ли у Вас внешний бекап с которого вы можете восстановиться?
Сколько данных будет потеряно навсегда и сколько времени понадобится на восстановление функциональности?
Если ответы на эти вопросы неутешительные, самое время подумать над тем, чтобы разработать Disaster Recovery Plan для вашей компании. Если нужна консультация - вы всегда можете написать нам!
здесь ценят всякое знание: