Везли, везли и вывезли: работа над сайтом логистической компании
О клиенте
Подробности работы с этой компанией отчасти засекречены по условиям договора. Мы не сможем сказать, кто наш клиент — зато напишем, в решении каких проблем мы особенно хороши.
Наш заказчик входит в топ-10 оптовых перевозчиков в РФ. К нему обращаются и владельцы бизнесов на маркетплейсах, и промышленные производители, и ритейл-компании. Обороты компании исчисляются уже миллиардами: важно, чтобы работа сайта была бесперебойной, иначе ошибки замечают тысячи клиентов.
В компании есть отдел разработчиков: они сосредоточены на работе с CRM и внутренними сервисами. А вот наша команда решала специфические задачи — о них расскажем ниже.
Инструменты и технологии
О проекте
Сайт компании разработали на Laravel более 10 лет назад. Недавно в процессе редизайна к стеку добавился и фронтенд-фреймворк React.
Заказчик выделил несколько проблем:
- медленная работа сайта;
- многочисленные баги в веб-версии личного кабинета клиента, которые появились после редизайна;
- ошибки при отправке формы заявки.
Ресурсов команды не хватало для решения таких задач.
Мы выделили личного менеджера и 3-х разработчиков для полного погружения в проект. Специалисты получили доступ к трекеру клиента, а рабочую коммуникацию вели в общем чате в Telegram.
Проблема №1
медленная скорость
работы сайта
С ростом числа клиентов и расширением бизнеса постоянно встает проблема оптимизации. Посещаемость сайта росла, а вот скорость падала с каждым месяцем. Расширение ресурсов сервера помогало ненадолго: мощности сайта приходилось постоянно наращивать.
Чтобы снизить нагрузку, мы оптимизировали запросы к базе данных.
Index Scan
Плашка «Загрузка» висела в ЛК почти после каждого перехода.
Мы выстроили логирование процессов в разных частях личного кабинета. Выяснили: в сервисе были «узкие места», где запрос отправляется в базу данных и обрабатывается по 5-20 секунд.
Программисты начали с оптимизации простых запросов и настройки индексного сканирования вместо последовательного.
База данных сканировала около 12 миллионов строк.
Процесс занимал 4-5 секунд. Добавив индекс, мы ускорили работу в тысячи раз до 400 миллисекунд:
Затем мы подробно изучили схему работы базы данных и добавили «лишние» столбцы в некоторые таблицы, чтобы использовать их в операторах WHERE или JOIN ON.
Так большие запросы делятся на маленькие, а их общее количество сокращается.
Redis
Для еще большей оптимизации работы системы и ускорения загрузки данных мы добавили кэш-сервер Redis. Почему его? Redis — это in-memory и key-value хранилище, где доступ к данным по их ключу имеет сложность O(1). Так информация на сайте появляется гораздо быстрее.
В такой кэш мы положили часто запрашиваемые данные.
Для работы с Redis в PHP использовали PHPRedis:
Не понимаете, как это работает? Представьте: информацию об одном и том же грузе запрашивают 10 пользователей.
Данные о местоположении загружаются один раз, а затем сохраняются в кэше. 9 из 10 пользователей получат информацию моментально.
Проблема №2
постоянные баги и
нестандартные ошибки
Личный кабинет — самая проблемная зона на сайте. Багов — и простых, и посложнее — встречалось довольно много. Вот лишь некоторые из них:
- Статус заявки у клиента отображался неверно и несвоевременно обновлялся;
- Не все клиенты-юрлица могли войти в личный кабинет по ИНН;
- СМС для подтверждения входа или операции часто не доходили с первого раза;
- В разделе «Электронные чеки» клиенты видели документы только за последний год.
Для решения этих проблем мы перебрали весь сервис и декомпозировали его на модули и подмодули. Теперь вся система разделена на функциональные единицы — частично это можно назвать сервис-ориентированной архитектурой.
Такая система помогает молниеносно отреагировать на любой сбой или ошибку в работе.
Заодно мы перенесли тяжелые модули на отдельные ресурсы. Теперь они не снижают производительность всего сервиса.
Проблема №3
некорректная работа
форм обратной связи
А именно:
- Заявки приходили на почты менеджеров, но не дублировались в CRM;
- Не вся информация из заполненных полей отображалась в CRM, например, габариты посылки или комментарий к заказу. Менеджеры перезванивали клиентам, вновь запрашивали данные и сталкивались с их недовольством;
- 35% источников лидов было невозможно определить: заявки никак не маркировались. Оценить эффективность рекламных кампаний было сложно.
Мы столкнулись с неожиданностью — почти у каждой формы был свой обработчик. Какое решение? Универсальный модуль для работы со всеми формами.
Так команда наладила отправку заявки в CRM по API. Затем настроила верный обмен полями, убрала смысловые дубли. Например, поле «Комментарий» в большинстве форм помечалось как question, а в остальных — как message. Вторые терялись и не загружались в CRM. Мы привели все к единому стандарту и настроили верную передачу полей.
А что с аналитикой? Оставалось лишь наладить грамотную передачу UTM-меток. Теперь с помощью библиотеки Sourcebuster JS метки автоматически указываются в каждой заявке. А вместе с ними — и ClientID в Яндекс.Метрике.
О результатах
За 6 месяцев сотрудничества мы:
- снизили количество багов в 10 раз;
- написали 20 000 строк кода;
- выработали более 700 часов.
Работу над сайтом продолжаем и сегодня. О новых и интересных задачах расскажем в продолжении кейса.