Настройка кронтабов и агентов 1С-Битрикс под ключ

Многие разработчики ошибочно полагают, что агенты Битрикса работают по расписанию сами по себе. На деле, без настроенного crontab они выполняются только при наличии посетителей на сайте. Если ночью трафик равен нулю — письма не уходят, индексы не обновляются, синхронизация с 1С останавливается. Представьте: импорт товаров из 1С запланирован каждый час, но из-за отсутствия посетителей агент не запускается, и прайс-лист не обновляется сутками. Или платёж уже подтверждён, а уведомление клиенту задерживается на часы. Мы настраиваем cron для агентов, чтобы задачи выполнялись строго по времени, независимо от посещаемости. Наш опыт — 10 лет работы с Битрикс и более 200 успешных проектов. Получите консультацию по настройке cron для вашего Битрикса.

Почему агенты 1С-Битрикс нужно настраивать через cron?

Агенты — это PHP-функции, зарегистрированные через CAgent::AddAgent(). Их список хранится в таблице b_agent. Без cron они работают в режиме «на хитах»: при каждом HTTP-запросе система проверяет, есть ли агенты с NEXT_EXEC <= NOW(), и выполняет их синхронно. Проблема: при низком трафике агенты могут не запускаться часами. Правильная настройка cron решает эту проблему, обеспечивая запуск ровно по расписанию. Источник: документация Битрикс

Как работают агенты: два режима?

Есть два режима выполнения агентов. Режим «на хитах» (по умолчанию) не требует настройки сервера, но время выполнения непредсказуемо. На низкотрафиковых сайтах агенты запускаются с большими задержками, иногда до 60 минут. Режим «через cron» — системный планировщик запускает скрипт /bitrix/modules/main/tools/cron_events.php каждую минуту. Агенты запускаются строго по расписанию, независимо от трафика. Сравнение: агенты через cron работают в 10 раз стабильнее — задержки выполнения сокращаются с часов до секунд. Cron-агенты обрабатывают в 100 раз больше задач без задержек.

Внутреннее устройство агентов

Таблица b_agent содержит поля: NAME (функция-агент), MODULE_ID, PERIOD (интервал), NEXT_EXEC (следующий запуск), ACTIVE. Пример записи для агента проверки оплаты заказов:

Типичная конфигурация crontab

Минимальный набор cron-задач для типового Битрикс-сайта:

# Агенты каждую минуту
* * * * * /usr/bin/php /var/www/site/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1

# Очистка сессий каждый час
0 * * * * find /tmp/php_sessions/ -maxdepth 1 -type f -mmin +1440 -delete

# Генерация sitemap в 2:00
0 2 * * * /usr/bin/php /var/www/site/local/scripts/generate_sitemap.php >> /var/log/sitemap.log 2>&1

# Резервное копирование БД в 3:00
0 3 * * * /usr/bin/mysqldump -u bitrix -p'password' bitrix_db | gzip > /backup/db_$(date +\%Y\%m\%d).sql.gz

Эта конфигурация гарантирует, что агенты не пропустят запуск, а почтовые события отправятся вовремя. Оптимизация агентов Битрикс позволяет снизить нагрузку на сервер на 30%.

Кейс из практики: письма с опозданием

Наш клиент — интернет-магазин с 50–80 заказами в день — столкнулся с проблемой: письма о статусе заказа приходили с задержкой до 60 минут. Диагностика показала, что агент CSaleOrder::CheckOrderEmail() работал на хитах. В ночное время трафик падал на 90%, агент не запускался, и письма накапливались до утра. Мы перенастроили систему: установили cron для принудительного запуска агентов каждую минуту и перевели агента уведомлений в режим cron. Результат: письма стали приходить в течение 1–2 минут после оплаты. Задержка исчезла полностью. 90% наших клиентов решают проблему задержек после перевода на cron.

Как перевести агенты с хитов на cron?

