Минус 20 млн за 5 дней: система не справилась с пиковой нагрузкой
В преддверии длинных майских праздников, хочу поделиться с вами одной историей — не совсем весёлой, и не совсем праздничной...
Для большинства компаний Новый год - это не просто праздник. Это 20-40% годовой выручки за несколько недель. Маркетинг усиливается, склады работают на пределе, трафик растет в разы.
Один ритейлер (магазины офлайн + онлайн) подошёл к декабрю в полной готовности:
- сайт держит пиковую нагрузку,
- маркетинг запущен,
- склад усилен,
- команда на месте.
В первые дни распродаж всё шло отлично:
- трафик вырос в 3 раза,
- заказы - почти в 2,5 раза.
Казалось бы идеально подготовились, пока не начались сбои. Критической аварии не было, просто фиксировались отклонения от нормы, которым не сразу придали значение по причине увеличения трафика и заказов:
- часть заказов обрабатывались дольше обычного,
- появились задержки в сборке,
- увеличилось количество обращений в поддержку.
Узкое место оказалось не в сайте и не в складе. Не выдержала связка:
сайт → процессинг → ERP → склад
Что произошло:
- при росте заказов увеличилась нагрузка на интеграцию с ERP,
- часть операций начала выполняться медленнее,
- включились повторные попытки (ретраи),
- очередь начала расти.
В какой-то момент система вошла в «эффект снежного кома»: больше заказов → больше задержек → больше повторных операций → выше нагрузка
Как это выглядело для бизнеса
Самое опасное в этой ситуации было то, что проблемы проявлялись не как резкое «падение» системы, а как постепенная деградация процессов. Заказы не исчезали полностью — они продолжали создаваться и отображаться в системе. Но на деле они либо обрабатывались с задержкой, либо ломались в процессе передачи между системами.
Для бизнеса это было очень болезненно:
Часть заказов не доходила до склада вовремя, что влияло на скорость доставки и клиентский опыт.
Некоторые заказы отменялись самими клиентами, уставшими ждать.
А с оставшимися приходилось разбираться вручную, используя время сотрудников и ресурсы компании.
В результате процесс, который должен был быть автоматическим и прозрачным, превращался в источник скрытых потерь и стресса для команды.
Считаем деньги
Возьмем реальные масштабы:
- 15 000 заказов в день в пик
- средний чек = 5 000 ₽
- дневная выручка = 75 млн ₽
Из-за деградации интеграции:
- 5% заказов не были обработаны корректно или вовремя
Это:
- 750 заказов в день
- 3,75 млн ₽ потерь ежедневно
Проблема длилась 5 дней, пока её точно диагностировали и стабилизировали.
Итого около 18–20 млн ₽ прямых потерь, несчитая тех что появились после диагностики.
Но главное - даже не это.
После праздников последствия стали особенно заметны. Сначала перегрузилась поддержка: сотрудники тратят часы на разбор заказов, возвраты и жалобы клиентов, которые не получили свои покупки вовремя.
Одновременно бизнес почувствовал потерю повторных продаж. Часть клиентов, разочарованная задержками или ошибками, просто не вернулась, а это напрямую ударило по будущей выручке.
Кроме того, команда вынуждена была работать вручную. Сотрудники неделями «разгребали» последствия, проверяя заказы, исправляя ошибки и стараясь восстановить клиентский опыт.
И, наконец, оказался потерян эффект от маркетинга. Деньги на трафик были потрачены, но конверсия снизилась: покупатели либо уходили, либо отменяли заказы, и вложения в рекламу не окупились. В сумме это превратилось в реальные финансовые потери, которые нельзя было быстро компенсировать.
Почему это произошло
Ошибка была не в том, что система «сломалась».
Ошибка была в том, что:
- интеграции не тестировались под реальную пиковую нагрузку
- не было понимания, где узкие места в потоках
- не контролировалась скорость прохождения заказа по цепочке
Проще говоря: бизнес был готов к росту, а интеграции — нет.