0,7 мс до 1.1.1.1: как один анкор ослепил наш мониторинг на три месяца
Если вы отправляете ping на 1.1.1.1, и он отвечает, что вы узнали? В течение трёх месяцев мы считали, что ответ таков: «эта точка наблюдения может достичь глобального интернета». Это не так. 23 августа 2026 года мы измерили тот же адрес из нескольких точек наблюдения одновременно, и полученные данные оказались несравнимыми в каком-либо полезном смысле.
Это заметка о том, как мы ошиблись, что нам это стоило и как любой может проверить то же самое в своей системе мониторинга примерно за пять минут.
Один и тот же адрес, четыре совершенно разные задержки
Каждое из приведённых ниже значений - это среднее время кругового прохождения пакета (RTT) по результатам 52 последовательных выборок по 20 ICMP-пакетов каждая, выполненных в один и тот же день из разных точек наблюдения нашей распределённой измерительной сети. Анкор идентичен в каждой строке.
| Точка наблюдения | RTT до 1.1.1.1 | RTT до 8.8.8.8 | Соотношение |
|---|---|---|---|
| Киев | 0,69 мс | 14,20 мс | 20,6x |
| Одесса | 11,54 мс | 24,88 мс | 2,2x |
| Минск | 11,78 мс | 9,95 мс | 0,8x |
| Алматы | 29,78 мс | 73,65 мс | 2,5x |
Три из этих строк ведут себя как обычные интернет-маршруты. Одна - нет. Из Киева 1.1.1.1 отвечает менее чем за миллисекунду, в то время как резолвер Google с той же машины имеет задержку 14 мс. Устройство не находится необычно близко к интернету в целом. Оно находится необычно близко только к этому одному адресу.
Трассировки
Два маршрута с одного и того же хоста, выполненные с разницей в несколько секунд. Сначала к 1.1.1.1:
| Хоп | Адрес | Потери | Среднее |
|---|---|---|---|
| 1 | 192.168.0.1 | 0% | 0,3 мс |
| 2 | 217.66.102.33 | 0% | 0,5 мс |
| 3 | 193.110.106.4 | 0% | 0,9 мс |
| 4 | 193.25.181.201 | 33% | 11,8 мс |
| 5 | 1.1.1.1 | 0% | 0,7 мс |
Пять хопов, и пакет никогда не покидает пределы города. Теперь тот же хост к 8.8.8.8:
| Хоп | Адрес | Среднее |
|---|---|---|
| 3 | 193.110.106.4 | 0,7 мс |
| 4 | 193.110.106.114 | 1,2 мс |
| 6 | 74.125.245.84 | 1,3 мс |
| 8 | 142.251.242.41 | 14,5 мс |
| 11 | 8.8.8.8 | 14,3 мс |
Одиннадцать хопов, и вы можете точно увидеть, где трафик покидает город: между хопами 6 и 8 задержка увеличивается с 1,3 мс до 14,5 мс. Этот скачок - то, что мы думали, что мониторим. На маршруте к 1.1.1.1 этот скачок никогда не происходит.
Почему такая разница? Оба адреса используют anycast, поэтому оба отвечают с того экземпляра, который топологически ближе. В Киеве экземпляр одного из них находится практически по соседству, доступный через локальный пиринг. Является ли это узлом на границе, пириующимся с локальной сетью, или чем-то на маршруте, отвечающим за этот адрес, наши данные сказать не могут, и для целей мониторинга это не имеет значения. Важно то, что маршрут не проходит через глобальный интернет, а значит, не может сообщать о нём.
Анкор даже скрывает сбои на своём собственном маршруте
Посмотрите снова на хоп 4 в первой трассировке: 33% потерь пакетов, с отдельными выборками от 1,7 мс до 21,9 мс. Это действительно проблемный хоп. Однако он никак не влияет на измерение, потому что анкор отвечает до того, как маршрут доходит до этого хопа. Система мониторинга, наблюдающая за этим анкором, сообщила бы о полностью исправной сети, находясь всего в одном хопе от канала, теряющего треть пакетов.
Что нам это стоило
Мы провели тест корреляции, чтобы выяснить, отражается ли задокументированный внешний стрессор в наших данных о доступности. Для киевской точки наблюдения мы взяли все дни, в которые в городе фиксировались публичные воздушные тревоги, и сравнили интенсивность тревог с измеренными потерями пакетов до анкоров.
За 69 таких дней средняя доступность составила 99,87%. В 67 из 69 дней она составляла 99,9% или выше, включая все дни с самой высокой активностью тревог. Результат оказался полностью нулевым.
Мы чуть не опубликовали этот нулевой результат как вывод о стойкости сети. Но это не был вывод о сети. Это был вывод об анкоре: мы измеряли канал внутри города, который не имел особых причин для сбоев, и правильно наблюдали, что он не выходил из строя. Инструмент не имел чувствительности к поставленному вопросу.
Нулевой результат от инструмента, который вы не валидировали, не является доказательством отсутствия. Это вообще не доказательство.
Что мы изменили
Три изменения, все скучные, ни одно из них не является хитроумным.
Больше одного анкоров. Теперь каждая точка наблюдения измеряет глобальный анкор, второй глобальный анкор, управляемый другой организацией, и пир внутри того же региона. Три цели, которые выходят из строя по трём разным причинам, гораздо сложнее обмануть, чем одну.
Первый хоп, явно. Теперь каждая проверка также измеряет локальный шлюз. Если первый хоп чистый, а всё остальное за ним - нет, проблема выше по цепочке. Если первый хоп проблемный, то это последний участок. Это единственное дополнительное измерение позволяет разделить два класса сбоев, которые один анкор объединяет в одно недифференцированное «ухудшение».
Используемый размер выборки. Мы отправляли шесть пакетов за цикл. Шесть пакетов не могут отличить 5% потерь от 0%; минимальный шаг, который они могут выразить, составляет 17 процентных пунктов. Теперь мы отправляем двадцать. В первом цикле после изменения одна точка наблюдения зафиксировала 19 из 20 пакетов до своего основного анктора, в то время как оба других анктора и локальный шлюз оставались чистыми, что позволило локализовать 5% потерь на одном конкретном маршруте. Старая конфигурация округлила бы это до «всё в порядке».
Мы сознательно не изменяли анкор, который используется для порога оповещения. Переопределение метрики с сохранением её названия - это способ незаметно обесценить историю мониторинга. Основной анкор остался на своём месте, чтобы существующая база оставалась сопоставимой; новые анкоры записываются вместе с ним и займут его место, как только наберут достаточно данных для формирования собственной базы.
Проверьте свои системы
С любого хоста, который вы мониторите, выполните трассировку до адреса, который ваша система мониторинга считает «интернетом». Затем выполните трассировку до другого известного адреса, управляемого другой организацией. Сравните количество хопов и, что важнее, найдите скачок задержки, где трафик покидает ваш городской район. Если на маршруте к вашему анкору такого скачка нет, ваша проверка доступности - это тест локального канала, выдаваемый за глобальный.
Тест требует двух команд. Мы не выполняли его три месяца, и только поэтому эта заметка существует.
Ограничения
Это снимок одного дня для одного анктора из нескольких точек наблюдения; топология anycast меняется, и тот же адрес может вести себя совершенно иначе в следующем месяце или в другой сети. Мы не установили, почему маршрут из Киева завершается локально, а только то, что он завершается. Описанный выше тест корреляции охватывает один город и один анкор и ничего не говорит о стойкости сети в целом - этот вопрос остаётся открытым именно потому, что наш инструмент не мог на него ответить. Мы рассчитываем вернуться к нему, как только серия измерений с несколькими анкорами накопит достаточно данных.
Все приведённые здесь данные взяты из нашей собственной распределённой измерительной сети и могут быть воспроизведены с помощью стандартных команд ping и mtr с любого хоста в тех же сетях.