Service Unavailable

Диагностика и исправление ошибки 503 на сайте

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

Временная недоступность

Почему сервис
не принимает запрос

RFC 9110 связывает 503 с временной перегрузкой или обслуживанием и допускает заголовок Retry-After. Однако сам код не доказывает конкретную причину: её определяем по метрикам, журналам и состоянию зависимостей.

01

Режим обслуживания

Проверяем служебный файл или флаг CMS, незавершённое обновление, деплой и правила временной страницы.

02

Нагрузка

Сопоставляем всплеск запросов с CPU, памятью, диском, соединениями, лимитами хостинга и временем ответа.

03

Воркеры и очереди

Проверяем число процессов, занятые воркеры, зависшие задачи, длину очереди и политику перезапуска.

04

База и зависимости

Проверяем пул соединений, блокировки, кэш, поиск, внешний API и другие обязательные сервисы.

05

Ответ для клиента

Проверяем корректность кода, страницы обслуживания, кэширования и Retry-After, если время восстановления известно.

06

Устойчивость

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

Диагностика 503

Как отличаем перегрузку от ошибки приложения

Код 503 означает временную недоступность, но источник бывает на разных уровнях: веб-сервер, PHP, база, контейнер, прокси или внешний сервис. Сначала определяем, кто сформировал ответ.

01

Время и охват

Сопоставляем момент сбоя с журналами, мониторингом и заданиями cron. Проверяем весь сайт, административную панель и отдельные тяжёлые URL.

02

Ресурсы сервера

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

03

PHP и база данных

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

04

Прокси и интеграции

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

Безопасное восстановление

Что проверяем перед закрытием инцидента

Достаточно ли перезапустить сервис?

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

Как тестируем исправление?

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

Что остаётся после работы?

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

Результат

Сервис снова обрабатывает запросы

Восстановленная доступность

Критические страницы и операции возвращают ожидаемые ответы.

Понятная ёмкость

Известен ограничивающий ресурс или зависимость.

Контроль повторения

Настроен сигнал по коду, очереди, ресурсам или состоянию процессов.

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

От восстановления к профилактике

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

01

Оцениваем масштаб

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

02

Сохраняем данные

Фиксируем журналы, метрики, список процессов и очередей до перезапуска или изменения лимитов.

03

Восстанавливаем

Завершаем зависшее обслуживание, возвращаем процесс или освобождаем подтверждённый ограничивающий ресурс.

04

Предотвращаем повтор

Исправляем причину, настраиваем мониторинг и проверяем сценарий повторно.

Важно

Масштабирование не всегда лечит причину

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

Для диагностики подготовьте

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

Увеличение тарифа или покупку инфраструктуры предлагаем только при подтверждённой потребности и не выполняем без отдельного согласования.

Вопросы

Перед исправлением

Что означает 503?

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

Нужно просто ждать?

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

Чем 503 отличается от 502?

503 сообщает о временной неготовности сервиса. 502 означает, что шлюз получил некорректный ответ от другого сервера.

Когда нужен Retry-After?

При ожидаемой временной недоступности сервер может сообщить срок повторной попытки. Он должен соответствовать реальному сценарию восстановления.

Первый шаг

Покажите ошибку 503

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