Чек-лист проверки связности до запуска проекта: один день, который спасает месяц

MAATRIX

Новый сервер поднят, приложение задеплоено, домен смотрит куда надо — и хочется сразу открыть проект миру. Но большинство сетевых проблем, которые потом два месяца разгребают ночами, закладываются именно на этом шаге: пока трафика мало, никто не заметит ни лишние 200 мс до части аудитории, ни то, что сервер унаследовал чужой бан-лист, ни что «резервный канал» существует только в презентации хостера. Один день на структурную проверку связности до запуска обычно стоит меньше, чем один день разбора инцидента после.

Почему это отдельный этап, а не часть общего тестирования

Функциональное тестирование отвечает на вопрос «работает ли код». Проверка связности отвечает на другой вопрос: «будет ли то, что работает у вас на сервере, одинаково хорошо доступно из тех точек, откуда придёт реальная аудитория, и переживёт ли сервер типовые сетевые неприятности — потерю пакетов на маршруте, отказ аплинка, попадание IP в чужой бан-лист».

Это разные плоскости. Приложение может отдавать 200 OK за 20 мс с самого сервера — и одновременно быть недоступным трети аудитории из-за маршрутизации, которая заворачивает трафик через перегруженный транзитный узел. Домен может резолвиться правильно с вашего ноутбука — и одновременно иметь TTL в сутки, из-за которого смена IP при аварии докатится до части пользователей только на следующий день. Всё это не баги приложения, их не поймает CI, и без отдельного чек-листа они всплывают только на реальном трафике — то есть после запуска, когда цена ошибки уже включает репутационные потери.

Ниже — семь пунктов, которые стоит закрыть до того, как вы разошлёте ссылку на проект первым пользователям, подключите домен к продакшену или запустите email-рассылку с нового сервера.

Латентность и доступность от реальной аудитории

Первая ошибка — проверять доступность сервера только с той машины, с которой вы его администрируете. Если сервер стоит в Лондоне, а вы тоже сидите в Европе, пинг в 15 мс ничего не скажет о том, как до сервера доходит трафик из Юго-Восточной Азии или с восточного побережья США — если именно там часть вашей аудитории.

Правильный порядок: сначала оценить географию аудитории (даже приблизительно — по языку интерфейса, по таргетингу рекламы, по географии похожих проектов), затем измерить задержку и доступность именно из этих точек, а не из точки, откуда удобно администрировать. Подробный план такого замера на неделю — с перцентилями, а не средними значениями, и с инструментами для распределённых измерений — описан в статье про выбор локации по замерам аудитории. Если сервер уже выбран и переносить его поздно, тот же набор инструментов пригодится для другой задачи — заранее понять, каким регионам будет тяжелее, и учесть это в SLA, в кэшировании статики через CDN или в честном предупреждении пользователям, а не узнавать об этом из жалоб через месяц.

Если проект рассчитан на длительную работу, разовым замером в день запуска ограничиваться не стоит — сеть меняется, маршруты перестраиваются, у провайдеров бывают деградации, которые не видны в моменте, но накапливаются. Настройка постоянного мониторинга из нескольких городов — отдельная задача, которая разобрана в статье про мониторинг связности из нескольких точек: она объясняет, почему проверка из одной точки не отличает локальную аварию провайдера от системной проблемы вашего сервера, и как эту разницу увидеть на графике, а не гадать.

Потери пакетов на маршруте: mtr на длинном интервале

Разовый ping или traceroute с сервера — это снимок за секунду. Он не покажет периодическую потерю пакетов, которая проявляется под нагрузкой, в часы пик у транзитного провайдера или из-за флаппинга где-то на маршруте. Такие потери убивают TCP-производительность (retransmit, снижение окна) задолго до того, как станут заметны в виде явных таймаутов, и именно они чаще всего оказываются причиной «сайт иногда подтормаживает, но непонятно почему».

Правильная проверка — не разовый traceroute, а mtr, запущенный на несколько часов (в идеале — сутки, захватив разные периоды нагрузки), с сохранением отчёта:

mtr --report --report-cycles 500 --report-wide example.com > mtr_report.txt

Для длительного прогона удобнее собирать в фоне и логировать через cron или systemd timer, а не держать терминал открытым:

