SorrrokaTL;DR: при ошибках 5xx на проде не стоит сразу править код наугад. Сначала нужно быстро понять, где именно ломается цепочка: веб-сервер, PHP, база, внешний API, диск, память, cron или последний релиз. Чем точнее первичная диагностика, тем меньше риск усугубить инцидент. Ошибка 5xx почти всегда выглядит для бизнеса одинаково: сайт недоступен, форма не отправляется, кабинет не открывается, оплата не проходит или клиент видит белый экран. Но технически причины могут быть совершенно разными. Поэтому самое дорогое действие — хаотично менять прод без карты инцидента.
Порядок первичной проверки
- Проверить точный код: 500, 502, 503 и 504 указывают на разные классы проблем.- Снять время инцидента: когда началось, после какого релиза, обновления, миграции или изменения DNS.- Посмотреть логи веб-сервера: Nginx, Apache, LiteSpeed или hosting error log.- Проверить PHP: fatal errors, memory limit, timeout, несовместимые версии, сломанные include/autoload.- Проверить базу: доступность, лимиты, долгие запросы, повреждённые таблицы, нехватку места.- Проверить внешние зависимости: CRM, payment API, Telegram, webhooks, SMTP, сторонние endpoints.- Проверить ресурсы: диск, inode, память, CPU, процессы, лимиты shared hosting или VPS.
Типичные ошибки при реакции на 5xx
Первая ошибка — отключить половину plugin и не записать, что именно было сделано. Вторая — редактировать production-файлы без backup. Третья — лечить только симптом: например, увеличить memory limit, хотя настоящая причина в бесконечном API-запросе или сломанном cron. Четвёртая — не проверить форму заявки после восстановления страницы.
Практический чек-лист
- Сделать текущий backup файлов и базы, если проект ещё доступен.- Зафиксировать последние изменения: релиз, обновления, импорт, перенос, правки DNS/SSL.- Открыть error log и найти первую повторяющуюся ошибку по времени инцидента.- Проверить, воспроизводится ли ошибка для всех страниц или только для формы, checkout, админки, API.- Если есть интеграции — проверить, не зависает ли внешний запрос без timeout.- После фикса проверить не только главную, но и критичные бизнес-сценарии: заявка, письмо, CRM, оплата, личный кабинет.
Когда нужен специалист
Если сайт связан с заявками, оплатами, CRM или личным кабинетом, 5xx лучше разбирать как production-инцидент. Нужны доступы к логам, файлам, базе и понимание последнего изменения. В таких задачах я обычно начинаю с диагностики и безопасного rollback-плана, а не с немедленного редактирования кода.
Как быстро сузить источник 5xx
Хорошая диагностика начинается с разделения проблемы на слои. Если 5xx возникает на всех страницах, сначала проверяются сервер, PHP runtime, база и глобальная конфигурация. Если падает только форма, checkout, личный кабинет или endpoint интеграции, вероятнее всего проблема в конкретном сценарии: обработчик формы, внешний API, права пользователя, nonce, cron или бизнес-логика plugin. Отдельно полезно сравнить поведение для обычного пользователя, администратора и незалогиненного посетителя. В WordPress часть ошибок появляется только в админке, часть — только при ajax-запросах, а часть — только при отправке формы с конкретными данными. Это сильно сокращает область поиска.
Что фиксировать во время инцидента
- точное время первой ошибки и часовой пояс логов;- URL или действие, которое вызывает сбой;- последний релиз, обновление plugin, импорт или изменение конфигурации;- первую строку fatal error, а не только последний warning;- результат проверки базы, диска и внешнего API;- какие временные действия уже предпринимались. Такая фиксация важна не для бюрократии, а для безопасности. Если несколько человек одновременно “чинят” production без журнала действий, восстановление может стать сложнее самой исходной ошибки.
Минимальный rollback-план
До правок стоит понять, что именно можно откатить: файл темы, plugin, базу, конфигурацию сервера, версию PHP или DNS. Иногда безопаснее временно отключить один обработчик или вернуть прошлую версию plugin, чем пытаться исправлять код прямо в момент пикового трафика. После восстановления важно не останавливаться на “страница открылась”. Нужно проверить бизнес-цепочку: заявка создаётся, письмо уходит, CRM получает данные, менеджер видит уведомление, а в логах нет новых fatal errors. Иначе инцидент может формально закончиться, но проект продолжит терять лиды. Смежная услуга: VPS, миграции и восстановление WordPress/PHP проектов. Если 5xx связан с кодом или legacy-логикой, также полезна страница PHP backend.
Опубликовано: 2026-03-29