Как выбрать RTO/RPO: DR на практике без переплат

Что вы решаете с Disaster Recovery и почему это стоит денег

Disaster Recovery (DR) нужен не для того, чтобы просто хранить копии файлов. Его задача - вернуть работу бизнеса после аварии: когда серверная недоступна, шифровальщик повредил данные, отключили электричество, отказало хранилище или обновление уронило ключевую систему.

Бэкап отвечает на вопрос: «Смогу ли я восстановить данные?». DR отвечает на другой: «Как быстро я верну сервис в рабочее состояние и сколько данных потеряю по дороге?». Бывает, что копии есть, но восстановление занимает сутки - и бизнес все равно стоит.

Поэтому RTO и RPO стоит считать, а не выбирать на глаз. RTO - сколько времени вы можете быть без системы. RPO - сколько данных вы готовы потерять (например, последние 15 минут заказов или платежей). Эти цифры напрямую определяют архитектуру: нужна ли репликация, второй контур, отдельная площадка, автоматическое переключение, как часто делать копии и как регулярно проверять восстановление.

Главная причина переплат - одинаковые требования ко всем системам. Если поставить RTO 15 минут и RPO 5 минут для всего, включая архив, тестовые стенды и внутренние порталы, вы купите лишние серверы, каналы, лицензии и поддержку. Гораздо дешевле разделить сервисы по критичности и дать каждому свой уровень защиты.

DR затрагивает не только «серверы в стойке», а целые цепочки: приложения, базы и файлы, учетные записи и доступ, сеть и безопасность, а также рабочие места ключевых команд (например, кассы или колл-центр). Для портала заявок на закупки часто приемлем RTO 8 часов, а для платежей или регистрации пациентов нужны минуты. Разговор о том, как выбрать RTO/RPO без лишних затрат, начинается именно с последствий для бизнеса, а не с выбора железа.

RTO и RPO без сложных терминов: как их понимать

RTO и RPO отвечают на два простых вопроса: сколько времени вы можете быть без системы и сколько данных вы готовы потерять. Это база, если вы хотите выбрать цели восстановления осознанно и не платить за скорость там, где она не нужна.

RTO: сколько простоя можно пережить

RTO (Recovery Time Objective) - максимально допустимое время простоя. Если RTO для бухгалтерии 8 часов, значит бизнес принимает, что после аварии бухгалтерия может не работать до одного рабочего дня.

RTO - это не только про серверы и виртуальные машины. Это еще и про процесс: кто принимает решение о переключении, кто выполняет шаги, где лежат инструкции, есть ли доступы.

RPO: сколько данных можно потерять

RPO (Recovery Point Objective) - допустимая потеря данных по времени. Если RPO 15 минут, то после восстановления допускается откат максимум на 15 минут назад. Если RPO 24 часа - потеря данных за сутки считается приемлемой (например, если их можно восстановить из других источников или ввести заново).

Чтобы почувствовать разницу, удобнее думать последствиями:

• RTO 15 минут, RPO 0-5 минут - обычно нужны почти непрерывное резервирование и репликация плюс быстрые процедуры.
• RTO 2 часа, RPO 30 минут - часто хватает репликации по расписанию и готового плана переключения.
• RTO 8 часов, RPO 4 часа - обычно достаточно регулярных бэкапов и понятного восстановления.
• RTO 24-48 часов, RPO 24 часа - минимальные затраты, но нужно принять долгий простой и ручные шаги.

На реальные RTO/RPO влияют четыре вещи: люди (дежурства, роли, обучение), процессы (регламенты, тесты), инфраструктура (одна площадка или две, сеть, хранилища, серверы) и сами приложения (зависимости, базы данных, лицензии). Даже с надежными серверами без отработанного сценария переключения нужные RTO останутся на бумаге.

Как оценить последствия простоя и потери данных

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

Дальше посчитайте цену простоя: недополученная выручка, простой сотрудников, срыв поставок, штрафы и пени, ручная обработка. Отдельно стоит репутация: один инцидент в клиентском сервисе иногда стоит дороже нескольких часов простоя внутренней системы.

Практичный подход - оценивать «стоимость 1 часа простоя» и «стоимость потери 1 часа данных». После этого обсуждать, как выбрать RTO/RPO без переплат, становится проще.

Не забывайте про зависимости. «Неважная» система иногда останавливает десять других. Простой пример: если не работает каталог пользователей, сотрудники могут не войти ни в почту, ни в учетные системы.

