Что делать, если ваш интернет-магазин стал неуправляемым? Разбираем на примере STOCKMANN

Привет! На связи Николай Резун, CEO Ctrlweb. Мы разрабатываем веб-решения для e-commerce проектов. В кейсе рассказываем, как помогли сети магазинов STOCKMANN вернуть управляемость собственным сайтом, перевести его на новую архитектуру без остановки процессов и ускорили работу платформы в 40 раз.

Мы уже давно предлагаем клиентам уходить от монолитных неповоротливых решений в сторону составных сервисов, построенных на принципах headless и composable commerce.

Headless требует разделять фронтенд и бэкенд сайта, чтобы сделать их независимыми друг от друга. Это позволяет быстрее обновлять внешнюю оболочку сайта, не затрагивая его логику. Composable commerce — это архитектурный подход, который подразумевает создание интернет-магазина из отдельных независимых сервисов от разных вендоров, как из кубиков LEGO. Кейс STOCKMANN оказался серьезным испытанием для нас, но ни один наш проект не покажет лучше эффективность подхода.

Структура кейса:

• Ситуация на старте
• Три варианта решения
• Переход на SOA-архитектуру
  
• Возвращаем управляемость и «дробим» монолит на сервисы
  
• Внедряем возможность апдейта информации до 60 раз в минуту
  
• Создаем платформу 2.0

Сеть STOCKMANN представлена в Европе и крупных городах России — Москве, Санкт-Петербурге, Сочи и Екатеринбурге. С 2018 года развивают собственный онлайн-магазин как один из ключевых каналов продаж.

Когда мы пришли на проект, ситуация был критической. Сайт работал с перебоями, часто зависал или вовсе падал. Во время «Сумасшедших дней» — традиционной ежегодной распродажи от STOCKMANN, когда за десять минут на сайт обрушиваются максимальное количество заказов — интернет-магазин регулярно падал, а попытки вернуть его работоспособность растягивались на несколько дней.

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

Наша работа со STOCKMANN началась во время подготовки к очередной акции «Сумасшедшие дни». На старте мы выделили несколько приоритетных задач:

• Вернуть управляемость в интернет-магазин;
• Обеспечить бесперебойную работу в дни распродаж;
• Создать условия для устойчивого развития сайта в будущем.

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

Вариант 1. Стабилизировать текущую платформу и сделать ее управляемой. Затем заняться развитием.

Почему отказались?

• Платформа представляла из себя единый монолит: связанность процессов зашкаливала;
• Документация отсутствовала или была неактуальна;
• Было невозможно быстро разобраться, как работает система и ее отдельные узлы;
• Попытки решить проблему вычислительными мощностями и реализация quick-wins не позволяли справиться так быстро, как это требовалось.

Вариант 2. Выделить две команды — одна поддерживает текущий проект, вторая работает над новым.

Почему отказались?

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

Вариант 3. Меняем колеса «на ходу», или как мы усидели на двух стульях

Итак, система умоляла что-то сделать и сделать быстро: на носу были ежегодные распродажи, во время которых e-commerce испытывает колоссальную нагрузку. Десятки тысяч людей активно оформляют заказы и ждут, что всё будет работать без сбоев.

Первым делом мы решили разделить монолит и перейти к сервисно-ориентированной архитектуре (SOA).

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

Беспокойство вызывали масштаб задачи и то, что решить ее нужно было максимально быстро. Но у нас уже был похожий опыт, поэтому мы пошли на риск, а технический отдел STOCKMANN нас поддержал. Итак, в нашей команде было 18 человек: 12 со стороны Ctrlweb, 6 — заказчика. В неё входили frontend- и backend-разработчики, UX-дизайнер, DevOps, аналитики, архитектор e-com систем, тестировщики и менеджер проекта.

Рабочий процесс построили так:

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

В этом нам помогали коллеги из «Крок Интеграции», которые изначально занимались обслуживанием инфраструктуры сайта. В процессе работы нам удалось выяснить важные архитектурные моменты, которые позволили отслеживать, где начинаются неисправности, и каким образом можно их решать, благодаря внедрению трассирующих логов и метрик в едином пространстве с инструментами исследования (сетап ELK и Prometheus).

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

Промежуточные результаты:

• Мы успешно пережили первую распродажу: если до работы с нами во время «Сумасшедших дней» сайт попросту падал, и на работы по его восстановлению уходило до нескольких дней, то нам удалось провести акцию без серьезных технических проблем. Даже «Черная Пятница», которая традиционно обрушивает шквал заказов на интернет-магазины и становится тихим ужасом для технической команды, прошла без единого падения;

• Ускорили появление новых обновлений на сайте в несколько раз: раньше STOCKMANN получал релизы один-два раза в неделю, мы сумели перестроить систему так, что в день выходили десятки обновлений;

• Параллельно подготовили систему к переходу на SOA-архитектуру.

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

1. Отказались от промежуточных запросов в 1C;
2. Настроили бесшовную систему авторизации;
3. Разработали систему очередей, которая исключила возможность потери заказа, если сторонние сервисы (например, 1С) по каким-то причинам не доступны;
4. Провели редизайн интерфейса: улучшили эргономику и сделали его более удобным для пользователя;
5. Внедрили системы мониторинга и уведомления об ошибках.

Это ознаменовало переход к новой контролируемой SOA-архитектуре и сделало сервис с заказами одним из самых быстрых на рынке.

Каталог — важнейшая часть ecom-проекта. Он должен быть быстрым, актуальным и иметь гибкий для настроек функционал.

Мы начали перестройку процессов постепенно: за два первых месяца frontend-разработчики создали фронт на React.js, а поверх старого монолита добавили слой API без изменения логики сервиса. Это позволило увеличить скорость как для пользователей, так и для внедрения нового функционала. При этом снизилось число ошибок, а у нас появились важные предпосылки для будущего обновления дизайна и перевода каталога на принципиально новый сервис.

Для того, чтобы добиться этого, вместе с разработчиками ERP реализовали следующее:

• Распараллелили обмен разных типов данных. Теперь цены, остатки, сегменты и акции обрабатываются в разных очередях;
• Разбили массив данных на части, благодаря чему распределили нагрузку и ускорили обработку;
• Встроили уведомления ERP на всех этапах обработки данных: валидации, начале и завершении;
• Настроили обработку данных на основе повторных попыток средствами очередей, а при невозможности обработки начали уведомлять ERP;
• Вывели уведомления об ошибках и статистике обработки данных в Телеграм.

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

• создали полноценную SOA-архитектуру;
• запустили сервисы управления контентом;
• обновили каталог в новом UI;
• создали новое API для mobile-разработчиков и системы управления контентом.

Если раньше данные попадали на сайт за часы, то сейчас это стало происходить за несколько минут или секунд.

Если у вас остались вопросы, буду рад ответить на них в комментариях или обсудить в Телеграме. С другими нашими работами можно ознакомиться здесь.