Привет, Хабр! Меня зовут Валентин, я CTO в Lamoda, где работаю почти с момента основания компании. Все эти годы мы всей командой так быстро бежали вперед, что не было возможности немного остановиться и рассказать о себе. Думаю, время пришло.
Может показаться, что Lamoda – один из пионеров российского интернета, но нам всего семь лет. С момента основания в 2011 году по сегодняшний день наша компания выросла с 11 сотрудников до более чем пяти тысяч. Каждый месяц к нам на сайт заходит >10 млн человек. Фактически мы были стартапом-новичком в устоявшемся российском IT, а в итоге за такой короткий срок смогли догнать и превзойти многих заслуженных ребят.
Я надеюсь, что мы понемногу расскажем вам о наших самых полезных и интересных достижениях, неудачах, опыте и том, с какими задачами наша команда сталкивается каждый день. Будем считать этот пост нашим знакомством.
В 2011 году мы самостоятельно развивали только подготовку контента и закупку стока для продажи, все остальное было на аутсорсе. Сейчас мы все делаем сами. Мы курируем эксплуатацию собственного пятиуровневого склада размером с футбольное поле, три контакт-центра и доставку покупателям. Несмотря на то, что в России очень высокая IT-культура, крупные компании только начинают погружаться в то, как выстроить подобную инфраструктуру, а в Lamoda по этому пути успешно идут уже много лет.
Итак, из чего состоит техническое закулисье Lamoda? По сути это пять больших подразделений:
Эта история о ребятах, которые разрабатывают e-commerce платформу, а в свободное от работы время гоняют на мотах и водят экскурсии по барам крафтового пива.
Именно в отделе разработки e-commerce платформы создают все то, чем покупатели Lamoda пользуются ежедневно: десктопную и мобильную версию сайта и приложения для iOS и Android. Сложность работы не в реализации функциональности для пользователя, команде нужно максимально быстро, но без потери качества и стабильности раскатывать новые фичи и поддерживать проекты в четырех странах: России, Казахстане, Украине и Белоруссии. На сегодняшний день сотрудники этого отдела в состоянии запускать по сервису каждую неделю, если это необходимо, и работают под девизом: «Все в GO».
Команды в основном разбиты по платформам (desktop, mobile site, mobile apps), также существуют четыре команды для backend сервисов. Каждая команда включает в себя фронт- и бэк-разработчиков, аналитиков, тестировщиков и менеджера продукта.
Чтобы доставлять изменения как можно чаще, мы практикуем такой подход к итерациям разработки: в начале спринта выдвигаем гипотезу, а выпуская новые фичи в production, проверяем ее, тем самым понимая, идет ли нововведение на пользу продукту и становится ли жизнь пользователей Lamoda лучше. Например, не так давно мы научились показывать, какое количество просматриваемого человеком товара было куплено за последнее время. Для этого мы взяли продуктовую задачу, нашли в ней MVP и определили наиболее быструю стратегию реализации. Перед тем, как выкатить все в продакшн, мы определили, что критерием успешности будет увеличение конверсии. По результатам A/B-теста конверсия выше в той группе, где была внедрена фича.
Какое-то время назад в Lamoda начался массовый и стремительный переход на микросервисы. Что нам это дает? Первое — низкий порог вхождения для нового разработчика или специалиста из другой команды. Второе — легкая поддержка и изменение микросервисных систем, чтобы рабочий процесс был наполнен интересностями, а не только болью. Но небольшое количество монолитов (например система, которая отвечает за распределение заказов) у нас по-прежнему живет, и от них на данный момент трудно и неудобно избавляться.
Всем известно, что не бывает работы без фейлов. Каждый раз, решая задачу и запуская код, мы надеемся, что вот оно, счастье, а потом нет – снова опыт. Говоря об опыте, стоит отметить тот факт, что сотрудники отдела разработки e-commerce платформы, как истинные бойцы, умеют в прямом смысле собирать Lamoda с нуля. Случалось такое, что из-за неверных сетевых настроек наш кластер решал, что он больше не кластер, и отказывался существовать. Повезло, что это было ночью, и за четыре часа нам удалось вдохнуть в Lamoda жизнь. Есть у нас и другие истории.
Тимур Нурутдинов, руководитель разработки e-commerce платформы:
Перед началом работы над новой функциональностью мы, как обычно, сели оценить, какие ресурсы нам нужны. В проект были вовлечены четыре команды. Мы учли приоритеты других задач, график отпусков коллег и трудозатраты. В итоге у нас получилось 32 недели.
Восемь месяцев на реализацию одной фичи. Это звучит дико. С помощью нехитрых изменений нам удалось сократить time to market до 4 недель, и вот что мы сделали.
Фишка платформенных команд в том, что они в состоянии делать и фронт, и бэк. Так работают и у нас в отделе. Но на бэке бывает необходимость вносить изменения во многие интегрированные системы, и компетенции платформенной команды этого не позволяют. Мы начали проект Sizes, касающийся предоставления клиенту максимально подробных размерных сеток, и не захотели ждать. Для начала пришлось разобраться, в какие системы необходимо внести изменения, затем мы собрали небольшую команду с подходящими компетенциями. Так мы сняли блок на ожидание ресурсов от других платформенных команд и получили продуктовую команду. Что касается задач, то мы действовали своим проверенным методом — разбили большие таски на более мелкие, делали их, выкатывали в прод и проверяли свои гипотезы на пользователях, чтобы понимать, в верном ли направлении движемся. После такого удачного эксперимента с созданием продуктовой команды мы планируем организовать команды по направлениям, когда сотрудники образуют единый юнит и развивают определенное направление, например доставку.
Ребятам из автоматизации некогда скучать, и задачки тут нетривиальные. Например, как залить на сайт миллионы товаров с одинаково высоким уровнем качества контента (автоматизация фотостудии), как обрабатывать и учитывать все заказы с сайта, принимая во внимание сотню маркетплейс-партнеров и четыре страны СНГ, как за три часа собрать заказ на пятиэтажном складе, как реализовать доставку клиенту на следующий день в выбранный им 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 – для визуализации.
Одной из важных задач команды является персонализация клиентского опыта: мы создаем решение, где каждому пользователю будет показываться наиболее релевантный для него список товаров и предложений, и все наши сервисы будут индивидуально подстраиваться под каждого отдельного клиента, а не под группу, как это сделано сейчас.
Сергей Гилев, руководитель департамента данных и аналитики:
Перед департаментом аналитики на данный момент стоят две большие задачи: первая — это консолидация разнородного хозяйства, которое у нас было до объединения. Для дальнейшей эффективной работы нам необходимы единые метрики, аналитическая инфраструктура и процессы. Вторая цель — это проект по созданию аналитических дашбордов, описывающих «здоровье» определенного процесса или всей компании в целом. Таким образом мы стремимся значительно улучшить доступность данных для людей, принимающих решения, и привить всем наш подход к работе: в любой непонятной ситуации ориентируйся на данные.
Постепенный отказ от аутсорса привел нас к тому, что пора было вводить в эксплуатацию собственный склад. Кроме всей подготовки по автоматизации операционных процессов на новом складе, мы ставили перед собой цель не уменьшать ассортимент и ни в коем случае не останавливать продажу. Наши специалисты разработали решение, основанное на создании дополнительных «виртуальных» складов. Таким образом, на всем протяжении переезда у нас функционировали склады трех типов: старый, новый и «в пути». Так как перевозка товаров производилась постепенно группами фур, то сток, который оказывался в очередной партии, перемещался в «виртуальный» склад. У нас было расписание погрузок и разгрузок, поэтому мы точно знали, сколько времени сток будет находиться в пути и ориентировали клиентов на корректную дату доставки заказа.
Также мы придумали и реализовали хитрый алгоритм, который позволял нам балансировать скорость переезда и организовывать получение всех товаров заказа одной доставкой: когда человек заказывал несколько товаров, которые физически могли находиться на разных складах, мы старались организовать полную сборку заказа на каком-то одном складе, а преимущество отдавали складу партнера, поскольку процесс сборки там был уже отлажен.
Работа по запуску собственного склада кипела три месяца, в течение которых ни один клиент не пострадал.
Несколько лет назад мы боялись «Черной пятницы» как страшного монстра. Мы понятия не имели, как отреагируют наши системы на такой поток заказов. Но постоянная работа над рефакторингом и развитием инфраструктуры стабилизировала наши системы и сделала их максимально предсказуемыми. Последняя «Черная пятница» была самым скучным днем в году. Специалисты ключевых систем и DevOps просто сидели за столом, играли в видеоигры или смотрели фильмы и только одним глазком следили за состоянием нашей инфраструктуры. Но подготовка к этому дню проходит несколько иначе.
Мы составляем график нагрузочных тестов на основе бизнес-прогнозов, затем и разработчики, и администраторы настраивают системы на прохождение тестов. Несколько месяцев тестирования, крэшей, исправлений, и только после этого мы считаем, что готовы к волне пользователей и заказов.
War room — наш оперативный центр на Black Friday
Решения, которые мы принимаем, чтобы выжить в «Черную пятницу», зависят от узких мест, с которыми мы сталкиваемся во время тестирования. Несколько лет назад мы физически заменили сетевые коммутаторы, чтобы исключить проблему с пропускной способностью. Еще одно действие, которое мы обычно выполняем с целью снижения нагрузки – это отключение подсистем, которые не являются критичными.
Все эти годы мы старались постоянно улучшать и упрощать наш рабочий процесс, собирая обратную связь с сотрудников компании, налаживая каналы «bottom-up» и всецело поддерживая свежие задумки и концепции.
Кто-то скажет, что Lamoda – это абсолютный зоопарк технологий и систем. Мы сами часто шутим на эту тему и говорим: «Лучше спросите, что мы не используем». Но в этом вопросе существенным фактом выступает то, что у нас происходит постоянная эволюция стека и технологий, и при этом отсутствует их бездумный выбор. В этом нам помогает Architecture review каждого нового сервиса и проекта, ориентир на имеющуюся экспертизу сотрудников, а также ведение Technology Radar, детали и свои аргументы по которому мы с удовольствием расскажем в очередном посте. И также с удовольствием похоливарим на эту тему.
Может показаться, что 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 просто сидели за столом, играли в видеоигры или смотрели фильмы и только одним глазком следили за состоянием нашей инфраструктуры. Но подготовка к этому дню проходит несколько иначе.
Мы составляем график нагрузочных тестов на основе бизнес-прогнозов, затем и разработчики, и администраторы настраивают системы на прохождение тестов. Несколько месяцев тестирования, крэшей, исправлений, и только после этого мы считаем, что готовы к волне пользователей и заказов.
War room — наш оперативный центр на Black Friday
Решения, которые мы принимаем, чтобы выжить в «Черную пятницу», зависят от узких мест, с которыми мы сталкиваемся во время тестирования. Несколько лет назад мы физически заменили сетевые коммутаторы, чтобы исключить проблему с пропускной способностью. Еще одно действие, которое мы обычно выполняем с целью снижения нагрузки – это отключение подсистем, которые не являются критичными.
Итоги
Все эти годы мы старались постоянно улучшать и упрощать наш рабочий процесс, собирая обратную связь с сотрудников компании, налаживая каналы «bottom-up» и всецело поддерживая свежие задумки и концепции.
Кто-то скажет, что Lamoda – это абсолютный зоопарк технологий и систем. Мы сами часто шутим на эту тему и говорим: «Лучше спросите, что мы не используем». Но в этом вопросе существенным фактом выступает то, что у нас происходит постоянная эволюция стека и технологий, и при этом отсутствует их бездумный выбор. В этом нам помогает Architecture review каждого нового сервиса и проекта, ориентир на имеющуюся экспертизу сотрудников, а также ведение Technology Radar, детали и свои аргументы по которому мы с удовольствием расскажем в очередном посте. И также с удовольствием похоливарим на эту тему.
