Двойной аркан. Пингуем РФ с двух сторон

Как мы добавили вторую точку мониторинга в Новосибирске — и почему одной точки из Москвы хронически недостаточно для РФ-аудитории. С реальными цифрами, curl-логами и снимком живого Рунета за апрель 2026.

Пролог: RBC в Сибири медленнее в 12 раз — и из Москвы вы этого не видите

Представьте, что у вас B2B-сервис с клиентом в Новосибирске, интегрирован с ВТБ по API. Мониторинг https://www.vtb.ru/ показывает p50 163 мс и зелёное, uptime 99,9%. Техдир пишет: «коллеги в Сибири жалуются — оформление платежа 5–6 секунд, в Москве мгновенно».

Проверяем с пробы в Новосибирске: p50 414 мс, p99 за секундой. На каскадных API-вызовах +250 мс на подзапрос превращается в 1–3 секунды ожидания. Сайт не упал, 200 OK отдаёт — просто в 2,5 раза медленнее для пользователя в Сибири, чем вы видите из Москвы.

И это не баг ВТБ. Самый дикий пример сегодня — rbc.ru: 47 мс из Москвы, 592 мс из Новосибирска. Разрыв в 12,6×. Медиана по 23 не-Яндекс URL’ам — в 2,5 раза latency из НСК (+148%). Полтора десятка сайтов идут от +200% до +1200%: rbc +1160%, mos.ru +302%, gosuslugi.ru +406%, sberbank.ru +373%, telegram.org +346%, ria.ru +382%. Это значит: типичный РФ-сайт из Сибири отвечает в 2–5 раз дольше, чем из Москвы — и ваш московский мониторинг этого не видит.

Есть и вторая причина, менее очевидная. Российская инфраструктура меняется за дни, часто тихо. С 17 по 20 апреля наша Новосибирская проба получала от fssp.gov.ru стабильный 403 Forbidden — VARITI (Москва, с 2016 года), российский anti-bot WAF, записал подсеть AS57494 Adman в «плохие» и отрезал её. 655 эпизодов блокировки за те три дня, последний — 20 апреля в 15:17 МСК. После этого момента — снова 200 OK, и сегодня проба держит 100% uptime. Мы ничего не меняли, IP пробы тот же — просто правила VARITI тихо переключились.

Сайт тот же. Сервер тот же. Правила WAF — другие. И это не единичный случай, а базовая механика Рунета.

Если вы мониторите внешние эндпойнты только из одной точки, вы живёте с предположением «что видел вчера — увижу и сегодня». В РФ это предположение ломается.

Мы прогнали 27 ресурсов × 2 пробы × 120 часов (последний замер — 27 апреля 2026, 03:32 МСК). Ниже покажем что получилось и почему одной точки мониторинга в РФ хронически недостаточно.

Топ-10 по разнице p50 (24 часа, не-Яндекс, 27 апреля 2026)

Caveat: наш «МСК» — это Yandex Cloud (AS200350), NSK — Adman (AS57494). Для Яндекс-сайтов МСК-baseline нечестно низкий (1-2 хопа внутри сети), поэтому Яндекс-сервисы из таблицы убраны. Также важно: AS57494 (Adman) — региональный провайдер, у него меньше пиринговых маршрутов, и часть delta объясняется не «расстоянием до Сибири», а «слабой связностью отдельной AS». Это тоже реальный сценарий — большинство ваших клиентов сидит за такими же провинциальными провайдерами.

Медиана по всем 23 не-Яндекс сайтам — +148% (т.е. в 2,5 раза медленнее из Сибири). Хвост чудовищный: 8 сайтов идут в 3+ раза медленнее, рекордсмен rbc.ru — в 13 раз. Это означает простое: ваш московский мониторинг на rbc/mos.ru/gosuslugi/sberbank не видит в разы более медленный user experience у пользователей в Сибири — тихий drift качества, на который вы не реагируете, пока клиент не напишет.

Россия как «сеть», а не как «страна»

Рунет — это около 5,9 тысяч зарегистрированных AS (по отчёту ГРЧЦ 2023 через CNews), из которых 7 крупнейших операторов держат больше половины всех IP. У каждого — свои пиринговые соглашения с глобальными CDN. Мы прогнали mtr с обеих проб и получили контринтуитивное:

Для Cloudflare и Google из Сибири ближе, чем из Москвы — у Adman прямой peer с их POP. Для Яндекса наоборот: у MSK 0.3 мс, потому что это внутренняя сеть. Один и тот же URL из разных AS видится радикально по-разному, и ваш мониторинг из одной подсети — это проекция сложного peering-графа на одну точку.

Плюс ТСПУ, WAF-продукты типа VARITI, региональные шатдауны мобильного интернета и время от времени DDoS на Ростелеком. Всё срабатывает неравномерно — у разных операторов и в разных регионах.

Пять инцидентов 2025–2026, где одной точки мониторинга не хватило

