Rakhmanov Studio 
Тендеры и лиды
Информация
В пик распродаж сайты падают не из-за слабых серверов, а из-за узких мест архитектуры. Разбираем 4 реальных граблей в связке каталога, 1С и чекаута, а также экспресс-чеклист подготовки за 48 часов.
В недавнем выпуске рубрики «Слово экспертам» редакция Workspace подняла острый вопрос: как экстренно спасти упавший сайт. Коллеги из ASTRIO, GRCH и GEOSEO дали отличную базовую инструкцию: добавить облачных мощностей, заблокировать ботов через Cloudflare, настроить кэш в Memcached и убрать лишние виджеты.
Это рабочие и правильные шаги. Однако когда сталкиваешься с резкими пиковыми нагрузками (будь то сезонные всплески в крупных travel-экосистемах вроде FUN&SUN или ноябрьские распродажи в ритейле), быстро понимаешь: природа сбоев везде одинаковая. Витрина оживает, но продажи всё равно стоят.
Интернет-магазины редко умирают от простого просмотра страниц. Коллапс наступает в секунду, когда покупатель жмет «Оформить заказ». Кэш пробит. Тысячи запросов одновременно лезут в 1С, эквайринг и онлайн-кассы.
Классические грабли. Сотня покупателей одновременно оформляет акционный товар. Сайт шлет сотню параллельных запросов в 1С, чтобы проверить и зарезервировать остатки.
База моментально блокирует таблицы. Очередь растет. Сервер висит в мертвой клинче, и увеличение памяти уже не спасает.
Это классическое поведение систем при отсутствии изоляции ресурсов. Решение тут одно: полностью отвязать витрину от учетной системы. Каталог должен отдаваться из кэша (Redis или Varnish), а остатки в пиковые дни достаточно обновлять небольшими дельтами раз в 10–15 минут.
Представьте картину: покупатель нажимает «Оплатить». Шлюз эквайринга задерживает ответ, ОФД тормозит, а проверка маркировки задумывается на секунду.
Чекаут зависает. Человек видит белый экран, нервничает и кликает по кнопке еще раза три. Итог — ошибка на экране, тройное списание денег с карты и разъяренный клиент в поддержке.
Здесь спасают только очереди сообщений (RabbitMQ, Redis, Kafka). Заказ моментально сохраняется в защищенный буфер за 50 миллисекунд. Покупатель сразу получает подтверждение «Заказ принят», а фискализация и списание происходят асинхронно в фоновом режиме.
Один из самых болезненных уроков. За три часа до начала распродажи прилетает просьба: «Быстренько поправьте цвет кнопки и таймер акции».
Разработчик выкатывает быстрый правку прямо в боевое окружение без полного тестирования. И случайно ломает скрипт валидации в корзине.
В итоге витрина летает, а касса молчит — ни одного заказа из-за банальной ошибки в коде. Поэтому перед крупными акциями необходима жесткая заморозка кода (Code Freeze) хотя бы за 48–72 часа. В прод — ни строчки, кроме критических хотфиксов безопасности.
Накануне старта сайт превращается в новогоднюю елку: всплывающие колеса фортуны, три онлайн-чата, пуши, товарные рекомендации и десятки пикселей аналитики.
Каждый виджет тянет данные со своего стороннего сервера. Если в пик распродажи проседает хотя бы один сторонний сервис, браузер пользователя блокирует отрисовку. Страница грузится 15 секунд. Покупатель просто уходит.
На время акции стоит оставлять максимально чистый путь: поиск, карточка, корзина, быстрая оплата. Все остальное — отключить без сожалений.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13829 тендеров
проведено за восемь лет работы нашего сайта.
Заморозить любые доработки и релизы кода (Code Freeze);
Включить жесткое кэширование статики и страниц каталога на CDN и Nginx;
Отвязать отображение остатков товаров от прямых запросов в 1С;
Снять с сайта все сторонние виджеты, анимации и тяжелые скрипты;
Перевести прием заказов на очереди с гарантией защиты от повторных списаний;
Уточнить лимиты по транзакциям у платежного шлюза и облачных касс;
Заранее подготовить и протестировать легкую статическую страницу ожидания на случай сбоев внешних сервисов.
И здесь мы подходим к вечной теме: кто виноват, когда в ноябрьский пик летит ошибка 504?
Бизнес хочет выжать максимум и ждет рост трафика в 10 раз. Но оплачивать нагрузочные тесты и оптимизацию архитектуры на этапе подготовки отказывается: «Вы же разработчики, сделайте так, чтобы всё работало».
В полночь сайт падает. А наутро агентство получает претензию с требованием компенсировать упущенную выгоду за сорванный старт распродажи.
Вопрос к техническим директорам, руководителям e-com и владельцам студий:
Как вы юридически и регламентно разграничиваете ответственность за сбои под нагрузкой? Удается ли убеждать клиентов проводить стресс-тесты до акции, или всё упирается в разбор полетов уже после падения?
Поможет ли простое увеличение тарифа хостинга защитить сайт от падения?
Нет. Если сайт делает синхронные блокирующие запросы к 1С при каждом открытии страницы, добавление ядер процессора лишь немного отсрочит падение. Узкое место находится в логике работы с базой данных, а не в объеме оперативной памяти сервера.
Что делать в первую очередь, если сайт упал прямо в разгар распродажи?
Не пытаться экстренно переписывать код на боевом сервере. Немедленно перевести сайт на статическую страницу ожидания, отключить ресурсоемкие фоновые процессы (полную переиндексацию, тяжелые выгрузки отчетов), перезапустить сервисы баз данных и временно включить отдачу каталога из кэша.
Как проверить, выдержит ли сайт наплыв покупателей до начала акции?
Провести нагрузочное стресс-тестирование (например, с помощью Apache JMeter или k6). Тест должен эмулировать не просто открытие главной страницы, а реальные пользовательские сценарии: поиск, фильтрация, добавление в корзину и чекаут с разной степенью интенсивности.
За сколько дней до распродажи нужно замораживать обновления сайта?
Оптимальный срок — за 5–7 дней, минимальный критический — не менее 48 часов до старта рекламной кампании.
