Как понять, что проблема в коде сайта, а не в сервере?

Если кратко: отличить «код» от «сервера» можно по тому, что именно ломается в момент нагрузки — ресурсы и системные лимиты (CPU/RAM/дескрипторы/пулы) или сама обработка запросов в приложении (ошибки в логах, медленные запросы, блокировки). Вам не нужно «верить на слово» — достаточно собрать 3–5 типов фактов: метрики ресурсов, HTTP-коды и время ответа, логи веб-сервера, логи приложения, логи БД.

Как это устроено и где обычно «рвётся» под нагрузкой

Под нагрузкой сайт «падает» по двум крупным сценариям:

• Инфраструктурный предел: сервер не успевает обслуживать соединения (заканчивается CPU/RAM, упираетесь в лимиты процессов/соединений, очередь запросов растёт, веб-сервер/пул воркеров переполняется). В этом случае даже «хороший» код начнёт сбоить, но первопричина — нехватка ресурсов/неверные лимиты/настройки.
• Прикладная деградация: код на каждую страницу делает слишком тяжёлые операции (N+1 запросы, отсутствие кэша, долгие внешние API, блокировки в БД, утечки памяти, синхронные задачи), и при росте RPS это лавинообразно увеличивает время ответа. В этом случае ресурсы могут быть не на 100%, но запросы «висят», появляются таймауты и 5xx из-за внутренних ошибок.

Ключевой принцип диагностики: в одном и том же временном окне сопоставить пики нагрузки с метриками и логами. Без привязки ко времени спор «код или хостинг» всегда будет бесконечным.

Как самостоятельно определить источник: чек-лист по шагам

1) Зафиксируйте симптомы в терминах HTTP

• Какие коды: 502/504 (часто прокси/апстрим/таймауты), 500 (ошибка приложения), 503 (нет доступных воркеров/сервис недоступен), 499 (клиент оборвал — часто из-за долгого ответа).
• Что происходит со временем ответа: сначала растёт latency, потом начинаются ошибки — типичный признак упора в очередь/воркеры/БД.

Практически: попросите у разработчика или хостинга выгрузку access/error логов веб-сервера за проблемный интервал или хотя бы агрегаты: топ кодов, p95/p99 времени ответа, количество активных соединений.

2) Посмотрите метрики сервера в момент «падения»

• CPU: если устойчиво близко к 100% на всех ядрах — вероятно, не хватает вычислений или слишком много процессов/плохая оптимизация, но первично — упор в CPU.
• RAM: если начинается активный swap или OOM (убийство процессов) — это почти всегда причина 502/504/500.
• Диск/IO: высокий iowait и очередь диска при росте нагрузки — признак узкого места в дисковой подсистеме или тяжёлой работы с БД/логами/сессиями на диске.
• Сеть: реже, но бывает — упор в лимиты соединений, DDoS/боты, или внешние зависимости.

Если у вас managed-хостинг, запросите у поддержки графики CPU/RAM/IO/сети за точное время инцидента и события типа OOM, рестарты сервисов.

3) Проверьте лимиты и очереди веб-сервера/пула приложения

• Если 502/504: часто проблема в том, что прокси (Nginx) не дождался ответа от приложения (PHP-FPM/Node/Java) из-за таймаутов или отсутствия свободных воркеров.
• Признаки «упора в пул»: в логах формулировки вроде upstream timed out, no live upstreams, сообщения о нехватке воркеров, переполнении очереди.

Это может быть и «хостинг» (слишком маленькие лимиты), и «код» (слишком долгие запросы, которые удерживают воркеры). Отличают по следующему шагу — что делает приложение внутри.

4) Посмотрите логи приложения и БД на те же минуты

• Логи приложения: исключения, ошибки, падения процессов, сообщения про превышение времени выполнения, ошибки памяти.
• База данных: рост числа соединений, медленные запросы, блокировки/дедлоки, рост времени выполнения SQL.

Если в момент сбоя в логах приложения/БД видны конкретные ошибки или резкий рост времени SQL — это почти всегда зона ответственности кода/архитектуры (индексы, запросы, кэширование, конкуренция транзакций), даже если проявляется как 502/504 на уровне веб-сервера.

5) Быстрая развилка по типовым «сигналам»

• Сервер уходит в OOM / начинается swap → первопричина: ресурсы/лимиты или утечки памяти в приложении. Отличить утечку от нехватки просто: если память растёт «ступеньками» и не возвращается даже при падении трафика — похоже на утечку.
• CPU 100% + рост latency → либо недооценённые ресурсы, либо тяжёлые операции в коде. Дальше смотрим APM/профилирование и топ самых медленных эндпоинтов.
• Ошибки 500 с трассировками/исключениями → код/зависимости.
• 502/504 и при этом приложение «молчит», но воркеры заняты → часто медленные запросы/БД/внешние API.
• 503 при нормальных ресурсах → лимиты на число воркеров/соединений или неправильная конфигурация балансировки.

Практическая рекомендация: что сделать бизнесу за 1–3 дня

1. Включить минимальную наблюдаемость (без «больших внедрений»): сбор графиков CPU/RAM/IO, статус-коды и время ответа, логирование ошибок приложения. Важно: всё с точным временем (таймзона, синхронизация времени на серверах).
2. Договориться о едином формате инцидента: время начала/конца, симптом (коды/страницы), масштаб (сколько запросов/пользователей), что изменилось перед инцидентом (релиз, акция, рассылка).
3. Сделать повторяемый нагрузочный прогон на стейдже (или в низкий сезон на проде с ограничением): цель — не «сломать», а поймать момент деградации и зафиксировать метрики/логи.
4. Поставить APM/трейсинг (если есть возможность): чтобы увидеть, какие 3–5 операций съедают время (эндпоинт → SQL → внешние API). Без этого разработчик часто спорит на уровне ощущений.
5. Разделить зоны ответственности документом: хостинг предоставляет метрики/логи и гарантирует ресурсы; разработчик — анализ медленных запросов, оптимизацию кэша/БД/пула, исправление исключений.

Типичные ошибки, из-за которых спор «код vs сервер» не заканчивается

• Нет общей временной линии: логи в разных таймзонах, отсутствуют метрики именно на момент сбоя.
• Смотрят только на CPU и игнорируют очередь запросов, лимиты воркеров, соединения к БД, iowait.
• Лечат симптом увеличением ресурсов без поиска причины: помогает на неделю, потом проблема возвращается при следующем росте нагрузки.
• Смешивают фронт и бэк: иногда «падает сайт» — это CDN/DNS/SSL/сторонние скрипты, а сервер жив. Нужно отделять доступность HTML от полной загрузки страницы.

Если вы дадите: примерные коды ошибок (502/504/500/503), стек (PHP/Node/Java), тип хостинга (VPS/облако/managed) и есть ли БД на том же сервере — я подскажу, какие именно логи и метрики запросить в первую очередь и как интерпретировать их за один инцидент.