Расчет реального RTO и RPO: метод HSTX для проверки плана восстановления

Андрей Отинов -

Представьте ситуацию: в договоре с клиентом или во внутреннем регламенте записано, что при аварии сервис должен восстановиться за 4 часа. Инженеры кивают: «Да, бэкап базы данных разворачивается за 2 часа, мы укладываемся». Но когда происходит реальный инцидент, выясняется, что терабайтный архив физически не успевает распаковаться из-за ограничений дисковой подсистемы, а команда тратит еще несколько часов на поиск причин, настройку окружения и переключение трафика. В итоге простой длится 8–10 часов, бизнес теряет деньги, а доверие к IT-отделу падает.

Источник: Habr

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

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

Что на самом деле скрывается за аббревиатурами RTO и RPO

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

RPO (Recovery Point Objective) — это максимально допустимый объем потери данных, выраженный во времени. Простыми словами: насколько «старой» может быть копия данных, к которой мы откатимся после сбоя. * Пример: Если база данных резервируется один раз в сутки, ровно в полночь, а сервер выходит из строя в 23:59 следующего дня, то реальный RPO составляет почти 24 часа. Все транзакции, заказы или изменения, внесенные за этот день, будут потеряны. Для интернет-магазина это катастрофа, для внутреннего архива документов — возможно, приемлемый риск.

RTO (Recovery Time Objective) — это целевое время, за которое сервис должен снова стать доступным для пользователей или смежных систем после аварии. * Важное уточнение: RTO — это не только время, за которое технический специалист нажимает кнопку «Восстановить из бэкапа». Это общее время простоя, которое видит бизнес.

Главная ошибка, которую допускают компании, — путать RTO со временем чисто технического восстановления данных. Если дамп базы PostgreSQL весом 500 ГБ разворачивается на тестовом стенде за 2 часа, это не значит, что RTO компании равен 2 часам. В реальности к этим двум часам добавляются этапы, которые невозможно пропустить.

Из чего складывается «честное» время восстановления

Опыт HSTX показывает, что реальное время восстановления (Real RTO) — это сумма нескольких последовательных этапов. Если исключить хотя бы один из них из расчетов, план окажется нерабочим.

Формула честного RTO выглядит так:

  1. Время обнаружения аварии. Система мониторинга должна заметить сбой, а дежурный инженер — получить оповещение. Это может занять от 5 минут до часа, в зависимости от настроек алертов.
  2. Время принятия решения. Команда должна собраться (онлайн или офлайн), оценить масштаб проблемы и подтвердить, что требуется именно восстановление из бэкапа, а не быстрый перезапуск сервиса.
  3. Подготовка инфраструктуры. Нужно развернуть чистые серверы, настроить операционную систему, обеспечить сетевую связность. Если используется облако, это может быть быстро; если свое железо — дольше.
  4. Восстановление данных и сервисов. Тот самый этап, который обычно считают единственным. Распаковка архива, импорт данных в базу.
  5. Настройка конфигураций и секретов. Сервис не заработает, пока не будут прописаны пароли, ключи API, пути к файлам и другие настройки, которые часто хранятся отдельно от самих данных.
  6. Проверка работоспособности (валидация). Инженеры должны убедиться, что данные не повреждены, связи между таблицами целы, а приложение корректно читает информацию.
  7. Переключение трафика. Направление пользователей с заглушки или старого сломанного адреса на восстановленный сервис. Обновление DNS-записей может занимать время.
  8. Прогрев системы. После запуска кэши пусты, соединения с базой еще не установлены в полном объеме. Первые минуты или часы сервис может работать медленно, пока не выйдет на штатную производительность.

Если сложить эти этапы, картина меняется. Допустим, само восстановление данных занимает 2 часа. Но добавьте к этому: * 20 минут на диагностику; * 40 минут на подготовку окружения; * 30 минут на раскатку конфигов; * 40 минут на проверку целостности данных; * 10–20 минут на переключение сетевого трафика.

