Как системный аналитик может проверить сетевую доступность endpoint?

Что проверяют

Умеете ли вы диагностировать сеть по слоям и отличаете ли «сервер недоступен» от «сервер ответил ошибкой». Для инженера данных вопрос почти всегда практический: DAG в Airflow падает на подключении к API или базе, и нужно быстро понять, где сломалось. Следом спрашивают, как проверить доступность изнутри контейнера.

Как отвечать

Идите снизу вверх, каждый шаг отвечает на свой вопрос:

• DNS: nslookup host или dig host. Имя не резолвится, дальше можно не идти;
• TCP-порт: nc -vz host 443, в Windows Test-NetConnection host -Port 443. Для баз есть свои утилиты, например pg_isready -h host -p 5432;
• TLS: openssl s_client -connect host:443 покажет, в порядке ли сертификат и цепочка;
• HTTP: curl -v https://host/health даёт код ответа, заголовки и время. Ключ --max-time не даст команде висеть бесконечно;
• маршрут: traceroute или mtr, если нужно понять, на каком узле теряются пакеты.

Результат читают так: connection refused значит, что хост доступен, но порт никто не слушает; таймаут чаще всего означает, что пакеты молча отбрасывает файрвол или security group; 401 и 403 говорят, что сеть в порядке, а проблема в доступе.

Проверять нужно оттуда, откуда будет ходить код: из воркера Airflow, пода (kubectl exec) или контейнера. Ноутбук может видеть endpoint через VPN, а сервер нет. Учитывайте и переменные HTTPS_PROXY и NO_PROXY. В коде та же проверка делается через socket.create_connection((host, port), timeout=3) или requests.get(url, timeout=5), а постоянный контроль отдают мониторингу: Prometheus с blackbox exporter или Zabbix.

Где спотыкаются

Ограничиваются ping. ICMP часто закрыт, и отсутствие ответа ничего не говорит о доступности HTTP-порта.

Проверяют со своей машины и делают вывод про продовый сервер.

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