Чтобы оценка была реалистичной, проверьте:

• кто потребитель системы (клиенты, операторы, бухгалтерия, врачи, касса)
• что ломается при простое (процессы, договоры, безопасность)
• какие есть зависимости (сеть, AD, базы, интеграции)
• в какие часы простой критичнее (рабочие часы, конец месяца)
• сколько времени допустимо работать «вручную»

Контекст решает. Час простоя в 11:00 в будний день и час простоя ночью - это разные потери. А у систем отчетности пик критичности часто приходится на закрытие месяца или квартала.

Уровни критичности систем: понятная шкала для бизнеса

Чтобы не переплатить за Disaster Recovery, полезно договориться о простой шкале критичности. Она переводит разговор из «все важно» в конкретику: сколько простоя терпимо и сколько данных можно потерять.

Ниже - практичная градация 0-4. Ее удобно использовать как основу для матрицы критичности систем.

• Уровень 0-1 (некритичные): без них можно жить несколько дней. Восстановление по заявке, без круглосуточной готовности. Пример: внутренний портал новостей, тестовая среда, часть архивов.
• Уровень 2 (важные внутренние): остановка мешает работе, но не «роняет» бизнес. Допустимо восстановление в пределах рабочего дня. Пример: бухгалтерия, кадровая система, корпоративная почта (если есть запасные каналы связи).
• Уровень 3 (клиентские и производственные): простой заметен клиентам или срывает операции. Счет идет на часы, потеря данных должна быть небольшой. Пример: ERP для склада и отгрузок, портал услуг, прием заявок в контакт-центре.
• Уровень 4 (миссион-критичные): даже короткий простой недопустим, цели близки к «минутам», RPO - минимальный. Пример: кассы и платежи, ядро транзакций, системы безопасности и непрерывности услуг.

Если при остановке системы вы сразу считаете потери в деньгах, штрафах или репутации - это чаще уровень 3-4. Если больше страдает удобство и скорость работы, а не результат - обычно уровень 1-2.

Один и тот же тип системы может иметь разный уровень в разных компаниях. Почта для части команд - уровень 2, а для службы поддержки 24/7 - уже уровень 3.

Пошагово: как выбрать RTO/RPO и составить матрицу приоритетов

Чтобы выбрать RTO/RPO без переплат, начните с перечня того, что вы реально должны восстановить после сбоя. Важно, чтобы это был общий документ для ИТ и бизнеса, а не таблица «для галочки».

Пять шагов, которые работают

Соберите короткую рабочую группу: ИТ, безопасность, финансы и владельцы ключевых процессов.

• Составьте список систем и назначьте владельца на каждую (кто принимает решение о допустимом простое и потерях данных).
• Опишите зависимости и «минимальный запуск»: что нужно, чтобы компания работала хотя бы в базовом режиме (сеть, AD, почта, ERP, платежи, телефония).
• Задайте целевые RTO/RPO по уровням критичности, а не по каждой системе с нуля.
• Зафиксируйте исключения и временные компромиссы: где можно жить на бэкапах вместо репликации, где допустим ручной режим, где нужен обходной процесс.
• Утвердите матрицу приоритетов и правила пересмотра: кто обновляет, как часто, что считается изменением, требующим пересмотра.

Как заполнить матрицу, чтобы она была полезной

Для каждой системы обычно хватает 6-8 полей: владелец, критичность, RTO, RPO, зависимости, способ восстановления (бэкап/репликация/резерв), место размещения и порядок тестирования.

Например, у банка платежный шлюз может требовать RTO 1 час и RPO 5 минут (обычно нужны репликация и заранее подготовленные мощности). А для внутреннего портала обучения подойдет RTO 3 дня и RPO 24 часа (часто достаточно ежедневных копий). Для инфраструктуры это означает разные классы ресурсов: часть сервисов держать на подготовленных мощностях, а часть восстанавливать по мере необходимости.

Если RTO/RPO выглядят красиво, но вы не готовы регулярно тестировать восстановление, это не цель, а риск.

Матрица приоритетов: что в ней должно быть, чтобы она работала

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

Держите набор полей коротким, но обязательным: название системы, владелец (человек, который принимает решения), целевые RTO и RPO, приоритет восстановления и зависимости.

Приоритет лучше привязывать к понятным критериям:

• деньги (выручка, штрафы, простой производства)
• безопасность и риск (персональные и медицинские данные, доступы)
• обязательства (регуляторика, договоры, госуслуги)
• клиенты и репутация (массовые обращения, критичный сервис)

