Вибираємо RTO/RPO для 1С-Бітрікс: від інтерв'ю до runbook
Коли бізнес каже: «сайт не має лежати більше години», ми розуміємо — це питання 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 рекомендує враховувати час виявлення в розрахунку RTO.
Технічні рішення для різних рівнів 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 проектів з критичними вимогами до доступності — наш досвід говорить сам за себе. Гарантуємо прозорість розрахунків та працездатність схеми. Замовте аудит поточної схеми відновлення.