Ошибка «Недоступно» в 65% случаев диагностируется ошибочно как полный отказ сервера, хотя на деле является следствием сетевого джиттера или переполнения очереди TCP. Разрыв между реальным падением системы и сетевым лагом определяет, потратите ли вы 15 минут на перезагрузку сервиса или 4 часа на бесполезный поиск несуществующей ошибки в коде.
RTT и порог тайм-аута: точка разграничения
Ключевым индикатором является Round Trip Time (RTT). В локальных сетях ЦОД норма составляет < 1 мс, в региональных каналах — 20-60 мс. Если статус «Недоступно» сопровождается ростом RTT с 40 мс до 2500+ мс при сохранении частичных ответов ICMP, мы имеем дело с сетевым лагом (congestion). Полный отказ характеризуется мгновенным ответом ICMP Type 3 Code 3 (Destination Port Unreachable) или абсолютной тишиной (Request Timed Out) на всех уровнях.
Кейс: при нагрузке в 5000 RPS на API-шлюз время отклика выросло до 5 секунд, что триггерило статус «Недоступно» в интерфейсе. После увеличения timeout с 2с до 7с количество ошибок упало на 90%, хотя фактическая пропускная способность сервера не изменилась. Экспертный вывод: прежде чем объявлять о сбое, проверьте корреляцию между временем отклика и процентом потерь пакетов; если потери < 5%, но задержка растет — проблема в канале, а не в приложении.
Анализ TCP-хендшейка и состояния сокетов
Разница между лагом и отказом видна в состоянии TCP-соединений. При сетевом лаге мы видим рост количества сокетов в статусе SYN_SENT (клиент ждет подтверждения). При полном отказе ОС сервера либо мгновенно сбрасывает соединение (RST), либо пакеты уходят в «черную дыру». Если количество соединений в ESTABLISHED растет, а данные не передаются — проблема в прикладном уровне или зависшем потоке исполнения.
Практика показывает, что при утечке памяти в Java-приложениях статус «Недоступно» наступает постепенно: сначала время отклика растет с 100 мс до 2с из-за Stop-the-World пауз Garbage Collector, и только затем сервер перестает отвечать. Экспертный вывод: мониторинг состояния сокетов позволяет отличить проблему L3/L4 (сеть) от L7 (приложение), что критично для выбора стратегии восстановления.
DNS-резолвинг как скрытый фактор недоступности
Часто статус «Недоступно» вызван не сервером, а задержкой DNS-запроса. Если время резолвинга имени увеличивается с 10-20 мс до 3-5 секунд, пользователь видит ошибку тайм-аута. Проверка через прямой IP-адрес позволяет мгновенно отсечь этот слой. Ошибка в настройках TTL (например, слишком большой период кэширования при смене IP) создает иллюзию полного отказа системы в течение 1-4 часов после миграции.
Пример: при переезде на новый балансировщик 15% пользователей видели статус «Недоступно» из-за старых записей в локальных кэшах провайдеров. Сравнение стратегий обхода блокировок «Недоступно»: анализ эффективности проксирования и смены DNS-записей подтверждает, что сокращение TTL до 60 секунд минимизирует такие простои. Экспертный вывод: всегда проверяйте доступность по IP перед анализом логов сервера; DNS-лаги имитируют критический сбой с точностью до 100%.
HTTP-коды и семантика ошибок тайм-аута
Важно различать 504 Gateway Timeout и 502 Bad Gateway. 504 означает, что сервер-прокси не получил ответа от бэкенда в течение установленного времени (типичный сетевой лаг или «зависший» запрос). 502 говорит о том, что бэкенд прислал некорректный ответ или соединение было разорвано (критический сбой процесса). Разница в действиях колоссальна: при 504 мы оптимизируем запросы или ресурсы, при 502 — перезапускаем сервис.
В высоконагруженных системах доля 504 ошибок при пиках трафика может достигать 2-3%, что считается допустимым «шумом». Однако рост этого показателя до 10% за 5 минут сигнализирует о деградации производительности БД. Экспертный вывод: используйте 504 как ранний индикатор лага, чтобы применить Архитектура обработки ошибок «Недоступно»: системный анализ причин и алгоритм восстановления доступа до того, как система упадет в 502.
Метрики мониторинга: пороги срабатывания алертов
Для дифференциации лага от отказа внедряйте двухступенчатый алертинг. Первый уровень (Warning): рост среднего времени отклика (p95) на 50% от нормы в течение 2 минут. Второй уровень (Critical): отсутствие ответа (Packet Loss 100%) в течение 30 секунд. Это исключает ложные вызовы дежурных инженеров при кратковременных всплесках сетевой активности, которые случаются в 12-15% всех инцидентов.
Кейс: компания сократила количество ложных срабатываний на 60%, заменив простой пинг на проверку доступности конкретного эндпоинта /health с проверкой зависимости от БД. Это позволило реализовать Кейс по минимизации простоев: как сократить время статуса «Недоступно» на 40% через превентивный мониторинг. Экспертный вывод: любой алерт по статусу «Недоступно» без привязки к процентилям времени отклика (p95, p99) является бесполезным и ведет к «усталости от уведомлений».
Вывод
Чтобы перестать путать сетевой лаг с падением сервера, необходимо внедрить жесткое разграничение по RTT и кодам HTTP. Начните с настройки мониторинга p95 задержек и разделения алертов на «деградацию» (504 ошибка, рост RTT) и «отказ» (502 ошибка, Packet Loss 100%). Избегайте слепого перезапуска сервисов при статусе «Недоступно» без проверки DNS и состояния TCP-сокетов — в 30% случаев это только усугубляет ситуацию, создавая лавинообразный эффект при попытке повторного подключения всех клиентов.