Токийский тестовый стенд TEAMFELNULL на 25 Гбит/с виден; его хостинговые мощности — нет

Кратко

• Самый очевидный текущий факт об инфраструктуре TEAMFELNULL — действующее подключение 25 Гбит/с для AS58790 на точке обмена INIXP в Токио; это ёмкость сетевого стыка, а не доказательство 25 Гбит/с клиентского трафика, наличия серверов, хранилищ или продаваемых облачных мощностей.
• Четыре записи о площадках в Токио делают стенд физически правдоподобным, но не подтверждают четыре независимые стойки, четыре запитанных развёртывания, отдельные домены отказов или право на отказоустойчивость, которую рекламируют операторы дата-центров.
• Публичная сервисная поверхность — это сообщество игровых серверов, программных проектов и Discord-бота, тогда как коммерческие условия, гарантии поддержки, резервные копии, цели восстановления, защита платежей и экспорт размещённых данных не задокументированы; пользователям следует считать среду образовательным стендом, пока частные доказательства не покажут обратного.

Порт 25 Гбит/с, четыре названия площадок и одно важное умолчание

Самая сильная цифра, связанная с TEAMFELNULL, — 25 Гбит/с. Она есть в текущейзаписи PeeringDB для AS58790, где «SERVER-G TestBed TeamFelNull» показана с действующим подключением к Japan Community IX, или INIXP. Насобственной странице биржи в PeeringDBрядом с AS58790 повторяется запись о 25 Гбит/с с одним IPv4- и одним IPv6-адресом обмена.Просмотр членства в той же точке обмена на ресурсе Internet Society Pulseхарактеризует сеть как образовательную или исследовательскую и также сообщает о порте 25 Гбит/с. Для столь небольшого публичного следа эти записи необычно конкретны.

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

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

В том же профиле перечислены четыре площадки, все в Токио: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building и Otemachi Place West Tower. Это создаёт убедительный контур городской сети. Но это всего лишь контур. Запись о площадке в базе соединений может отражать физический порт, кросс-коннект, доступ через другую сторону или услугу, оказанную удалённо. Сама по себе она не показывает сервер в собственности TEAMFELNULL, арендованную полную стойку, цепь питания или реплику хранилища в каждом месте. В записи нет идентификаторов портов, количества стоек, энергопотребления, контрагентов по аренде или серийных номеров серверов.

Это различие — центр всей истории. У TEAMFELNULL достаточно видимых сетевых свидетельств, чтобы показать: AS58790 — не просто имя на заброшенной веб-странице. Но открытых операционных данных недостаточно, чтобы поддержать обычное прочтение «облачный провайдер». Клиент облака покупает полезную часть цепочки: вычисления, память, хранилище, питание, охлаждение, сетевые пути, замену оборудования, труд поддержки, непрерывность биллинга и способ восстановиться или мигрировать. Цифра 25 Гбит/с описывает лишь одно звено этой цепочки.

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

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

Название описывает тестовый стенд, а не обычного облачного вендора

В публичной идентичности AS58790 есть самый полезный предупреждающий ярлык: «TestBed». PeeringDB классифицирует её как образовательную или исследовательскую сеть и относит к организации SERVER-G Group, где TeamFelNull — альтернативное имя. Публичнаядомашняя страница TeamFelNullописывает сообщество, которое запускает сезонные Minecraft-серверы с модами, играет в игры, разрабатывает модификации и адаптирует открытое ПО. Это рассказ о совместных экспериментах и удовольствии, а не коммерческое предложение предприятиям, переносящим рабочие нагрузки в производственную среду.

Собственные формулировки более широкой группы подтверждают такое прочтение. Настранице группы SERVER-Gсказано, что она долгосрочно предоставляет среды для игры, обучения и разработки. Там AS63800 названа базовой сетью, а TeamFelNull описана как партнёрская группа, получающая сетевые и серверные ресурсы для разработки, эксплуатации и игры. Эта формулировка важна, потому что разделяет как минимум три вещи, которые иначе сливаются: группу-зонтик, магистральную деятельность AS63800 и тестовый стенд TeamFelNull, связанный с AS58790. Публичные записи показывают аффилиацию и ресурсную поддержку; они не раскрывают контракт, который передавал бы TeamFelNull право собственности на стойки, роутеры или серверы.

