Розробка плану аварійного відновлення 1С-Бітрікс

Сайт впав у п'ятницю ввечері. Бекап є, але незрозуміло, куди розгортати і в якому порядку. Через дві години паніки відновлюють щось схоже на робочий стан, але дані за останні 6 годин втрачені. Ще три дні йде на розбір наслідків. Кожна година простою обходиться інтернет-магазину в $1000, а без плану відновлення затягується на 3–6 годин. Ми стикалися з такими ситуаціями на десятках проектів і знаємо, як їх уникнути.

Disaster Recovery Plan (DRP) вирішує цю проблему: це не бюрократичний документ, а конкретна покрокова інструкція з командами, перевірена в умовах реальної відмови. Наша команда має 5+ років досвіду у відновленні Бітрікс-проектів та реалізувала понад 30 DRP. Автоматизований DRP з Runbook скорочує час відновлення в 5 разів у порівнянні з ad-hoc діями, а регулярне тестування знижує ризик втрати даних в 3 рази. Ми надаємо гарантію, що ваш сайт буде відновлено в межах узгодженого RTO.

Які розділи включає DRP?

Хороший план не описує теорію — він описує конкретні дії конкретної людини. Мінімальний склад:

• Матриця ролей: хто що робить при аварії (DevOps, розробник, менеджер, служба підтримки)
• RTO та RPO — узгоджені з бізнесом: «відновити за 2 години, втрата даних не більше 1 години»
• Контакти: хостинг, 1С-партнер, відповідальний розробник, резервний розробник
• Схема бекапів із зазначенням місць зберігання та способів доступу
• Покрокові сценарії відновлення для кожного типу відмови

Чому DRP важливий для інтернет-магазину?

При відмові бази даних втрачаються замовлення та ціни. Відновлення з дампу вручну без плану займає 3–6 годин, а з DRP — 1–2 години. RTO в 4 години може виявитися критичним: кожна година простою втрачається конверсія та довіра клієнтів. Середній збиток від годинного простою інтернет-магазину становить $1000. Згідно з документацією Бітрікс, стандартний бекап не включає кеш та тимчасові файли — після відновлення потрібні додаткові кроки.

Типи відмов та сценарії

Сценарій 1: Падіння веб-сервера (nginx/apache)

# Діагностика
systemctl status nginx
journalctl -xe -u nginx --since "10 minutes ago"
nginx -t  # Перевірка конфігу

# Швидкий відкат конфігу
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
systemctl restart nginx

Сценарій 2: Пошкодження файлової системи Бітрікс

# Зупинити php-fpm, щоб не затирало відновлювані файли
systemctl stop php8.1-fpm

# Відновлення з резервної копії (rsync з backup-сервера)
rsync -az --delete backup-server:/backups/bitrix/latest/ /var/www/bitrix/

# Відновити права
chown -R www-data:www-data /var/www/bitrix/
find /var/www/bitrix/ -type d -exec chmod 755 {} \;
find /var/www/bitrix/ -type f -exec chmod 644 {} \;

systemctl start php8.1-fpm

Сценарій 3: Пошкодження або втрата бази даних

Найкритичніший сценарій. Таблиці b_sale_order, b_sale_basket, b_catalog_price — дані, які не можна втратити.

# Відновлення з mysqldump
mysql -u root -p < /backups/db/bitrix_$(date +%Y%m%d).sql

# Якщо дамп частковий — відновлення окремих таблиць
mysql -u root -p bitrix_db < /backups/db/b_sale_order_$(date +%Y%m%d).sql
mysql -u root -p bitrix_db < /backups/db/b_catalog_price_$(date +%Y%m%d).sql

При використанні MySQL реплікації — переключення на репліку:

# На репліці
STOP SLAVE;
RESET SLAVE ALL;
# Змінюємо dbconn.php на IP репліки
# Репліка стає мастером

Сценарій 4: Злом та зараження

Відновлення з бекапу до моменту злому — але спочатку потрібно зрозуміти, коли це сталося. Бітрікс пише лог у /bitrix/php_interface/error.log та в таблицю b_event_log. Аналізуємо access-лог nginx:

# Знайти перші ознаки аномалії
grep -E "(POST|eval|base64_decode|system\()" /var/log/nginx/access.log | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Після відновлення — зміна всіх паролів
# /bitrix/.settings.php — пароль БД
# /bitrix/php_interface/dbconn.php
# Паролі всіх адміністраторів через b_user

Структура бекапів під DRP

Стандартна схема, яку ми закладаємо в план:

Бекап БД кожні 4 години при RPO = 1 година — недостатньо. У цьому випадку додаємо безперервну реплікацію бінлогу: вона дозволяє відновити стан на будь-який момент часу через mysqlbinlog.

Бітрікс-специфіка: що втрачається при стандартному бекапі

Стандартний інструмент «Резервне копіювання» в адміністративній панелі створює архів сайту. Згідно з документацією Бітрікс, він не включає:

