Aquanet

«Акванет» — производственно-торговая группа, которая работает на российском рынке более 25 лет. Является крупнейшим производителем акриловых ванн и мебели для ванной в России и входит в Топ-5 крупнейших импортеров сантехники. У компании работает собственная фабрика и производственные площадки в г. Обнинске, которые выпускают продукцию под собственным брендом Aquanet.

У клиента были проблемы со скоростью работы сайта. Поэтому, чтобы найти и устранить причины низкой производительности, он обратился к нам за техническим аудитом. При этом на проекте уже работала команда разработчиков.

С помощью технического аудита нам необходимо было:

• выяснить причины медленной загрузки страниц сайта;
• понять, из-за чего появляются баги при внедрении функционала;
• помочь клиенту принять работы от текущего подрядчика, который разрабатывал сайт.

В рамках технического аудита наши эксперты провели всестороннее и глубокое исследование сайта, чтобы выявить текущие и потенциальные проблемы, установить источники рисков, а затем устранить их.

Провели:

1. Анализ сервера и серверной архитектуры. Проверили сайт с помощью стандартных инструментов от «Битрикс»: настройки сервера, загрузку ресурсов, систему резервного копирования сайта, а также произвели ряд других проверок.
2. Стандартные тесты «1С-Битрикс». Провели тесты производительности сайта и проверку системы, анализ фасетных и SQL-индексов, проверку работы и настроек различных модулей.
3. Анализ кода и программной архитектуры. Подробно изучили компоненты «Битрикс», которые обычно содержат тяжелые запросы, проверили использование системных папок и проанализировали задачи, которые выполняются на Cron.
4. Тестирование фронтенда. Проверили работу верстки на разных платформах и браузерах, проанализировали сайт на ошибки с помощью специализированных сервисов и инструментов.
5. Нагрузочное тестирование. Произвели проверку работоспособности сайта при повышении нагрузок, резких скачках трафика, проанализировали настройки ПО серверов.
6. Функциональное тестирование. Протестировали функциональность важнейших этапов пользовательского пути, провели ряд тест-кейсов.

По итогам выявили ряд проблем:

• низкая производительность значительно влияла на конверсии;
• имелись повышенные нагрузки на сервер, в том числе при росте трафика;
• из-за неоптимального кода и архитектуры ПО было много багов, которые значительно повышали риск крупных сбоев.

Среди причин низкой производительности можно было вычленить основные:

• сложная система интеграции с «1С» и фильтрации товаров в каталоге;
• большое количество «костылей», то есть наличие неоптимальных решений при разработке на платформе «1C-Битрикс»;
• несогласованность различных программных модулей из-за того, что доработками и внедрением решений занимались разные подрядчики.

Через некоторое время после проведения технического аудита мы также взяли на себя функцию техподдержки и уже самостоятельно внедряли доработки. Поэтому в процессе прежде всего фокусировались на ускорении работы отдельных функциональных блоков: каталога, фильтров, карточки товара, корзины и чекаута, в том числе скрипты пересчета рейтингов, статусов, цен по уникальным алгоритмам от клиента в режиме мультирегиональности.

Однако, начав работу с сайтом, помимо явных причин низкой производительности мы обнаружили еще ряд проблем.

Одной из причин низкой производительности были нагрузки, которые создавали боты, перегружавшие сервер своими запросами. Доходило до того, что страницы каталога могли отдавать код по 4–6 секунд, а сайт периодически полностью терял работоспособность.

Причем было несколько видов угроз:

• спам-атаки, в том числе DDoS;
• нашествие ботов из определенных сетей и регионов;
• нагрузка от различных ботов поисковых систем и сервисов, которые не имели цели навредить, но постоянными запросами создавали ненужную нагрузку.

У сайта работало около ста поддоменов, а боты-краулеры начинали парсить их все сразу, из-за чего сервер получал нагрузку, как при работе сотни сайтов.

Для отслеживания ситуации и оперативного реагирования мы подключили проект к системе автоматического мониторинга 24/7. На раннем этапе это было жизненно необходимо, чтобы не упустить момент очередного нашествия ботов и быстро отреагировать.

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

