Аварийное восстановление интернет-магазина: что такое RTO и RPO, план восстановления и ежегодные учения

Классификация RTO/RPO при аварийном восстановлении и четырёхшаговый процесс ежегодных учений

Аварийное восстановление интернет-магазина: что такое RTO и RPO, план восстановления и ежегодные учения

Сначала вывод: Два ключевых показателя аварийного восстановления — это RTO (целевое время восстановления) и RPO (целевая точка восстановления). Для большинства B2B-сайтов разумные значения — RTO 4 часа и RPO 4 часа; не нужно стремиться к доступности 99,99% — это требование уровня электронной коммерции и платёжных систем, а затраты растут экспоненциально. Процесс восстановления состоит из четырёх шагов: переключить трафик на резервный сервер, восстановить базу данных и файлы из резервной копии, проверить работу форм заявок и доставку почты, затем переключиться обратно на основной сайт. Учения проводятся не реже одного раза в год с замером времени; если фактические RTO/RPO превышают целевые, план нужно пересматривать.

1. RTO и RPO: сначала определите, сколько данных вы готовы потерять и сколько времени — простоять

RTO (Recovery Time Objective, целевое время восстановления) — это максимально допустимое время от сбоя до возобновления обслуживания. RPO (Recovery Point Objective, целевая точка восстановления) — это допустимый объём потерянных данных за период до восстановления. Как только эти два числа определены, определяются и частота резервного копирования, и затраты на аварийное восстановление — это компромисс между стоимостью и доступностью.

Контринтуитивный вывод: для B2B-сайта стремление к доступности 99,99% — это избыточные вложения. У B2B-сайтов небольшая посещаемость, заявки приходят в основном по почте и через формы, и разница между простоем в 4 часа и в 1 час на бизнес практически не влияет; но разница в стоимости аварийного восстановления огромна — чтобы достичь RTO 15 минут, нужны два активных дата-центра и синхронизация баз данных в реальном времени, а ежемесячные затраты в 5–10 раз выше, чем у схемы с одним дата-центром.

Тип сайта	Целевое RTO	Целевое RPO	Доступность	Схема аварийного восстановления
Сайт с ключевыми заявками	≤1 часа	≤15 минут	99,9%	Резервный сервер в другом регионе + синхронизация binlog в реальном времени
Обычный B2B-сайт	≤4 часов	≤4 часов	99,5%	Один дата-центр + ежедневное резервное копирование + восстановление в другом регионе
Блог/контентный сайт	≤24 часов	≤24 часов	99%	Еженедельное резервное копирование + ручное восстановление
Сайт электронной коммерции/платежей	≤15 минут	≤1 минуты	99,99%	Мультиактивная схема + синхронизация в реальном времени (очень дорого)

Пример из практики: сайт промышленного оборудования для выхода на зарубежные рынки, около 30 заявок в месяц, средний чек 500 000 юаней. При простое в 4 часа, исходя из плотности заявок, будет упущено примерно 1–2 заявки — потери ограничены. Для такого сайта достаточно одного дата-центра с ежедневным резервным копированием, RTO 4 часа и RPO 4 часа, а ежемесячные затраты на аварийное восстановление — менее 200 юаней. Если же навязать мультиактивную схему, дополнительные 2000 юаней в месяц за доступность не дадут измеримой отдачи для бизнеса.

Чтобы определить, к какой категории относится ваш сайт, сначала посмотрите на месячное количество заявок и средний чек: если заявок более 100 в месяц и средний чек ниже 10 000, сайт ближе к электронной коммерции, и RTO нужно снижать до 1 часа; если заявок менее 30 в месяц и средний чек выше 100 000, сайт ближе к проектному типу, и RTO 4 часа вполне приемлемо.

2. План восстановления: четыре шага, запишите заранее

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

Стандартный план восстановления состоит из четырёх шагов. Шаг первый — переключить трафик: перевести DNS или CDN на IP резервного сервера. Шаг второй — восстановить данные: выгрузить последнюю резервную копию из удалённого объектного хранилища, восстановить файлы и базу данных. Шаг третий — проверить: пройти по главной странице, списку товаров, отправке формы запроса, доставке письма. Шаг четвёртый — уведомить заинтересованных: отдел продаж, поддержку и руководство — сообщить время восстановления сайта. Особый порядок восстановления после взлома описан в После взлома сайта.

Шаг	Действие	Руководитель	Ожидаемое время	Критерии приёмки
1. Подтверждение сбоя	Сработал алерт мониторинга, основной сайт недоступен	Дежурный инженер	5 минут	3 неудачные проверки подряд
2. Переключение трафика	DNS TTL снижен до 60 секунд, переключение на IP резервного сервера	Техническое обслуживание	10 минут	DNS обновлён по всему миру
3. Восстановление данных	Выгрузка резервной копии из S3, восстановление файлов и базы данных	Техническое обслуживание	1–2 часа	Сайт доступен
4. Проверка функций	Пройти по главной странице, страницам товаров и форме запроса	Инженер + продажи	30 минут	Письмо с формы приходит
5. Уведомление	Продажи и поддержка знают, что сайт восстановлен	Руководитель маркетинга	10 минут	Уведомление отправлено в чат
6. Разбор	Отчёт об инциденте в течение 24 часов	Технический руководитель	1 рабочий день	Первопричина и план улучшений