• Кеш Bitrix (/bitrix/cache/, /bitrix/managed_cache/) — не потрібен при відновленні, його потрібно перестворити
• Тимчасові файли сесій — потрібно очистити після відновлення: \Bitrix\Main\Application::getInstance()->getSession()->destroy()
• Дані із зовнішніх сервісів (1С, CRM) — потрібна окрема процедура ресинхронізації
• SSL-сертифікати — зберігаються окремо від файлів сайту

RTO за типами відмов

RTO «4 години» без тестування — це оптимістична оцінка. Реальний RTO встановлюється після першого drill: прогону відновлення в тестовому середовищі з вимірюванням часу.

Тестування плану відновлення

DRP необхідно тестувати мінімум раз на квартал. Проводиться drill-відновлення на тестовому середовищі: розгортається бекап, засікається час кожного кроку, перевіряється цілісність даних. Після тесту план коригується. Регулярне тестування знижує ризик тривалого простою в 3 рази в порівнянні з щорічним тестуванням.

Як ми розробляємо DRP?

Процес складається з п'яти етапів:

1. Аудит поточної інфраструктури — схема бекапів, точки відмови, ролі (1-2 дні).
2. Визначення RTO/RPO — узгодження з бізнесом критичності даних та часу простою.
3. Розробка сценаріїв та Runbook — 4-6 сценаріїв з конкретними командами (2-3 дні).
4. Налаштування інфраструктури бекапів — S3, реплікація, моніторинг (2-5 днів).
5. Тестовий drill та коригування — відновлення на тест-стенді, замір часу, оновлення плану (1-2 дні).

Після затвердження передаємо документацію та проводимо навчання команди.

Що входить у розробку DRP під ключ?

• Аналіз інфраструктури та точок відмови
• Узгодження RTO та RPO
• Сценарії відновлення для 4+ типів відмов
• Налаштування системи бекапів (S3, реплікація, моніторинг)
• Написання Runbook з командами
• Проведення drill-тестування
• Документація та навчання команди
• Пост-релізна підтримка 1 місяць

Строки та вартість

Вартість розраховується індивідуально, залежно від масштабу проекту. Орієнтовна вартість — від $1500. Замовте розробку DRP — ми оцінимо ваш проект за 2 дні та запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб отримати консультацію.

rsync -avz на продакшен у п’ятницю ввечері, рестарт php-fpm — і сайт відповідає 502, бо в .settings.php залишилися локальні налаштування БД. Деплой «по-старому» — лотерея. Оновлення модуля через адмінку ламає кастомний шаблон компонента, правки не зафіксовані в Git — відновлення займає години.

Ми проєктуємо передбачуваний DevOps-цикл для проєктів на Бітрікс: від Docker-середовища до алертів у Telegram. Кожен деплой стає рутиною, а не стресом.

Проблеми, які ми вирішуємо

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». Результат: двоє розробників одночасно правлять init.php, затираючи зміни один одного. Оновлення модуля через адмінку ламає шаблон компонента — файли не зафіксовані в /local/templates/. Про падіння сайту дізнаються від клієнта, staging-середовища немає, перевірки йдуть на проді. Вартість такого підходу — години відновлення та втрата бізнес-логіки.

Чому DevOps критичний для Бітрікс-проєктів?

Проєкти на Бітрікс мають специфіку: важкий торговий каталог, обмін з 1С через CommerceML, безліч агентів та подій. Без CI/CD та моніторингу кожна зміна — ризик. Ручний деплой може спричинити тижневий простій. Після впровадження DevOps середня економія трудовитрат — до 12 годин ручної роботи на місяць, а бюджету підтримки — 15 000–25 000 грн на місяць. Наш 5-річний досвід (понад 50 проєктів на Бітрікс) і ліцензійна чистота рішень — гарантія стабільності.

Інструменти та конфігурація

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main, staging, develop, feature-гілки. .gitignore під Бітрікс — нетривіальне завдання:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код: PHPStan level 5+ ловить звернення до неіснуючих методів CIBlockElement, PHP_CodeSniffer з Bitrix-стандартом, PHPUnit для бізнес-логіки, composer audit, збірка фронту. CD-пайплайн розгортає без участі людини. Мерж у staging — деплой на staging. Мерж у main — деплой на production (з ручним підтвердженням або без). Zero-downtime через symlink-стратегію: нова версія в окремій папці, current → symlink перемикається за мілісекунди. upload/ живе поза релізними директоріями. При помилці healthcheck після деплою symlink відкочується. Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer зручний для Бітрікс — є готові рецепти для symlink-деплою та shared-директорій.

Як Docker вирішує проблему «у мене працює»?

Docker-середовище фіксує версії всіх компонентів: nginx, PHP, MySQL, Redis. Docker скорочує час розгортання нового розробника в 10 разів порівняно з ручним налаштуванням. Локальна розробка — docker-compose.yml включає nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached. Новий розробник: git clone + docker-compose up -d — за 5 хвилин пише код. Паралельна робота над різними версіями PHP — через окремі compose-файли.