mtr --report --report-cycles 200 8.8.8.8 >> /var/log/mtr-daily.log

Ключевая грабля здесь — не путать потери на промежуточных хопах с реальными потерями до конечного узла. Многие маршрутизаторы намеренно ограничивают частоту ответов на ICMP (rate limiting) и в отчёте mtr показывают Loss% 20-40% на середине маршрута, при этом на последнем хопе Loss% честные 0%. Как читать колонки Loss%, Avg, Best, Wrst, StDev и не обвинить транзитный узел в проблеме, которой на самом деле нет, подробно разобрано в статье про mtr вместо traceroute. Перед запуском стоит прогнать mtr в обе стороны — от сервера до нескольких внешних точек и, если есть возможность, от внешних точек до сервера — чтобы увидеть асимметрию маршрута, которая тоже встречается чаще, чем кажется.

Репутация выделенного IP и подсети

Это пункт, который чаще всего пропускают — и который может обнулить весь запуск, если проект связан с email-рассылками, регистрацией пользователей или интеграциями, куда письма критичны (подтверждение почты, восстановление пароля, транзакционные уведомления). Выделенный IP, который вы только что получили от хостера, не гарантированно чист: у большинства провайдеров IP-адреса переиспользуются, и если предыдущий арендатор подсети рассылал спам или держал скомпрометированный сервер, вся подсеть могла попасть в общие бан-листы — Spamhaus, SORBS, репутационные базы почтовых провайдеров.

Проверка перед запуском:

• Пробить свежий IP через несколько DNSBL-сервисов (mxtoolbox.com/blacklists.aspx, multirbl.valli.pp.fr) — не только сам IP, но и соседние адреса в /24, если есть возможность узнать диапазон.
• Если проект будет отправлять почту — проверить репутацию до подключения продакшен-домена, а не после первой волны писем, которая уйдёт в спам.
• Настроить SPF, DKIM, DMARC для домена рассылки заранее, а не постфактум, когда часть писем уже потеряна.

Механика того, почему сервер расплачивается за чужие грехи по подсети, и как это диагностировать до того, как проблема аукнется на реальной рассылке, разобрана в статье про блокировку по чужому бан-листу. Если IP оказался в плохой репутационной истории — обычно проще запросить у хостера другой адрес на этапе, пока сервер ещё не публичный, чем разбираться с делистингом после того, как домен уже засветился с плохим IP в заголовках отправленных писем.

Реальная пропускная способность канала

Тарифный план хостера почти всегда указывает канал в духе «до 1 Гбит/с» или «unmetered» — и это далеко не всегда означает, что именно ваш сервер гарантированно получит эту полосу в моменте пиковой нагрузки. Разница между заявленной и фактической пропускной способностью особенно велика на бюджетных VPS с общим (shared) каналом, где несколько арендаторов физического хоста делят одну восходящую линию, и на тарифах с честной, но невысокой гарантированной полосой при высоком burst-лимите.

Практическая проверка до запуска — прогнать реальный тест пропускной способности, а не поверить цифре из тарифа:

# на сервере
iperf3 -s

# с внешней точки (другой сервер/VPS в иной сети)
iperf3 -c ip_вашего_сервера -t 30 -P 4

Флаг -P 4 запускает несколько параллельных потоков — это ближе к реальной картине, чем один поток, и часто вскрывает лимиты, которые не видны в однопоточном тесте. Полезно повторить измерение в разное время суток: на общем канале пропускная способность может заметно проседать в часы пиковой нагрузки соседей по хосту, и разовый тест в 3 часа ночи покажет благополучную, но не вполне честную картину.

Если у вас уже есть результат замера задержки и потерь из первых двух пунктов чек-листа, тест пропускной способности логично проводить в те же сессии, что и mtr — так проще сопоставить, не совпадают ли просадки скорости с эпизодами потерь на маршруте. Отдельно стоит проверить, что тариф именно с гарантированной, а не просто заявленной полосой, если проект рассчитывает на постоянную высокую нагрузку — раздача видео, бэкапы, синхронизация больших объёмов данных.

Резервирование: что происходит при отказе основного канала

