Кратко

  • План RIS на третий квартал 2026 года сообщает о завершении переноса данных RIS/RIPEstat на арендованные bare-metal-серверы. В том же пункте продолжаются улучшение мониторинга обработки, расчистка технического долга и изучение способов снизить зависимость от HBase.
  • Замена машин Kafka и переход на новую версию выделены в самостоятельную задачу. Ранее её отложили из-за нехватки ресурсов; теперь она выполняется. Это не доказывает ни провала переноса, ни нестабильности Kafka.
  • Архивный план RIPEstat фиксирует дополнительную задержку между сервисом и backend-системами. Команда рассматривала параллельные запросы и наблюдала эффект, но не опубликовала величину задержки и не заявила о нарушении цели или недоступности.
  • Нужен ограниченный по компонентам акт: охват данных, поколения систем, окно переключения, решение о replay или backfill, раздельные проверки MRT, RIS Live и RIPEstat, известные исключения, ответственные роли и срок наблюдения.

Одно окончание, несколько незакрытых глаголов

В квартальном плане RIS RIPE NCC формулирует результат узко: завершён перенос данных RIS/RIPEstat на арендованное bare metal. Следующие предложения описывают уже другой объём работ. Улучшается мониторинг обработки данных, убирается часть технического долга, исследуются альтернативные архитектуры хранения ради меньшей зависимости от HBase. Статус этого пункта — «в работе».

Отдельно заменяются машины Kafka и обновляется версия. Эту задачу раньше отложили из-за ограниченных ресурсов; сейчас она тоже выполняется.

Открытые пункты не отменяют законченный перенос. Из источников не следует утрата данных, повреждение, простой или неудачное переключение. Но и законченный перенос не означает автоматическую приёмку каждого брокера, задания обработки, хранилища, запроса и публичного файла.

Проблема возникает позже, когда квартальная формулировка превращается в память «мы закончили RIS». Исследователю, разбирающему интервал вокруг переключения, недостаточно общего статуса. Ему нужно знать, какая часть цепочки и по какому тесту получила право на слово «готово».

Данные маршрутизации проходят через разные зоны ответственности

Routing Information Service собирает BGP-данные через распределённые Remote Route Collectors, обычно расположенные на точках обмена. Добровольные сети устанавливают с RRC BGP-сессии; коллекторы получают announcements и withdrawals. RIPE NCC хранит и публикует наблюдения для операторов и исследователей.

Каждый переход меняет хранителя. Пир определяет передаваемое представление. Коллектор фиксирует полученное. Транспорт переносит сообщения. Обработка строит файлы и доступные для запроса структуры. Хранилище удерживает поколения. Публичный слой выдаёт архив, поток или ответ. Пользователь выбирает выборку и делает вывод.

Во время миграции происхождение становится частью качества данных. Какое поколение обработало интервал? Он пришёл из старого или нового хранилища? Был ли параллельный период? Повторно ли проигрывалась очередь? Совпадает ли время публикации со временем наблюдения или отражает поздний backfill?

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

Задержка RIPEstat относится к другому приёмочному контуру

В архивном плане RIPEstat сказано, что перенос больших данных, связанных с сервисом, создал дополнительную задержку между RIPEstat и backend-системами. Команда помогала миграции, искала способы скрыть задержку — в том числе через параллельные запросы — и внимательно следила за влиянием. Пункт поддержки закрыт в третьем квартале 2026 года.

Документ не сообщает миллисекунды или процентили, не перечисляет классы запросов и не говорит о нарушении уровня обслуживания. Фраза «рассматривали методы» не равна повсеместному внедрению параллелизма. Поэтому это не описание инцидента.

Зато запись показывает самостоятельность пользовательского слоя. Корректно перенесённый набор может находиться дальше от запроса. Успешный ответ не описывает хвост распределения. Проверка хранилища не заменяет наблюдение за классами запросов до, во время и после переключения.

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

MRT, RIS Live и RIPEstat дают разные показания

