Lamoda изнутри: зачем интернет-магазину 300 инженеров
Привет, Хабр! Меня зовут Валентин, я CTO в Lamoda, где работаю почти с момента основания компании. Все эти годы мы всей командой так быстро бежали вперед, что не было возможности немного остановиться и рассказать о себе. Думаю, время пришло.
Может показаться, что Lamoda — один из пионеров российского интернета, но нам всего семь лет. С момента основания в 2011 году по сегодняшний день наша компания выросла с 11 сотрудников до более чем пяти тысяч. Каждый месяц к нам на сайт заходит >10 млн человек. Фактически мы были стартапом-новичком в устоявшемся российском IT, а в итоге за такой короткий срок смогли догнать и превзойти многих заслуженных ребят.
Я надеюсь, что мы понемногу расскажем вам о наших самых полезных и интересных достижениях, неудачах, опыте и том, с какими задачами наша команда сталкивается каждый день. Будем считать этот пост нашим знакомством.
В 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.
У нас в отделе работает бакетная система для планирования спринтов: 60% — это проектный бакет, 20% — технический долг, приоритетным багам отдается 10% спринта, и 10% на то, что что-то обязательно прилетит извне. Кроме всего прочего, backlog grooming, online planning poker, stand-up, retro, code review 360, сбор и анализ базовых метрик, проведение мониторинга (Prometheus, Grafana, Icinga, Kibana), в общем все как в лучших домах Парижа командах разработки.
Вот пара забавных историй от Павла Савельева, руководителя отдела автоматизации бизнес-процессов.
Невозможно все протестировать и учесть, потому что в каждом бизнес-процессе так или иначе участвуют люди. А люди, как известно, разумные существа и всегда стараются придумать хитрые штукенции, которые облегчат им жизнь. Но когда эти самые придумки идут вразрез с описанным бизнес-процессом, случаются веселые истории.
Однажды мы заметили, что система, отвечающая за распределение товара на складе, получает в сотню раз больше сканирований в течение минуты, чем обычно. Оказалось, что сотрудники склада нашли хак системы и решили облегчить себе работу. Уходя на обед, они зажимали кнопку на сканере, чтобы их не выбрасывало из пользовательской сессии. И этот их ворк-хак работал бы и дальше, но в одном из тотов (специальный ящик для товаров на складе) оказалось много мелких айтемов. Сканер, подобно пулемету Максима, обрабатывал товары из злополучного тота, что привело к резкому скачку нагрузки, глюкам системы и обнаружению явного бага со стороны разработчиков. Баг мы, конечно, пофиксили, но думаю, что сотрудники склада не позволят нам скучать и придумают что-то новенькое.
Второй случай также произошел на складе. Эта история называется »43 веселые футболки». Не всегда сходу удается распознать сложность алгоритма, тем более когда решаешь задачу о рюкзаке и тебе нужно оптимальным образом разместить в определенном объеме N предметов (задача трехмерной упаковки). Оказалось, что если к нам на склад попадают 43 совершенно одинаковые футболки, система, отвечающая за упаковку товара, генерирует столько комбинаций распределения для данного кейса, что ей банально не хватает памяти. Мы пересмотрели алгоритм и нам больше не страшны одинаковые футболки —, но что будет, если на упаковку попадут сотни пар носков, которые производители решат продавать по одному? Об этом стоит задуматься…
В любой непонятной ситуации ориентируйся на данные
Перемены, касающиеся аналитики в Lamoda, назрели уже давно, и в этом году мы затеяли объединение разрозненных подразделений аналитики со своей аналитической инфраструктурой и привычками в один большой департамент. Зачем? Основная причина в том, что сотрудники, находящиеся в разрозненных командах аналитики, часто делают одну и ту же работу, но по-разному, и затем не вполне ясно, на какие данные ориентироваться. Разные данные — это в целом нормально, потому что команды исходят из разных задач и предпосылок, но нужно тратить много времени на то, чтобы в них разобраться.
Сотрудники департамента — истинные евангелисты того, что все решения в компании должны приниматься на основе данных, поэтому каждый день здесь с энтузиазмом изучают бизнес-явления в данных, анализируют и извлекают ценность из данных, оценивая, как их можно применить. Основной инструмент это — SQL, а также Spark, Hadoop, Python для анализа данных, Excel, SAP BusinessObjects — для отчетности и Tableau — для визуализации.
Одной из важных задач команды является персонализация клиентского опыта: мы создаем решение, где каждому пользователю будет показываться наиболее релевантный для него список товаров и предложений, и все наши сервисы будут индивидуально подстраиваться под каждого отдельного клиента, а не под группу, как это сделано сейчас.
Сергей Гилев, руководитель департамента данных и аналитики:
Перед департаментом аналитики на данный момент стоят две большие задачи: первая — это консолидация разнородного хозяйства, которое у нас было до объединения. Для дальнейшей эффективной работы нам необходимы единые метрики, аналитическая инфраструктура и процессы. Вторая цель — это проект по созданию аналитических дашбордов, описывающих «здоровье» определенного процесса или всей компании в целом. Таким образом мы стремимся значительно улучшить доступность данных для людей, принимающих решения, и привить всем наш подход к работе: в любой непонятной ситуации ориентируйся на данные.
История большого переезда: как мы запустили свой собственный склад незаметно для клиентов
Постепенный отказ от аутсорса привел нас к тому, что пора было вводить в эксплуатацию собственный склад. Кроме всей подготовки по автоматизации операционных процессов на новом складе, мы ставили перед собой цель не уменьшать ассортимент и ни в коем случае не останавливать продажу. Наши специалисты разработали решение, основанное на создании дополнительных «виртуальных» складов. Таким образом, на всем протяжении переезда у нас функционировали склады трех типов: старый, новый и «в пути». Так как перевозка товаров производилась постепенно группами фур, то сток, который оказывался в очередной партии, перемещался в «виртуальный» склад. У нас было расписание погрузок и разгрузок, поэтому мы точно знали, сколько времени сток будет находиться в пути и ориентировали клиентов на корректную дату доставки заказа.
Также мы придумали и реализовали хитрый алгоритм, который позволял нам балансировать скорость переезда и организовывать получение всех товаров заказа одной доставкой: когда человек заказывал несколько товаров, которые физически могли находиться на разных складах, мы старались организовать полную сборку заказа на каком-то одном складе, а преимущество отдавали складу партнера, поскольку процесс сборки там был уже отлажен.
Работа по запуску собственного склада кипела три месяца, в течение которых ни один клиент не пострадал.
Подготовка к Black Friday или как мы выживаем в период шопингомании
Несколько лет назад мы боялись «Черной пятницы» как страшного монстра. Мы понятия не имели, как отреагируют наши системы на такой поток заказов. Но постоянная работа над рефакторингом и развитием инфраструктуры стабилизировала наши системы и сделала их максимально предсказуемыми. Последняя «Черная пятница» была самым скучным днем в году. Специалисты ключевых систем и DevOps просто сидели за столом, играли в видеоигры или смотрели фильмы и только одним глазком следили за состоянием нашей инфраструктуры. Но подготовка к этому дню проходит несколько иначе.
Мы составляем график нагрузочных тестов на основе бизнес-прогнозов, затем и разработчики, и администраторы настраивают системы на прохождение тестов. Несколько месяцев тестирования, крэшей, исправлений, и только после этого мы считаем, что готовы к волне пользователей и заказов.
Решения, которые мы принимаем, чтобы выжить в «Черную пятницу», зависят от узких мест, с которыми мы сталкиваемся во время тестирования. Несколько лет назад мы физически заменили сетевые коммутаторы, чтобы исключить проблему с пропускной способностью. Еще одно действие, которое мы обычно выполняем с целью снижения нагрузки — это отключение подсистем, которые не являются критичными.
Итоги
Все эти годы мы старались постоянно улучшать и упрощать наш рабочий процесс, собирая обратную связь с сотрудников компании, налаживая каналы «bottom-up» и всецело поддерживая свежие задумки и концепции.
Кто-то скажет, что Lamoda — это абсолютный зоопарк технологий и систем. Мы сами часто шутим на эту тему и говорим: «Лучше спросите, что мы не используем». Но в этом вопросе существенным фактом выступает то, что у нас происходит постоянная эволюция стека и технологий, и при этом отсутствует их бездумный выбор. В этом нам помогает Architecture review каждого нового сервиса и проекта, ориентир на имеющуюся экспертизу сотрудников, а также ведение Technology Radar, детали и свои аргументы по которому мы с удовольствием расскажем в очередном посте. И также с удовольствием похоливарим на эту тему.