Публичная история AS63800от SERVER-G называет магистраль некоммерческой сетью, созданной для изучения интернет-технологий. Её хронология откровенна об экспериментах: получение адресных ресурсов, поиск апстримов, попытки подключиться к общественным точкам обмена, смена связности и создание инструментов мониторинга маршрутов.Страница группысообщает, что основное место деятельности — Токио, и называет такие цели, как связность, обучение, строительство и технологическая разработка. Эти страницы касаются AS63800 и SERVER-G Group, а не отдельного корпоративного баланса AS58790. Они помогают объяснить среду вокруг TEAMFELNULL, но не доказывают, что каждый актив или политика AS63800 принадлежит стенду.

Эта граница важна всякий раз, когда слово «группа» принимают за юридическую или операционную гарантию. На публичном сайте TEAMFELNULL используются имена «TeamFelNull» и «FelNull»; в маршрутных записях — «TeamFelNull», «SERVER-G Group» и «SERVER-G TestBed TeamFelNull». Условия бота описывают FelNull как организацию. Ни на одной из просмотренных страниц нет типичной регистрации хостинговой компании, юридического имени для контракта на инфраструктурные услуги, платёжного адреса или стороны, которая была бы обязана выплатить клиенту сервисный кредит. Выводить эти детали из одного лишь бренда было бы небезопасно.

Дажеописание магистрали SERVER-Gпроводит черту между деятельностью сообщества и ограниченным коммерческим использованием. Там сказано, что сетью руководят студенты и она в основном некоммерческая, упомянуты финансовые ограничения и отмечено, что часть адресов помогает финансировать деятельность и эксплуатацию. Там также сказано, что эти коммерческие адреса не анонсируются и не используются с AS63800. Это свидетельство смешанного экономического контекста, а не доказательство того, что AS58790 предлагает стандартный коммерческий хостинговый продукт. Это делает контрактное уточнение ещё более необходимым: кто выставляет счета, кому принадлежит оборудование, чья сеть несёт сервис и кто остаётся ответственным, когда отказывает одна из частей?

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

Пользователи, которые предполагают корпоративную непрерывность, увидев «25G» и четыре названия площадок, покупали бы обещание, которого публичная запись не даёт.

Что TeamFelNull действительно показывает пользователям

Самые заметные сервисы конкретны и обращены к сообществу. Сайт TeamFelNull представляет сезонные Minecraft-серверы с модами, разработку ПО и небольшие публичные проекты. Егостраница Discord-бота для озвучкирекламирует несколько инстансов текстового бота, астраница Reversiпредлагает игровую активность для Discord. Это реальные пользовательские поверхности: люди подключаются, отправляют контент, ожидают, что состояние сохранится некоторое время, и замечают, когда сервис исчезает. Они лучше свидетельствуют о цели существования, чем общая фраза об «облаке».

Условия и уведомление о конфиденциальностибота дают редкую возможность увидеть границу данных. Там сказано, что идентификаторы пользователей, серверов и каналов могут храниться для работы сервиса; имена пользователей, ники и сообщения могут собираться для генерации речи и сохраняться только необходимое время. В уведомлении обещаны разумные меры защиты, но оговорено, что полная безопасность не гарантируется, допускается изменение сервиса или условий без предупреждения и исключается ответственность за убытки. Эти положения касаются именно бота, а не автоматически каждого сервера или сетевого сервиса, но они показывают стиль единственного найденного здесь публичного пользовательского контракта: широкая операционная свобода, ограниченные гарантии и никаких количественных обязательств по восстановлению.

Программная сторона задокументирована полнее, чем хостинговая.Учебник по лаунчеру TeamFelNullобъясняет настройку доработанного игрового лаунчера и описывает проверку антивирусом в процессе сборки.Сайт документации SERVER-Gпосвящён этому лаунчеру, установке и работе с игровыми инстансами. Это показывает группу, способную создавать инструкции для пользователей. Контраст показателен: публичные инструкции есть для клиентского ПО, а аналогичных страниц о создании виртуальных машин, долговечности хранилища, резервном копировании серверов, обработке злоупотреблений, статусе инцидентов и закрытии аккаунта не видно.