1. 14 января 2025. Вечером по всей России на полтора часа лёг доступ к .ru и .рф — пострадали Яндекс, банки, Wildberries, Ozon. Причина, по словам источника в Минцифры, — «Ростелеком некорректно накатил обновление АСБИ». Одна проба в Москве видела DOWN, но не могла отличить «лёг весь Рунет» от «лёг мой хостер». Проба за рубежом подтвердила бы: RU-эндпойнты недоступны отовсюду. Разница между «будить DevOps в три ночи» и «ждать час, пока Ростелеком откатит».

2. 9 июня 2025 — по сей день. Все крупные российские ISP троттлят Cloudflare до первых 16 КБ ответа (официальный пост Cloudflare). Лёгкие страницы грузятся, SPA с шрифтами и картинками — нет. Под раздачу попали Hetzner, DigitalOcean, OVH. Для мониторинга это системная ловушка: healthcheck отдаёт JSON в пару килобайт и проходит, а реальный пользователь видит битый UI. Ловится только проверкой полной страницы + контрольной пробой из-за рубежа.

3. Лето–декабрь 2025. По данным проекта «На связи» через Meduza в июле 2025 года — 2 099 случаев отключения мобильного интернета в России. К декабрю шатдауны хоть раз коснулись 80 регионов из 89. Честно: даже мультирегион тут спасает только частично — серверный мониторинг слеп к мобильным отключениям. Но проба из затронутого региона хотя бы фиксирует рост latency и packet loss.

4. 20 октября 2025. РКН «частично ограничил» WhatsApp и Telegram в 34 регионах — Meduza и РБК документируют. Асимметричное замедление: текст проходит, медиа (фото, видео, голоса) троттлится на уровне CDN-трафика Telegram к Cloudflare/AWS. Мониторинг текстового эндпойнта видит всё зелёным, а пользователь в Ростове не может послать голосовое.

5. 6 апреля 2026, вечер. DDoS на Ростелеком, ~1 час падения. Steam, Госуслуги, Wink, RuTube, банки. Кроме Дальнего Востока — там Ростелеком шёл другими транзитами (3DNews). Одна проба в Москве — паника. Проба во Владивостоке в тот час показывала зелёный дашборд — и именно это ценная подсказка: «не мы сломались, транзит восстановится через час».

Что показал наш бенчмарк

27 URL-таргетов (21 популярный РФ-сайт, 3 иностранных ориентира, 3 CDN/ICMP эталона) × 2 пробы × 120 часов свежих данных. По «старым» мониторам ~7180 замеров, по 6 пересозданным мониторам (ria, lenta, kommersant, raiffeisen, tinkoff, telegram_nsk) — ~74 замера за последний час, p50 уже устойчив, p95/p99 формируются.

Расхождения: 278 эпизодов за 5 суток, перекос в сторону НСК

За 5 суток (последний замер 27 апр 03:32 МСК) поймали 278 минут-эпизодов, когда одна проба видела UP, а другая — DOWN или timeout. Из них 206 раз «МСК видит, НСК нет» (157 timeout + 49 down) и 72 раза наоборот. Перекос 2,9× в сторону НСК-как-жертва. То есть Adman в Новосибирске чаще «слепнет» — это ожидаемо, у периферийной AS меньше пиринговых маршрутов, чем у Yandex Cloud в центре.

Топ-5 ресурсов по расхождениям — и telegram.org + github.com дают 65% всего шума:

Про telegram.org — самый яркий гео-эффект бенчмарка. 96 эпизодов из 96 — это только НСК timeout, МСК всегда UP. Это типовой ТСПУ на маршруте Adman → инфраструктура Telegram. Конкретный кейс: с 21:38 МСК (26 апр) до 00:31 МСК (27 апр) — 2 часа 53 минуты непрерывного блока из НСК (с короткими «вдохами» по 1–2 минуты). Из Москвы в это же время telegram.org отвечал 200 OK с p50 64 мс. Одноточечный мониторинг МСК полностью пропустил бы трёхчасовой outage пользователей за пределами центральной России.

Про github.com — главный «системный» антагонист. Российские ISP (включая Yandex Cloud и Adman) замедляют GitHub с июня 2025 (CF-троттлинг 16 КБ), плюс к этому ТСПУ периодически режет SYN-пакеты с cloud-IP. Результат — оба наших probe-агента из своих cloud-датацентров видят github.com нестабильно: примерно поровну НСК timeout / МСК timeout. Это не гео — это антибот ТСПУ против cloud-датацентровых подсетей, симметрично бьющий обоих.