Итого: вместо заявленных 2 часов реальный простой составит около 4–5 часов. А если база весит не 500 ГБ, а несколько терабайт, и диски работают медленно, то 2 часа превращаются в 8, а общий простой — в 10–12 часов. Именно такой разрыв между «бумажным» SLA и реальностью приводит к конфликтам с бизнесом.

Почему одинаковые требования для всех систем — это дорого и опасно

Еще одна распространенная ошибка — устанавливать жесткие нормативы восстановления (например, RTO < 15 минут) для всех информационных систем компании подряд.

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

Минимальный RTO (быстрое восстановление) требует сложной и дорогой архитектуры: * Постоянной репликации данных на备用ные (standby) серверы. * Автоматического переключения (failover) без участия человека. * Избыточных каналов связи и мощностей. * Регулярных дорогостоящих учений.

Если применить такую архитектуру ко всем системам, бюджет на IT вырастет многократно. Опыт HSTX подсказывает другой подход: сегментировать системы по критичности. * Критичные системы (продажи, биллинг, основной сайт): высокий бюджет на отказоустойчивость, низкий RTO/RPO. * Вспомогательные системы (внутренние порталы, архивы, тестовые среды): допустим более длительный простой и потеря данных за последние сутки. Здесь можно использовать простые ночные бэкапы и ручное восстановление.

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

Главная причина провалов: план, который никогда не проверялся

Самый опасный миф в управлении инфраструктурой — «У нас всё хорошо, потому что бэкапы делаются регулярно». Наличие файла с резервной копией на диске не гарантирует, что из него можно восстановиться.

План Disaster Recovery, который ни разу не был проверен на практике, — это не план, а гипотеза. Его реальная эффективность становится понятна только в момент настоящей аварии, когда цена ошибки максимальна, а стресс команды зашкаливает.

Проблемы, которые вскрываются только при тестовом восстановлении: * Бэкап оказался битым или неполным. * Инструкция по восстановлению устарела: сменились версии ПО, пути к файлам или пароли. * У сотрудника, который знает, как восстанавливать систему, нет доступа в нужный момент (болезнь, отпуск, увольнение). * Оборудование для восстановления занято другими задачами или его просто не хватает.

HSTX подчеркивает: регулярные учения (DR-drills) — это единственный способ превратить гипотезу в рабочий инструмент. При этом учения должны быть безопасными: проводиться на изолированном контуре, чтобы не задеть работающий продакшн, но максимально приближенными к реальности.

Чек-лист: как проверить свой план восстановления за неделю

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

1. Пересчитайте RTO с учетом всех этапов

Возьмите текущий норматив восстановления для ключевой системы. Спросите инженеров: «Сколько времени занимает каждый из 8 этапов, описанных выше?». Зафиксируйте ответы. Сравните сумму с заявленным в SLA значением. Если сумма превышает норматив — у вас есть риск, который нужно либо устранить (ускорить процессы), либо признать (изменить SLA).

2. Проверьте актуальность инструкций

Найдите документ с инструкцией по восстановлению. Попросите сотрудника, который не писал эту инструкцию, попробовать восстановить тестовую копию системы, строго следуя тексту. Если он застрял, начал звонить коллегам или гуглить решения — инструкция нерабочая. Её нужно обновить.

3. Оцените скорость чтения с дисков

Проведите замеры: как быстро ваша система хранения данных может прочитать большой объем информации (например, 1 ТБ)? Часто узким местом становится не процессор, а пропускная способность дисковой подсистемы. Если диски медленные, никакой софт не поможет уложиться в короткий RTO.

4. Разделите системы по критичности

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

5. Назначьте ответственных за учения

Внедрите правило: раз в квартал (или чаще для критичных систем) проводится тестовое восстановление. Результат учения — не просто галочка, а отчет: сколько времени заняло восстановление, какие возникли проблемы, что нужно исправить в документации или архитектуре.

Источники

Материал подготовлен на основе открытой публикации компании HSTX (Хайстекс) на платформе Habr, где подробно разбирается техническая сторона проектирования отказоустойчивости и приводятся примеры расчета метрик.

Что почитать дальше