Послуги з аудиту сайтів на 1С-Бітрікс

Аудит сайтів на 1С-Бітрікс

Відкриваєш проєкт від попередньої команди — в init.php 3000 рядків, обробники OnBeforeIBlockElementUpdate вкладені один в одного, в корені лежить dump.sql на 4 гігабайти, а upload/ важить більше за базу даних. І це типова ситуація, не виняток. Аудит — спосіб зрозуміти масштаб лиха до того, як почнеш вкладати гроші в доопрацювання.

Коли аудит із «добре б» перетворюється на «треба було вчора»

• Зміна підрядника — потрібно зрозуміти, що залишила попередня команда. Якість коду, архітектурні рішення, міни сповільненої дії
• Позиції просіли — за падінням органіки майже завжди стоять конкретні технічні причини: дублі сторінок, зламаний canonical, 50К сміттєвих URL в індексі
• Сайт гальмує під навантаженням — і падає саме в розпал розпродажу, коли кожна хвилина даунтайму коштує грошей
• Підозра на злам — спам-розсилки з сервера, редиректи на казино в мобільному трафіку, незрозумілі файли в /bitrix/modules/
• Перед великими доопрацюваннями — вкладати в розвиток проєкту, не знаючи його реальний стан — все одно що будувати поверх, не перевіривши фундамент

Технічний аудит: що реально перевіряємо

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

init.php та обробники подій — головний смітник проєкту. Тут накопичуються обробники OnAfterUserLogin, OnBeforeOrderAdd, OnAdminContextMenuShow, які ніхто не рефакторить роками. Один проєкт — 47 обробників в init.php, з яких 12 вже нічого не робили (інфоблоки давно видалені), але продовжували смикати CIBlockElement::GetList() на кожному хіті.

Версії та сумісність:

• Версія ядра — якщо нижче 22.0, оновлення обов'язкове (PHP 8.1 не підтримується)
• Модулі маркетплейсу — часто конфліктують між собою та з ядром після оновлення
• Ліцензія — без активної ліцензії немає оновлень безпеки

Конфігурація сервера:

• PHP: memory_limit < 256M — проблема на каталогах > 10K товарів. OPcache revalidate_freq = 0 у продакшні — CPU плаче
• MySQL: innodb_buffer_pool_size має бути 70–80% від RAM. query_cache на MySQL 8.0+ — видалений, але в конфігах часто залишається, генеруючи помилки в логах
• nginx: відсутність expires для статики, немає gzip для JS/CSS, відсутність fastcgi_cache

База даних — тут зазвичай найцікавіше:

• Таблиця b_event_log — розростається до гігабайтів, якщо не налаштоване очищення
• b_search_content_text — повнотекстовий індекс, який може важити більше за сам контент
• «Мертві» таблиці від видалених модулів — b_forum_*, b_learning_* — займають місце і гальмують бекапи
• Slow query log — вмикаємо, чекаємо добу, аналізуємо. Один запит до b_iblock_element_property без індексу може гальмувати весь сайт

Файлова система:

• /upload/resize_cache/ — може важити 50–100 ГБ. Часто зберігає ресайзи давно видалених зображень
• Бекапи в корені — backup_2019.tar.gz поруч із index.php. Доступний за прямим посиланням. Були випадки
• Файли ядра, змінені вручну — перезапишуться при оновленні, і кастомна логіка мовчки зникне

SEO-аудит: дублі, каноникали та сміття в індексі

• Дублі — параметри фільтрів і сортувань генерують тисячі URL. /catalog/?PAGEN_1=2, /catalog/?sort=price&order=asc — кожен в індексі як окрема сторінка
• canonical — модуль SEO Бітрікс вміє ставити canonical, але за замовчуванням не робить цього для параметризованих URL
• robots.txt — стандартний від Бітрікс закриває /bitrix/, але не закриває /search/, /personal/, /ajax/ — а там ще тисячі сміттєвих сторінок
• sitemap.xml — генератор Бітрікс іноді включає неактивні елементи та 404-сторінки
• Schema.org — Product, BreadcrumbList, Organization. Без структурованих даних сніпети у видачі нудні
• Core Web Vitals — LCP > 2.5s на мобільних — норма для непрооптимізованого Бітрікса. Зазвичай винні неоптимізовані зображення та блокуючий JS

Аудит безпеки: бекдори, веб-шели та забуті скрипти

Перевірка на вразливості:

• SQL-ін'єкції через $_REQUEST у кастомних компонентах — попередні розробники не завжди використовують $DB->ForSql()
• XSS — вивід користувацького вводу без htmlspecialcharsbx()
• Завантаження файлів — кастомні форми, які не перевіряють MIME-тип і розширення. Завантажив .php як «зображення» — отримав веб-шел

Типові знахідки:

• Модуль «Проактивний захист» вимкнений — WAF не працює, журнал вторгнень порожній
• Адмінка доступна без обмежень по IP — /bitrix/admin/ відкритий всьому інтернету
• adminer.php або phpMyAdmin в корені сайту — забули видалити після міграції
• Обфускований код у .htaccess — редирект мобільного трафіку через RewriteCond %{HTTP_USER_AGENT}
• Модифіковані файли ядра — include.php у модулях із вставками eval(base64_decode(...))

Аудит продуктивності

Серверна сторона:

• Профілювання через Blackfire або Tideways — бачимо, які функції з'їдають CPU. Часто це CIBlockElement::GetList() у циклі — класичний N+1
• Кеш: hit rate OPcache, Memcached, керованого кешу Бітрікс. Якщо кеш композитного сайту інвалідується при кожному замовленні — він марний
• Агенти Бітрікс — якщо agents_use_crontab не ввімкнений, агенти виконуються на хітах користувачів. Важкий агент = гальмо для випадкового відвідувача

Навантажувальне тестування:

• Базовий RPS, деградація при 2x, 5x навантаженні
• Як поводиться сайт, коли ліміт перевищено — коректна деградація чи 502 Bad Gateway?

Аудит коду

Оцінюємо кастомні розробки попередніх команд:

• Чи використовують D7 ORM або ліплять $DB->Query() в обхід усього
• PSR-12, автозавантаження, структура модулів — або все в одному файлі
• N+1 — GetList() всередині while($arItem = $rsItems->Fetch()) — класика
• Модифіковані файли ядра — bitrix/modules/sale/lib/ з ручними правками. При оновленні все зламається
• «Тимчасові» рішення, які живуть третій рік — // TODO: переробити від 2021-го

Формат звіту

Кожна проблема: що знайшли → де → як впливає → як виправити → трудомісткість.

Як проводимо

1. Доступи — панель Бітрікс, SSH, база, Яндекс.Вебмастер, Search Console
2. Автоматика — «Монітор якості» Бітрікс, Screaming Frog, GTmetrix, сканери безпеки. Ловлять 60% проблем
3. Ручний аналіз — решта 40%. Архітектура, код, бізнес-логіка, конфігурація — це тільки руками
4. Звіт — систематизація, пріоритети, рекомендації
5. Обговорення — зустріч із замовником, відповіді на запитання, план усунення

Види аудиту та терміни

Результат — не стос паперів, а керівництво до дії з конкретними задачами та пріоритетами.