После перезапуска сайт может снова открываться, хотя причина ошибки 503 остается неизвестной. Чтобы не повторять этот цикл, нужно зафиксировать, кто возвращает ответ и что происходит с приложением в момент отказа.
Кто возвращает 503: приложение, сервер или промежуточный сервис
Ошибка 503 на сайте означает временную неспособность обработать запрос: например, из-за перегрузки или планового обслуживания. Так статус определен в HTTP Semantics, RFC 9110; обещания автоматического восстановления в нем нет.
Между посетителем и приложением могут находиться CDN, защитный сервис, балансировщик и веб-сервер. Поэтому надпись Service Unavailable сама по себе не показывает, какой компонент отказал. Специалист сопоставляет ответ посетителю с журналами каждого участвующего слоя за то же время: дошел ли запрос до приложения, что оно вернуло и где появился 503.
Есть и более узкие причины. Например, модуль ограничения частоты запросов nginx по умолчанию возвращает 503 при отклонении запроса; код настраивается через limit_req_status. Это описано в документации nginx. Сначала нужно подтвердить, что сработало именно это правило.
Данные, которые стоит сохранить до перезапуска
Главная, каталог и отправка формы могут вести себя по-разному: сообщение «сайт лежал утром» слишком широко для поиска в журналах. Для начала достаточно собрать:
- точный адрес страницы, время и часовой пояс;
- действие перед ошибкой: открытие страницы, поиск, отправка формы;
- видимый текст ошибки и, если доступен, идентификатор запроса;
- какие еще страницы не открываются и когда сайт в последний раз работал;
- время недавнего обновления, импорта, смены настроек или перезапуска.
Специалисту нужны журналы запросов и ошибок, состояние служб и показатели нагрузки за этот интервал. Данные желательно сохранить до перезапуска, если это не задерживает необходимое восстановление. В частности, показатели страницы статуса PHP-FPM относятся к отдельному пулу и сбрасываются при его перезапуске — это прямо указано в документации PHP.
При передаче материалов убирают пароли, cookies, токены и персональные данные.
Режим обслуживания: плановые работы или сбой
Сначала уточняют, проводятся ли согласованные работы и кто отвечает за их завершение. У обслуживания должны быть причина, ожидаемое окончание и проверка после включения сайта. Если никто не запускал работы, одна надпись о техническом обслуживании не доказывает, что происходящее запланировано.
После обновления специалист проверяет, завершился ли процесс и соответствует ли режим обслуживания фактическому состоянию приложения. Отключать его вслепую опасно: за заглушкой может оставаться незавершенное изменение данных. Выход из обслуживания возможен после проверки работ или согласованного отката.
Затем проверяют связь веб-сервера с приложением и его готовность обрабатывать запросы. Существование процесса еще не подтверждает работоспособность нужной страницы. Для PHP-FPM в том числе сверяют адрес или сокет подключения и права доступа; назначение этих параметров приведено в документации конфигурации FPM. Проверки выполняет специалист, без открытия служебных адресов посетителям.
Нагрузка, процессы и зависимости в момент отказа
Смотреть нужно на момент появления 503 и предшествующий интервал. Сопоставляют входящие запросы, занятые процессы, память, процессор, дисковые операции и обращения к базе данных. Отдельно отмечают фоновые задания: отказ, совпадающий с импортом, дает проверяемую гипотезу, но еще не доказывает его виновность.
Для PHP-FPM полезны очередь ожидающих запросов, число активных и свободных процессов, признак достижения лимита процессов. Эти показатели описаны на странице статуса FPM. Их сравнивают во времени: накопленный признак достижения лимита не говорит, что лимит был достигнут именно во время последней жалобы.
Если процессы заняты, выясняют чем: вычислениями, запросами к базе или ожиданием внешнего сервиса. Низкая загрузка процессора не отменяет такой проверки. Увеличение числа процессов обсуждают только вместе с доступной памятью и возможностями зависимостей, иначе дополнительная параллельная работа может усилить нагрузку на них.
Условный пример задачи специалисту: проверить, совпадают ли отказы с запуском импорта, определить, где растет ожидание, и предложить изменение с возможностью отката. Проблему производительности можно вынести в работу по ускорению сайта после восстановления доступности.
Восстановление по подтвержденной причине
Восстановление выбирают по подтвержденной причине. Завершенное обслуживание позволяет вернуть обычный режим; ошибка недавнего изменения может потребовать проверенного отката; остановленная служба — запуска после выяснения причины остановки. При перегрузке рассматривают временную приостановку конкретного фонового задания или ограничение источника лишних запросов.
До действия фиксируют, что именно меняют, ожидаемый эффект и способ отмены. Не стоит одновременно перезапускать все службы, менять лимиты и отключать расширения: после этого трудно понять, какое действие помогло. Если перезапуск необходим для срочного возврата сайта, сохраняют доступные данные и отмечают его как меру восстановления, а не установленную причину сбоя.
После вмешательства проверяют ранее падавший адрес и пользовательское действие, а не только главную страницу. Открывшаяся форма еще не подтверждает ее отправку, а загрузка каталога — работу поиска. Проверки с записью данных проводят контролируемо, чтобы не создавать повторные заказы и платежи.
Как проверить повторяемость и настроить наблюдение
Наблюдение должно охватывать условия прежнего отказа: период посещаемости, фоновое задание или конкретную операцию. Если сайт упал при импорте, отсутствие ошибок сразу после перезапуска не проверяет эту гипотезу. Повторную проверку планируют с учетом риска; намеренно воспроизводить тяжелую нагрузку на рабочем сайте без согласования не нужно.
Для внешнего контроля выбирают значимые страницы и проверяют не только код ответа, но и ожидаемое содержимое. Внутренние показатели помогают объяснить сигнал: время ответа, число 503, очередь обработки, состояние процессов и зависимостей. У уведомления должны быть получатель и порядок действий.
Итог диагностики — установленный источник 503, подтверждающие его данные, выполненное изменение и результат наблюдения в нужных условиях. Если причина пока не найдена, это так и записывают вместе с планом сбора данных при повторении. Статус «доступность восстановлена» не объясняет причину отказа.