Сайт падает под нагрузкой: как найти причину и не тушить пожары

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

Как понять, что виновата нагрузка на сайт

Не каждое падение связано с наплывом посетителей. Прежде чем что-то чинить, сопоставьте сбои с событиями в бизнесе.

Похоже на нагрузку, если:

• сайт тормозит или отдаёт ошибки 502 и 504 в часы пик, а ночью работает нормально;
• падения совпадают с рассылкой, запуском рекламы, постом блогера или распродажей;
• сначала замедляются корзина, поиск и личный кабинет, а статичные страницы ещё открываются;
• после перезагрузки сервера всё работает, пока снова не придут люди.

Похоже на другую причину, если:

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

Во втором случае ищут ошибку в коде, утечку памяти или задачу по расписанию, которая забирает ресурсы. Это тоже решается разбором первопричины, но другими инструментами.

Где обычно узкое место

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

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

Почему сервер помощнее помогает ненадолго

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

• Не лечит блокировки. Если запросы в базе ждут друг друга, лишние ядра простаивают.
• Не лечит медленные интеграции. Внешний сервис отвечает так же долго, как раньше.
• Растёт счёт. Каждый следующий шаг тарифа стоит дороже, а эффект от него меньше.
• Откладывает разбор. Пока сайт держится, причину никто не ищет. Следующий рост трафика упирается в то же самое место.

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

Как найти первопричину: порядок разбора

Разбор начинается с фактов. Код открывают позже, когда круг подозреваемых сужен. Первопричину ищут по тому же принципу, что и в любом инциденте: подробно о методе в статье «Root cause analysis: как найти первопричину сбоя».

1. Хронология. Выпишите все падения за месяц и рядом события: рассылки, реклама, выгрузки, релизы. Совпадения видны сразу.
2. Метрики сервера в момент падения. Процессор, память, диск, сеть. Если графиков нет, их стоит включить сегодня: без них каждый следующий сбой придётся разбирать вслепую.
3. Логи веб-сервера и приложения. Какие адреса отвечали дольше всего, какие ошибки сыпались, откуда шёл трафик.
4. Медленные запросы к базе. Журнал медленных запросов показывает, какие из них съедают время. Часто это несколько запросов без нужного индекса.
5. Воспроизведение на копии. Нагрузочный тест на копии сайта подтверждает догадку: если убрать найденную причину, предел должен вырасти.
6. Исправление и проверка. Индексы, кеш, перенос тяжёлых задач в очередь, асинхронные вызовы внешних сервисов. После исправления тест повторяют.

Что делать, если сайт лежит прямо сейчас

Пока идёт разбор, бизнесу нужно продавать. Временные меры, которые помогают пережить пик:

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

Каждая такая мера снимает только симптом. Зафиксируйте, что сделали, и вернитесь к разбору, когда пик пройдёт. Иначе следующая распродажа повторит ту же историю.

Нагрузочный тест перед пиком

Если впереди сезон распродаж, крупная рекламная кампания или запуск, узнайте предел системы заранее. Нагрузочный тест отвечает на вопрос, какую нагрузку на сайт система выдержит и что сломается первым.

Что важно в тесте:

• Реальные сценарии. Не только главная страница: поиск, карточка товара, корзина, оформление заказа, вход в кабинет.
• Копия, похожая на боевую. С таким же объёмом данных, иначе база будет летать на тесте и падать в жизни.
• Ступенчатый рост нагрузки. Чтобы увидеть точку, после которой время ответа начинает расти.
• Понятный результат. Например: «держим 800 одновременных, на 1 000 перестаёт работать оформление заказа, причина в запросе остатков».

Пример: платформа, которая переросла свою основу

Бывает, что узкое место это сама основа системы. Так было у платформы инфлюенс-маркетинга DariCrew: она выросла на связке no-code сервисов, и с ростом числа пользователей связка перестала держать нагрузку. Мы начали с аудита и поддержки старой версии, а затем перевели платформу на собственный код. После переезда она держит 2 000+ одновременных пользователей, а за весь переезд не было ни одной остановки.

Как проходил такой переезд, мы подробно описали в статье «Переезд с no-code на свой код без остановки бизнеса».

Когда звать внешнюю команду

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

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

Частые вопросы

Почему сайт падает при наплыве посетителей?

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

Поможет ли переезд на сервер мощнее?

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

Как узнать, сколько посетителей выдержит сайт?

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

Сайт тормозит, но не падает. Это тоже про нагрузку?

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

Сколько времени занимает поиск причины?

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