Было принято решение создать отдельный веб-сервер, чтобы отправлять на него трафик от поисковых и части других ботов.

Всего мы задействовали на проекте 4 сервера.

1. Балансировщик веб-трафика, который фильтрует трафик и направляет его на один из следующих серверов.
2. Основной веб-сервер, который обслуживает весь входящий поток посетителей кроме трафика от поисковых и некоторых других ботов.
3. Веб-сервер для обслуживания запросов от поисковых и других ботов. На нем же развернули Slave-базу сайта. Задача этого сервера — убрать нагрузку с основного веб-сервера и снизить нагрузку на БД. Он расположен на отдельном физическом сервере.
4. Сервер БД сайта, на котором расположена мастер-база сайта.

На основном сервере и сервере для ботов был установлен ProxySQL — это сервис, который проксирует запросы к базе данных. То есть запросы проходят не напрямую, а через прокси и часть из них кэшируется. Также на сервере для ботов происходило разделение запросов на изменение и чтение данных. Запросы на чтение шли на локальную Slave-базу, а на изменение — на мастер-базу.

Также ProxySQL мультиплицирует соединения к БД и уменьшает потребление памяти на сервере БД, что позволяет продолжать работать в рамках текущего объема памяти даже в моменты сильного наплыва ботов.

Отдельно прописали правила направления трафика по веб-серверам в зависимости от User-Agent клиента. Это позволяет отсечь входящие запросы от спам-ботов и ограничить нагрузку от ботов поисковых систем. В целях отладки добавили возможность отправлять трафик на другой сервер также и по IP-адресу клиента и таким образом отсечь ботов, которые занимаются регулярными атаками.

Также описали правила фильтрации трафика:

• Заблокировали часть клиентов по IP-адресу, для чего создали список нежелательных адресов и сетей.
• Установили глобальную блокировку клиентов по User-Agent, куда внесли имена нежелательных ботов, которые собирают статистику и информацию о сайте, и при этом создают дополнительную нагрузку.
• Добавили лимиты на количество запросов с одного IP-адреса.
• Путем сложной фильтрации направили на сервер для ботов GET-запросы от ботов из сетей мобильных операторов московского региона, откуда приходила значительная часть ботов.

Таким образом, мы стабилизировали работу сайта и устранили критическую угрозу. И если раньше даже небольшой наплыв ботов приводил к серьезным замедлениям, вплоть до «падения», то после доработки серверной архитектуры сайту стали не страшны даже массовые атаки и запросы со стороны ботов.

После чего уже можно было переходить к непосредственной оптимизации технической части.

На проекте наблюдались проблемы с фасетными индексами — периодически они переставали работать, что могло привести к остановке работы сайта. А восстановление занимало достаточно много времени, в среднем 15–20 минут. Проблема возникала из-за большого количества запросов к БД, которые генерировал умный фильтр без фасетного индекса.

Для выявления причин мы установили логирование на события добавления, изменения и удаления свойств инфоблоков.

Выяснили, что проблемы возникают по двум причинам:

• сбои в работе баз данных;
• периодическое изменение свойств из «1С»: данные об изменении приходили без изменений самих свойств.

В качестве временной меры написали специальный скрипт для пересоздания фасетного индекса. Затем проблему решили рядом доработок и отладкой механизмов фасетного индекса.

Из-за сложного первоначального концепта и того, что на сайте осталось много неиспользуемого функционала от предыдущих разработчиков, было решено провести рефакторинг кода на всем сайте. Это позволило бы стандартизировать код и привести его к оптимальному виду.

Что сделали:

• удалили костыли, которые мешали работе;
• привели код к единому стандарту;
• устранили ошибки, текущие и потенциальные баги;
• исправили ошибки проектирования и слабоструктурированный код, привели его в оптимальный вид.

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

По нашему опыту, поиск на сайте — один из важнейших элементов, с которого начинается пользовательский путь. Он влияет на то, как быстро посетитель найдет искомый товар, и на вероятность успешного завершения заявки.

На данном проекте мы внедрили «умный поиск» от AnyQuery — самый популярный сервис для поиска в интернет-магазинах.

