Устранение ошибок на сайте 1С-Битрикс

Устранение ошибок на сайте 1С-Битрикс

Сообщение «На сайте произошла ошибка» — это не диагноз, а симптом. За одинаковым внешним проявлением скрываются десятки причин: от переполненной таблицы b_event до конфликта обновлений модулей. Устранение ошибок на Битрикс — это прежде всего методичная диагностика, и только потом исправление. Разберём системный подход, который позволяет находить причину, а не гадать.

Классификация ошибок

Прежде чем лезть в код, определите тип ошибки:

Первый шаг: включение детального логирования

По умолчанию Битрикс подавляет вывод ошибок на продакшене. Для диагностики нужно временно включить расширенный режим.

В файле /bitrix/.settings.php найдите секцию exception_handling и установите:

• debug → true
• handled_errors_types → E_ALL
• log → настройте запись в файл, например /var/log/bitrix/error.log

Альтернативный способ — через dbconn.php (для старых версий): $DBDebug = true; и error_reporting(E_ALL);. На продакшене не забудьте вернуть настройки после диагностики — вывод ошибок раскрывает пути и структуру БД.

Системный подход к диагностике

Есть устоявшийся алгоритм, который покрывает 90% случаев:

1. Воспроизведите ошибку. Если ошибка плавающая — соберите данные: URL, время, браузер, авторизован ли пользователь. Часто ошибка проявляется только для определённой группы пользователей или при определённых настройках компонента.

2. Проверьте журнал событий. Административная панель → Настройки → Инструменты → Журнал событий. Таблица b_event_log хранит ошибки с метками времени, модулем-источником и stack trace. Фильтруйте по severity ERROR и WARNING.

3. Исключите проблему кэша. Сбросьте весь кэш: управляемый кэш (/bitrix/managed_cache/), автокэш (/bitrix/cache/), статический кэш (/bitrix/html_pages/). Через админку: Настройки → Настройки продукта → Автокеширование → Очистить все файлы кеша. Если ошибка исчезла после сброса — проблема в закэшированных данных, а не в коде.

4. Отключите сторонние модули. Через bitrix/modules/ переименуйте подозрительный модуль (например, partner.module → partner.module_disabled). Если ошибка пропала — виновник найден. Для компонентов аналогично: замените вызов компонента заглушкой.

5. Проверьте целостность ядра. Инструмент «Проверка системы» в админке (/bitrix/admin/site_checker.php) сравнивает контрольные суммы файлов ядра с эталонными. Модифицированные файлы ядра — частая причина проблем после обновлений.

Частые причины ошибок и их устранение

Переполнение таблиц служебных данных. Таблицы b_event, b_event_log, b_search_content_stem, b_stat_* растут без ограничений. На нагруженных сайтах b_event может содержать миллионы строк. Решение: настроить агент очистки или написать cron-скрипт для ротации. Для b_event — настроить лимит в Настройки → Почтовые события.

Конфликт обновлений модулей. Обновление ядра до версии, несовместимой со сторонним модулем, вызывает Fatal Error. Паттерн: обновили Битрикс, всё сломалось. Решение: откатить обновление через /bitrix/updates/ или отключить конфликтующий модуль. Перед обновлениями всегда делайте бэкап и проверяйте совместимость на тестовой копии.

Ошибки в result_modifier.php и component_epilog.php. Кастомизации компонентов через эти файлы в шаблонах — основной источник ошибок при обновлениях. Компонент изменил формат $arResult, а result_modifier.php обращается к несуществующему ключу. Решение: добавляйте проверки isset() и логируйте расхождения.

Проблемы с сессиями. Битрикс по умолчанию хранит сессии в файлах (/tmp/ или /bitrix/tmp/). При недостатке прав или места сессии не создаются, пользователь получает бесконечный редирект на страницу авторизации. Проверяйте session.save_path в phpinfo() и права на директорию.

Ошибки на уровне БД

Самые коварные — ошибки, связанные с целостностью данных. Типичные:

• «Duplicate entry» при добавлении элементов инфоблока — нарушен автоинкремент или индекс. Решение: ALTER TABLE ... AUTO_INCREMENT = <max_id + 1>.
• «Table is marked as crashed» (MyISAM) — повреждение таблицы. Решение: REPAIR TABLE b_iblock_element.
• Deadlocks при массовых операциях — две транзакции блокируют друг друга. Проявляется как «Lock wait timeout exceeded». Решение: оптимизация порядка обращений к таблицам, использование SHOW ENGINE INNODB STATUS для анализа.

Сроки устранения по сложности

Для каждой найденной ошибки фиксируйте: причину, способ обнаружения, решение, и меры предотвращения. Без этого одна и та же ошибка будет возвращаться после каждого обновления.