Исторический неофициальныйлистинг Japan Minecraft Serversфиксирует сервер «TeamFelNull-24h-Server», добавленный в 2019 году, с очень низким зафиксированным аптаймом и статусом «не работает». Эта запись не может установить состояние AS58790 в 2026 году. Она может описывать другую машину, другой адрес и другой период работы, а внешние проверки могут не срабатывать по множеству причин. Она полезна только как рыночный сигнал: имя TeamFelNull было связано с публичным игровым сервером, и как минимум одна старая конечная точка не оставалась постоянно доступной. Чтобы связать эту историю с сегодняшним стендом, нужны текущий мониторинг, архив инцидентов или заявление оператора.

Публичные сервисы также показывают разные схемы зависимостей. Игровому серверу нужны вычисления, память, хранилище, совместимое ПО и стабильный маршрут; голосовому боту дополнительно нужны Discord и движки синтеза речи вне контроля TeamFelNull. Лаунчер может оставаться рабочим на компьютере пользователя, даже если сервер сообщества исчезнет, но загрузки, мод-паки и зависимости аутентификации могут исчезнуть. Сводить всё это к «хостингу» скрывает, кто контролирует какой отказ.

TEAMFELNULL может эксплуатировать приложения и часть серверов, тогда как SERVER-G или другая сторона контролирует маршрутизацию, площадка — питание, а внешние платформы — идентичность и распространение.

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

Где физическая система может находиться в Токио

След площадок AS58790 полностью городской. Отдельные страницы площадок в PeeringDB относят стенд кAT TOKYO CC1/CC2,Equinix TY8,NTT DATA Otemachi BuildingиOtemachi Place West Tower. Эти записи подтверждают четыре названия из сетевого профиля, но их точность заканчивается на присутствии. Они не показывают, какое здание в объединённом названии кампуса используется, является ли подключение физическим или удалённо протянутым и установлены ли вычислительные мощности рядом с сетевым портом.

Сами площадки значительны.Собственное описание AT TOKYOсообщает, что общая площадь CC1 составляет 140 000 квадратных метров, и упоминает несколько линий питания, ИБП, аварийные генераторы и круглосуточный мониторинг на всех объектах.Спецификация Equinix для TY8даёт адрес в Токио, 40 418 квадратных футов площади, резервирование питания N+1 и резервирование охлаждения N+20 %.Таблица операционного покрытия Equinixсообщает, что на TY8 есть круглосуточное присутствие персонала на месте.

Для Otemachi Placeописание площадки New Otemachiот BroadBand Tower рекламирует стандартные 6 кВА фактической мощности стойки, две линии 200 В по 30 А, генераторы N+1, способные работать до 72 часов без дозаправки, несколько вариантов связности и удалённую поддержку. Отдельнаястраница сетевых услугпредлагает проектирование и эксплуатацию роутеров, сетей хранения и облачных подключений. Это возможности оператора площадки, доступные в здании. Они не показывают, что TEAMFELNULL покупает у BroadBand Tower полную стойку, две цепи питания, услуги remote hands или какую-либо конкретную услугу.

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

Устойчивый дизайн площадки не компенсирует один блок питания в сервере клиента, неоплаченный кросс-коннект, отказавший диск без замены или базу данных приложения без проверенного восстановления.

Поэтому географическое утверждение одновременно и сильнее, и уже, чем «глобальность». Сервисы могут быть доступны со всего мира, а интернет-маршруты глобальны по своей природе. Рассмотренные здесь физические свидетельства указывают на Токио, Япония. Они не подтверждают стойки компании в Европе, Северной Америке, других городах Азии или даже Осаке. Четыре токийских названия не создают автоматически защиту от городского бедствия, общего отказа апстрима или единственной административной ошибки. Локализацию данных для видимой инфраструктуры следует считать токийской, пока актуальный реестр активов не докажет иное.

Для пользователей у такой локализации два следствия. Во-первых, задержка будет зависеть от расстояния до Токио и выбранного пути апстрима; слово «глобальный» не отменяет физику. Во-вторых, договорённости о физическом доступе, питании и любых хранимых данных на практике, скорее всего, японские, даже если удалённые пользователи подключаются из других мест. Публичное уведомление бота не сообщает, где находится его база данных, а записи о площадках не связывают конкретное приложение с конкретным зданием.

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

Почему четыре записи о площадках не равны четырём независимым объектам