Такой поиск гораздо быстрее обрабатывает запросы и лучше закрывает потребности пользователей:

• ищет наиболее подходящую информацию по запросу;
• добавляет подсказки и настраиваемую область поиска;
• исправляет ошибки в запросе и корректирует раскладку клавиатуры;
• позволяет искать по свойствам товаров и артикулам, а также исправляет их, если они набраны с ошибкой;
• при запросе параллельно проверяет по транслитерации, когда кириллическое написание набрано латиницей.

Эти возможности позволяют существенно повысить коммерческие показатели сайта за счет того, что пользователь быстрее и точнее находит нужный товар.

Кроме того, сервис дает возможность внедрять собственные мерчендайзинговые правила, собирать данные аналитики и проводить тестирование UX-гипотез.

Сервис позволяет:

• исключить нулевые результаты в поиске;
• подключать автоподсказки для нужных брендов, категорий и популярных товаров;
• подстраивать выдачу под задачи бизнеса, чтобы поиск показывал приоритетные товары;
• настраивать ранжирование результатов поиска, чтобы пользователь видел наиболее релевантные запросу товары.

В процессе работы на проекте AnyQuery постоянно развивается:

• накапливает данные: какие запросы вводят посетители, какие ошибки и опечатки встречаются чаще всего;
• нормализованные и размеченные данные используются для дальнейшего машинного обучения;
• AI обучается различать синонимы, ошибки и опечатки и предугадывать запросы пользователей еще до окончания ввода.

Это кардинально повышает качество поиска на сайте и значительно влияет на процент успешных конверсий. По статистике на наших проектах, подключение умного поиска повышает конверсию до +30% в поисковых сессиях и до 8% по всему сайту.

Для того чтобы ускорить загрузку и отображение сайта мы подключили технологию «Композитный сайт» от «1С-Битрикс».

Ускорение загрузки страницы важно для хорошего ранжирования в поисковых системах и с точки зрения пользовательского опыта — посетители не любят медленные страницы — это плохо влияет на конверсии.

Страница разделяется на две части: статическую и динамическую. При первом посещении сайта с композитной технологией сервер генерирует кэшированную версию HTML-кода, а браузер запоминает скрипты, CSS-таблицы и графику.

При повторном открытии пользователем той же страницы сервер не скачивает все заново, а отдает версию из кэша, параллельно подгружает графику и информацию, которая изменилась с момента кэширования.

Таким образом, пользователю не нужно ждать, пока скачается весь контент, а загрузка страницы гарантированно возрастает в несколько раз.

Сложность заключалась в том, что разработчик, который собирал проект, не позаботился о том, чтобы в дальнейшем была возможность беспрепятственно подключить композитный кэш. Поэтому нам пришлось размечать все динамические области

На проекте большой каталог с десятками тысяч товаров, каждый из которых также может иметь множество свойств, что создает значительную нагрузку на «Битрикс» и серьезно замедляет работу. Это стандартная проблема «Битрикса», которая вызвана особенностями архитектуры хранения данных в инфоблоках второй версии.

Мы неоднократно сталкивались с подобными ограничениями со стороны «Битрикса» на других проектах и поэтому уже имеем готовое рабочее решение.

Суть проблемы в том, что в «Битриксе» доступно два типа инфоблоков — 1 и 2 версии, которые отличаются по способу записи данных.
«Инфоблоки 2.0» созданы для ускорения работы небольших интернет-магазинов, где каталог ограничивается 50 тысячами товаров и 300 свойствами. Однако при их использовании на крупных проектах БД значительно разрастается, из-за чего сервера перестают справляться с нагрузкой.

Поэтому на проектах с большими и сложными каталогами, мы переводим каталожные страницы на «Инфоблоки 1.0», которые лучше справляются при данных условиях.

По сути, это кастомная система хранения данных, которая использует преимущества двух версий инфоблоков, и при этом позволяет обходить их ограничения. Благодаря нашему опыту и наработкам, делается это довольно быстро и малозатратно, поскольку здесь используются стандартные технологии «Битрикс», а архитектура данных не разрабатывается с нуля.