Сайт отдаёт 502 в часы рекламы: как найти причину аудитом сервера

Аудит серверной части сайта проверяет, как сервер держит нагрузку: время ответа, память и процессор, настройки веб-сервера и PHP, базу данных, SSL, логи и резервные копии. Он объясняет, почему сайт тормозит или отдаёт ошибки 502 и 504, и заканчивается списком правок с приоритетами.

Почему возникает ошибка 502 на сайте именно в часы наплыва 🚦

Понедельник, 10:00. Маркетолог включил рекламу на новую акцию, и через четверть часа на сайт пошёл поток, к которому он не готов. Директор открывает главную со своего телефона: всё летает. Клиент нажимает «Оставить заявку» и получает 502 Bad Gateway.

Сервер при этом не упал. Веб-сервер принимает запросы, но передать их некому: у PHP-FPM закончились свободные процессы, все заняты долгими запросами к базе. Новые запросы встают в очередь и отваливаются по таймауту. Ошибка 504 работает по тому же механизму, просто таймаут срабатывает раньше, чем приходит ответ. Директор проблему не видит, потому что главную отдаёт кэш, а форма заявки идёт через PHP и базу.

Что обычно стоит за такой очередью:

• ✓запрос к базе без индекса держит процесс несколько секунд, а в пик таких запросов десятки;
• ✓на общем хостинге соседний сайт забирает процессор, и лимиты тарифа режут ваш;
• ✓выгрузка каталога по cron стартует в 10:00 и отнимает память у того же сервера;
• ✓боты и парсеры создают нагрузку, которой нет в Метрике, потому что многие из них не исполняют скрипт счётчика.

Что теряет бизнес, пока очередь не разобрана. Рекламный бюджет оплачивает клики в страницу с ошибкой. Заявки пропадают молча: форма не отправилась, клиент ушёл к конкуренту, в CRM пусто, а в отчёте маркетолога «трафик есть». Поисковик, встречая повторяющиеся ошибки 5xx, реже заходит на сайт, и новые страницы дольше попадают в выдачу. Если сервер лёг ночью, вы узнаете об этом утром из письма клиента.

Что проверяют при аудите серверной части сайта 🔍

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

Ресурсы и время ответа

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

Веб-сервер, PHP и кэш

Проверяют число процессов PHP-FPM, лимиты памяти, таймауты nginx или Apache, версию PHP (поддерживает ли её разработчик), включён ли OPcache, работают ли кэш страниц и сжатие. Типичная находка: на сервере с большим запасом памяти стоят настройки по умолчанию, рассчитанные на маленький сайт.

База данных

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

Безопасность и SSL

Срок действия сертификата и автопродление, открытые порты, доступ по SSH, права на файлы, устаревшие CMS и плагины. Отдельный вопрос: где физически лежит база с заявками. Если форма собирает ФИО и телефоны граждан РФ, действует требование 152-ФЗ о хранении таких данных на серверах в России.

Логи и резервные копии

В error.log и access.log считают, сколько запросов заканчивается ответом 5xx и с каких адресов идёт аномальный трафик. Проверяют бэкапы: делаются ли они, лежат ли вне основного сервера и разворачивал ли их кто-нибудь. Копия, которую ни разу не восстанавливали, остаётся предположением.

Серверную часть мы проверяем в аудите сайта по 9 направлениям, поэтому сервер не изучают отдельно от остального сайта.

Как исправить медленный ответ сервера и ошибки 502 и 504 🛠️

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

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

Кэш страниц и объектов снимает с PHP основную массу повторных запросов, так что его включают раньше, чем меняют тариф. Для каталога с персональными ценами кэш настраивают аккуратно, иначе клиент увидит чужие данные.

Что можно сделать за вечер без администратора

• ✓включить кэш страниц в CMS;
• ✓посмотреть дату окончания SSL-сертификата и настроить оповещение;
• ✓проверить, где лежит последний бэкап, и скачать копию к себе;
• ✓найти в кабинете хостинга лимиты по процессору и памяти, которые действуют на вашем тарифе.

Что делать, если ошибка повторяется 🔁

Настройки поменяли, а через неделю снова 502, в другой день и при другой рекламе. Так бывает, когда чинили следствие. Перезапуск PHP-FPM убирает симптом на несколько часов, но утечку памяти в плагине не лечит, поэтому очередь копится заново. Второй вариант: нагрузка выросла выше того, что выдерживает тариф, и настройки этого не изменят.

Порядок действий:

1. ✓Сохраните логи и время инцидента сразу. Ротация затирает старые записи, а по свежим причину видно.
2. ✓Поставьте мониторинг на страницу заявки, а не на главную. Главная отвечает 200, пока форма лежит.
3. ✓Сравните график нагрузки с лимитами тарифа. Если процессор или память в пик упираются в потолок, нужен другой тариф или сервер.
4. ✓Если потолка нет, а очередь есть, отдайте разработчику конкретные запросы и страницы вместо формулировки «сайт тормозит».

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

Если упёрлись в потолок, чаще всего выбирают VPS или выделенный сервер. Перенос — работа системного администратора: развернуть окружение, скопировать базу, переключить DNS с минимальным простоем. Час администратора у нас стоит 3800 ₽/час, актуальные условия смотрите на странице цены и тарифы. Причину мы ищем до переезда: если виноват индекс, переезд только удорожит хостинг.

Как предотвратить падения сайта в пик нагрузки ✅

Большинство инцидентов повторяется по одному сценарию, поэтому профилактика скучная и работает.

• ✓Мониторинг доступности ключевых страниц (заявка, корзина, оплата) раз в минуту, оповещения дежурному в Telegram.
• ✓Нагрузочный тест перед крупной рекламной кампанией: лучше найти потолок в четверг, чем в понедельник в 10:00.
• ✓Договорённость между маркетологом и администратором: о запуске рекламы сообщают заранее.
• ✓Обновления PHP, CMS и плагинов по расписанию, сначала на копии сайта.
• ✓Бэкап вне основного сервера и пробное восстановление раз в квартал.
• ✓Тяжёлые cron-задачи ночью, с ограничением по ресурсам.

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

Что вы получите по итогам аудита и во что он обойдётся 📋

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

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

Серверная часть проверяется вместе с остальными направлениями: заказать аудит сайта. Правки считаются по часам системного администратора, 3800 ₽/час, и итоговую сумму видно до начала работ.

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

Какой доступ нужен для аудита серверной части сайта?

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

Чем аудит серверной части отличается от SEO-аудита?

SEO-аудит проверяет контент, структуру, теги и ссылки. Серверный аудит смотрит, как сайт отвечает людям и поисковым роботам: время ответа, ошибки 5xx, настройки и базу данных. Они дополняют друг друга: хороший контент не даст позиций, если сервер регулярно отдаёт роботу 502 при обходе.

Как понять, что тормозит сервер, а не сам сайт?

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

Поможет ли переезд на VPS, если сайт тормозит?

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

Сколько стоит исправление проблем, найденных при аудите?

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