Отказоустойчивость начинается с независимости, а не с подсчёта. Четыре названия площадок могут означать четыре домена отказов, но могут означать и один роутер, доступный через несколько соединений, один сервис, протянутый между зданиями, спящие кросс-коннекты или записи, поддерживаемые для планируемого доступа. PeeringDB — ценная отраслевая база, но сетевые записи и записи о площадках вносят сами участники. В записи AS58790 указано, что информация о площадках обновлена в феврале 2026 года, что подтверждает свежесть; тем не менее она не раскрывает лежащие в основе заказы на цепи или занятость стоек.

Осторожности требует и сама география. Два адреса — в Отэмати, один — это ярлык кампуса AT TOKYO, покрывающий CC1/CC2, и один — Equinix TY8 в Синагаве. В записи Otemachi Place в PeeringDB отмечена оптическая связь со зданием NTT DATA Otemachi Building. Такая связь может быть операционно полезной, но она также означает, что два названия в базе могут достигаться через одно физическое продление, а не через два отдельно запитанных развёртывания TEAMFELNULL. Из этой возможности нельзя выводить точный маршрут. Запись устанавливает доступное соединение между зданиями, а не путь или топологию AS58790.

Соединение с INIXP добавляет ещё один слой. Точка обмена присутствует на нескольких площадках Токио и Осаки, но запись AS58790 не публикует расположение порта в сетевом профиле. Подключение 25 Гбит/с к обмену может быть доставлено на одной площадке и перенесено через партнёрскую сеть или городскую цепь. Без письма авторизации, записи кросс-коннекта, схемы устройств и заявления о разнообразии цепей физическая точка передачи остаётся неизвестной. Два адреса обмена доказывают логическое подключение; они не локализуют порт коммутатора настолько точно, чтобы нанести кабель на карту.

Настоящая отказоустойчивость вычислений на нескольких площадках потребовала бы больше свидетельств. Как минимум актуальная инвентаризация показала бы запитанные серверы или хранилища как минимум на двух объектах; у репликации были бы известные направление и задержка; у переключения DNS или маршрутизации — проверенный триггер; пользователи знали бы, какие сервисы могут перезапуститься в другом месте; а схема восстановления избегала бы общей плоскости управления. Ничего из этого публичные страницы не утверждают о репликации Minecraft-сред, данных Discord-бота или сервисов разработки между объектами. Возможно, она есть.

Но она не продемонстрирована.

Та же осторожность относится к разнообразию апстримов. Роутер может слышать множество маршрутов, пока весь клиентский трафик зависит от одного транспортного провайдера, одной конечной точки туннеля, одного городского хвоста или одного органа конфигурации. Публичная история SERVER-G описывает множество отношений во времени и выход из некоторых зарубежных общественных обменов в декабре 2024 года. Её политика пиринга явно допускает туннели GRE, SIT и WireGuard, а также подключения на биржах. Туннели — легитимный инструмент для стенда, но логически отдельный BGP-сосед поверх той же базовой цепи доступа — это не физическое разнообразие.

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

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

Мощности: единственная твёрдая цифра — на границе обмена

Мощность — это не одно число. Это стек ограничений, и сервис управляется самым низким активным пределом. Порт обмена 25 Гбит/с — это установленная логическая сетевая мощность на одном соединении. PeeringDB помечает соединение как действующее, что сильнее плана на будущее. Но полезная пропускная способность может быть ниже из-за ограничений форвардинга роутера, политики апстрима, перегрузки, транспорта между стойкой и биржей, размера пакетов, атак или узких мест приложений. Проданная мощность может быть ещё ниже — или отсутствовать вовсе, если стенд не продаёт пропускную способность.

Адресное пространство — ещё один вид мощности. PeeringDB перечисляет пять IPv4-префиксов и 50 IPv6-префиксов для AS58790, тогда какобзор AS в Cloudflare Radarопределяет сеть в Японии и показывает виды трафика при наличии достаточного числа наблюдений. Отдельныйраздел маршрутизации Cloudflare Radarпредставляет анонсируемое адресное пространство, соединения, статус RPKI и активность BGP. Количество префиксов описывает гранулярность маршрутизации, а не серверы. Один /24 вмещает 256 IPv4-адресов, но адрес может быть неиспользуемым, идентифицировать роутер, быть назначенным виртуально или обслуживать множество доменов за одним хостом.

