Disaster Recovery – классическая задача из категории «важно, но не срочно». Она годами живёт в дальнем конце бэклога, потому что всегда есть что-то с более близким дедлайном: интеграция с новым маркетплейсом, переход на отечественный WMS, подготовка к сезону, замена кассового ПО. DR не блокирует релиз и не срывает промо. Его можно перенести – и переносят.
Логика отсрочки была вполне рациональной. Резервная площадка требовала капитальных затрат: закупить дублирующие серверы, СХД, лицензии, арендовать стойку, настроить каналы. Оплатить это нужно сразу и полностью, а простаивать оборудование будет 99% времени. Инцидент при этом – событие вероятностное, он может и не произойти. С такой арифметикой решение «в следующем году» выглядело разумным.
Проблема в том, что за последние несколько лет обе части этого уравнения изменились. Простой стал стоить принципиально дороже, характер угроз сместился, а резервная площадка перестала требовать капзатрат. Отсрочка, которая раньше была экономией, теперь превратилась в накопление риска.
Что изменилось: четыре фактора
1. Отказ одной системы останавливает выручку целиком
Десять лет назад падение ИТ в рознице означало переход на ручные процессы: бумажные накладные, пересчёт вечером, неприятно, но переживаемо. Сегодня системы связаны в цепочку, где выпадение одного звена парализует всё:
● Касса не работает – покупатель разворачивается и уходит. Этот чек не восстановится вечером, он просто не состоится.
● Сайт или приложение недоступны – заказ уходит к конкуренту в ту же минуту, при этом реклама продолжает работать и жечь бюджет на трафик, который упирается в ошибку.
● WMS встал – склад не собирает заказы, срываются слоты отгрузки, начинаются штрафы от маркетплейсов и претензии от логистов.
● ЕГАИС, «Честный ЗНАК», ОФД не отвечают – продажа маркированных и подакцизных товаров становится юридически невозможной. Это не деградация сервиса, это остановка торговли.
● Программа лояльности недоступна – списание бонусов не проходит, поток обращений в поддержку вырастает лавинообразно, клиентский опыт и репутация страдают.
Ключевое отличие от прежней ситуации: раньше эти системы работали автономно и отказ был локальным. Сейчас цепочка сквозная, и точек, где обрыв критичен, стало на порядок больше.
2. Сезонность делает риск неравномерным
У ритейла выручка концентрируется в узких окнах: «чёрная пятница», предновогодние недели, распродажи 11.11, сезонные пики в отдельных категориях. В эти дни инфраструктура работает на пределе – а значит, вероятность отказа максимальна ровно тогда, когда час простоя стоит дороже всего.
Это меняет смысл отсрочки. «Отложим до после сезона» означает: войти в самый рискованный период года заведомо без плана восстановления.
3. Шифровальщики целятся в резервные копии первыми
Раньше схема защиты выглядела просто: есть бэкап – есть страховка. Современные атаки эту логику обходят.
Порядок действий у вредоносного ПО изменился. Сначала оно ищет и уничтожает или шифрует доступные резервные копии, и только потом атакует продуктив. Смысл понятен: если жертва может восстановиться самостоятельно, платить она не будет.
Отсюда практический вывод. Резервная копия, которая лежит в той же сети, доступна под теми же учётными данными и может быть удалена администратором, – это защита от случайного удаления файла, но не от целенаправленной атаки. То, что несколько лет назад считалось достаточным, сегодня закрывает только часть сценариев.
4. Партнёры начали спрашивать конкретику
Крупные маркетплейсы, банки-эквайеры, логистические операторы и корпоративные заказчики всё чаще запрашивают подтверждение непрерывности бизнеса – в рамках due diligence, при заключении договора или продлении.
Формулировка «мы делаем ежедневные бэкапы» на такой запрос больше не проходит. Спрашивают целевые RTO и RPO, наличие резервной площадки и дату последнего теста переключения. То есть DR из внутренней технической темы стал элементом коммерческих отношений.
Почему бэкап и DR – не одно и то же
Эта путаница – главная причина, по которой задачу считали закрытой.
Разница проявляется в конкретном сценарии. Допустим, основная площадка недоступна: пожар, затопление, длительное отключение питания, потеря сетевой связности.
Если есть только бэкап, последовательность такая: найти вычислительные ресурсы, развернуть на них гипервизор, восстановить виртуальные машины из копий, поднять сеть, перенастроить маршрутизацию и DNS, проверить связность систем, запустить сервисы в правильном порядке. Каждый шаг требует времени и человека, который знает, как именно это делается. Реалистичная оценка – от суток.
Если есть DR, реплики уже находятся на второй площадке в актуальном состоянии. Переключение – это запуск заранее подготовленного плана. Минуты.
Ещё одно частое заблуждение – считать, что успешный бэкап равен успешному восстановлению. Проверка целостности резервной копии подтверждает, что файлы читаются. Она не подтверждает, что из него поднимется работающая система с корректными связями между компонентами. Это выясняется только при реальном восстановлении.
Как устроен DRaaS
Модель Disaster Recovery as a Service снимает именно тот барьер, из-за которого задачу откладывали, – необходимость закупать дублирующее железо.
Репликация. На основную площадку устанавливается агент, который передаёт изменения виртуальных машин на площадку провайдера. Работает непрерывно, инкрементально – передаются только изменённые блоки, а не весь образ. Нагрузка на канал предсказуемая, продуктив не останавливается и не страдает.
Хранение реплик. На стороне провайдера машины находятся в выключенном состоянии, поддерживая заданный интервал отставания от оригинала. Этот интервал и определяет RPO – объём данных, который вы готовы потерять.
Экономика. Постоянно оплачивается хранение реплик, то есть дисковое пространство. Полные вычислительные ресурсы – процессор и память – начинают потребляться только при фактическом или тестовом запуске. Именно это превращает капитальные затраты в операционные и убирает главное возражение прошлых лет.
Переключение. По плану восстановления машины запускаются в заданной последовательности с учётом зависимостей: например, сначала контроллеры домена и службы каталогов, затем базы данных, потом прикладные серверы, в конце – точки входа.
Обратный переезд. После восстановления основной площадки данные, накопленные за время работы на резервной, реплицируются обратно. Работа в резервном режиме не приводит к потере транзакций.
Практический план: с чего начать
Шаг 1. Разделите системы по критичности
Общая цель вроде «восстановиться за 20 минут» бесполезна для планирования. Нужна разбивка – иначе стоимость решения окажется неоправданно высокой, потому что защищать будете всё одинаково и критические и некритические сервисы.
Эта таблица – фундамент всей стратегии и одновременно главный аргумент в разговоре с финансовым директором. Из неё видно, что дублировать нужно не всю инфраструктуру, а конкретный ограниченный перечень. Это радикально меняет TCO (совокупную стоимость владения) DR.
Шаг 2. Измерьте фактическое время восстановления
Не расчётное, не по документации – реальное. Возьмите одну систему средней критичности и восстановите её с секундомером.
Полученная цифра почти всегда расходится с ожиданиями в разы. И она работает убедительнее любой презентации: одно дело обсуждать гипотетические риски, другое – показать руководству, что восстановление ключевой системы занимает не два часа, как все считали, а девять.
Это самый дешёвый шаг из всего списка и одновременно самый результативный для получения бюджета под закрытие риска.
Шаг 3. Вынесите одну копию за пределы площадки
Даже без полноценного DR это закрывает два самых опасных сценария – потерю площадки и шифровальщика, добравшегося до бэкап-сервера.
Объектное хранилище с включённой блокировкой изменений (object lock для обеспечения WORM, Write Once Read Many) не позволяет удалить или перезаписать объект до истечения заданного срока – даже под административной учётной записью. Именно это свойство делает копию устойчивой к целенаправленной атаке.
Для холодных архивов, к которым обращаются редко, есть отдельные тарифы – стоимость хранения существенно ниже.
Шаг 4. Постройте резервную площадку для критичного контура
Начинать с полной репликации всей инфраструктуры не нужно и не стоит. Возьмите системы из первого уровня – те, без которых останавливается выручка. Обычно это ограниченный набор виртуальных машин.
Шаг 5. Внесите тест в календарь
План восстановления, который никто не проверял, – это предположение о том, что всё сработает. Проверять его впервые в момент аварии – самая дорогая форма тестирования.
Современные платформы позволяют проводить тестовое переключение в изолированной сети: реплики поднимаются в песочнице, не затрагивая продуктив и не влияя на репликацию. Ночные окна и остановка сервисов не требуются.
Что фиксировать по итогам теста:
1. Фактическое время до полной работоспособности каждой системы – сравнить с целевым RTO
2. Порядок запуска – не выяснилось ли, что какой-то сервис зависит от того, который поднимается позже
3. Корректность сетевых настроек
4. Целостность данных – не только «база запустилась», но и «приложение с ней работает»
5. Действия людей – кто принимает решение о переключении, кто выполняет, кто оповещает бизнес
Отдельная рекомендация для ритейла: планируйте тест до начала сезона, а не после. Проверка в сентябре-октябре – это подготовка. Проверка в январе – уже разбор полётов.
Шаг 6. Опишите роли, а не только технологию
Технически исправный DR может не сработать из-за организационных пробелов. Регламент должен отвечать на вопросы: при каких признаках объявляется авария, кто уполномочен дать команду на переключение и что делать, если этот человек недоступен, как оповещаются магазины и колл-центр, кто принимает решение о возврате на основную площадку.
Практический момент: инструкция должна быть доступна без доступа к корпоративным системам. Регламент, лежащий на внутреннем портале, который упал вместе со всем остальным, бесполезен.
Гибридная модель как разумный компромисс
Возражение «у нас своя инфраструктура, второй сервер есть» заслуживает уточнения. Вопрос не в наличии резервного узла, а в том, где он физически стоит.
Если резервный сервер находится в том же серверном помещении, на том же вводе электропитания, за тем же маршрутизатором – это защита от отказа диска или блока питания, но не от потери площадки. А сценарий потери площадки как раз и есть то, ради чего существует DR.
Возражение «политика ИБ против облака» тоже часто унаследовано из времён, когда рынок выглядел иначе. Сегодня облачная резервная площадка может быть аттестована ФСТЭК для работы по 152-ФЗ, иметь все необходимые СЗИ и СКЗИ, соответствовать лучшим практикам построения отказоустойчивой инфраструктуры и обеспечивать сетевую изоляцию не хуже собственного контура.
Отсюда сложилась схема, которая закрывает обе группы возражений:
● Продуктив остаётся на своей площадке – контроль над инфраструктурой сохраняется
● Резервная площадка – в облаке – без капитальных затрат, разворачивается в разумные сроки
● Копии в объектном хранилище с object lock – защита от шифровальщика и случайного удаления
● Регулярное тестирование – подтверждение, что схема работает, а RPO/RTO достижимы
Такая архитектура не требует ни полного переезда, ни закупки дублирующего оборудования – то есть снимает оба барьера, из-за которых задачу переносили из квартала в квартал.
Резюме
DR и резервное копирование откладывали не из-за недооценки рисков, а из-за экономики: капитальные затраты сразу, а вероятная авария – когда-нибудь. Расчёт был рациональным для своего времени.
Сейчас он не работает по трём причинам:
1. Простой стоит принципиально больше – цифровые каналы, маркетплейсы и обязательная маркировка связали системы в цепочку, где отказ одного звена останавливает торговлю.
2. Бэкап перестал быть достаточной защитой – шифровальщики уничтожают копии раньше, чем атакуют продуктив, и без неизменяемого хранения схема не держит.
3. Резервная площадка больше не требует капзатрат – облачная модель убрала главный барьер, на который ссылались все предыдущие годы.
Начать можно с одного действия на этой неделе: измерить фактическое время восстановления одной системы. Цифра, полученная с секундомером, дальше сама построит аргументацию для бюджета – и превратит DR из пункта в бэклоге в проект с датой.
