Услуги по DevOps и серверной настройке для 1С-Битрикс

DevOps для 1С-Битрикс

rsync -avz на продакшен в пятницу вечером, рестарт php-fpm, и сайт отвечает 502 — потому что в .settings.php остались локальные настройки подключения к БД. Классика Битрикс-деплоя «по старинке». Мы выстраиваем полный DevOps-цикл для проектов на 1С-Битрикс: от Docker-окружения до алертов в Telegram, чтобы деплой был рутиной, а не лотереей.

Проблемы, которые решает DevOps на Битрикс-проектах

Битрикс исторически жил в парадигме «правим файлы по FTP на боевом сервере». В 2026 году так работают десятки команд, и вот к чему это приводит:

• Двое разработчиков правят init.php одновременно — один затирает изменения другого. Файл init.php в Битрикс — точка входа для обработчиков событий, кастомных функций и подключений модулей. Потерять правки здесь — потерять бизнес-логику
• Обновление модуля через админку ломает кастомный шаблон компонента, потому что никто не зафиксировал, какие файлы менялись в /local/templates/
• О падении сайта узнают от клиента, а не из мониторинга
• Staging-среды нет — «быстро проверим на проде», и bitrix:catalog.section пропал

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

Git — переводим проект с FTP на Git (GitLab, GitHub, Bitbucket). Структура веток: main (production), 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 для бизнес-логики, Jest для фронтенда
• composer audit — проверка зависимостей на уязвимости
• Сборка фронтенда (webpack/Vite)

CD-пайплайн разворачивает автоматически:

• Мерж в staging — деплой на staging
• Мерж в main — деплой на production (с ручным confirm или автоматически)
• Zero-downtime через symlink-стратегию: новая версия в отдельной директории, current → symlink-переключение за миллисекунды. upload/ живёт вне релизных директорий
• Автоматический rollback при ошибках — если healthcheck после деплоя вернул не 200, symlink откатывается

Инструменты: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer особенно удобен для Битрикс — есть рецепты для symlink-деплоя и shared-директорий.

Docker для Битрикс

Docker решает «у меня работает» раз и навсегда.

Локальная разработка — docker-compose.yml:

• nginx + php-fpm 8.1/8.2 + MySQL 8.0 (или MariaDB 10.6) + Redis + Memcached
• Конфигурация максимально близкая к продакшену — те же версии, те же модули PHP
• Новый разработчик: 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 в nginx и realip_module
• bitrix/php_interface/dbconn.php и .settings.php — через environment variables или отдельный .env-файл, не через volume с продакшен-конфигами

Production:

• Мультистейдж-сборка: build-стадия для ассетов, production-стадия с минимальным образом
• Docker Registry для версионированных образов
• Оркестрация через Docker Swarm или Kubernetes для крупных проектов

Настройка nginx и php-fpm

Разница между «сайт тормозит» и «200ms TTFB» — в конфигурации.

nginx:

• Location-блоки под Битрикс: urlrewrite.php обрабатывает ЧПУ, /bitrix/admin/ закрыт по IP через allow/deny
• expires 30d для статики — CSS, JS, изображения отдаются из кэша браузера
• Brotli (лучше gzip на 15-20% для текста): brotli on; brotli_comp_level 6;
• Rate limiting на /bitrix/tools/ — защита от брутфорса и простого DDoS
• HTTP/2 push для критических ресурсов

php-fpm:

• pm = dynamic, расчёт pm.max_children по формуле: (RAM - RAM_других_сервисов) / avg_memory_per_process. Для Битрикс avg обычно 40-80 МБ
• OPcache: opcache.memory_consumption=256 (стандартных 128 МБ не хватает — Битрикс тянет тысячи файлов), 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 МБ, диск > 85%, php-fpm queue > 0 (очередь означает, что воркеров не хватает)
• Node Exporter, MySQL Exporter, PHP-FPM Exporter — метрики собираются с каждого компонента

Приложение:

• Uptime check каждые 60 секунд — если сайт лёг, алерт в Telegram за минуту
• Время отклика ключевых URL: /, /catalog/, /personal/order/make/
• Sentry для PHP-ошибок — не tail /var/log/php-errors.log, а структурированные ошибки с контекстом
• Мониторинг агентов Битрикс (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 = '' — 152-ФЗ
• HTTP Basic Auth или IP-фильтрация. Robots.txt с Disallow: /
• Sandbox-режим платёжных шлюзов для тестирования оплаты

Ansible: инфраструктура как код

Нужен новый сервер? ansible-playbook site.yml -l production — через 15 минут настроен идентично текущему:

• Плейбуки: nginx, php-fpm, MySQL, Redis, certbot, firewall
• Роли переиспользуемые: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters)
• Идемпотентность — повторный запуск ничего не ломает
• Inventory: [production], [staging], [development] — управление группами серверов

Резервное копирование

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

Типичные сроки внедрения

DevOps — не проект с датой окончания, а переход от «закинул по FTP и молюсь» к предсказуемым процессам. Каждый деплой — рутина, каждый инцидент — алерт с контекстом, каждый новый разработчик — docker-compose up вместо трёхдневной настройки окружения.