DR-контур: зачем платить за то, что не пригодится

Самая опасная фраза про DR звучит спокойно: бэкапы делаются. Это правда. Только она не отвечает на вопрос, который важен собственнику: через сколько дней после аварии бизнес снова сможет принимать деньги?

С этого разрыва и начинается разговор про Disaster Recovery. Не с серверов и не с технических схем. С цены остановки бизнеса - и с того, кто за неё платит.

Два вопроса, которые всё объясняют

Однажды я задал CEO два вопроса подряд. Не про ИТ - про бизнес.

Первый: что произойдёт, если компания не сможет проводить платежи несколько дней? Ответ пришёл без паузы: поедут уже оплаченные заказы, начнутся задержки от поставщиков, в личных контактах, может, что-то удастся порешать - но срыв хотя бы части обязательств неизбежен.

Второй: что случится, если у отдела продаж перестанет работать инструмент для приёма заказов? Ответ был ещё короче: это вообще очень плохо. Мы не сможем принимать заказы, получать авансы и размещать производство. Остановка входящего потока денег.

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

До этого разговора ситуация была типичной. Все программы работали. ИТ регулярно отвечало: бэкапы делаются. CEO не видел поводов для беспокойства. Проблема была в том, что вопрос "делаются ли бэкапы" - не тот вопрос. Правильный: если завтра сломается критичная система, через сколько часов бизнес снова сможет работать?

После разговора я предложил простой тест: дай задачу ИТ прямо сейчас - поднять рабочую копию системы продаж. Засеки время.

Тест реальности: 21 день

Первая реакция от ИТ пришла мгновенно: на какой сервер? У нас нет свободных.

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

Рабочую копию, в которую CEO смог зайти и проверить данные, он получил через 21 день.

CEO понял, что нужно что-то менять, ещё на третий день. 21 день просто подтвердил правильность этого вывода.

Бэкапы делались. Только никто не отвечал за то, что из этих бэкапов можно восстановить бизнес за предсказуемое время. Резервные копии к тому же хранились в том же контуре, где и сами данные. При определённых сценариях сбоя - отказ основного хранилища, физическое повреждение оборудования - бэкап мог пострадать вместе с оригиналом. Защита была, но она не была независимой.

Разрыв между "бэкап есть" и "бизнес восстановлен" - это и есть управленческая проблема DR.

Три контура, которые решили всё

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

Прошли по всем системам. Сделали восстановление каждой по несколько раз - из реальных копий, на реальном оборудовании. Зафиксировали время. Потом сели с CEO и для каждой системы определили допустимый лимит: сколько времени на восстановление бизнес готов принять.

Три системы вышли за лимиты.

Товародвижение. Финансы. Зарплата.

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

Для этих трёх приняли отдельное решение: ЦОД с репликацией каждый час. Данные уходят туда в фоне, без участия команды. При необходимости - разворачивание на арендованных мощностях в пределах согласованного RTO. Максимальная потеря данных при любом сценарии - один час работы. Именно этот параметр стал основой для разговора о рисках с CEO, а не технические характеристики серверов.

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

Как устроили процесс

Технические решения - только часть работы. Параллельно выстраивали организационный контур: что происходит при инциденте, кто за что отвечает, как фиксируется результат.

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

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

DR без организационного процесса - это набор технических процедур, а не управляемое восстановление. Детали этого контура - runbook, роли, порядок запуска, механика контрольных проверок - разбираю в следующем материале.

У такого решения тоже есть цена

DR-контур не живёт сам по себе. Это эксплуатационная дисциплина, а не разовый проект.

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

Если этого не делать - через полгода компания снова получит старую проблему в новой упаковке. Бэкапы формально есть, DR формально построен, договор с ЦОД подписан. Но реальное восстановление снова превращается в импровизацию: последний тест был год назад, ответственный уволился, а инструкция описывает систему, которой уже нет.

Решение рабочее. Но у него есть цена: дисциплина сопровождения. Не разовая инвестиция - постоянная операционная ответственность.

Расчёт, который всё ставит на место

Стоимость постоянного DR-контура: 73 000 рублей в месяц на хранение копий и репликацию данных в ЦОД. 876 000 рублей в год.

Разовые вложения в подключение к ЦОД и диски для сейфа - ещё около 194 000 рублей. Один раз.

Теперь другая сторона. Компания с выручкой 3,2 млрд рублей в год зарабатывает в среднем около 8,8 млн рублей в день. Это только выручка - без учёта ФОТ остановленного персонала, стоимости ручного восстановления, штрафов по обязательствам и репутационных потерь.

Один день простоя - 8,8 млн рублей. Год обслуживания DR-контура - 876 000 рублей.

Один к десяти.

Один день вынужденной остановки бизнеса стоит как десять лет обслуживания DR. Разовые вложения в 194 000 рублей - это около получаса суточной выручки. Меньше, чем первое совещание по разбору последствий аварии.

Эти цифры индивидуальны для каждой компании - отрасль, модель продаж, сезонность, структура контрактов дают разный результат. Но пропорции устойчивы:

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

Когда всё сработало

Через некоторое время после того, как DR-контур был выстроен, на одном из торговых объектов вышел из строя сервер.

Всё прошло штатно. Критичный контур восстановили в пределах согласованного RTO - менее чем за час. Потерь данных не было. Для бизнеса это выглядело не как подвиг ИТ, а как штатная процедура: проблема есть, план есть, результат предсказуем.

Без поиска людей, которые знают пароли. Без вопросов, где лежит нужная копия. Без импровизации.

Именно так и должен работать DR: незаметно. Когда авария - это инцидент с известным решением, а не кризис с неизвестным исходом.

Единственный правильный критерий готовности: не "у нас есть бэкапы", а "мы знаем, что произойдёт при сбое, и это нас устраивает".

Для собственника

Вероятность аварии можно обсуждать бесконечно. Точную вероятность нельзя посчитать, и любая оценка будет предметом спора.

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

Один вопрос к себе: сколько дней вынужденной остановки мой бизнес выдержит без управленческого кризиса? Один? Три? Неделю? Ответ определяет, какой DR нужен - и сколько за него платить.

Для CEO

DR-бюджет - это не статья "на всякий случай". Это цена за то, что следующий сбой не станет кризисом с поиском виноватых, ручным восстановлением и потерями за счёт бизнеса.

Пока DR не выстроен, каждый инцидент начинается заново: поиск людей, выяснение где копия, ожидание с неизвестным горизонтом. После того, как процесс есть, инцидент - это последовательность шагов с известным временем на каждый.

Разница между этими двумя состояниями - и есть цена DR.

DR-контур нужен не на всякий случай. Он нужен, чтобы авария не стала управленческой импровизацией за счёт бизнеса.

Следующий материал - про runbook восстановления: что должно быть готово до сбоя, чтобы "меньше часа" было не обещанием ИТ, а проверенной процедурой.

#cio #управлениеиденьги