Хабрахабр

Как мы развивали ИТ в «Леруа Мерлен»: пересборка двигателя на ходу

Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.

Два года назад начали писать собственный код вместо того, чтобы модифицировать форк кода материнской компании. В предыдущих сериях: три года назад мы решили, что нужно делать свою разработку в России. Сегодняшняя история будет про то, как мы переключались с одного большого легаси-монолита на кучу маленьких микросервисов, соединённых своего рода шиной (оркестратор).

Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. И получали на это внятный ответ. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. Вторая история была с запросами наличия и свойств товара из его карточки.

Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Если сильно упростить.

Что было не так с Опусом?

OPUS — большая распределённая база. Точнее, это софт, который обеспечивает интерфейс доступа к базе данных, то есть обращается к БД и, например, производит поиск либо просто выставляет API, чтобы клиенты не ходили напрямую в БД. Это ПО работает и поддерживается во Франции. Вторая особенность, как мы уже рассказывали, в том, что очередь доработок по ней очень длинная, и мы в сравнении с бизнес-юнитом Франции — не в самом высоком приоритете.

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

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

Систему в целом назвали Russian PUB. Логичный следующий шаг — мы стали дёргать OPUS пореже и сделали свою базу (точнее, микросервисы с базами).

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

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

Что было не так с MoVe?

Ничего особенного, если не считать, что весь код мы решили выкинуть, потому что он:

  1. Был древний на старом стеке.
  2. Учитывал особенности каждого региона «Леруа Мерлен» в цепочке IF’ов.
  3. Читался и поддерживался настолько сложно, что лучший метод рефакторинга был «напиши заново и сразу нормально задокументируй».

Что мы и сделали. Только мы переписали его не монолитом, а стали делать микросервисы на каждую отдельную функцию вокруг. А потом плавно забирали часть функциональности MoVe с переключением на микросервис. И так — одно за одним, пока функциональность MoVe не кончилась целиком. То есть он ещё работает, но где-то в вакууме и без потоков данных.

Поскольку платформу мы собирали из кусков, проект назвали Лего.

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

Почему понадобилось переписывать всё это?

Потому что мы жили с отдельными клиентскими базами на каждый инстанс 15 лет с открытия в России, и это никого не устраивало. Синхронизации тоже не было. В других странах всё ещё так и живут.

Но это не полностью решало проблему омниканального заказа. Головная компания из Франции сделала общую логистику, мы переиспользовали систему Пиксис — это единое хранилище чеков, то есть клиентских заказов: один магазин видит заказы другого магазина. Это главное. Поэтому понадобилось консолидировать базу и делать общие обработки.

Второй причиной был федеральный закон о кассах: с нашими сроками разработки по общей для всех стран системе (и тестированию) мы бы влетели на штрафы.

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

Мы меняли ситуацию в три этапа: Пиксис позволял оформить заказ только с кассы, по сути.

  1. Сначала сделали мобильное приложение для сотрудника, которое очень упрощает его жизнь. На базе этого стали строить экосистему, где интерфейсы разделены с логикой.
  2. Пока всё настраивалось, интернет-заказы вбивались руками в кассу.
  3. Ставили микросервисы по очереди, которые заменяли это всё в миддле.

Почему понадобилось начать с приложения магазинов? Потому что у нас опять же уникальные процессы в сравнении с Францией. Например, решил человек купить шесть метров десять сантиметров цепи в магазине. Продавец ему отрезал, дал документ, сколько там длины и сколько это стоит. Ты идёшь с этой бумажкой на кассу, там платишь стоишь. С точки зрения логики, продажа не на кассе, а у продавца должна быть, но по факту именно на кассе начинается самое интересное: там надо иметь и товар, и бумажку.

Что-то вроде встраивания магазинов «Амазона» в блоги, только ещё универсальнее. В конечном итоге мы идём к тому, чтобы быть платформой оформления заказов: сейчас, например, поверх нашей основной системы пристроились сервисы покупки услуг мастеров (купил кухню — заказал установку у внешнего мастера, а мы его нашли и дали гарантию от себя), маркетплейс (покупка напрямую у поставщика по более широкому ассортименту), и скоро должна быть партнёрка, чтобы можно было наши блоки размещать где угодно.

Как принималось решение про замену?

I шаг. Уточнить бизнес-модель.

«Леруа Мерлен» в Европе существенно дороже, но именно в РФ это наша ниша: строительный магазин, где точно найдётся товар по самой хорошей цене. Мы проверили, и действительно: модель, как в России — низкие цены каждый день, — успешна.

Создать сценарий клиента. II шаг.

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

Построить архитектуру. III шаг.

Получилось 110 проектов, которые мы распределили на пять лет на пять категорий. Разбить это видение на конкретные ТЗ и архитектуру с более высокой детализацией.

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

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

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

Разработали песочницу идей, чтобы быстро внутренними ресурсами делать первые MVP, которые позволяют тестироваться быстро и дёшево. Третий подход — инновации. Это позволяло получать бюджет и полномочия тем, кто придумал крутой проект. Это вот и есть настоящий «try fast, fail fast».

Открывали тогда по 20 магазинов в год (сейчас чуть медленнее). Второй важный фокус был в георазвитии. Много регионов. Шесть тысяч сотрудников. Понадобилось переписывать всю цепочку поставок, быстро вырабатывать процессы поднятия инфраструктуры магазинов.

В 2017 году мы решили стать платформой для заказов по строительству: это перспективная стратегия на несколько лет вперёд.

Для омниканала (общего заказа) — другой уровень SLA по внутренним системам, реалтайм, микросервисы и синхронизация между сотнями подсистем. Для географии нам понадобился большой ИТ-бэк-офис для роста компании и роста цепочки поставок. Для платформы важна ещё скорость изменений. Это вообще другой уровень ИТ-зрелости.

При наличии подрядчиков agile может оказаться не таким эффективным. Когда это только начиналось, все думали, что agile спасёт мир. Отсюда и желание набрать 200 человек в ИТ-отдел.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть