Ошибка 500: что она значит и что делать инженеру поддержки
«У меня сайт не работает» — самое частое обращение в поддержку и самое бесполезное по содержанию. Если в ответе сервера код 500, круг подозреваемых сразу сужается. Разберём, что делать дальше.
Что на самом деле означает 500
Коды ответа сервера делятся на группы, и группа важнее самой цифры. Коды 4xx означают, что проблема на стороне клиента: не туда постучались, не передали нужные данные, не хватило прав. Коды 5xx означают, что запрос дошёл до сервера, сервер его понял — и сломался, пока обрабатывал.
Формулировка 500 Internal Server Error переводится буквально: «внутренняя ошибка сервера». Это ответ по умолчанию, когда приложение упало и не смогло объяснить, почему именно. Для пользователя это белая страница, для вас — сигнал, что виновата ваша сторона.
Отсюда главный вывод, который экономит время: при 500 бессмысленно просить пользователя почистить кэш, сменить браузер или перезагрузить компьютер. Он ничего не сделал неправильно. Такие просьбы только раздражают и оттягивают разбор.
Чем 500 отличается от 502 и 504
Эти три кода часто путают, а различие между ними прямо указывает, куда смотреть.
- 500 — приложение запустилось, приняло запрос и упало внутри. Ищите ошибку в коде или данных.
- 502 Bad Gateway — промежуточный сервер, обычно nginx, обратился к приложению и получил бессмысленный ответ. Чаще всего это значит, что приложение не запущено или упало совсем.
- 504 Gateway Timeout — промежуточный сервер достучался, но не дождался ответа. Обычно это долгий запрос к базе или зависший внешний сервис.
Практическое правило: 500 — «сломалось внутри», 502 — «не отвечает вообще», 504 — «думает слишком долго».
Первое, что нужно сделать
Не ищите причину сразу. Сначала определите масштаб — от этого зависит, спокойно вы разбираетесь или поднимаете всех.
Проверьте, у всех или у одного
Откройте тот же адрес сами. Если ошибка воспроизводится — это общий сбой, и обращений сейчас будет много. Если у вас всё работает, проблема связана с конкретным пользователем: его данными, его правами, его действиями.
Это разделение экономит больше всего времени. Массовый сбой чинят через инженеров и эксплуатацию, единичный — разбором конкретного случая.
Зафиксируйте точное время
Спросите у пользователя, когда именно он получил ошибку, и уточните часовой пояс. Без времени вы будете искать иголку в логах за сутки. С временем — смотрите отрезок в пару минут.
Узнайте, что именно он делал
Не «что у вас не работает», а по шагам: на какой странице был, что нажал, какие данные вводил. Ошибка при сохранении формы и ошибка при открытии списка — это две разные ошибки, даже если код один.
Где искать причину
Логи приложения
Это главный и часто единственный источник фактов. Открывайте логи за то самое время и ищите запись с уровнем ERROR и трассировкой стека — она обычно прямо называет строку кода и тип ошибки.
Если логи собираются в Kibana или похожей системе, отфильтруйте по времени и по уровню, а затем добавьте идентификатор пользователя или запроса, если он у вас проставляется. Хорошо настроенное приложение отдаёт в ответе идентификатор запроса — тогда поиск занимает секунды.
Панель мониторинга
Посмотрите на графики за последний час: нагрузка на процессор, память, свободное место на диске, количество ошибок в минуту. Резкий всплеск ошибок с определённого момента почти всегда совпадает с выкаткой новой версии или с исчерпанием какого-то ресурса.
Что изменилось
Девяносто процентов внезапных пятисоток объясняются одним вопросом: что менялось перед этим. Выкатили релиз, обновили конфигурацию, изменили схему базы, у внешнего сервиса кончился сертификат. Если сбой начался в 14:30, посмотрите, что происходило в 14:25.
Частые причины
- Ошибка в новом коде, которая проявляется только на боевых данных.
- Кончилось место на диске — падает запись логов и временных файлов.
- Недоступна база данных или исчерпан пул соединений.
- Внешний сервис отвечает не тем, чего ждёт приложение.
- Истёк срок действия сертификата или токена интеграции.
- Данные конкретного пользователя ломают логику: пустое поле там, где код его не ждёт.
Последний пункт — самый частый в единичных случаях. Именно поэтому важно узнать, что именно делал пользователь.
Что написать пользователю
Пока разбираетесь, ответьте. Молчание раздражает сильнее самой ошибки.
Скажите три вещи: что проблема на вашей стороне, что вы уже занимаетесь, и когда вернётесь с ответом. Не обещайте срок, которого не знаете — обещайте следующий контакт.
«Ошибка на нашей стороне, вы всё сделали правильно. Уже разбираемся, напишу в течение часа, даже если решения ещё не будет».
Когда эскалировать
Передавайте инженерам, если: ошибка массовая, если она затрагивает оплату или потерю данных, или если вы нашли в логах трассировку, но она указывает на код приложения. Чинить чужой код — не ваша задача.
Хорошая передача содержит: время, шаги воспроизведения, идентификатор запроса или пользователя, выдержку из лога и ответ на вопрос «у всех или у одного». Такая заявка решается в разы быстрее, чем «у пользователя ошибка 500, посмотрите».
Чего делать не стоит
- Просить пользователя почистить кэш. При 500 это не помогает.
- Перезапускать сервис до того, как заглянули в логи. Перезапуск сотрёт улики и вернёт проблему через час.
- Закрывать заявку словами «всё заработало», если вы не поняли причину. Это не решённый инцидент, это отложенный.
- Пересылать инженерам скриншот белой страницы без времени и шагов.
Коротко
Код 500 означает, что сломалось у вас. Сначала определите масштаб, потом зафиксируйте время и шаги, потом идите в логи. Отвечайте пользователю до того, как нашли причину. И всегда проверяйте, что менялось перед сбоем — именно там ответ чаще всего и лежит.