Какие знаешь статусы ответов?

Статусы HTTP-ответов: классификация и практическое применение в DevOps

В контексте DevOps понимание HTTP-статусов критически важно для мониторинга, отладки, автоматизации и обеспечения SLA (Service Level Agreement). Статусы разделены на пять классов по первой цифре трехзначного кода.

1xx: Информационные (Informational)

Эти статусы указывают на промежуточный этап обработки запроса. В современном вебе встречаются реже, но важны для некоторых продвинутых протоколов.

• 100 Continue: Сервер получил заголовки запроса и клиент может продолжать отправлять тело. Часто используется с Expect: 100-continue.
• 101 Switching Protocols: Сервер соглашается сменить протокол, например, с HTTP на WebSocket (важно для реального времени).
• 102 Processing (WebDAV): Указывает, что сервер обрабатывает запрос, но ответ еще не готов.

# Пример в логах Nginx/Apache или при отладке curl
$ curl -H "Expect: 100-continue" --data-binary @largefile.xml http://api.example.com

2xx: Успех (Success)

Запрос был успешно получен, понят и обработан.

• 200 OK: Базовый статус успешного запроса. Тело ответа содержит запрошенные данные.
• 201 Created: Успешно создан новый ресурс (часто в ответ на POST). В заголовке Location должен возвращаться URI ресурса.
• 202 Accepted: Запрос принят на обработку, но она еще не завершена (асинхронные задачи, очереди).
• 204 No Content: Сервер успешно выполнил запрос, но не возвращает контент (например, после DELETE).

# DevOps-скрипт для проверки успешности деплоя (пример на Python)
import requests
response = requests.get("https://api.service.com/health")
if response.status_code == 200:
    print("Сервис здоров. Продолжаем деплой.")
else:
    raise Exception(f"Health check failed with status: {response.status_code}")

3xx: Перенаправление (Redirection)

Требуются дополнительные действия для завершения запроса.

• 301 Moved Permanently: Ресурс навсегда перемещен на новый URI. Критически важно для SEO и кеширования.
• 302 Found / 307 Temporary Redirect: Ресурс временно доступен по другому URI. 307 сохраняет исходный HTTP-метод.
• 304 Not Modified: Ответ не был изменен с момента последнего запроса (кэширование на стороне клиента). Экономим трафик и CPU.

# Конфигурация перенаправления в Nginx (частая задача DevOps)
server {
    listen 80;
    server_name old.example.com;
    return 301 https://new.example.com$request_uri; # Постоянный редирект с сохранением пути
}

4xx: Ошибка клиента (Client Error)

Запрос содержит ошибку со стороны клиента (неправильный синтаксис, неавторизованный доступ).

• 400 Bad Request: Сервер не может обработать запрос из-за неверного синтаксиса. В DevOps логах сигнализирует о проблемах в клиентских приложениях или API-вызовах.
• 401 Unauthorized: Требуется аутентификация.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (нет прав).
• 404 Not Found: Самый известный статус. Ресурс не найден. Рост 404-ок может указывать на битые ссылки после редеплоя.
• 429 Too Many Requests: Клиент превысил лимит запросов (защита от DDoS, реализация rate limiting).

# Мониторинг 4xx ошибок в логах — ключевая задача
tail -f /var/log/nginx/access.log | grep '" 4'
# Или с помощью Prometheus/Grafana алертим на всплеск 4xx-кодов

5xx: Ошибка сервера (Server Error)

Сервер не смог выполнить допустимый запрос. Это прямые индикаторы проблем инфраструктуры или кода, за которые отвечает DevOps/SRE.

• 500 Internal Server Error: Общая ошибка сервера, когда иное более специфичное сообщение не подходит (падение приложения, ошибка конфигурации).
• 502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недействительный ответ от вышестоящего сервера (проблемы с upstream в Nginx, "упал" бэкенд).
• 503 Service Unavailable: Сервис временно недоступен (перегрузка, плановое техобслуживание). Часто сопровождается заголовком Retry-After.
• 504 Gateway Timeout: Таймаут при ожидании ответа от upstream-сервера (медленная БД, исчерпаны ресурсы).

# Пример алерта в Prometheus Alertmanager для 5xx ошибок
groups:
  - name: service_errors
    rules:
    - alert: High5xxErrorRate
      expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 0.05 # Более 5% 5xx-ответов
      for: 2m
      annotations:
        description: "Сервис {{ $labels.service }} генерирует {{ $value }}% 5xx ошибок."
        severity: critical

Практическое значение для DevOps инженера

• Мониторинг и алертинг: Мы настраиваем сбор метрик (например, через Prometheus) по кодам ответов, особенно 5xx и 4xx. Резкий рост 502/503 может указывать на проблемы с контейнерами или балансировщиком нагрузки.
• Логирование и анализ: Структурированные логи (JSON) с полем status_code агрегируются в ELK Stack или Loki для оперативного поиска корня проблемы.
• Автоматизация и CI/CD: В пайплайнах сборки и тестирования мы проверяем, что эндпоинты возвращают ожидаемые статусы (например, 200 для health-check, 401 без токена).
• Работа с кешем и CDN: Понимание различий между 301 и 302, а также значение 304 критично для настройки кеширования и сокращения нагрузки на backend.
• Диагностика инцидентов: Сочетание статусов (например, 502 на LB и 503 на бэкенде) быстро направляет расследование в нужное русло — к инфраструктуре или коду приложения.

Таким образом, для DevOps инженера эти коды — не просто теория протокола, а основной язык общения инфраструктуры, ключевые метрики здоровья системы и отправные точки для расследования любых инцидентов.