Жизненные истории: как из-за чёрной пятницы в интернет-магазине всё может пойти не так

Мы в Antro пообщались с заказчиками и вспомнили собственные кейсы: собрали подборку историй с чёрнопятничными факапами.

Жизненные истории: как из-за чёрной пятницы в интернет-магазине всё может пойти не так

Во время больших распродаж нагрузка на магазин возрастает. На сайт идёт много трафика, покупатели активно работают с корзинами и каталогом. Если в это время произойдёт сбой, бизнес может потерять клиентов и деньги.

90% наших клиентов — eCommerce-проекты. Мы работаем с магазинами на тысячи позиций, и теми, где всего несколько десятков товаров. Для многих сайтов мы ведём техподдержку, поэтому перед распродажами команда переходит в режим повышенной готовности:

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

От технических неполадок не защищён никто, но из каждой проблемы можно сделать выводы, чтобы не повторить ошибок в будущем. Истории дальше — от нас и наших клиентов: они анонимные по просьбе заказчиков, но все настоящие.

Рыболовы сделали в 20 раз больше заказов — сайт такого не выдержал

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

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

Ровно в 12 часов ночи скидки активировались на сайте, и он стал грузиться целую вечность. В тикете появилось сообщение: «по нагрузке на сервер слишком много желающих купить удочку походу собралось» — к стандартным 30–40 заказам в день прибавилось 800 сверху. Сайт не выдержал такой нагрузки и стал отвечать чрезмерно долго.

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

Вывод: проводите нагрузочные тестирования перед тем, как проводить масштабные акции

В день распродажи отключились телефоны

Эта история — от наших друзей. Мы публикуем её от лица клиента, но не ставим в цитатный блок, чтобы у вас не уставали глаза от розового фона:

Мы продаём спортивную экипировку для единоборств, в этой отрасли выступаем одними из лидеров. Когда в России только зарождались акции к «Чёрной пятнице», поняли, что продажи в эти дни существенно растут. Обрадовались новой практике и решили, что нужно детально продумывать распродажи в будущем.

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

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

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

Вывод: делайте резервную телефонию, чтобы подстраховаться на случай сбоев

Нарушилось оформление заказа из-за компании-доставщика

История ниже — тоже от нашего клиента. Публикуем от первого лица, но без розового фона:

Пару лет назад наш сайт работал на Cs-Cart’e. При оформлении заказа было две опции получения товаров: курьером CDEK или самовывозом из пункта выдачи.

В «Чёрную пятницу» CDEK столкнулся с пиком нагрузки и перестал рассчитывать стоимость доставки. При оформлении товаров у пользователей появлялась ошибка: «Не удалось рассчитать стоимость доставки. Обратитесь к администраторам интернет-магазина», и заказ сбрасывался.

Мы теряли много клиентов прямо перед покупкой, но оперативно среагировали и решили проблему. Чтобы покупатели могли оформить товары, добавили временный метод доставки, который не был привязан к API — заказы снова заработали корректно. Правда, после клиентов приходилось расстраивать стоимостью доставки.

Вывод: проверяйте работоспособность модулей на предмет того, если их зависимость от API перестанет работать

Сайт упал за день до акции

Недавняя история из нашей практики. Все клиенты активно готовится к «Чёрной пятнице», и как по закону подлости, в одном из проектов случился настоящий факап.

За день до распродажи сайт магазина упал. Сообщение из тикета: «Не отвечает. Сервер отдает 502. Скорее всего, жизнь там есть». Когда получали доступ к серверу напрямую, появлялась консоль восстановления загрузчика. Стало понятно, что сервер оказался полностью неработоспособен, и нужно восстанавливаться.

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

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

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

Рассказывайте свои истории — какие проблемы во время «Чёрной пятницы» возникали у вас?

Если хотите подстраховаться перед распродажами — прочитайте наши регламенты о правильной разработке на CMS 1C-Bitrix. Или напишите нам: мы возьмём техподдержку вашего интернет-магазина на аутсорс

4141
21 комментарий

Спасибо за крутую историю, очень нравится вас читать!

4
Ответить

к стандартным 30–40 заказам в день прибавилось 800 сверху

Пока у вас нет сотен заказов в секунду - не надо писать про хайлоад пожалуйста, это мягко говоря пошло.
Любая самописка на php на самом дешёвом сервере в хецнер это выдержит не напрягаясь.

4
Ответить

Количество заказов и количество запросов — не одно и тоже. Обсуждать такие темы бесполезно.
При желании можно положить и подготовленые под высокие нагрузки кластеры, типа того как положили в том году Яндекс, хотя и пишут что выдержал. Для кого-то сотня в секунду, для кого-то тысяча, для кого-то 17 миллионов в секунду.
Все имеет свою цену. Мы в бизнес работаем, а не rps ами мереемся. Нагрузка возросла — мы к этому не были готовы. Такое бывает.

Ответить

В статье, кстати, про неготовность проекта к нагрузкам написано. Там ни где не было что это highload :)

Посмотрел, чем вы занимаетесь — давайте дружить, вы крутые ребята)

Ответить

За день до распродажи сайт магазина упал. Сообщение из тикета: «Не отвечает. Сервер отдает 502. Скорее всего, жизнь там есть». Когда получали доступ к серверу напрямую, появлялась консоль восстановления загрузчика. Стало понятно, что сервер оказался полностью неработоспособен, и нужно восстанавливаться.

Если ваш сервис падает из-за падения одной железки на многие часы, то либо у вас очень жмут на IT-инфраструктуру, либо ваш IT-отдел некомпетентен.

3
Ответить

Вы знаете, мы настолько привыкли что все работает, что авария у нашего облачного провайдера ввело нас в некоторое замешательство, особенно когда IT-инфраструктура организована не нами:)

вы правы безусловно, сайт лежал правда не многие часы, а вполне разумное для решения время)

Ответить

хороший материал

3
Ответить