Діагностика та виправлення помилок на 1С-Бітрікс: профілактика

Нещодавно до нас звернувся інтернет-магазин: щоранку падав каталог товарів. Помилка з'являлася о 8:00 і зникала після перезавантаження сервера. Діагностика показала, що винен агент очищення кешу, який запускався за розкладом і з'їдав всю пам'ять. За 10 років ми вирішили понад 5000 таких помилок — і знаємо: 80% із них пов'язані з кешуванням, правами доступу або несумісністю модулів. Решта 20% — це проблеми цілісності даних та архітектурні прорахунки. Системний підхід до діагностики скорочує час пошуку в 5 разів порівняно з перебором гіпотез. Комплексна профілактика знижує частоту помилок на 80%.

Алгоритм діагностики помилок

Перш ніж лізти в код, визначте тип помилки. Ми використовуємо алгоритм, який покриває 98% випадків і займає в середньому 2 години.

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

За замовчуванням Бітрікс пригнічує виведення помилок на продакшені. Для діагностики потрібно тимчасово ввімкнути розширений режим.

У файлі /bitrix/.settings.php знайдіть секцію exception_handling і встановіть:

• debug → true
• handled_errors_types → E_ALL
• log → налаштуйте запис у файл, наприклад /var/log/bitrix/error.log

Офіційна документація 1С-Бітрікс рекомендує використовувати \.settings.php для керування рівнем помилок.

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

Що найчастіше викликає помилки 500?

Є усталений алгоритм, який покриває 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) порівнює контрольні суми файлів ядра з еталонними. Модифіковані файли ядра — часта причина проблем після оновлень.

Якщо ви не хочете витрачати години на перебір гіпотез, замовте професійну діагностику – ми виявимо всі приховані проблеми за один день.

Чому помилки повертаються після оновлень?

Конфлікт модулів. Оновлення ядра до версії, несумісної зі стороннім модулем, викликає Fatal Error. Патерн: оновили Бітрікс, все зламалося. Рішення: відкотити оновлення через /bitrix/updates/ або вимкнути конфліктуючий модуль. Перед оновленнями завжди робіть бекап та перевіряйте сумісність на тестовій копії. При інтеграціях з 1С через CommerceML оновлення часто ламають обмін через зміни в XML-схемах.

Помилки в 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 для аналізу.

Порівняння: системний підхід до діагностики скорочує час пошуку в 5 разів порівняно з перебором гіпотез. Ми використовуємо цей алгоритм на кожному проекті.

Що входить в послугу усунення помилок?

• Первинна діагностика та складання звіту з причинами
• Виправлення виявлених помилок (код, конфігурація, БД)
• Перевірка сумісності модулів та ядра
• Налаштування логування та моніторингу для запобігання рецидивам
• Рекомендації щодо профілактики та подальшої підтримки

Зв'яжіться з нами для діагностики вашого сайту — ми оцінимо складність та запропонуємо оптимальне рішення.

Строки усунення за складністю

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

Наш досвід понад 10 років та 500+ проектів дозволяє гарантувати результат. Замовте професійну діагностику вже сьогодні.