Особливості Бітрікс у Docker: /upload/ монтується як named volume (не bind mount — інакше на Windows/Mac проблеми з правами та швидкістю). Cron-завдання (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим же образом або supervisord. Модуль «Проактивний захист» (security) блокує запити через reverse proxy — потрібен правильний REMOTE_ADDR через set_real_ip_from та realip_module. bitrix/php_interface/dbconn.php та .settings.php задаються через змінні оточення.

Production: мультистейдж-збірка (build-стадія для асетів, production-стадія з легким образом), Docker Registry для тегованих образів, оркестрація через Docker Swarm або Kubernetes для великих проєктів.

Як правильно налаштувати nginx та php-fpm для Бітрікс?

Різниця між «сайт гальмує» та 200 ms TTFB — у конфігурації. nginx: location-блоки під Бітрікс обробляють urlrewrite.php для ЧПУ. /bitrix/admin/ закриває доступ по IP через allow/deny. expires 30d для статики — CSS, JS, зображення кешуються браузером. Brotli (стиснення на 15-20% ефективніше gzip) вмикається brotli on; brotli_comp_level 6;. Rate limiting на /bitrix/tools/ захищає від брутфорсу. HTTP/2 push для критичних ресурсів.

php-fpm: pm = dynamic, розрахунок pm.max_children за формулою (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 MB. OPcache: opcache.memory_consumption=256 (стандартних 128 MB недостатньо — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 у продакшені (скидання через cachetool opcache:reset при деплої). php.ini: memory_limit=256M (для важких операцій імпорту до 512M), max_execution_time=60, upload_max_filesize=100M. Slowlog з request_slowlog_timeout=5s знаходить вузькі місця до скарг користувачів.

Інфраструктура та автоматизація

Моніторинг, логування та резервне копіювання

Як відбувається моніторинг та реагування на інциденти? Prometheus + Grafana: метрики CPU, RAM, диска, мережі, стану сервісів. Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 MB, диск > 85%, php-fpm queue > 0. Node Exporter, MySQL Exporter, PHP-FPM Exporter збирають дані з кожного компонента. Uptime check кожні 60 секунд — алерт у Telegram за хвилину при падінні сайту. Sentry для PHP-помилок — структуровані помилки з контекстом. Моніторинг агентів Бітрікс (b_agent): завислий агент може тихо ламати обмін з 1С годинами — перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR. Логування: ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, помилки Бітрікс. Ротація через logrotate — без неї через півроку access.log займе 50 ГБ.

Staging-середовище ідентичне production: ті ж версії nginx, PHP, MySQL, модулі, налаштування php.ini. Автоматичне оновлення при мержі у staging-гілку. Періодичний клон БД з production з знеособленням персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = ''. HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /. Sandbox-режим платіжних шлюзів для тестування оплати.

Ansible як інфраструктура як код: ansible-playbook site.yml -l production — через 15 хвилин сервер налаштований ідентично. Ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Ansible забезпечує налаштування сервера за 15 хвилин замість 3 годин вручну.

Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД. Тестове відновлення щомісяця — бекап без перевірки лише ілюзія безпеки. Cron з повідомленнями: якщо беказ не пройшов — алерт одразу.

Що входить в роботу

• Документація DevOps-процесу (схема деплою, політика гілок, опис інфраструктури)
• Налаштовані CI/CD пайплайни (GitLab CI / GitHub Actions) з робочими тригерами
• Docker-середовище (docker-compose.yml, Dockerfile, конфіги)
• Ansible-плейбуки для відтворення серверів
• Моніторинг (Grafana дашборди, алерти в Telegram/Slack)
• Захищені доступи з ролевою моделлю
• Навчання команди: два заняття з роботи з CI/CD, Docker та деплоєм
• Підтримка на етапі впровадження (два тижні після запуску)

Приклад GitLab CI для Бітрікс (фрагмент):

stages:
  - test
  - build
  - deploy

cache:
  paths:
    - vendor/

unit_tests:
  stage: test
  script:
    - composer install --no-progress
    - php vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -l staging
  only:
    - staging

Як проходить впровадження?

1. Аудит поточного стану — оцінка інфраструктури, софту, процесів. Займає 2-3 дні.
2. Проектування архітектури — вибір стеку (Docker/K8s/Ansible), узгодження політик CI/CD, налаштування репозиторію.
3. Налаштування середовищ — Docker-середовище для локальної розробки, staging-середовище, production-сервери.
4. Реалізація CI/CD — написання пайплайнів, тестування деплою, інтеграція з моніторингом.
5. Моніторинг та алертинг — встановлення Prometheus + Grafana, налаштування дашбордів та оповіщень.
6. Навчання команди — два заняття з роботи з інструментами.

Типові терміни впровадження

DevOps — не проєкт з фінальною датою, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування середовища. Отримайте консультацію — зв'яжіться з нами, і за 2-3 дні підготуємо план впровадження. Замовте DevOps-впровадження під ключ — отримайте стабільність і контроль над інфраструктурою.