Сторонние наборы данных иллюстрируют, почему каждая цифра должна путешествовать вместе с датой и определением.Страница IPinfo для AS58790сейчас перечисляет два блока /24 — 44.30.37.0/24 и 44.30.62.0/24 — вместе с несколькими наблюдаемыми апстримами и горстью адресов, ответивших на проверки.Представление CIDR Reportтакже показывает два анонса /24 и 512 исходных IPv4-адресов в обзоре коллектора. Эти наблюдения поддерживают текущую IPv4-маршрутизацию, но ни одно из них не сообщает, сколько машин существует и пришёл ли ответ с пользовательских вычислений.

Другие агрегаторы противоречат друг другу.Зеркальная страница регистрациивоспроизводит имя AS от JPNIC и IPv6-диапазон 2401:d20:1020::/44, но не сообщает IPv4-диапазон.Страница IP2Locationпоказывает один /24 и IPv6-префикс /46, тогда какстраница IPGeolocationсообщает о нуле маршрутов, воспроизводя идентичность AS. Это не эквивалентные снимки: даты сбора, видимость маршрутов и методы классификации различаются. Противоречие — свидетельство пределов данных агрегаторов, а не повод усреднять числа.

Ни один просмотренный публичный источник не указывает ядра CPU, память, узлы bare-metal, виртуальные машины, дисковую ёмкость, резервирование хранилища, зарезервированное питание, среднее энергопотребление или свободные юниты стоек. Ни один источник не отделяет проектную мощность от установленной, запитанной, работающей и доступной клиентам. Общеплощадочные цифры не заполняют пробел. 40 418 квадратных футов Equinix на TY8 принадлежат площадке, а не AS58790. Стандартная спецификация стойки 6 кВА от BroadBand Tower — характеристика доступного продукта, а не доказательство стойки TEAMFELNULL или прав на неё.

Экономически значимая мощность — это то, что может пережить отказ, соблюдая обязательства. Если сервису нужно 16 ядер и 64 ГБ памяти, запасной хост имеет значение, только если он совместим, запитан, подключён и не зарезервирован. Если хранилище реплицировано, вторая копия имеет значение, только если она свежая и независимо восстанавливаемая. Если 25 Гбит/с доходят до обмена, но у сервера интерфейс 1 Гбит/с, у приложения нет 25 Гбит/с. Пока TEAMFELNULL не опубликует или не предоставит частным образом эти нижние уровни, продаваемая хостинговая мощность остаётся неизвестной.

История апстримов реальна, но задокументирована нечётко

AS58790 видна как сеть-источник, и несколько публичных обзоров видят до неё маршруты. Это значимое операционное свидетельство. IPinfo перечисляет Hurricane Electric, SDCC Japan-West Area и SERVER-G Group как апстримы или пиров, а трассировка от июня 2026 года к 44.30.37.1 проходила через японские сети перед AS58790. Вид коллектора CIDR Report показал AS38074 непосредственно рядом с AS58790 для двух видимых /24. Страница маршрутизации Cloudflare даёт ещё одну живую точку наблюдения. Вместе эти источники поддерживают достижимость, но не сходятся в одном стабильном графе провайдеров.

Есть несколько безобидных причин. BGP наблюдается конкретными коллекторами в конкретное время. Отношение, которое с одного пути выглядит как апстрим, может быть пирингом, путём через маршрутный сервер или сервисом, переносимым через другую сеть. IPv4 и IPv6 могут использовать разных провайдеров. Сессия может быть настроена, но простаивать, быть выборочной или видимой только из некоторых мест. Запись обмена в PeeringDB показывает подключение к INIXP, но отмечает, что AS58790 не использует там маршрутный сервер. Значит, само присутствие не раскрывает, какие двусторонние сессии действительно несут рабочий трафик.

Более широкая история SERVER-G информативна, но её нельзя просто приписать AS58790. Она фиксирует отношения AS63800 с Vultr, Hurricane Electric, SDCC и другими сетями в разные даты, а также позднейшие выходы и добавления.Политика пиринга AS63800требует глобальные номера AS, минимальные размеры префиксов, ROA, записи в IRR и контакты в PeeringDB; она также говорит, что некоторая нестабильность допускается, потому что сеть экспериментальная. Это заявленные политики для AS63800. Они указывают на культуру вокруг стенда, а не на обязательство по аптайму для AS58790.

