Когда бизнес говорит: «сайт не должен лежать больше часа», мы понимаем — это вопрос RTO?
И мы же отвечаем за то, чтобы зафиксировать договорённости с бизнесом и технически их обеспечить. Через полгода выясняется, что восстановление из последнего бекапа занимает 4 часа, а бизнес об этом не знал. RTO и RPO — это не технические характеристики, это договорённости, которые нужно зафиксировать и технически обеспечить. Мы, как сертифицированные специалисты по 1С-Битрикс с более чем 10-летним опытом, гарантируем, что ваши целевые показатели будут достигнуты при правильном подходе.
Типичный сценарий: для интернет-магазина с оборотом $9k–13k в день каждый час простоя обходится в $360–520. Снижение RTO с 4 часов до 10 минут может сэкономить до $1.4k–1.9k за один инцидент. Такие цифры мотивируют бизнес вкладываться в надёжность.
Что такое RTO и RPO применительно к Битрикс
RPO (Recovery Point Objective) — максимально допустимая потеря данных. Если RPO = 1 час, значит при катастрофе можно потерять не более часа транзакций: заказов, регистраций, изменений остатков.
RTO (Recovery Time Objective) — максимально допустимое время недоступности. Если RTO = 30 минут, значит через 30 минут после инцидента сайт должен работать.
Типичные значения для интернет-магазина на Битрикс: RPO = 1 час, RTO = 2 часа. Для highload-проектов: RPO = 5 минут, RTO = 15 минут. Чем жёстче требования — тем дороже инфраструктура.
Согласование RTO и RPO с бизнесом
Частая ошибка — инженеры сами устанавливают технические параметры, не спрашивая бизнес. В результате затраты на инфраструктуру могут оказаться неоправданными, или наоборот — бизнес терпит убытки из-за долгих простоев. Мы всегда начинаем с интервью с заказчиком: сколько вы теряете в час простоя? Какой объём данных критичен? Только после этого выбираем архитектуру.
Как рассчитать реальный RTO?
Время восстановления — это сумма всех шагов, а не только «восстановить базу»:
- Обнаружение инцидента — от 0 до 15 минут (зависит от мониторинга)
- Принятие решения о failover — 5–10 минут
- Восстановление/промоция БД — зависит от RPO-решения
- Смена конфигурации приложения — 2–5 минут
- Прогрев кешей — первые запросы после восстановления медленные, Redis/memcached пустые
- Проверка работоспособности — 5–10 минут
Пункт «прогрев кешей» часто игнорируется в расчётах RTO. После восстановления база принимает нагрузку с нуля: кеш Битрикс пустой, OPcache холодный. Первые 5–10 минут работы — пиковая нагрузка на БД. Если нет rate limiting, это может повалить только что поднятый сервер. ITIL recommends including detection time in RTO calculation.
Технические решения для разных уровней RPO
RPO = несколько часов. Достаточно ежечасного pg_dump во внешнее хранилище. Просто, дёшево, долго восстанавливается при больших базах.
RPO = минуты. Streaming replication PostgreSQL с синхронным режимом (synchronous_commit = on). Каждая транзакция подтверждается только после записи на реплику. Дополнительная задержка: +5–15 мс к каждой транзакции. Подробнее в документации PostgreSQL.
RPO = секунды. Patroni с синхронной репликацией + непрерывное архивирование WAL через archive_command в S3. При WAL-архивировании можно восстановить базу на любой момент времени (PITR — Point-in-Time Recovery).
# postgresql.conf для PITR archive_mode = on archive_command = 'aws s3 cp %p s3://backup-bucket/wal/%f' Технические решения для разных уровней RTO
RTO = несколько часов. Восстановление из pg_dump + деплой кода из git. Линейно зависит от размера базы: 10 ГБ — примерно 45–90 минут восстановления.
RTO = 30–60 минут. Standby-сервер с горячей репликой. При инциденте — ручной failover: промоция реплики, смена DNS или конфига приложения. Не автоматически, но быстро.
RTO = менее 10 минут. Автоматический failover через Patroni + HAProxy. Без участия человека. Требует предварительной настройки и регулярного тестирования.
Какой метод восстановления выбрать для вашего проекта?
Выбор зависит от бюджета и критичности данных. Сравните основные варианты:
| Метод | RPO типичный | RTO типичный | Сложность |
|---|---|---|---|
| pg_dump | 1 час | 2-4 часа | Низкая |
| Streaming replication | 1 мин | 1 час | Средняя |
| Patroni + WAL | 1 сек | 10 мин | Высокая |
Patroni с PITR обеспечивает RTO в 6 раз быстрее, чем восстановление из pg_dump.
Матрица решений для Битрикс
| Размер проекта | RPO | RTO | Инфраструктура |
|---|---|---|---|
| До 5k заказов/сутки | 1 час | 4 часа | pg_dump в S3, деплой из git |
| 5–50k заказов/сутки | 15 мин | 1 час | Streaming replica + ручной failover |
| Свыше 50k заказов/сутки | 1 мин | 10 мин | Patroni + HAProxy + WAL archiving |
Документирование и тестирование
RTO/RPO без задокументированного runbook — ничто. Runbook должен содержать точную последовательность команд для каждого сценария отказа: падение primary БД, падение веб-сервера, потеря /upload/, компрометация сервера.
# Пример раздела runbook: failover PostgreSQL (ручной) # 1. Проверить, что primary недоступен pg_isready -h primary.db -p 5432 # 2. Промотировать реплику ssh replica.db 'pg_ctl promote -D /var/lib/postgresql/data' # 3. Обновить конфиг Битрикс sed -i "s/primary.db/replica.db/" /var/www/bitrix/.settings.php # 4. Очистить кеш php /var/www/bitrix/bitrix/modules/main/cli/cache_clear.php Пример runbook для failover веб-сервера
При отказе веб-сервера: переключить балансировщик на резервный сервер, проверить сессии, перезапустить PHP-FPM.Что входит в работу по настройке RTO/RPO?
- Аудит текущей инфраструктуры и интервью с бизнесом для фиксации RPO/RTO
- Выбор и настройка решения (pg_dump, streaming replication, Patroni)
- Настройка WAL-архивирования для PITR при необходимости
- Создание детального runbook с командами восстановления
- Регламент тестирования и документация по эксплуатации
- Передача знаний команде заказчика (1–2 сессии)
Оценим ваш проект за два дня. Свяжитесь с нами для консультации — подберём решение под ключ. Более 50 проектов с критичными требованиями к доступности — наш опыт говорит сам за себя. Гарантируем прозрачность расчётов и работоспособность схемы. Закажите аудит текущей схемы восстановления.