Работали ли вы с настройкой сети

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

Сможете ли вы поднять и починить тестовый стенд сами, не дёргая администраторов на каждый шаг, и понимаете ли, где сеть влияет на результат проверки. От этого зависит, отличите ли вы дефект приложения от криво настроенного окружения.

Как отвечать

Назовите свой реальный уровень и подкрепите его инструментами:

• адресация и имена: ip a, ip r, /etc/hosts, DNS. Половина историй «стенд не отвечает» заканчивается тем, что имя резолвится не туда;
• доступность порта: ss -tlnp на сервере, nc -vz или curl -v с машины теста. Отказ соединения и молчащий таймаут говорят о разном: в первом случае никто не слушает, во втором режет фаервол;
• перехват трафика: браузерный прокси, снифферы, подмена ответа заглушкой, установка своего корневого сертификата в доверенные;
• эмуляция плохой сети: tc netem в Linux, троттлинг и режим offline в инструментах разработчика;
• контейнеры: у docker своя сеть, и localhost внутри контейнера это не хост.

sudo tc qdisc add dev eth0 root netem delay 300ms loss 5%

Границы опыта обозначайте честно: «настраивал стенд, прокси и контейнерные сети, продовую маршрутизацию не трогал» звучит сильнее, чем размытое «работал с сетью».

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

Заводят дефект на разработчика, не проверив окружение. Прежде чем писать «сервис недоступен», нужен curl с той же машины и тот же запрос мимо приложения: очень часто дело в закрытом порте или в записи в /etc/hosts.

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

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