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

Готовь сани летом, а ёлочные игрушки — весной

Мы работали над лендингом Нижегородской фабрики стеклянных ёлочных украшений. Игрушки выпускаются круглый год небольшими партиями — поклонники творчества завода могут постоянно пополнять свою коллекцию. К нам обратились, чтобы подготовить всё к запуску весенней коллекции.

Главная проблема заключалась в самом сайте — он не выдерживал нагрузку, которая одномоментно приходилась на сервер, когда открывались продажи.

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

Что делать, когда проблема уже есть, а решения пока нет

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

Оцените масштаб бедствия

Изучите текущее состояние сайта
Проведите анализ производительности: какой стек технологий используется, как настроены серверы и базы данных.

В нашем случае сайт был построен на CMS 1С-Битрикс и PHP 7.4. Это хорошие технологии, но не самые производительные.

Найдите узкие места

Это может быть что угодно: медленная передача запросов к базе данных или ограничение пропускной способности сервера. Главное — обнаружить, из-за чего всё упало.

В истории с ёлочными игрушками мы поняли, что CMS попросту не справляется с пиковыми нагрузками.

Составьте прогноз нагрузки
Поймите, сколько пользователей зайдёт на сайт одновременно и сколько запросов система должна будет обработать.

У нас это число составило 10 000 пользователей за 10 секунд.

Составьте план действий

Упростите функционал

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

Для сайта завода мы придумали такой патч: сделали простой лендинг, чтобы собирать заявки на покупку игрушек. После подтверждения заказа покупатель уже мог купить свой эксклюзив. У клиента были продуктовые ограничения: покупатели не могли сразу положить в корзину 100 игрушек. 1 заказ = 1 игрушка одного вида. Это тоже повлияло на итоговую логику разработанного нами продукта: заявка на покупку → экспорт данных в Excel для ручной обработки.

Выберите подходящие технологии

Мы решили использовать Golang: это одна из самых производительных технологий для разработки веб-сервисов.

Поймите свои приоритеты

Определите, какие функции наиболее важны в вашем случае: сделайте акцент на них на уровне MVP, а позже запланируйте доработки.

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

Нам необходимо было создать «чертёж» будущей системы. Это включает в себя решение, как именно новый сервис на Golang будет взаимодействовать с другими частями системы.

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

Затем мы детализировали техническое задание: превратили общие приоритеты в конкретные задачи для команды. Это устраняет двусмысленность и дает команде четкое понимание того, что именно нужно создать.

После этого мы подготовили инфраструктуру и окружение. Перед началом тестов и разработки нужно было подготовить «рабочее место»: настроить серверы для разработки и тестирования, развернуть базу данных, настроить систему контроля версий (Git) и базовый конвейер CI/CD для автоматической сборки и проверки кода.

Подготовьтесь к реализации

Проведите предварительные тесты

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

Мы использовали Grafana K6 и Apache Benchmark.

Apache Benchmark (ab) использоваться для быстрых и простых проверок на ранних этапах. Например, чтобы оперативно оценить производительность конкретного эндпоинта после внесения небольших изменений.

Grafana k6 был выбран для более комплексного и сложного нагрузочного тестирования. Его гибкость в написании сценариев на JavaScript, возможность интеграции в CI/CD и мощные средства визуализации сделали его идеальным для имитации реального поведения пользователей и детального анализа узких мест в системе перед запуском в «боевом» режиме.

Избавьтесь от узких мест

Например, мы не можем принять больше заявок, чем число игрушек в наличии. Поэтому заявки должны приниматься последовательно с предварительными проверками наличия. Мы вычислили необходимые ресурсы сервера: количество CPU/RAM. Настроили кэширование, настроили транзакции на уровне PostgreSQL.

Будьте готовы к неожиданностям

Даже если вы всё просчитали, высока вероятность, что какая-нибудь деталь всё-таки осталась без внимания. Это нормально, главное — держать руку на пульсе и в процессе следить за состоянием системы. Перед запуском обязательно:

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

В нашем случае продажи стартовали хорошо. Первые 600 заказов оформили за одну минуту — по 10 игрушек в секунду. Коллекция не была новой, поэтому привычного ажиотажа не было. Тем не менее, всю партию мы продали за 20 минут. И у нас ничего не упало.

Через два дня стартовала пасхальная коллекция — в ней было всего 650 игрушек — и мы надеялись, что всё пройдёт так же. Но не прошло, сервер упал почти моментально. Мы его поднимали несколько раз, а когда все починили — партию уже раскупили. На продажи ушло около минуты.

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

Проанализируйте запуск

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

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

Секрет успешного сезона продаж — в быстрой адаптации. Если вы знаете, что сайт будет испытывать пиковую нагрузку, не пытайтесь «чинить» старое и уже не работающее решение. Лучше создайте минимальный функционал, который обеспечит надёжную работу. Наш пример доказывает, что подход «малое, но работающее» приносит результаты: 1000 заказов за 6 секунд без падений — это не просто цифры.

Гайд: как не дать сайту упасть в сезон