Тяжёлый Битрикс-каталог умирает предсказуемо. Умный фильтр строит запросы к таблице свойств на сотни тысяч строк, подходящих индексов нет, CPU уходит в полку. Снаружи это выглядит как атака. Иногда это и есть атака — но её не разглядеть, пока выключен access-лог. В этом кейсе сошлись обе причины сразу, и обе закрылись за один оплаченный час.
Сводка
| Отрасль конечного клиента | интернет-торговля (магазин на 1С-Битрикс) |
| Конечный клиент | интернет-магазин в соседней стране (название под NDA) |
| Формат сотрудничества | абонентская DevOps-поддержка digital-студии; этот сервер — вне её парка, работа по запросу |
| Тип проекта | аварийная диагностика производительности MySQL |
| Объём работ | включение access-лога nginx · профилирование запросов · 2 индекса MySQL |
| Дата проекта | 30 окт 2025 (1 день) |
| Трудозатраты | 1 ч из 1 ч оценки |
| Команда | 3 специалиста (инженер · инженер-сисадмин · руководитель проекта) |
| Технологический стек | 1С-Битрикс · MySQL · nginx · Apache httpd · CentOS 7 |
| Сдано | запросы фильтра: с 15–30 с до менее секунды; атакуемый раздел найден по включённому логу |
Постановка задачи
Днём 30 октября менеджер студии пишет в чат поддержки: «можете чекнуть сайт — оч долго грузится или вообще не открывается». Речь про Битрикс-магазин конечного клиента в соседней стране. Сервер старый, на CentOS 7, в парк студии не входит: бюро касается его только по прямому запросу.
Руководитель направления студии заглянул на сервер сам и упёрся в стену. База выедает процессор, а смотреть не во что: access-лог nginx час как не пополняется, в логе httpd вместо реальных адресов посетителей — адрес прокси. Основной инженер бюро по этому направлению ответил честно: «Я в дороге, вечером только…»
Для магазина «вечером» — потерянный день продаж. В 13:07 студия спросила: «кто-то может глянуть?» В 13:13 руководитель проекта бюро подключил второго инженера. В 13:20 тот уже запрашивал доступы: час с минутой от первого сообщения менеджера.
Что в этом сложного
Страшный сценарий для агентства, отвечающего перед конечным клиентом, выглядит ровно так: единственный инженер подрядчика едет в поезде, магазин лежит, сервер чужой. Ни мониторинга, ни истории конфигурации, ни даже root-пароля MySQL под рукой. Пароль пришлось сбрасывать по ходу. Диагностика начинается вслепую: логи выключены, и тяжёлый легитимный трафик не отличить от атаки. Подрядчик из одного человека в такой день бессилен, каким бы сильным этот человек ни был. Бюро закрывает это преемственностью внутри команды: направление ведёт один инженер, но на эскалации в течение часа в дело вступает второй.
Как мы это сделали
1. Включили access-лог nginx. Лог оказался выключен, причём в конфиге стоял комментарий, что это стандартная настройка Битрикса. Экономия дискового ввода-вывода? Может быть. Слепота при любом инциденте? Гарантированно. Инженер вернул строку access_log /var/log/nginx/access.log common; в nginx.conf. Эта строчка сыграет в кейсе дважды.
2. Нашли виновника в плане запроса. Профилирование MySQL показало: фильтр по брендам гоняет запросы к b_iblock_element_property, стандартной таблице свойств Битрикса, в которой здесь лежало 530 тысяч записей. Подходящего индекса не было. Стоимость запроса по оптимизатору — 538 080, время выполнения 15–30 секунд. Несколько таких запросов параллельно, и CPU держится на 90–100%.
3. Добавили два индекса.
-- поиск по свойству бренда
ALTER TABLE b_iblock_element_property
ADD INDEX idx_brand_opt (IBLOCK_PROPERTY_ID, VALUE(10));
-- связь разделов и элементов
ALTER TABLE b_iblock_section_element
ADD INDEX idx_section_element_opt (IBLOCK_SECTION_ID, IBLOCK_ELEMENT_ID);
VALUE в таблице свойств — текстовое поле, поэтому индекс префиксный: первых десяти символов хватает для селективности по бренду, а индекс остаётся компактным. Стоимость запроса упала с 538 080 до 154 — в 3500 раз. Время выполнения: меньше секунды.
4. Честно сказали: CPU всё ещё высокий. Запросы ускорились, а нагрузка не ушла. Анализ трафика показал поток, похожий на легитимный; признаков DDoS инженер не увидел и предложил добавить серверу 2 ядра.
5. И тут второй раз сработал включённый лог. Руководитель направления студии, получив наконец живой access-лог и наводку «весь шум — вокруг брендов», сам нашёл аномалию: основной трафик шёл на раздел /brands, на который нет ни одной ссылки на сайте. Заблокировал раздел — процессор пришёл в норму. Из чата: «Похоже все таки на атаку… Заблокировал его, ЦП пришло в норму. Спасибо за наводку с брендами, и что починили логи». Дополнительные ядра не понадобились.
Вывод «DDoS не обнаружен» оказался преждевременным. Это честная часть истории. Но рабочий лог плюс найденный вектор по брендам дали студии ровно ту зацепку, по которой она через 26 минут после нашего отчёта закрыла атаку своими руками.
От первого сообщения менеджера до «ЦП пришло в норму» — 3 часа 10 минут календарных. В трекере 1.0 часа: столько инженер реально провёл на сервере, и ровно столько стояло в оценке.
Результаты
| Метрика | До | После |
|---|---|---|
| Стоимость запроса фильтра (оптимизатор MySQL) | 538 080 | 154 |
| Время запроса фильтра брендов | 15–30 с | менее 1 с |
| Загрузка CPU | 90–100% | норма — после блокировки /brands клиентом |
| access-лог nginx | выключен («дефолт Битрикса») | включён, остаётся для анализа |
| Подключение второго инженера | — | в течение часа от первого сообщения |
| Трудозатраты | — | 1.0 ч по трекеру (оценка 1.0 ч) |
Простыми словами: магазин снова открывается меньше чем за секунду, сервер видит свой трафик, а у студии в руках инструмент, которым она в тот же день сама закрыла атаку. Расширение сервера, которое уже ушло на согласование, не потребовалось.
Команда
- инженер (бюро) — диагностика MySQL, индексы, access-лог; подключился по эскалации
- инженер-сисадмин (бюро) — основной инженер направления; в день инцидента в дороге, вернулся к вечеру
- Антон Херсун, Xaver Pro — руководитель проекта; эскалация на второго инженера за 10 минут
Если каталог на Битриксе встаёт под фильтрами или нагрузка на CPU не объясняется трафиком — пришлите описание симптомов. Посмотрим планы запросов, назовём узкое место и вернёмся с фиксированной оценкой в часах. Разбор планов запросов бесплатный.