Хабрахабр

Lamoda изнутри: зачем интернет-магазину 300 инженеров

Привет, Хабр! Меня зовут Валентин, я CTO в Lamoda, где работаю почти с момента основания компании. Все эти годы мы всей командой так быстро бежали вперед, что не было возможности немного остановиться и рассказать о себе. Думаю, время пришло.

С момента основания в 2011 году по сегодняшний день наша компания выросла с 11 сотрудников до более чем пяти тысяч. Может показаться, что Lamoda – один из пионеров российского интернета, но нам всего семь лет. Фактически мы были стартапом-новичком в устоявшемся российском IT, а в итоге за такой короткий срок смогли догнать и превзойти многих заслуженных ребят. Каждый месяц к нам на сайт заходит >10 млн человек.

Будем считать этот пост нашим знакомством.
В 2011 году мы самостоятельно развивали только подготовку контента и закупку стока для продажи, все остальное было на аутсорсе. Я надеюсь, что мы понемногу расскажем вам о наших самых полезных и интересных достижениях, неудачах, опыте и том, с какими задачами наша команда сталкивается каждый день. Мы курируем эксплуатацию собственного пятиуровневого склада размером с футбольное поле, три контакт-центра и доставку покупателям. Сейчас мы все делаем сами. Несмотря на то, что в России очень высокая IT-культура, крупные компании только начинают погружаться в то, как выстроить подобную инфраструктуру, а в Lamoda по этому пути успешно идут уже много лет.

По сути это пять больших подразделений:
 
Итак, из чего состоит техническое закулисье Lamoda?

  • департамент разработки (отдел автоматизации бизнес-процессов и отдел разработки онлайн-магазина)
  • отдел сопровождения IT (инфраструктура и безопасность)
  • отдел внедрения и поддержки ERP-системы
  • отдел поддержки сервисов
  • департамент данных и аналитики

Все в GO

Эта история о ребятах, которые разрабатывают e-commerce платформу, а в свободное от работы время гоняют на мотах и водят экскурсии по барам крафтового пива.
 
Именно в отделе разработки e-commerce платформы создают все то, чем покупатели Lamoda пользуются ежедневно: десктопную и мобильную версию сайта и приложения для iOS и Android. Сложность работы не в реализации функциональности для пользователя, команде нужно максимально быстро, но без потери качества и стабильности раскатывать новые фичи и поддерживать проекты в четырех странах: России, Казахстане, Украине и Белоруссии. На сегодняшний день сотрудники этого отдела в состоянии запускать по сервису каждую неделю, если это необходимо, и работают под девизом: «Все в GO».

Команды в основном разбиты по платформам (desktop, mobile site, mobile apps), также существуют четыре команды для backend сервисов. Каждая команда включает в себя фронт- и бэк-разработчиков, аналитиков, тестировщиков и менеджера продукта.

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

Что нам это дает? Какое-то время назад в Lamoda начался массовый и стремительный переход на микросервисы. Второе — легкая поддержка и изменение микросервисных систем, чтобы рабочий процесс был наполнен интересностями, а не только болью. Первое — низкий порог вхождения для нового разработчика или специалиста из другой команды. Но небольшое количество монолитов (например система, которая отвечает за распределение заказов) у нас по-прежнему живет, и от них на данный момент трудно и неудобно избавляться.

Собираем Lamoda с нуля без SMS и регистрации

Всем известно, что не бывает работы без фейлов. Каждый раз, решая задачу и запуская код, мы надеемся, что вот оно, счастье, а потом нет – снова опыт. Говоря об опыте, стоит отметить тот факт, что сотрудники отдела разработки e-commerce платформы, как истинные бойцы, умеют в прямом смысле собирать Lamoda с нуля. Случалось такое, что из-за неверных сетевых настроек наш кластер решал, что он больше не кластер, и отказывался существовать. Повезло, что это было ночью, и за четыре часа нам удалось вдохнуть в Lamoda жизнь. После этой истории мы решили переезжать на микросервисы. Есть у нас и другие истории.

Тимур Нурутдинов, руководитель разработки e-commerce платформы:

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

Это звучит дико. Восемь месяцев на реализацию одной фичи. С помощью нехитрых изменений нам удалось сократить time to market до 4 недель, и вот что мы сделали.

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

Автоматизация склада и 15-минутные интервалы доставки