Пример из практики: в 3 часа ночи у зарубежного сайта сработал алерт, главная страница отдаёт 502. Дежурный инженер действует по плану. Первый шаг — подтверждает, что упал MySQL, перезапуск не помогает. Второй шаг — переключает DNS на резервный сервер, TTL заранее выставлен в 60 секунд, через 10 минут обновление разошлось по всему миру. Третий шаг — выгружает из S3 вчерашнюю вечернюю резервную копию и восстанавливает базу данных, уходит 40 минут. Четвёртый шаг — отправляет тестовый запрос с телефона, письмо приходит через 30 секунд. Пятый шаг — пишет в чат отделу продаж; к 8 утра сайт уже работает. Весь процесс занял около часа по RTO и около 6 часов по RPO — в рамках целей плана.

Подробнее о том, как DNS-переключение работает вместе с CDN, читайте в Глобальное ускорение CDN в разделе о переключении при отказе узла. Переезд на новый домен и передача через 301 устроены похожим образом, читайте в Реструктуризация сайта и смена домена.

3. Резервный сервер и холодный резерв: не всегда нужна двойная активность

Схемы аварийного восстановления делятся на три уровня: холодный резерв, тёплый резерв и двойная активность. Холодный резерв — это только резервные копии: после сбоя временно поднимают сервер и восстанавливают данные. Тёплый резерв — резервный сервер постоянно включён и простаивает, данные синхронизируются асинхронно. Двойная активность — два дата-центра одновременно принимают трафик и синхронизируются в реальном времени. Стоимость растёт от низкой к высокой, а RTO сокращается от долгого к короткому.

Большинству независимых B2B-сайтов достаточно сочетания холодного и тёплого резерва: резервный сервер постоянно включён, но не принимает трафик, данные синхронизируются раз в сутки, после сбоя достаточно переключить DNS — RTO укладывается в 1–2 часа. Двойная активность для одного человека или небольшой команды — избыточные вложения, а сложность эксплуатации такая, что её не потянуть.

Подход	Состояние резерва	RTO	Прирост месячных затрат	Для чего подходит
Холодный резерв	Резервного сервера нет, только копии	4–8 часов	0 ₽	Блоги, контентные сайты
Тёплый резерв	Резервный сервер постоянно включён, синхронизация раз в сутки	1–2 часа	Около 300–500 юаней	Основные B2B-сайты с запросами
Горячий резерв	Резервный сервер всегда включён, синхронизация в реальном времени	15–30 минут	около 1500–3000 ₽	Основной бизнес-сайт
Активный-активный	Оба сервера работают одновременно	Секунды	от 5000 ₽	Интернет-магазины, платежи

Контринтуитивное напоминание: переключение DNS происходит не мгновенно. Даже если TTL выставлен в 60 секунд, глобальное распространение DNS занимает 5–15 минут, а локальный кэш DNS у части пользователей будет держать старый адрес ещё несколько часов. Поэтому перед переключением трафика настройтесь на переходный период: после переключения не все сразу попадут на резервный сервер. В плане нужно чётко прописать: «После переключения DNS подождать 15 минут, затем проверить доступность по всему миру».

4. Ежегодные учения: прогоните план и найдите слабые места

Главный риск плана аварийного восстановления — «написано, значит сделано». В документе всё расписано красиво, а при реальной аварии выясняется, что пароль от резервного сервера неизвестен, резервную копию не скачать, а настройки SMTP жёстко прописаны на старом сервере. Эти проблемы выявляются только на практике.

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

Этап учений	Что проверяем	Частая проблема	Что улучшить
Доступность резервных копий	Распаковывается ли последняя копия из S3	Повреждён gzip, истёк срок ключа	Добавить проверку целостности копий
Запуск резервного сервера	Поднимается ли резервный сервер за 5 минут	Резервный сервер давно не включали, ПО устарело	Запускать резервный сервер раз в месяц
Переключение DNS	Действительно ли TTL равен 60 секундам	Забыли заранее снизить TTL	Зафиксировать TTL на 60 секундах
Восстановление базы данных	Корректно ли отображается кириллица после импорта	Ошибка кодировки, кракозябры	Зафиксировать кодировку в скрипте восстановления
Письма с формы	Приходит ли тестовая заявка после отправки	Пароль SMTP жёстко прописан в старой конфигурации	Хранить SMTP в переменных окружения
Готовность людей	Можно ли связаться с дежурным	Не провели передачу дел при увольнении	Обновлять контакты раз в квартал