Вопрос собственности находится внутри вопроса маршрутизации. PeeringDB относит AS58790 к SERVER-G Group и указывает felnull.dev как сайт. Публичная страница группы говорит, что AS63800 — базовая сеть и предоставляет TeamFelNull ресурсы. Поэтому разумно видеть AS58790 как стенд TeamFelNull при поддержке SERVER-G. Неразумно предполагать, что TeamFelNull владеет каждым контрактом апстрима, каждым кросс-коннектом или адресными ресурсами, которые она анонсирует. Клиенту нужно знать, какая сторона может продлить, отменить или перенастроить каждую зависимость.

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

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

Питание, железо и руки — скрытая поверхность управления

Сетевые записи обычно доминируют, потому что они публичны. Однако большинство сбоев хостинга устраняется на гораздо менее заметном слое: кто-то находит отказавший блок питания, диск, модуль памяти, оптику, вентилятор или кабель и заменяет его. TEAMFELNULL не публикует инвентаризацию оборудования, политику жизненного цикла или склад запчастей. Порт 25 Гбит/с может оставаться совершенно здоровым, пока один сервер приложения офлайн из-за отсутствия одной совместимой детали.

Отказоустойчивость площадки помогает только до границы клиента. AT TOKYO рекламирует несколько линий, ИБП, генераторы и круглосуточный мониторинг. Equinix рекламирует питание N+1 на TY8 и операционное покрытие круглосуточно. BroadBand Tower рекламирует две линии стойки, генерацию N+1 и удалённую поддержку в New Otemachi. Эти меры снижают риски на уровне здания для клиентов, которые их покупают и правильно используют. Они не показывают, есть ли у оборудования AS58790 два блока питания, законтрактованы ли обе линии, авторизована ли удалённая поддержка и как быстро TeamFelNull может согласовать работы.

Труд поддержки — сам по себе мощность.Страница контактовTeamFelNull направляет запросы в Discord. Это удобно для сообщества, но не даёт публичной шкалы серьёзности, обязательств по времени ответа, телефонной эскалации, поименованной дежурной ротации или альтернативного канала, если Discord недоступен. Страницы SERVER-G дают пути email или Discord для пиринга, но нет публичного центра инцидентов, который конкретно обещал бы восстановление хостинговых сервисов. Когда машина отказывает в 03:00, разница между «кто-то может заметить» и «авторизованный техник должен ответить в течение 30 минут» и есть сервис.

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

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

Пользователи страдают по-разному. Игрок может потерять доступ к сезонному миру; разработчик — к сервису сборки; Discord-сообщество — к голосовому выводу; спонсируемый проект — к адресу или маршруту. Ущерб может быть неудобством, а не потерей выручки, но потеря данных может быть личной и необратимой. Правильный стандарт устойчивости должен соответствовать обещанному использованию. Тестовый мир может пережить простой, если пользователей предупредили; база данных с идентификаторами или долгоживущий мир сообщества нуждаются в правилах резервного копирования, хранения и восстановления, даже когда деньги не участвуют.

Отказ начинается с неоднозначности ещё до стойки

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

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

На сетевом уровне могут отказать порт обмена, городская цепь, конечная точка туннеля, сессия апстрима или анонс маршрута. Четыре записи площадок не показывают, разнообразны ли эти элементы. Порт 25 Гбит/с на INIXP — полезный путь, но точка обмена описывает себя как best-effort, без раскрытых условий обслуживания в публичном листинге. Двусторонний пиринг на бирже — не то же самое, что полный интернет-транзит, и подключение к бирже не достигает любой точки назначения без подходящих пиров или апстрима. Поэтому пользовательский сервис может отказывать для одних сетей, оставаясь доступным из других.

На уровне приложений обновления создают собственные окна ремонта. TeamFelNull работает с модифицированным Minecraft и доработанными лаунчерами, где версии сервера и клиента должны совпадать. Неудачное обновление может оставить пользователей за бортом, даже когда маршрутизация и железо здоровы. Документация лаунчера показывает внимание к установке и миграции, но нет публичного расписания обслуживания серверов, отката, совместимости баз данных или хранения старых миров. Состояние приложений часто труднее всего воссоздать: новая машина не может восстановить утраченную историю.

Внешние платформы добавляют коррелированные зависимости. Голосовой бот полагается на Discord для идентичности, событий и доступа пользователей, а также, возможно, на один или несколько движков синтеза. Сбой или изменение политики на этих сервисах сделает бота недоступным без какой-либо вины AS58790. Контакты также зависят от Discord, поэтому сервис и его основной публичный канал поддержки могут отказать одновременно. Страница статуса на независимо размещённом домене плюс email-эскалация разделили бы эти пути.