Ребятам из автоматизации некогда скучать, и задачки тут нетривиальные. Например, как залить на сайт миллионы товаров с одинаково высоким уровнем качества контента (автоматизация фотостудии), как обрабатывать и учитывать все заказы с сайта, принимая во внимание сотню маркетплейс-партнеров и четыре страны СНГ, как за три часа собрать заказ на пятиэтажном складе, как реализовать доставку клиенту на следующий день в выбранный им 15-минутный интервал в 600 городах только в России. А на десерт здесь подают продажу всего этого хозяйства B2B-партнерам и Marketplace-направление.
 
Работа ведется в основном на PHP, для автоматизации склада мы используем Java плюс Docker/Kubernetes, Atlassian stack, PostgreSQL, RabbitMQ.

Кроме всего прочего, backlog grooming, online planning poker, stand-up, retro, code review 360, сбор и анализ базовых метрик, проведение мониторинга (Prometheus, Grafana, Icinga, Kibana), в общем все как в лучших домах Парижа командах разработки. У нас в отделе работает бакетная система для планирования спринтов: 60% – это проектный бакет, 20% – технический долг, приоритетным багам отдается 10% спринта, и 10% на то, что что-то обязательно прилетит извне.

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

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

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

Эта история называется «43 веселые футболки». Второй случай также произошел на складе. Оказалось, что если к нам на склад попадают 43 совершенно одинаковые футболки, система, отвечающая за упаковку товара, генерирует столько комбинаций распределения для данного кейса, что ей банально не хватает памяти. Не всегда сходу удается распознать сложность алгоритма, тем более когда решаешь задачу о рюкзаке и тебе нужно оптимальным образом разместить в определенном объеме N предметов (задача трехмерной упаковки). Об этом стоит задуматься… Мы пересмотрели алгоритм и нам больше не страшны одинаковые футболки — но что будет, если на упаковку попадут сотни пар носков, которые производители решат продавать по одному?

В любой непонятной ситуации ориентируйся на данные

Перемены, касающиеся аналитики в Lamoda, назрели уже давно, и в этом году мы затеяли объединение разрозненных подразделений аналитики со своей аналитической инфраструктурой и привычками в один большой департамент. Зачем? Основная причина в том, что сотрудники, находящиеся в разрозненных командах аналитики, часто делают одну и ту же работу, но по-разному, и затем не вполне ясно, на какие данные ориентироваться. Разные данные – это в целом нормально, потому что команды исходят из разных задач и предпосылок, но нужно тратить много времени на то, чтобы в них разобраться.

Основной инструмент это – SQL, а также Spark, Hadoop, Python для анализа данных, Excel, SAP BusinessObjects – для отчетности и Tableau – для визуализации. Сотрудники департамента – истинные евангелисты того, что все решения в компании должны приниматься на основе данных, поэтому каждый день здесь с энтузиазмом изучают бизнес-явления в данных, анализируют и извлекают ценность из данных, оценивая, как их можно применить.

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

Сергей Гилев, руководитель департамента данных и аналитики:

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

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

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

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

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

Подготовка к Black Friday или как мы выживаем в период шопингомании

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

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


War room — наш оперативный центр на Black Friday

Несколько лет назад мы физически заменили сетевые коммутаторы, чтобы исключить проблему с пропускной способностью. Решения, которые мы принимаем, чтобы выжить в «Черную пятницу», зависят от узких мест, с которыми мы сталкиваемся во время тестирования. Еще одно действие, которое мы обычно выполняем с целью снижения нагрузки – это отключение подсистем, которые не являются критичными.

Итоги

Все эти годы мы старались постоянно улучшать и упрощать наш рабочий процесс, собирая обратную связь с сотрудников компании, налаживая каналы «bottom-up» и всецело поддерживая свежие задумки и концепции.

Мы сами часто шутим на эту тему и говорим: «Лучше спросите, что мы не используем». Кто-то скажет, что Lamoda – это абсолютный зоопарк технологий и систем. В этом нам помогает Architecture review каждого нового сервиса и проекта, ориентир на имеющуюся экспертизу сотрудников, а также ведение Technology Radar, детали и свои аргументы по которому мы с удовольствием расскажем в очередном посте. Но в этом вопросе существенным фактом выступает то, что у нас происходит постоянная эволюция стека и технологий, и при этом отсутствует их бездумный выбор. И также с удовольствием похоливарим на эту тему.

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

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

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

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

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