Про ria.ru и tinkoff.ru — оба показали «качающийся» паттерн Qrator/антибота: сначала блок одной AS, через час-два — другой. ria.ru: 26 апр 21:54–22:14 НСК timeout (21 мин), затем 23:17–23:23 МСК timeout (6 мин). tinkoff.ru: 22:50–22:54 НСК timeout, 23:31–23:34 МСК timeout, и снова 00:15–00:17 НСК timeout. Идеальный пример: одиночный мониторинг с любой стороны увидит «сайт лежит» в один из этих интервалов и пропустит другой. Двухточечный consensus сразу подсказывает: «инциденты попеременные → причина на стороне сервиса (WAF), а не транзита».

Кому это даёт деньги и спасает волосы

B2B-сервис с корпоративными клиентами — про SLA и UX

Если вы обещаете клиенту в Новосибирске «99.9% uptime, p95 response < 500 мс», измерять это обязаны с точки клиента, не из Yandex Cloud, где у вас бэкенд. Наши сегодняшние данные: vtb.ru p50 163 мс из МСК / 414 мс из НСК. sberbank.ru — 34 / 156, rbc.ru — 47 / 594. На каскадных API-интеграциях это +250–550 мс на пользовательский запрос, а на rbc-CDN — секунда сверху.

И это невидимо из Москвы. В дашборде — 99.9%, в реальности — клиент из Сибири в 2,5 раза дольше ждёт ответа.

SRE / on-call — про alert fatigue

На наших 27 мониторах × 2 пробы × минута × 5 суток ≈ 388 000 проверок, и в них 278 минут-эпизодов расхождений (~0,07%). Если бы мы алертили по одной пробе, это 280 фальшивых тревог за 5 дней — около 56 в сутки только из-за транзитной нестабильности. On-call мьютит канал → пропускает реальный алерт → инцидент. Это классическая проблема alert fatigue, о которой регулярно пишут и Google SRE-бук, и индустриальные гайды (тот же Hyperping разбор false positives).

Правило «алертим только когда обе пробы DOWN подряд 3 минуты» отсекает весь транзиентный флап github.com / telegram.org / ria.ru — это 228 из 278 эпизодов (82%) сразу. Плюс error signature подсказывает, куда копать: HTTP 403 обеими → WAF на стороне сервиса, TCP timeout с одной → проблема в транзите. Дежурный не будит всех разработчиков, а идёт в правильную сторону.

Кратко: одноточечный мониторинг — инструмент для «сервер жив?». Двухточечный — для «пользователю можно нормально пользоваться сервисом?». Разница — между «uptime 99.9%» (отчёт для галочки) и «клиенты не пишут в поддержку» (реальная метрика бизнеса).

Что можно сделать прямо сейчас (без PingZen)

Если вы дочитали до сюда — минимальный план на эту неделю:

1. Выпишите 10–20 критичных внешних endpoints — API партнёров, CDN-assets, healthcheck’и, платёжные шлюзы. Это ваша реальная «attack surface» из-за пределов вашей сети.

2. Поднимите вторую точку в другом AS: VPS у регионального провайдера за 500–1500₽/мес, домашний NUC у друга в другом городе, или просто другое облако (DigitalOcean / Hetzner). Главное — другой AS.

3. Поставьте туда крон с curl -o /dev/null -w "%{http_code} %{time_total}s" раз в минуту на каждый endpoint. Результаты — в Prometheus, VictoriaMetrics, или хоть в текстовый файл.

4. Через неделю сравните с данными основного мониторинга. Если drift’а нет — поздравляем. Если есть — вы только что нашли первое blind spot.

И если лень собирать самим — мы это сделали за вас

Сделали PingZen — инди-SaaS для мониторинга с точками в Москве (Yandex Cloud) и Новосибирске (Adman). Заход через Google / Yandex / Telegram за 30 секунд, без верификаций и кредитки. Free-тариф: 55 мониторов, интервал от 60 секунд, обе точки проверки, алерты в Telegram/Discord/Email/Slack/Webhook.

Создаёте монитор, в dropdown «Check from» выбираете обе локации — и через несколько минут на дашборде видны реальные расхождения (и живой пример того, как они меняются каждую неделю — VARITI поправили правила, и ФССП у нас открылся).

Новые пробы (Санкт-Петербург, Екатеринбург, Владивосток, Казахстан) разворачиваем там, куда дотягиваемся железом. Если у вас есть свободный VPS (4 vCPU / 4 ГБ хватит) и вы готовы его отдать под публичную PingZen-пробу — напишите, в обмен дадим Pro-тариф и упоминание в документации.

Мы инди, не большой SaaS. Каждый коммент читаем, каждую просьбу пилим руками: SOCKS5, MTProxy, inline Discord-визард, Yandex OAuth — всё появилось из комментов на Habr. Предыдущая статья — «Не соглашаясь с Большим Братом. Telegram и MTProxy», если зашло.

Пишите в комментах ↓:

• Из какого ISP / региона вы чекаете свои сервисы прямо сейчас?

• Какой был самый бредовый случай «мониторинг зелёный, клиент не работает» у вас?

• Какие локации вам критичны для пробы в первую очередь?