Отдельно фиксируйте общие платформы, которые «тянут» все остальное. Частая ошибка: поставить бизнес-приложение «приоритет 1», а AD/DNS, сеть, хранилища и виртуализацию - «приоритет 3». В итоге приложение вроде бы первое, но запустить его негде.

Договоренности формулируйте простыми фразами, которые легко проверить на учениях:

• «Восстановить доступ к системе не позже чем через 4 часа после инцидента»
• «Потеря данных допустима не более 15 минут»
• «Если зависимость недоступна, RTO увеличивается до X»
• «Владелец системы подтверждает приоритет и участвует в тестах 2 раза в год»

Типовые DR-архитектуры под разный бюджет

DR почти всегда сводится к выбору: вы платите за скорость восстановления (RTO), за минимальную потерю данных (RPO) или за оба параметра. Поэтому архитектуру лучше подбирать после того, как вы определили цели для разных систем.

Частые варианты, от простых к более быстрым:

• Бэкап на той же площадке - дешево и быстро внедряется, но плохо переживает пожар, затопление и часто не спасает от шифровальщика, если он добрался до хранилища.
• Бэкап + отдельное хранилище или лента - снижает риск уничтожения копий и дает длинное хранение, но RTO обычно измеряется часами или днями.
• Репликация на вторую площадку - возврат быстрее, но дороже из-за канала связи, второй инфраструктуры и поддержки.
• Warm standby - площадка подготовлена, но часть мощностей включается по факту аварии. Часто разумный компромисс для важных систем.
• Hot standby - все работает параллельно, переключение почти мгновенное. Переплата появляется, когда бизнесу достаточно восстановиться за 1-2 часа, а платят как за минуты.

Отдельный вопрос - как переключаться. Ручное переключение дешевле, но требует людей, инструкций и времени.

Автоматизация обычно оправдана, если RTO измеряется минутами, ночью и в выходные некому выполнять регламент, ошибка оператора слишком дорога или регуляторика требует предсказуемого восстановления.

Как требования меняются для разных типов систем

Одинаковые RTO/RPO для всех систем почти всегда ведут к переплате. Смотрите на тип нагрузки и на то, как она восстанавливается. Полезный вопрос для владельца процесса: что будет, если сервис вернется, но данные окажутся «вчерашними»?

Файлы и почта: важно не только «где лежит копия»

Для файловых хранилищ и почтовых систем критично быстро найти нужное письмо или документ и вернуть права доступа. Частая ошибка - иметь копию, но без понятного каталога, без проверок восстановления и без учета версий. RPO тут часто можно сделать больше, чем для транзакционных систем, а RTO обычно упирается в объем и скорость поиска.

Базы данных и ERP: консистентность и порядок восстановления

У ERP и баз данных главный риск - «битые» данные после восстановления. Нужны согласованные точки восстановления (журналы, согласование приложений) и порядок запуска: база, затем сервисы приложения, затем интеграции и только потом отчеты. Иначе система может подняться, но начнет ошибаться.

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

VDI и «рабочие места» редко требуют сохранения целых виртуальных ПК. Обычно достаточно профилей пользователей, шаблонов образов и доступа к ключевым приложениям. Это снижает требования к хранилищу и каналу.

Для сервисов 24/7 цель простая - убрать ручные шаги, потому что ночью и в стрессе люди ошибаются. Минимальный набор практик: автоматический запуск критичных компонентов и проверка доступности, заранее описанные зависимости (DNS, AD, сертификаты, сети), один ответственный за решение «переключаемся или ждем», короткие инструкции для дежурной смены и регулярная репетиция на тестовом контуре.

Частые ошибки, из-за которых DR не сработает или станет слишком дорогим

Самая частая причина провала DR - цели RTO/RPO берут «с потолка». Если бизнес не понимает, что означает «2 часа простоя» или «потеря 15 минут данных», требования либо занижают (и потом не успевают восстановиться), либо завышают (и переплачивают за инфраструктуру).

Вторая ошибка - путать RTO и RPO. RTO - про время восстановления сервиса, RPO - про потерю данных. Если перепутать, можно купить дорогую репликацию, но все равно восстанавливаться сутки из-за ручных шагов и отсутствия готового процесса.

Третья проблема - одинаковые цели для всех систем, как будто они одинаково важны.

Четвертая ошибка - игнорировать зависимости. «Восстановим ERP» звучит просто, пока не выясняется, что ей нужны AD, DNS, сетевые политики, сертификаты, хранилище, лицензии, ключи шифрования и учетные записи админов.