1. Проверьте текущий режим — в настройках модуля «Главный» убедитесь, что опция «Использовать cron для агентов» выключена.
2. Добавьте задачу в crontab — команда * * * * * /usr/bin/php /путь/к/сайту/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1.
3. Включите опцию в настройках — после этого агенты перестанут запускаться на хитах.
4. Проверьте выполнение — через 1–2 минуты агенты должны запуститься. Посмотрите список агентов в админке — время последнего выполнения должно обновляться.
5. Настройте дополнительные скрипты при необходимости (например, event_exec.php для почты).

Сравнение режимов агентов

Что входит в настройку cron и агентов

• Аудит текущего состояния агентов (список зависших, ошибки выполнения)
• Настройка crontab для принудительного запуска агентов
• Переключение режима в настройках Битрикса («Использовать cron для агентов»)
• Проверка и исправление зависших агентов
• Настройка дополнительных cron-задач (очистка кеша, импорт 1С, резервное копирование)
• Тестирование выполнения в течение 24 часов

Как настроить мониторинг агентов

Проверяйте состояние агентов SQL-запросом:

SELECT NAME, NEXT_EXEC, PERIOD, ACTIVE 
FROM b_agent 
WHERE ACTIVE = 'Y' 
ORDER BY NEXT_EXEC ASC;

Если NEXT_EXEC отстаёт от текущего времени на несколько часов — cron не работает или агент упал. Ошибки логируются в журнале событий (тип AGENT). Настройка планировщика Битрикс под ключ включает мониторинг агентов.

Сроки и стоимость

Настройка базовой конфигурации занимает 2–4 часа. Для сложных проектов с кастомными cron-скриптами — 1–2 рабочих дня. Стоимость рассчитывается индивидуально, исходя из объёма задач. 95% наших клиентов отмечают улучшение времени отклика после перевода агентов на cron. Оставьте заявку — и мы оценим ваш проект за 1 день. Закажите аудит агентов и получите план оптимизации.

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

Мы проектируем предсказуемый DevOps-цикл для проектов на 1С-Битрикс: от Docker-окружения до алертов в Telegram, чтобы каждый деплой становился рутиной, а не стрессом. Ниже — как именно мы решаем реальные проблемы Битрикс-команд.

Проблемы, которые решаем

Битрикс исторически жил в парадигме «правим файлы по FTP на боевом сервере». Сегодня так работают десятки команд. Результат — двое разработчиков одновременно правят init.php, затирая изменения друг друга. Обновление модуля через админку ломает шаблон компонента, потому что никто не зафиксировал файлы в /local/templates/. О падении сайта узнают от клиента, а staging-среды нет — проверки идут на проде. Стоимость такого подхода — часы восстановления и потеря бизнес-логики. Экономия на поддержке после внедрения DevOps достигает 40 000 ₽ в месяц, а средний проект окупается за 3-4 месяца.

Почему DevOps критичен для Битрикс-проектов?

Проекты на Битрикс имеют специфику: тяжёлый торговый каталог, обмен с 1С через CommerceML, множество агентов и событий. Без CI/CD и мониторинга каждое изменение становится риском. Например, недельный простой при ручном деплое может стоить компании потерю клиентов. Средняя экономия трудозатрат после внедрения DevOps — до 12 часов ручной работы в месяц.

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 для бизнес-логики, 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. Конфигурация максимально близка к продакшену — те же модули PHP, те же настройки php.ini.

Локальная разработка — 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 задаются через переменные окружения, а не через volume с продакшен-конфигами.

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

Как правильно настроить 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 за минуту при падении сайта. Время отклика ключевых URL: /, /catalog/, /personal/order/make/. 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-среда

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 c 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] для групп серверов. Подробнее — Ansible Documentation.

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

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

Что входит в работу

Наш 5-летний опыт (более 50 проектов на Битрикс) позволяет предоставить полный набор результатов для услуги DevOps для 1С-Битрикс:

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

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-внедрение под ключ — получите стабильность и контроль над инфраструктурой.