Аварийное восстановление: RTO, RPO и game days

Аварийное восстановление (disaster recovery) — это дисциплина возврата всей системы к работе после катастрофы: потери региона, дата-центра или повреждения данных. В отличие от устойчивости в рантайме, которая маскирует отказ отдельных компонентов, DR работает с дискретными копиями всей системы, когда штатные механизмы уже не помогают.

Сердце дисциплины — два числа: целевое время восстановления (RTO) и целевая точка восстановления (RPO). Они выводятся из бизнес-impact: стоимости минуты простоя и ценности данных, которые можно потерять. Чем меньше RTO и RPO, тем дороже и сложнее решение — от backup&restore через pilot light и warm standby к active/active.

Но план восстановления стоит ровно столько, сколько подтверждено учением. Непроверенный бэкап — это гипотеза, а RTO на бумаге расходится с реальным переключением. Регулярные game days и DR-дни измеряют фактическое RTO секундомером, вскрывают забытые зависимости, дрейф конфигурации и риск split-brain до того, как случится настоящая катастрофа.

Практическая польза главы

Практика проектирования

Переводите знания о DR как дисциплина: целевые RTO/RPO, стратегии восстановления и регулярные game days в конкретные эксплуатационные решения: правила оповещений, границы операционных инструкций и стратегии отката.

Качество решений

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

Аргументация на интервью

Структурируйте ответ вокруг жизненного цикла надёжности: сигнал деградации, реакция, локализация причины, восстановление и профилактика повторов.

Формулировка компромиссов

Явно фиксируйте компромиссы по DR как дисциплина: целевые RTO/RPO, стратегии восстановления и регулярные game days: скорость релизов, уровень автоматизации, стоимость наблюдаемости и операционная сложность.

Источник

AWS Well-Architected

Reliability Pillar: планирование аварийного восстановления, цели RTO/RPO и стратегии.

Перейти на сайт

Отказоустойчивость в рантайме рассчитана на потерю узла. Когда исчезает целый регион или данные приходят повреждёнными во все реплики, штатные механизмы уже не помогают — и здесь начинается аварийное восстановление (): дисциплина возврата всей системы к работе после катастрофы. Это не то же самое, что устойчивость в рантайме (она маскирует отказ отдельных компонентов) и не то же, что управление инцидентами (координация людей во время сбоя). DR задаёт целевые и , выбирает стратегию под их стоимость и регулярно проверяет план в — game days.

Зачем: катастрофа против обычной отказоустойчивости

Потеря региона или дата-центра

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

Логическая порча данных

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

Шифровальщики и удаление

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

Чем DR отличается от устойчивости

Устойчивость в рантайме маскирует отказ отдельных компонентов и держит сервис в рамках . DR — про восстановление дискретных копий всей системы после катастрофы, когда штатные механизмы уже не помогают.

RTO и RPO: что именно мы обещаем

RTO

Целевое время восстановления

Recovery Time Objective

Максимально допустимая задержка между прерыванием сервиса и его восстановлением. Отвечает на вопрос «как быстро мы должны снова работать».

RPO

Целевая точка восстановления

Recovery Point Objective

Максимально допустимый объём данных, измеренный временем, который можно потерять. Отвечает на вопрос «сколько последних данных не страшно потерять».

Чем меньше и , тем меньше простой и потеря данных — но тем выше стоимость и сложность решения. Эти два числа не выбирают «по умолчанию ноль»: их задаёт влияние на бизнес. Стоимость минуты простоя и ценность данных, которые можно потерять, определяют, какую DR-стратегию вообще имеет смысл строить. Связь с деньгами легче всего увидеть на калькуляторе ниже.

Стратегии по стоимости и скорости (модель AWS)

AWS делит DR-подходы на четыре уровня — от дешёвого и медленного к дорогому и почти мгновенному. Первые два активны/пассивны (трафик идёт в основной регион, резервный ждёт переключения), последний работает во всех регионах сразу.

Резервная копия и восстановление

Backup & Restore

Данные периодически копируются в другой регион; инфраструктура и приложение разворачиваются заново при катастрофе через . Самый дешёвый вариант, но самое долгое восстановление.

RTO

часы

RPO

часы

Цена

минимальная

Дежурный огонёк

Pilot Light

Ядро данных непрерывно реплицируется, базовая инфраструктура существует, но прикладные серверы «выключены» и поднимаются только при .

RTO

десятки минут

RPO

минуты

Цена

низкая

Тёплый резерв

Warm Standby

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

RTO

минуты

RPO

секунды-минуты

Цена

средняя

Активный/активный мульти-сайт

Multi-Site Active/Active

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

RTO

близко к нулю

RPO

близко к нулю

Цена

высокая

Оценки / здесь качественные (порядок величины из документации AWS), а не гарантии конкретной системы — реальные числа зависят от объёма данных, лага репликации и автоматизации.

Калькулятор: во что обходятся RTO и RPO

Стоимость простоя ($/час)Целевое RTO (мин)Целевое RPO (мин)Ценность данных ($/мин)Катастроф в год (оценка)

