Честные RTO и RPO: как проектировать Disaster Recovery без самообмана

Disaster Recovery часто выглядит убедительно в документах: есть SLA, план восстановления, ответственные, бэкапы и красивые диаграммы. Проблема начинается в момент реального инцидента. Оказывается, терабайтный PostgreSQL разворачивается дольше, чем обещанный RTO, доступы устарели, инструкции не проверялись, а часть зависимостей вообще не попала в план.

Честный расчёт RTO и RPO важен потому, что отказоустойчивость нельзя проектировать только ожиданиями бизнеса. Её нужно приземлять на физику инфраструктуры, скорость восстановления и регулярные учения.

RTO и RPO простыми словами

RTO — это максимальное время, за которое сервис должен восстановиться после сбоя. Если RTO равен 4 часам, бизнес ожидает, что через 4 часа сервис снова работает.

RPO — это допустимая потеря данных. Если RPO равен 15 минутам, компания готова потерять не больше 15 минут изменений.

Обе метрики легко написать в документе. Но реальный вопрос другой: подтверждены ли они практикой?

Почему бумажный RTO обманывает

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

Честный RTO складывается из всех этапов:

• обнаружение инцидента;
• принятие решения о восстановлении;
• подготовка инфраструктуры;
• разворачивание backup;
• применение WAL/binlog;
• проверка данных;
• переключение трафика;
• smoke tests;
• коммуникация с пользователями.

Если считать только копирование backup, получится самообман.

RPO зависит от частоты и качества данных

RPO тоже не равен частоте бэкапа. Если backup делается раз в час, но последние успешные проверки восстановления были месяц назад, уверенности мало. Если WAL архивируется, но при сбое обнаруживается дырка в цепочке, фактический RPO станет хуже.

Нужно проверять:

• что backup реально создаётся;
• что он восстанавливается;
• что данные консистентны;
• что журналы применяются;
• что восстановленная система проходит проверки;
• что процедура не зависит от одного человека.

DR-учения

Disaster Recovery без учений — это теория. Учения показывают, где план расходится с реальностью: не хватает прав, инструкция устарела, DNS переключается дольше, backup лежит не там, мониторинг молчит, а команда не понимает порядок действий.

Хорошие DR-учения должны быть безопасными, но максимально близкими к реальности. Не обязательно сразу выключать production. Можно начать с восстановления в изолированном окружении и измерить фактическое время каждого шага.

Стоимость простоя

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

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

Что мониторить

Для контроля DR нужны не только alerts по сервису, но и метрики готовности к восстановлению:

• возраст последнего успешного backup;
• время последнего тестового restore;
• размер backup;
• скорость восстановления;
• lag репликации;
• доступность backup storage;
• ошибки архивирования WAL/binlog;
• статус standby-инфраструктуры;
• срок действия credentials и сертификатов.

Если эти параметры не мониторятся, команда узнает о проблеме слишком поздно.

Практический чеклист

Для каждого критичного сервиса стоит ответить:

1. Где лежат backup и кто имеет доступ?
2. Когда последний раз выполнялся restore?
3. Сколько времени он занял?
4. Какие зависимости нужны для запуска?
5. Как переключается трафик?
6. Какие данные можно потерять?
7. Кто принимает решение о failover?
8. Где инструкция и кто её проверял?
9. Какие метрики подтверждают готовность?
10. Что будет, если основной регион недоступен?

Итог

Честные RTO и RPO — это не числа в SLA, а результат измерений. Их нужно подтверждать восстановлением, мониторингом и учениями. Иначе Disaster Recovery превращается в документ, который хорошо выглядит до первого серьёзного сбоя.

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