Налаштування RTO/RPO для проекту 1С-Bitrix
Бізнес каже: «сайт не має бути недоступним більше години». Інженер киває і йде налаштовувати репліку. Через півроку виявляється, що відновлення з останньої резервної копії займає 4 години, а бізнес про це не знав. RTO та RPO — це не технічні характеристики, це угоди з бізнесом, які потребують фіксації та технічного забезпечення.
Що таке RTO та RPO стосовно Bitrix
RPO (Recovery Point Objective) — максимально допустима втрата даних. Якщо RPO = 1 година, то при катастрофі можна втратити не більше однієї години транзакцій: замовлень, реєстрацій, змін залишків.
RTO (Recovery Time Objective) — максимально допустимий час недоступності. Якщо RTO = 30 хвилин, то через 30 хвилин після інциденту сайт має працювати.
Типові значення для інтернет-магазину на Bitrix: RPO = 1 година, RTO = 2 години. Для highload-проектів: RPO = 5 хвилин, RTO = 15 хвилин. Чим жорсткіші вимоги — тим дорожча інфраструктура.
Технічні рішення для різних рівнів RPO
RPO = кілька годин. Достатньо щогодинного pg_dump у зовнішнє сховище. Просто, дешево, але довго відновлюється для великих баз.
RPO = хвилини. Streaming replication PostgreSQL з синхронним режимом (synchronous_commit = on). Кожна транзакція підтверджується лише після запису на репліку. Вартість: +5–15 мс на кожну транзакцію.
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. Без участі людини. Потребує попередньої налаштування та регулярного тестування.
Матриця рішень для Bitrix
| Розмір проекту | RPO | RTO | Інфраструктура |
|---|---|---|---|
| До 5k замовлень/день | 1 година | 4 години | pg_dump в S3, розгортання з git |
| 5–50k замовлень/день | 15 хв | 1 година | Streaming replica + ручний failover |
| Понад 50k замовлень/день | 1 хв | 10 хв | Patroni + HAProxy + WAL архівування |
Розрахунок реального RTO: що входить у час відновлення
Час відновлення — це сума всіх кроків, а не тільки «відновити базу»:
- Виявлення інциденту — від 0 до 15 хвилин (залежить від моніторингу)
- Прийняття рішення про failover — 5–10 хвилин
- Відновлення/підвищення рівня БД — залежить від RPO-рішення
- Зміна конфігурації програми — 2–5 хвилин
- Прогрів кешів — перші запити після відновлення повільні, Redis/memcached порожні
- Перевірка працездатності — 5–10 хвилин
Пункт «прогрів кешів» часто ігнорується в розрахунках RTO. Після відновлення база приймає навантаження з нуля: кеш Bitrix порожний, OPcache холодний. Перші 5–10 хвилин роботи — пікове навантаження на БД. Без rate limiting це може завалити щойно піднятий сервер.
Документування та тестування
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. Оновити конфіг Bitrix
sed -i "s/primary.db/replica.db/" /var/www/bitrix/.settings.php
# 4. Очистити кеш
php /var/www/bitrix/bitrix/modules/main/cli/cache_clear.php
Що налаштовуємо
- Визначення цільових RPO та RTO спільно з бізнесом
- Вибір та налаштування інфраструктурного рішення під задані параметри
- WAL-архівування для PostgreSQL PITR при RPO < 15 хвилин
- Runbook з командами відновлення для кожного сценарію відказу
- Регламент тестування: щоквартально піднімаємо з резервної копії, вимірюємо реальний RTO