Пример из практики: команда впервые проводит ежегодные учения — по плану скачивает резервную копию, восстанавливает базу данных, открывает сайт, первые 40 минут всё идёт гладко. На этапе проверки формы заявки после отправки письмо не приходит полдня — оказалось, пароль SMTP прописан в wp-config.php, а почтовый сервис на старом сервере давно остановлен. Если бы это выяснилось во время реальной аварии, пришлось бы потратить ещё час на поиск причины. Ценность учений в том, что они заранее выявляют такие слабые места.

Подробная настройка стратегии резервного копирования описана в Бэкап и восстановление сайта, пороги мониторинга и оповещений — в Мониторинг сайта и оповещения, список ежедневных задач — в Шесть задач на месяц в период обслуживания сайта.

FAQ: частые вопросы

Что такое RTO и RPO и как их определить?

RTO — это целевое время восстановления: максимально допустимый срок от сбоя до возобновления работы сервиса. RPO — это целевая точка восстановления: какой объём данных допустимо потерять после восстановления. Для B2B-сайта рекомендуем RTO 4 часа и RPO 4 часа — этой конфигурации достаточно для проектного бизнеса с высокой ценой заказа и примерно 30 заявками в месяц. Если заявок больше 100 в месяц и бизнес ближе к электронной коммерции, RTO сокращают до 1 часа. Чем короче RTO, тем экспоненциально выше затраты, поэтому не стоит слепо гнаться за доступностью 99,99%.

Нужна ли B2B-сайту схема с двумя активными центрами обработки данных?

В большинстве случаев нет. Два активных ЦОД — это когда оба одновременно обслуживают трафик и синхронизируют базы данных в реальном времени. Стоит это от 5000 рублей в месяц, а сложность эксплуатации для одного человека или небольшой команды — настоящая катастрофа. Гораздо выгоднее схема с тёплым резервом: резервный сервер постоянно включён, но трафик не принимает, данные синхронизируются раз в сутки, а после аварии достаточно переключить DNS. RTO укладывается в 1–2 часа, а ежемесячные затраты растут всего на 300–500 рублей. Схему с горячим резервом или двумя активными ЦОД стоит рассматривать только для интернет-магазинов, платёжных сервисов и сайтов с сотнями заявок в месяц.

Как написать план аварийного восстановления и насколько подробным он должен быть?

Он должен быть написан вплоть до командной строки. Включите в него: критерии сбоя (три неудачных проверки подряд считаются аварией), конкретные шаги переключения DNS и время ожидания, из какого бакета S3 брать какой бэкап, полные команды восстановления базы данных, чек-лист проверки (главная страница, страницы товаров, форма заявки, доставка почты), список контактов с телефонами и шаблон отчёта о разборе. Не пишите расплывчатое «связаться с эксплуатацией» — указывайте конкретные имена и запасных контактов. Храните план в двух местах: в менеджере паролей и в облачном диске. Не оставляйте его только на том сервере, который вышел из строя.

Как проводить ежегодные учения и нужно ли останавливать сайт?

Проводите их в тестовой среде, не останавливайте основной сайт. Порядок такой: разверните последний бэкап в тестовой среде и полностью пройдите процесс восстановления — от распаковки файлов и импорта базы данных до настройки nginx, открытия сайта, отправки тестовой заявки и получения письма. Замеряйте время на каждом этапе. Сравните фактическое время с целевым RTO из плана: если превышает — пересматривайте схему. Назначайте учения на воскресенье ранним утром, в часы минимальной нагрузки, не реже одного раза в год. Новые сотрудники обязаны пройти учения в течение полугода после выхода на работу.

Сколько времени занимает переключение DNS и почему после переключения пользователи всё ещё заходят на старый сайт?

Даже при TTL 60 секунд глобальное обновление DNS занимает от 5 до 15 минут, а локальный кэш DNS у части пользователей будет держать старый адрес ещё несколько часов. Это нормально, а не ошибка настройки. Перед переключением трафика заранее снизьте TTL до 60 секунд (лучше держать его на этом уровне постоянно, а не ждать аварии). После переключения подождите 15 минут и только потом проверяйте доступность по всему миру. Одновременно предупредите отдел продаж и поддержку: часть пользователей может ещё заходить на старый сайт — это переходный период.

Одинаков ли процесс восстановления после взлома и после отказа оборудования?

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

В заключение

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

Три шага к внедрению. Первый: исходя из месячного числа заявок и среднего чека определите RTO/RPO — большинству B2B-сайтов хватает 4 часов, не гонитесь за завышенными цифрами. Второй: напишите план восстановления на уровне командной строки и храните его в двух местах — в менеджере паролей и в облаке. Третий: раз в год проводите полное учение в тестовой среде, фиксируйте фактические RTO/RPO и, если они превышают целевые, пересматривайте план. Только пройдя эти три шага, вы будете знать, за сколько реально поднимется ваш сайт после аварии.

Запомните одну фразу: RTO — не «чем выше, тем лучше»; разница в стоимости аварийного резервирования между 4 часами и 15 минутами — десятикратная. Сначала посчитайте, сколько именно вы теряете за 4 часа простоя, и уже потом решайте, до какого уровня вам нужно резервирование.