Ответ
503 Service Unavailable — статусный код HTTP, означающий, что сервер временно не может обработать запрос из-за перегрузки или проведения технических работ. Это не ошибка клиента, а указание на временную проблему на стороне сервера.
Типичные причины с точки зрения тестировщика:
- Сервер или микросервис "упал".
- Балансировщик нагрузки не может направить запрос на работающий инстанс.
- Исчерпаны ресурсы (память, соединения с БД).
- Плановое техническое обслуживание.
Как тестировать и проверять:
- Мониторинг и нагрузочное тестирование: Целенаправленно создавать условия, при которых сервер может начать возвращать 503.
- Проверка Retry-After заголовка: Сервер может (но не обязан) вернуть заголовок
Retry-After, указывающий, когда повторить запрос.HTTP/1.1 503 Service Unavailable Retry-After: 3600 Content-Type: text/html - Тестирование отказоустойчивости клиента: Проверять, корректно ли клиентское приложение (или другой сервис) обрабатывает эту ошибку — использует ли retry с экспоненциальной задержкой, переключается ли на fallback-режим.
- Верификация логов: При получении 503 в тестах необходимо проверять логи сервера для установления точной причины.
Ответ 18+ 🔞
А, ну это классика, ёпта! Сидит себе пользователь, тычет в кнопку, а ему в ответ — 503 Service Unavailable. По-нашему, по-простому: «Сервер, братан, прилёг, не до тебя сейчас». Это не ты косячишь, это где-то там, на той стороне, всё накрылось медным тазом.
Что это за зверь такой? Это когда сервер такой: «Э, сабака сука, овердохуища запросов, я больше не могу!» Или его админы на время вырубили, чтобы что-то починить. Короче, проблема не у тебя, а у них. Но понимать-то от этого легче не становится, когда твоё приложение встало колом.
Из-за чего обычно бывает? Глазами тестировщика:
- Сервис или микросервис просто взвыл и лёг. Как будто его вырубили.
- Балансировщик нагрузки, этот хитрая жопа, бегает туда-сюда, а живого сервера не находит.
- Закончилась память, кончились подключения к базе — ресурсов ноль ебать.
- Плановые работы, всем известные, но всем же мешающие.
И как эту хрень ловить и проверять?
- Устроить ад. Самый честный способ — это нагрузочное тестирование. Надо давить на систему, пока она не захрипит и не начнёт плеваться этими самыми 503-ми. Если не падает — молодцы. Если падает — ну, ебать копать, есть над чем работать.
- Ловить заголовок
Retry-After. Сервер может, если не совсем пидарас шерстяной, подсказать, когда вернуться. Типа: «Отстань на час, потом приходи».HTTP/1.1 503 Service Unavailable Retry-After: 3600 Content-Type: text/htmlПроверяй, шлёт ли он эту бумажку. А то бывает, ошибку кинул, а когда ждать — не сказал. Доверия ебать ноль к такому.
- Смотреть, как клиент охуевает. Самое важное! Твоё приложение или соседний сервис, получив 503, не должно просто сдохнуть. Оно должно э бошка думай: «Ладно, щас отстану, а через секундочку спрошу ещё разок». И так несколько раз, с паузами. А если всё совсем плохо — перейти в аварийный режим. Надо тестить, как он это делает.
- Копаться в логах. Получил в тестах 503 — это полдела. Надо лезть в логи сервера и смотреть, какого хуя это произошло. Может, память кончилась, а может, кот сука собака на провода наступил. Без логов ты так и останешься в дураках.
Вот и вся магия. Статус как бы говорит: «Не ты мудя, а я временно пизда рулю. Подожди чутка». Задача тестировщика — убедиться, что это «чутка» не превращается в вечность, и что все вокруг умеют эту ситуацию переживать.