Документация MRT описывает файлы по каждому route collector. bview фиксирует состояние маршрутизации в конкретный момент, update-файлы — изменения за интервал. В текущей документации dumps создаются раз в восемь часов, updates — раз в пять минут.

Такое расписание позволяет построить список ожидаемых слотов для каждого RRC. Однако наличие имени не доказывает содержимое, поколение обработки или исправность других способов доступа. Стоит связать файл с размером или хешем, ограниченной проверкой содержания, исключениями и состоянием replay или backfill.

RIS Live предназначен для почти реального времени. Свежий поток не подписывает полноту исторического MRT-архива. Полный набор файлов не измеряет задержку RIPEstat. Из рассмотренных материалов не следует, что эти поверхности используют один внутренний маршрут.

Поэтому у каждой должна быть собственная проверка. Для MRT — интервалы и содержимое по RRC. Для RIS Live — определённая специально для потока свежесть. Для RIPEstat — распределение по классу запроса. Результаты можно сопоставлять, но нельзя выдавать один за доказательство остальных.

Предыдущие поколения всё ещё участвуют в смысле результата

В архивных планах RIS записано, что в 2023 году RIPE NCC заменила конвейер создания публичных MRT dumps, получила существенно меньшую задержку и внесла некоторые изменения в структуру файлов. Два корректных исторических интервала могут, следовательно, принадлежать разным производственным поколениям.

План 2025 года сообщает об устранённой несогласованности: данные одного удалённого IPv6-пира продолжали появляться в наборах. Публичное документирование этого и других менее значительных артефактов было отложено. Важно не потерять вид: несогласованность названа устранённой, отложена документация. Источник не подтверждает продолжающуюся ошибку.

Более ранние проекты внешней раздачи через Kafka и публикации исходного кода RIS Live были понижены в приоритете на время пересмотра стратегии. Они не описывают сегодняшнюю архитектуру. Старый эксперимент с публичным Kafka нельзя без связи приравнять к машинам Kafka, которые сейчас заменяются.

Хорошая запись происхождения фиксирует не только установленные связи, но и границы, где связь неизвестна или неприменима.

Компонентный акт без раскрытия инфраструктуры

Первый раздел задаёт охват: datasets, RRC, временные диапазоны, потребительские продукты и исключения. Общее «данные RIS» слишком широко для приёмки.

Второй раздел связывает применимые поколения сбора, транспорта, обработки и хранения. Если Kafka не участвует в конкретном пути, это указывается прямо. Исследование альтернативы HBase остаётся исследованием до опубликованного выбора.

Третий раздел раскладывает переключение. Извлечение старых данных, первичная загрузка, параллельное наблюдение, перевод чтения и записи, окончание перекрытия и вывод старой среды — разные решения. Стенограмма RIPE 88 разделяет подобные этапы в более широком историческом рассказе о платформах данных. Она полезна как схема последовательности, но не как актуальная топология RIS.

Четвёртый раздел содержит проверки. Выбираются сопоставимые RRC и интервалы по обе стороны cutover, проверяются пятиминутные updates и восьмичасовые dumps. Свежесть RIS Live измеряется отдельно. Для RIPEstat фиксируются процентили по классам. Указываются допуски и период наблюдения.

Replay и backfill получают один из ясных статусов — не требовался, запланирован, частичен, завершён — с диапазоном. Рядом находятся известные артефакты и исключения. Каждую приёмку подписывает ответственная роль с датой.

В публичной версии достаточно диапазонов, идентификаторов сборки, хешей, счётчиков и агрегированной задержки. Имена хостов, учётные данные, внутренние адреса и raw logs не нужны.

Такой акт не оспаривает завершение. Он позволяет честно закрыть перенос данных и не закрывать чужие задачи. Kafka сохраняет свой срок. Выбор после HBase остаётся открытым до решения. Мониторинг обработки собирает свидетельства. RIPEstat отдельно описывает потребительский эффект. Чем точнее граница утверждения, тем надёжнее его можно принять.

Источники