Формулировка «два аплинка» или «резервированный канал» в описании тарифа звучит убедительно, но сама по себе ничего не гарантирует. Резерв бывает мнимым: второй аплинк физически подключён, но не настроен на реальный failover, либо BGP-анонсы идут только через один upstream, и отказ провайдера означает полную потерю связности, несмотря на «два кабеля» в стойке.

До запуска стоит либо напрямую спросить у хостера, как реализован резерв (BGP multihoming с несколькими upstream и реальным failover, или второй канал только для внутренней сети), либо проверить самостоятельно доступными инструментами — посмотреть анонсируемые AS через looking glass, RIPEstat или bgp.he.net, и увидеть, действительно ли префикс сервера анонсируется через нескольких провайдеров или это разговоры на словах. Подробный разбор, какие вопросы задавать хостеру и какими инструментами проверить обещание про резервный аплинк, — в статье про проверку резерва у хостера.

Для проектов, где downtime особенно дорог (платежи, аутентификация, что-то с SLA перед клиентами), стоит заранее решить, устраивает ли вас резерв на уровне одного хостера вообще, или нужна географическая избыточность — второй сервер у другого провайдера с переключением через DNS или балансировщик. Это решение дешевле принять на этапе архитектуры, чем достраивать поверх уже работающего продакшена.

DNS-конфигурация: записи и TTL

DNS — тот компонент, который работает незаметно, пока не понадобится быстро что-то поменять, и именно в этот момент неудачная конфигурация становится дорогой. Перед запуском стоит явно проверить:

• Корректность всех записей — A/AAAA указывают на актуальный IP, CNAME не зациклены, MX настроены, если планируется почта на домене.
• TTL записей, которые может понадобиться менять быстро (в первую очередь A-запись основного домена). TTL в 24 часа, унаследованный от дефолтных настроек регистратора, означает, что при аварии и смене IP часть пользователей будет достукиваться до старого адреса ещё сутки. Разумный компромисс для боевого домена — TTL 300-3600 секунд: достаточно короткий, чтобы быстро переключиться, и достаточно длинный, чтобы не создавать лишнюю нагрузку на DNS-серверы.
• Отсутствие расхождений между тем, что видно у авторитативных серверов домена, и тем, что раздают публичные резолверы — проверяется через dig +trace до корневых серверов и сверкой с dig @8.8.8.8, dig @1.1.1.1.
• Если используется несколько NS — что все они реально отдают одинаковый и актуальный набор записей, а не устаревшую копию с забытого вторичного сервера.

dig example.com A +short
dig example.com NS +short
dig +trace example.com

Отдельно стоит сверить TTL именно перед миграцией или запуском — если через неделю после публикации потребуется срочно менять IP (после теста резерва или репутации из предыдущих пунктов), а TTL всё ещё на суточном значении, унаследованном от предыдущего провайдера, само переключение растянется на этот же срок.

Файрвол и security groups: не открыто ли лишнее

Последняя проверка перед запуском — простая, но именно поэтому её чаще всего пропускают. Новый сервер часто настраивают в спешке: разработчик открывает порт для отладки, тестирует что-то через временное правило, забывает закрыть — и это правило остаётся в проде. Публичный запуск — хороший повод сделать финальную ревизию, а не полагаться на память о том, что «вроде всё закрыл».

Минимальный набор проверок:

# что реально слушает сервер
ss -tulpn

# что разрешает firewall на самом сервере
ufw status verbose        # или
iptables -L -n -v         # или
nft list ruleset

# внешний скан с другой машины — что видно снаружи
nmap -Pn -p- ip_вашего_сервера

Внешний скан важен отдельно от локальной проверки правил: security group у облачного провайдера и firewall на самой машине — это два независимых уровня, и открытое правило может существовать на любом из них независимо от другого. Стоит явно свести список открытых портов к тому, что реально нужно (обычно 80/443 наружу, SSH — желательно не на дефолтном порту и ограниченный по IP, остальное — по необходимости через VPN или bastion), и убедиться, что порты для служебных сервисов — базы данных, панели администрирования, метрики, Redis, Elasticsearch без аутентификации — не смотрят в интернет по умолчанию, что для многих СУБД и панелей до сих пор так из коробки.

Частые вопросы