Потери от простоя

$20 000

за 1 ч простоя

Потери данных

$22 500

за 15 мин окна

Ожидаемые потери в год

$85 000

Уровень под цели

Тёплый резерв

Модель: потери = RTO × цена_простоя + RPO × ценность_данных. Это упрощённая оценка порядка величины, чтобы сравнить бюджет на DR с ожидаемым ущербом, а не точный прогноз для конкретной системы.

Переключение на резерв и обратно: failover и failback

При активной/пассивной стратегии переключение на резерв (failover) и возврат (failback) — это два отдельных рискованных перехода. Между ними возможно расщепление кластера, если оба региона решат, что они главные.

Резервные копии: типы, 3-2-1 и защита от порчи

Сочетайте полные и инкрементальные копии: полная — опорная точка восстановления, инкрементальные между ними экономят место и сокращают окно бэкапа, но удлиняют цепочку восстановления.
Держите правило 3-2-1: три копии данных, на двух разных носителях, одна из них — вне площадки. Это базовый рубеж против локальной катастрофы (рекомендация CISA / US-CERT).
Защищайтесь от логической порчи и шифровальщиков: неизменяемые (immutable) копии, версионирование объектов и дают точку до момента повреждения, которую злоумышленник не сотрёт.
Изолируйте копии по доступу и аккаунту: бэкап, который удаляется теми же правами, что и боевые данные, не защищает от инсайдера и компрометации учётных данных.
Регулярно проверяйте именно восстановление, а не факт создания копии. Непротестированный бэкап — это гипотеза, а не план восстановления.

Данные: согласованность копий и RPO распределённых хранилищ

Различайте crash-consistent и application-consistent копии: снимок диска в произвольный момент похож на «выдернутый шнур». Для согласованного бэкапа БД нужны квисцентные снимки или копии через механизм самой СУБД.
В распределённом хранилище определяет лаг . Асинхронная репликация даёт больше нуля: всё, что не успело уехать в резервный регион, теряется при катастрофе источника.
У шардированных и многотабличных систем согласованная по времени копия требует общей точки: без неё разные шарды восстановятся в разные моменты и нарушат ссылок между ними.
Непрерывная репликация даёт почти нулевое окно потерь, но сама по себе не защищает от порчи — ошибка реплицируется так же быстро. Поэтому к репликации всегда добавляют копии на момент во времени (point-in-time).

Учения по отказу (game days) и DR-учения: проверять план, а не верить ему

Проводите и DR-дни регулярно: Google регулярно проводит DiRT (Disaster Recovery Testing), создавая контролируемые аварии без вреда для пользователей.
Измеряйте реальное целевое время восстановления (RTO) секундомером, а не цифру из документа. Учение показывает фактическое время до восстановления и расхождение с бумажной целью.
Держите актуальные -сценарии переключения и тренируйте по ним людей — план, который знает один человек в отпуске, не план.
Ловите дрейф конфигурации резервной площадки: со временем DR-регион отстаёт от боевого по версиям, квотам и секретам. Учение вскрывает это до настоящей аварии.

Компромиссы и частые ошибки

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

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

Забытые зависимости: , секреты, очереди, сторонние API или через операции , которые сами недоступны во время катастрофы.

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

Риск : оба региона одновременно считают себя главными и принимают записи — после восстановления связи данные конфликтуют.

Что взять с собой

Сформулируйте и от влияния на бизнес, а не «по умолчанию ноль» — это определяет бюджет.
Выберите стратегию (backup&restore → pilot light → warm standby → active/active) под эти цели и их стоимость.
Защитите копии от логической порчи: неизменяемость, версионирование, , изоляция доступа.
Регулярно проводите и измеряйте реальное секундомером, обновляя runbook-сценарии.
Продумайте failback и защиту от split-brain так же тщательно, как и само .

Источники и материалы

Карта источников: AWS Well-Architected и Prescriptive Guidance держат стратегии DR, цели RTO/RPO и практики резервного копирования; Google SRE Book — проверку надёжности через тестирование на отказ (disaster testing); CISA — базовую рамку резервного копирования 3-2-1. Конкретные RTO/RPO, стоимость простоя и стратегия восстановления должны выводиться из бизнес-риска и регулярно проверяться учением по отказу (game day), а не копироваться из таблицы.

Связанные главы

Управление инцидентами - Соседняя дисциплина реакции на инциденты: координация, роли и коммуникация, когда катастрофа уже случилась и план восстановления нужно исполнять.
Паттерны устойчивости - Устойчивость в рантайме: таймауты, ретраи, разрыватели цепи и переборки, которые маскируют локальные отказы до того, как они станут катастрофой.
Мульти-регион и глобальные системы - Как устроены кросс-региональная репликация и маршрутизация трафика, на которых стоят стратегии warm standby и active/active.
Инструменты хаос-инжиниринга - Инструментарий для контролируемых отказов и учений по отказу (game days), которым проверяют план восстановления и измеряют реальное время восстановления (RTO).