Затронутая аудитория не оценена количественно. Домашняя страница приглашает сообщество; страница бота показывает несколько инстансов; старый игровой листинг фиксирует публичную конечную точку. Нигде нет текущих активных пользователей, пиковых сессий или числа зависимых проектов. Это мешает численной оценке ущерба. Качественный ущерб ясен: доступ сообщества, хранимые идентификаторы, игровое состояние, распространение ПО и спонсируемые ресурсы могут быть прерваны. Правдивый план действий при инцидентах назвал бы эти классы, не заявляя число клиентов, которое не раскрыто.

Восстановление и переносимость заканчиваются на границе приложений

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

На клиентской стороне есть узкое полезное исключение. Документация лаунчера описываетпроцедуру экспорта инстанса, которая создаёт ZIP из выбранных локальных файлов, а отдельноеруководство по миграции лаунчераобъясняет, как копировать локальные папки инстансов между версиями. Эти инструкции улучшают переносимость игровой среды пользователя. Они не экспортируют серверные миры, базы данных бота, учётные данные, DNS, IP-адреса или виртуальные машины.

Эту границу легко пропустить. Игрок может сохранить моды и конфигурацию, но потерять общий мир. Администратор бота может сохранить Discord-сообщество, но потерять хранимые настройки. Разработчик может сохранить исходный код, но потерять артефакты сборки или секреты развёртывания. Пользователь сети может сохранить образ приложения, но не суметь удержать адреса, если права на ресурсы принадлежат другой стороне. Для каждого слоя нужны свои методы экспорта и восстановления.

Восстановление на нескольких площадках столь же недоказано. Список площадок даёт правдоподобные места, из которых можно строить устойчивость, но никакие публичные данные не связывают сервис с двумя живыми объектами и не сообщают задержку репликации. Даже если вторая машина существует, успешное переключение требует актуальных данных, секретов, маршрутизации, DNS, мощности и авторизованных людей. Холодный резерв без проверенного восстановления может занять больше времени, чем ремонт основного. Горячая реплика с общим административным аккаунтом может отказать при компрометации.

Эскалация поддержки должна быть частью дизайна восстановления, а не мыслью после. Контакт только через Discord может работать при обычном использовании сообществом, но серьёзное событие требует независимого пути, ответственного человека, авторизации площадки и правила решения о трате денег на детали или транспорт. Преемственность тоже важна: более чем один доверенный оператор должен уметь продлевать домены, получать доступ к роутерам, связываться с площадками и расшифровывать резервные копии. Ни одна публичная страница не устанавливает такого покрытия, поэтому это остаётся вопросом, а не обвинением.

Минимальный достоверный пакет переносимости был бы прост: список данных, принадлежащих пользователю; форматы экспорта; границы резервного копирования и хранения; сроки удаления; уведомление о планируемом закрытии; процедура получения последней копии; и тест, показывающий, что копию можно восстановить в другом месте. Для игровых сервисов это может быть архив мира плюс манифест версий. Для бота — структурированный экспорт настроек и подтверждение удаления. Для виртуального сервера — стандартный образ диска и запись конфигурации. Без таких обязательств пользователям следует хранить собственные копии везде, где это технически возможно.

Данные сосредоточены вокруг Токио, но размещение данных приложений остаётся некартированным.

Свидетельства маршрутизации и площадок указывают на Японию, особенно на Токио. AS58790 зарегистрирована с японской идентичностью в маршрутных данных, перечисленные площадки соединений находятся в Токио, а наблюдаемые IPv4-адреса в целом геолоцируются в Японию. Это поддерживает физическую оценку с центром в Токио. Это не доказывает, что каждый байт данных приложений остаётся в Токио, потому что программные зависимости, резервные копии, доставка контента и сторонние сервисы могут пересекать границы.

Бот — самый ясный пример. Его условия говорят, что идентификаторы могут храниться, а сообщения обрабатываться для синтеза речи, но не называют место хостинга, провайдера базы данных, поставщика синтеза или юрисдикцию резервных копий. Discord сам по себе внешняя платформа. Присутствие AS58790 на площадках не может ответить, где Discord хранит данные или где обрабатывается запрос синтеза. Утверждение о локализации данных потребовало бы документации уровня приложения, а не только кода страны автономной системы.