И, наконец, DR часто существует только на бумаге, потому что восстановление не тестируют. Бэкап без регулярной проверки восстановления - это надежда, а не план.

Короткий набор проверок, который обычно экономит и деньги, и нервы:

• Цели RTO/RPO подтверждены владельцем процесса и понятны в деньгах и рисках.
• Есть разные уровни для разных систем, а не один стандарт на всех.
• Зависимости и общий инфраструктурный слой перечислены и приоритизированы.
• Проводятся тесты восстановления по расписанию, фиксируются реальные результаты.
• Описаны доступы, ключи, контакты, шаги и ответственность (кто что делает в аварии).

Быстрые проверки: готова ли компания к DR

Чтобы быстро понять, есть ли у Disaster Recovery план шансы сработать, начните не со схем и железа, а с простых вопросов. Проблемы чаще в том, что никто не знает, что именно восстанавливать и в каком порядке.

Чек-лист за 30 минут

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

• Есть актуальный список систем с владельцами и ключевыми зависимостями (БД, AD, сеть, интеграции).
• Для каждой системы задана критичность и целевые RTO/RPO, понятные бизнесу.
• Зафиксирован порядок восстановления и «минимальный рабочий набор»: что должно подняться в первые часы.
• Есть отдельный сценарий киберинцидента: что делаем при шифровальщике и как защищены бэкапы (изоляция, неизменяемость, отдельные учетные данные).
• Запланированы тесты и назначены ответственные: кто запускает DR, кто подтверждает восстановление, кто общается с руководством.

Быстрый тест на реалистичность

Возьмите один сценарий: «не работает основной серверный зал» или «зашифрованы файловые ресурсы и часть виртуальных машин». Попросите команду назвать три вещи: какая система поднимается первой, где лежит последняя чистая копия данных и кто дает добро на переключение.

Если ответы расплывчатые, начните с матрицы приоритетов и минимального набора сервисов, а уже затем выбирайте архитектуру (бэкап, репликация, горячий или холодный резерв). Часто это дешевле, чем сразу строить максимально быстрый DR для всего.

Пример из практики и следующие шаги для внедрения

В пятницу в 10:15 в головном офисе отключили электричество. ИБП продержались только 12 минут, после чего упали виртуализация и часть сетевого оборудования. Формально «упал ЦОД», но для бизнеса это выглядело иначе: кассы и онлайн-оплаты не проходили, колл-центр не видел заявки, склад не мог отгружать.

Команда заранее утвердила матрицу критичности, поэтому восстановление пошло в понятном порядке: связь и доступ (VPN, AD/DNS), платежи и фронт продаж, база заказов и интеграции со складом, затем почта и внутренние порталы, а аналитика и витрины данных - последними.

Матрица полезна тем, что фиксирует компромиссы. Для платежей выбрали RTO 1 час и RPO 15 минут, для аналитики - RTO 24 часа и RPO 8 часов. В аварии никто не тратил время на спор «давайте сначала поднимем отчеты».

Дальше встал вопрос бюджета. Вариант «только бэкап» был дешевле по инфраструктуре, но дороже по простоям: восстановление баз из копий заняло бы 6-10 часов, плюс риск потери данных между бэкапами. Во втором варианте сделали репликацию только для части систем (платежи, заказы, каталог, AD), а для остального оставили бэкап. Это добавило затрат на второй контур, каналы и поддержку, зато критичные сервисы реально поднимались за 30-60 минут при RPO до 15 минут.

После теста важно зафиксировать фактические RTO/RPO по каждому сервису, что мешало (люди, доступы, пропускная способность, порядок действий) и что нужно изменить. Обычно хватает короткого отчета на 1-2 страницы и обновления runbook.

Дальнейшие шаги чаще всего такие:

1. короткий аудит зависимостей и данных
2. выбор целевой DR архитектуры под матрицу и бюджет
3. подбор площадки и оборудования, пилот на 1-2 критичных системах
4. регулярные тесты и обучение дежурных

Если вы строите DR-контур в локальной инфраструктуре, удобно привлекать интегратора, который одновременно закрывает проектирование, внедрение и поддержку. Например, GSE.kz как производитель и системный интегратор в Казахстане помогает собирать решения на собственной аппаратной базе (в том числе стойковые серверы S200) и сопровождать их 24/7, чтобы цели RTO/RPO подтверждались не на словах, а на учениях.