Связаться с редакцией
Для электронной коммерции осень, и особенно ноябрь, — самое напряженное время. Активность покупателей вырастает кратно по сравнению с любым другим сезоном, проводятся масштабные распродажи, маркетинговые акции. Нагрузка на сервисы огромная. Как в этот период обеспечить непрерывность процессов и высокое качество обслуживания клиентов? Универсального рецепта не существует, но есть практический опыт, накопленный Lamoda.
День холостяка и «черная пятница»: главные вызовы года
Пики нагрузки традиционно приходятся на День холостяка, 11.11, и «черную пятницу» — в 2026 году это 27.11. Эти дни не похожи ни на что, с чем мы сталкиваемся в течение года. Меняются паттерны поведения пользователей, проводятся акции, а значит, меняется нагрузка на все основные сервисы маркетплейса — в течение суток она может вырасти в десять раз. А в последние минуты акций пики выстреливают как свечки. Обеспечить безукоризненное качество сервиса в таких условиях — основной фокус и большой челлендж для команды.
Год от года задача не становится проще: растут бизнес, аудитория, ассортимент. Соответственно, растет количество заказов. Вместе с этим увеличивается сложность функционала. Но и мы не стоим на месте: наращиваем арсенал решений для пикового сезона и с каждым годом приходим к этому периоду все более подготовленными.
Цена ошибки
Когда мы разрабатывали систему KPI доступности Lamoda, то ставили во главу угла влияние технических инцидентов на бизнес-цели компании. Требовать от всех сервисов доступности на уровне четырех девяток (99,99%) не всегда оправданно.
В силу асинхронности отдельных бизнес-сценариев, например в логистике или при подготовке контента, мы можем себе позволить кратковременную недоступность — это не повлияет на качество обслуживания пользователя. Поэтому в наших KPI коммитимся на долю потерь NMV (чистая стоимость проданных товаров) и выручки по техническим причинам. Мы оцениваем влияние на бизнес каждого инцидента: сколько заказов не было создано или не доставлено клиенту в срок, сколько не показано коммерческой рекламы. И все эти импакты переводим в деньги. Так гораздо нагляднее и для ИТ, и для бизнеса.
Как все это выглядит в цифрах? Во время пиковых распродаж сезона 2025 года, в «черную пятницу» и День холостяка, нам удалось не допустить ни одного инцидента с потерей заказов, и за весь ноябрь потери составили менее 0,14% NMV. Команда тогда отработала на отлично. На второе полугодие 2026 года наш KPI меньше 0,3% от NMV потерь по техническим причинам. И в этом году нам удается идти значительно ниже этой цифры.
Что критично для непрерывности
Для непрерывности важна не только работа ИТ-инфраструктуры, но и процессы самого сервиса. Нагрузка в сезон повышается по двум причинам: растет аудитория и увеличивается количество заказов. Плюс расширяется ассортимент, множатся промоакции, усиливается активность партнеров — но это куда более предсказуемые факторы, не такие динамичные, как поведение пользователей. А значит, узкими местами, которые необходимо своевременно выявить и укрепить, сделав устойчивыми к скачкам нагрузки, становятся сервисы, задействованные в сценариях выбора товара, оформления заказа и на всех этапах доставки товара (от склада до вручения клиенту).
С помощью чего мы обеспечиваем непрерывность? Lamoda — большая платформа, поэтому назвать технологию или подход, которые не нашли отражения в нашей системе, будет сложно. У нас уже больше 600 микросервисов. Конечно, есть ряд требований к архитектуре, направленных на исключение типичных проблем: дублирования заказов, неактуальности информации по остаткам. При оформлении заказа одно из первых действий в системе — резервирование конкретного экземпляра товара на складе под конкретный заказ. Так мы исключаем ошибки в учете стоков. Если клиент приступил к оплате заказа, мы уверены, что этот товар есть в наличии именно для него.
Высокая устойчивость к сбоям — результат большой работы последних нескольких лет. Мы привели архитектуру сервиса и ИТ-инфраструктуру в соответствие с канонами построения облачных решений. Все критичные сервисы и базы данных размещены в трех зонах доступности, реализована репликация данных. Если происходит сбой в работе отдельных баз данных или сервисов либо выходит из строя зона доступности, нагрузка перераспределяется — и работоспособность восстанавливается автоматически.
Механизмы обратной связи ограничивают подключение новых пользователей, если сервис перестает справляться с нагрузкой при экстраординарном скачке активности. Это позволяет тем, кто уже начал работать с Lamoda, продолжать оформлять заказы. Когда часть пользователей завершат сессии, мы начнем постепенно впускать новых. Принцип такой: лучше обеспечить полноценный функционал тем, кто уже начал пользоваться сервисом и находится глубже в воронке, чем пытаться со снижением качества обрабатывать запросы всех желающих.
Это автоматический механизм. У нас за это отвечает Session Limiter, он постоянно мониторит состояние всех сервисов, участвующих в критических бизнес-сценариях.
Мир в режиме офлайн
С учетом периодически возникающих сложностей с мобильным интернетом мы приняли ряд мер для снижения рисков. В частности, обеспечили наиболее востребованные ПВЗ и магазины Lamoda Sport проводным интернетом и резервными каналами связи от разных провайдеров.
Наши курьеры теперь могут выдавать заказы в офлайн-режиме. Если мобильный интернет недоступен, курьер может вручить клиенту заказ и даже принять оплату. Для этого мы загружаем в специальное приложение курьера на сортировочном центре всю необходимую информацию по заказам и условиям оплаты. Клиент сможет оплатить покупку с помощью QR-кода, используя свой домашний интернет, а курьер уже без интернета сможет выдать заказ и провести эти операции.
А чтобы уменьшить влияние сбоев на стороне сервисов партнеров, мы используем принцип graceful degradation (плавной деградации). К примеру, если некоторые виды оплаты недоступны, мы предложим воспользоваться альтернативными методами или оформить заказ с постоплатой. При недоступности сервисов, реализующих некритичный для основного сценария функционал, мы продолжим работу без него — например, можем отключить показ рекламы, чтобы при этом предоставлять полноценную информацию о товаре, что для клиента гораздо важнее.
Там, где возможно, мы снижаем связанность сервисов, используя очереди сообщений. То есть сервисы не ждут мгновенного ответа друг от друга и не падают каскадом при временных сбоях, так как общаются через буфер (очередь). Такая возможность помогает переживать кратковременные сбои с меньшим влиянием на обработку пользовательских запросов и возвращаться к обработке заказов на том же этапе, на котором произошла ошибка.
Стресс-тест для системы
Ключевой метод подготовки сервиса к росту нагрузки — нагрузочное тестирование. Этот процесс у нас автоматизирован, и он не останавливается в течение всего года.
Мы регулярно получаем прогнозы бизнеса по ключевым для нас драйверам роста (объему дневной аудитории, заказам, ассортименту) и на основе дневных прогнозов и исторической информации оцениваем потенциальные пики нагрузки. Тесты ежедневно валидируют готовность продакшена к пиковой нагрузке, которая ожидается в течение ближайшего месяца. Если выявлена деградация или необходимо масштабирование, команда оперативно вносит необходимые изменения.
Особенность нагрузочных «стрельб» для подготовки к распродаже — в том, что мы воспроизводим специфичный для нее профиль нагрузки. Как это делается? Во время реальных распродаж мы записываем всю последовательность обращений пользователей к нашему сервису, затем обезличиваем эти данные и воспроизводим в качестве теста, полностью имитируя нагрузку, характерную для тех или иных распродаж.
Кроме того, по расписанию тестируем DR-планы — сценарии восстановления при сбоях отдельных реплик и сервисов, переключения на резервные каналы связи с дата-центрами и логистическими объектами. У нас есть отработанный процесс управления инцидентами, он адаптирован для управления ситуациями разного масштаба. Для определенных сценариев есть протоколы реагирования как технических, так и операционных команд. Вторые должны скорректировать свои бизнес-процессы для митигации последствий технического сбоя. А при масштабных сбоях, которые влияют на большое количество пользователей, мы подключаем PR-службу, чтобы наладить коммуникацию.
DR-планы в классическом их понимании мы сформировали для нескольких критичных для бизнеса кейсов и при помощи автоматических тестов периодически валидируем готовность ряда систем к таким сценариям. Составлять исчерпывающие DR-планы на все случаи жизни пока считаем избыточным шагом.
Выпускайте канареек
Важное правило для ИТ-команды — не создавать дополнительных рисков, разворачивая новые функции или внося изменения в системы во время распродаж. Впрочем, фризы на поставку релизов (то есть периоды, когда запрещено выкатывать новые версии в «боевую» среду) у нас крайне ограничены по времени, и мы стараемся дифференцировать их по сервисам и сценариям. К примеру, в B2C- и в B2B-направлениях фриз длится, как правило, сутки-двое до акции плюс сам день акции, не дольше. Для логистических компонентов более важен день акций и пара дней после: у них нагрузка в виде доставки рекордных объемов заказов, которые удалось оформить во время акции. При этом доставка в срок — не менее важная цель, поэтому мы очень внимательно относимся к стабильности логистики в этот период.
В остальные дни все команды разработки поставляют изменения в обычном режиме. Тем не менее мы постоянно контролируем активность пользователей, чтобы в случае ее всплеска приостановить поставку рискованных изменений.
Кроме того, мы постоянно развиваем инструменты по контролю качества и снижению рисков при выкатке релизов. Это известные на рынке подходы:
- канарейки — стратегия, при которой новая версия приложения сначала тестируется на небольшой части пользователей;
- feature toggle — переключатели функций приложения на лету, без развертывания нового кода;
- AB-эксперименты — метод сравнения версий одного и того же компонента;
- политики — наборы правил и условий, которые автоматически проверяются перед тем, как разрешить или запретить какое-либо действие;
- гейты — контрольные точки в процессе поставки ПО, на которых автоматически или вручную принимается решение: пропустить релиз дальше или остановить;
- автоматические и перформанс-«стрельбы» — тестирование новой версии приложения, когда мы стреляем запросами-патронами в сервис и смотрим, как он реагирует на эту нагрузку.
Все эти подходы постоянно совершенствуем, чтобы снизить риски и иметь возможность поставлять релизы в том числе и во время высокого сезона.
Подготовка маркетплейса к пику сезона
- Проводите регулярные нагрузочные тесты именно на проде — они дают гораздо больше гарантий готовности, чем любые проверки в тестовых средах. Важно, чтобы профиль нагрузки был не смоделирован вручную, а снят во время реальных распродаж. Да, продакшен-тестирование дорого и сопряжено с рисками, однако именно оно позволяет выявить проблемы в менее критичный момент и предотвратить катастрофические инциденты в пиковые нагрузки. А заодно исключает целый класс ошибок, связанных с неадекватной имитацией прода в тестовых окружениях.
- Применяйте механизмы graceful degradation как можно шире — они делают сервис эластичным к нагрузке, а дежурным дают дополнительное время для принятия мер. Однако помните, что это не панацея: включение таких механизмов, к сожалению, снижает эффективность работы продукта.
- Устанавливайте ограничители внешней нагрузки — допустите сценарий, при котором ваша распродажа превзойдет самые смелые прогнозы аналитиков. В этом случае избыточный трафик создаст нагрузку, к которой ИТ-инфраструктура не будет готова. Разумнее качественно обработать запросы приемлемой части аудитории, чем позволить сервису упасть целиком.
- Проверьте эффективность антиробот-системы заранее — высокий сезон несет рост не только полезной активности пользователей, но и паразитной нагрузки. Ее создают парсеры цен, стоков, перекупщики, вылавливающие лучшие предложения, и киберхулиганы, стремящиеся обрушить сервис в момент максимального внимания аудитории. Убедитесь, что ваш антиробот действительно качественно чистит трафик и вы не просто так оплачиваете счета за этот сервис.
- Вводите фризы (заморозку) релизов новых функций за 24 часа до старта распродажи. Я понимаю желание в последний момент выкатить «ту самую» фичу, тем более если ведущий разработчик готов поклясться, что с ней все будет хорошо. Но лучше возьмите паузу для наблюдения за сервисом и избегайте ненужных сюрпризов. Масштабные архитектурные изменения следует замораживать еще раньше, чтобы оставить время на стабилизацию и перебалансировку.
- Будьте в постоянном синке с планами бизнеса — следите, чтобы календари акций и рассылки промо не накладывались друг на друга без необходимости. И лучше, если соответствующие ограничения в сервисах будут заданы технически.
- Поставьте дежурить сильнейших специалистов в дни распродаж. Ноябрь — не лучшее время для отпусков. За ключевыми запусками и завершениями акций стоит следить как минимум основным дежурным неотрывно. В эти критические моменты мы держим ключевых специалистов в режиме реального времени в общей конференции и отслеживаем каждый этап процесса.