Игровые сервисы и сервисы разработки имеют похожую неопределённость. Серверный процесс может работать на машине в Токио, пока загрузки модов идут с другой платформы, исходный код лежит в глобальном репозитории, а резервные копии — если они есть — находятся в другом месте. И наоборот, адрес, анонсируемый AS58790, может достигать оборудования, доставленного удалённо через другую сеть. IP-геолокация — это оценка, а не доказательство стойки.

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

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

Поэтому ярлык сферы обслуживания «Global» следует читать как охват, а не как присутствие. Сайт, игровой сервер или Discord-бот могут обслуживать людей по всему миру из Токио. Это не делает TEAMFELNULL мультирегиональным провайдером. Физические записи поддерживают один городской кластер; записи приложений не картируют потоки данных. Любая организация с требованиями к размещению данных должна запросить карту данных для конкретного сервиса с указанием основного хоста, реплик, резервных копий, внешних обработчиков и пути удаления.

Есть и компромисс устойчивости. Хранение всех копий в Токио упрощает локализацию, но подвергает их отключению городского масштаба. Репликация за рубежом может улучшить восстановление после катастроф, но меняет юрисдикцию и задержку. Ни один выбор не верен сам по себе. Проблема в том, что текущие публичные данные не раскрывают выбор. Достоверный ответ назвал бы, где находится каждая копия, почему, как часто она обновляется и кто может её получить.

Что требовать заказчикам — и вердикт комплексной проверки

Первым запросом должно быть расписание активов и сервисов, а не глянцевая сетевая карта. Оно должно назвать контрактную сторону, предлагаемый сервис, участвует ли платёж, и точный ресурс: ядра, память, хранилище, адресное пространство, пропускную способность и поддержку. Оно должно отличать выделенные ресурсы от общих и указывать, какие объёмы установлены, запитан, работают, зарезервированы и ещё доступны. Номинальный порт обмена 25 Гбит/с должен быть в расписании, но только как компонент соединения.

Второй запрос должен картировать ответственность. Какая организация владеет или арендует каждый сервер? Кто держит аккаунт площадки, транспортную цепь и соглашение апстрима? Кто контролирует роутеры AS58790, DNS, учётные данные приложений и биллинг? Какая площадка может принять запрос поддержки от какого поименованного лица? Аффилиация SERVER-G и TeamFelNull видна, но точки перехода — нет. Таблица ответственности на одной странице убрала бы много текущей неопределённости.

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

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

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

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

Вердикт: полезный тестовый стенд, неподтверждённая хостинговая платформа.

У TEAMFELNULL SERVER-G Group больше содержательности, чем можно предположить по скудному корпоративному следу. У AS58790 есть актуальная идентичность в PeeringDB, действующее подключение 25 Гбит/с к INIXP, недавние обновления площадок и глобально видимые маршруты. TeamFelNull поддерживает публичные проекты, пользовательские условия и документацию. SERVER-G описывает продолжающуюся образовательную сеть и открыто признаёт её студенческий, в основном некоммерческий характер и финансовые ограничения. Это признаки активности, а не пустой регистрации.

Свидетельства всё же не дотягивают до точки, где размещённый сервис становится надёжным. Четыре записи площадок не доказывают четыре развёртывания. Порт 25 Гбит/с не доказывает пропускную способность серверов или свободную мощность. Анонсы адресов не считают машины. Устойчивость площадки не переходит автоматически через неизвестный дизайн стойки. Несколько наблюдаемых апстримов не доказывают физически разнообразный транспорт. Клиентские экспорты игры не защищают серверные данные. Контакт через Discord не создаёт гарантию ответа.

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

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

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

До тех пор TEAMFELNULL лучше понимать как образовательную сеть с центром в Токио, с реальными сервисами сообщества и впечатляющим подключением к точке обмена, — а не как документированное облако на нескольких площадках.

Этот вывод уважает обе стороны свидетельств. Он не превращает отсутствие раскрытия в заявление о провале и не превращает хорошо подключённый роутер в стойку устойчивых вычислений. Видимый порт 25 Гбит/с — начало вопроса о мощности. Для пользователей TEAMFELNULL решающие факты остаются за ним: какие машины запитан, какие данные можно восстановить, какой путь выживает и кто будет действовать, когда откроется окно ремонта.