TEAMFELNULLs 25-Gbit/s-Testumgebung in Tokio ist sichtbar; ihre gehostete Kapazität ist es nicht

Zusammenfassung

• Die derzeit klarste Infrastruktur-Tatsache von TEAMFELNULL ist eine betriebsfähige 25-Gbit/s-Verbindung für AS58790 am INIXP in Tokio; dies ist Netzwerkrand-Kapazität, kein Nachweis von 25 Gbit/s Kundenverkehr, Serverbestand, Speicher oder verkaufbarer Cloud-Kapazität.
• Vier Tokio-Standorte machen die Testumgebung physisch plausibel, belegen jedoch keine vier unabhängigen Racks, vier aktive Installationen, separate Fehlerdomänen oder ein Recht auf die von den zugrundeliegenden Rechenzentrumsbetreibern beworbene Ausfallsicherheit.
• Die öffentliche Dienstoberfläche besteht aus einer Gemeinschaft von Spieleservern, Softwareprojekten und einem Discord-Bot, während kommerzielle Bedingungen, Support-Garantien, Backups, Wiederherstellungsziele, Abrechnungsschutz und Export von gehosteten Daten undokumentiert bleiben; Nutzer sollten die Umgebung als Bildungstestumgebung betrachten, es sei denn, private Belege belegen mehr.

Ein 25-Gbit/s-Port, vier Standortnamen und ein bedeutendes Schweigen

Die stärkste Zahl, die TEAMFELNULL zugeordnet wird, ist 25 Gbit/s. Sie erscheint im aktuellenPeeringDB-Eintrag für AS58790, wo „SERVER-G TestBed TeamFelNull“ mit einer betriebsfähigen Verbindung zum Japan Community IX, kurz INIXP, angezeigt wird. Dieeigene PeeringDB-Seite der Austauschswiederholt den 25-Gbit/s-Eintrag neben AS58790, mit je einer IPv4- und IPv6-Austauschadresse. EineInternet Society Pulse-Ansicht derselben Austauschmitgliedschaftcharakterisiert das Netzwerk als Bildungs- oder Forschungseinrichtung und meldet ebenfalls einen 25-Gbit/s-Port. Diese Aufzeichnungen sind für einen so kleinen öffentlichen Fußabdruck ungewöhnlich konkret.

Sie sind jedoch leicht falsch zu verstehen. Eine Portgeschwindigkeit ist die nominale Rate eines Austauschsanschlusses. Sie ist keine Messung des anhaltenden Verkehrs, keine verfügbare Kundenbindung oder der Durchsatz der Maschinen hinter dem Router. Sie sagt nichts darüber aus, wie viele physische Server installiert sind, wie viel Speicher intakt ist, wie viel Rack-Leistung reserviert ist oder ob ein Host eine weitere virtuelle Maschine aufnehmen kann. PeeringDB lässt den Verkehrspegel, das Verkehrsverhältnis und die geografische Reichweite von AS58790 bewusst unveröffentlicht.

Es meldet Adressfamilien- und Verbindungsdaten, aber keine verkaufte Last, Auslastungskurve oder Service-Level-Verpflichtung.

Das gleiche Profil listet vier Standorte auf, alle in Tokio: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building und Otemachi Place West Tower. Das ergibt eine überzeugende Umriss eines metropolitanen Netzwerks. Dennoch bleibt es ein Umriss. Ein Standorteintrag in einer Verbindungsdatenbank kann einen physischen Port, eine Querverbindung, einen Zugang durch eine andere Partei oder einen remote bereitgestellten Dienst widerspiegeln. Es zeigt nicht von selbst einen TEAMFELNULL-eigenen Server, ein gemietetes Vollrack, einen Stromkreis oder eine Speicherkopie an jedem Ort.

Der Eintrag veröffentlicht keine Portkennungen, Rackmengen, Stromaufnahme, Leasingpartner oder Serverseriennummern.

Diese Unterscheidung ist der Kern der Geschichte. TEAMFELNULL hat genügend sichtbare Netzwerknachweise, um zu zeigen, dass AS58790 nicht nur ein Name auf einer verlassenen Webseite ist. Es hat nicht genügend öffentliche Betriebsnachweise, um eine konventionelle Cloud-Provider-Lesart zu unterstützen. Ein Cloud-Kunde kauft den nutzbaren Teil einer Kette: Rechenleistung, Arbeitsspeicher, Speicher, Strom, Kühlung, Netzwerkpfade, Ersatzhardware, Supportarbeit, Abrechnungskontinuität und eine Möglichkeit zur Wiederherstellung oder Migration. Die 25-Gbit/s-Zahl beschreibt nur ein Glied in dieser Kette.

Das Schweigen ist daher wichtiger als die Schlagzeilenzahl. Keine öffentliche Seite, die für dieses Profil geprüft wurde, gibt ein aktuelles Angebot von VPS, Bare-Metal oder Managed-Hosting-Plänen unter dem Namen TEAMFELNULL an. Keine gibt eine garantierte Betriebszeit, Support-Antwortzeit, Wiederherstellungspunkt, Wiederherstellungszeit, Ersatzteilpolitik, Backup-Grenze, Datenexportformat, Wartungsankündigungsfrist oder Entschädigungsregel an. Diese Abwesenheit beweist nicht, dass diese Vereinbarungen nicht privat existieren.

Sie bedeutet, dass ein potenzieller Nutzer sie nicht aus den öffentlichen Nachweisen ableiten kann und ein Austausch-Port-Etikett nicht als Ersatz betrachten sollte.

Der Name beschreibt eine Testumgebung, keinen konventionellen Cloud-Anbieter

Die öffentliche Identität von AS58790 enthält ihr nützlichstes Warnschild: „TestBed.“ PeeringDB klassifiziert es als Bildungs-/Forschungsnetzwerk und ordnet es der Organisation SERVER-G Group zu, mit TeamFelNull als Alternativname. Die öffentlicheTeamFelNull-Startseitebeschreibt eine Gemeinschaft, die saisonale modifizierte Minecraft-Server betreibt, Spiele spielt, Modifikationen entwickelt und Open-Source-Software anpasst. Es ist ein Bericht über gemeinsames Experimentieren und Vergnügen, keine Verkaufsargumentation für Unternehmen, die Produktionsarbeitslasten verlagern.

Die eigene Sprache der breiteren Gruppe verstärkt diese Lesart. DieSERVER-G-Gruppenseitesagt, dass sie Umgebungen zum Spielen, Lernen und Entwickeln über einen langen Zeitraum bereitstellt. Sie bezeichnet AS63800 als Kernnetzwerk und beschreibt TeamFelNull als Partnergruppe, die Netzwerk- und Serverressourcen für Entwicklung, Betrieb und Spiel erhält. Diese Formulierung ist wichtig, weil sie mindestens drei Dinge trennt, die sonst verschwimmen können: die Dachgruppe, die AS63800-Backbone-Aktivität und die TeamFelNull-Testumgebung, die mit AS58790 verbunden ist. Öffentliche Aufzeichnungen zeigen Zugehörigkeit und Ressourcenunterstützung; sie offenbaren keinen Vertrag, der das Eigentum an Racks, Routern oder Servern auf TeamFelNull überträgt.

Die öffentliche Geschichte von SERVER-GsAS63800bezeichnet das Backbone als ein nicht-kommerzielles Netzwerk zum Lernen von Internet-Technologie. Seine Chronologie spricht offen über Experimente: Adressressourcen beschaffen, Upstreams finden, Community-Austausche ausprobieren, Konnektivität ändern und Routenüberwachungswerkzeuge bauen. DieÜber-Seite der Gruppesagt, dass ihr Hauptaktivitätsort Tokio ist, und nennt Zwecke wie Konnektivität, Lernen, Aufbau und technische Entwicklung. Diese Seiten betreffen AS63800 und die SERVER-G Group, nicht eine separat dokumentierte Unternehmensbilanz für AS58790. Sie helfen, die Umgebung um TEAMFELNULL zu erklären, beweisen aber nicht, dass jedes AS63800-Asset oder jede Richtlinie der Testumgebung gehört.

Diese Grenze ist wichtig, wenn das Wort „Gruppe“ mit einer rechtlichen oder betrieblichen Garantie verwechselt wird. Die öffentliche Seite von TEAMFELNULL verwendet „TeamFelNull“ und „FelNull“; Routing-Aufzeichnungen verwenden „TeamFelNull“, „SERVER-G Group“ und „SERVER-G TestBed TeamFelNull“. Die Bot-Bedingungen beschreiben FelNull als eine Organisation. Keine der geprüften Seiten identifiziert eine konventionelle Hosting-Unternehmensregistrierung, einen vertraglichen rechtlichen Namen für Infrastrukturdienstleistungen, eine Rechnungsadresse oder die Partei, die einem Kunden Service-Gutschriften schulden würde.

Es wäre unsicher, diese Details allein aus dem Branding abzuleiten.

Selbst SERVER-GsBackbone-Beschreibungzieht eine Linie zwischen Gemeinschaftsaktivität und begrenzter kommerzieller Nutzung. Sie sagt, das Netzwerk sei studentengeführt und im Grunde nicht gewinnorientiert, nennt finanzielle Grenzen und weist darauf hin, dass einige Adressnutzungen dazu beitragen, Aktivitäten und Betrieb zu finanzieren. Sie sagt auch, dass diese kommerziellen Adressen nicht von AS63800 propagiert oder genutzt werden. Das ist ein Hinweis auf einen gemischten wirtschaftlichen Kontext, kein Beweis dafür, dass AS58790 ein standardmäßiges kommerzielles Hosting-Produkt anbietet. Es macht eine vertragliche Klarstellung notwendiger: wer stellt Rechnungen, wem gehört die Hardware, wessen Netzwerk trägt den Dienst, und wer bleibt verantwortlich, wenn ein Teil ausfällt?

Eine Testumgebung kann technisch kompetent und nützlich sein. Sie kann echte Konnektivität bieten, geschätzte Dienste hosten und Betreiber Lektionen lehren, die ausgefeilte Anbieter verschleiern. Aber ihre Risikoverteilung ist anders. Informeller Support kann schnell sein, wenn Freiwillige verfügbar sind, und langsam, wenn Studium, Arbeit oder Leben dazwischenkommen. Hardware kann opportunistisch gekauft werden. Netzwerkpfade können sich ändern, wenn Sponsoring oder Gemeinschaftsbeziehungen sich ändern. Nutzer, die dieses Geschäft verstehen, mögen es völlig angemessen finden.

Nutzer, die Unternehmenskontinuität annehmen, weil sie „25G“ und vier Standortnamen gesehen haben, würden ein Versprechen kaufen, das die öffentliche Aufzeichnung nicht macht.

Was TeamFelNull tatsächlich vor den Nutzern präsentiert

Die sichtbarsten Dienste sind spezifisch und gemeinschaftsorientiert. Die TeamFelNull-Seite präsentiert saisonale Minecraft-Mod-Server, Softwareentwicklung und kleine öffentliche Projekte. IhreDiscord-Sprachbot-Seitebewirbt mehrere Instanzen eines Text-zu-Sprache-Bots, während ihreReversi-Seiteeine Spielaktivität für Discord anbietet. Dies sind reale Benutzeroberflächen: Menschen verbinden sich, senden Inhalte, erwarten, dass der Zustand für eine gewisse Zeit bestehen bleibt, und bemerken, wenn der Dienst verschwindet. Sie sind ein besserer Beweis für einen Betriebszweck als eine allgemeine Behauptung von „Cloud“.

DieBedingungen und Datenschutzhinweisdes Bots bieten einen seltenen Einblick in die Datengrenze. Sie sagen, dass Benutzer-, Server- und Kanalidentifikatoren gespeichert werden können, um den Dienst funktionsfähig zu halten; Benutzernamen, Spitznamen und Nachrichten können gesammelt werden, um Sprache zu erzeugen, und nur für den notwendigen Zeitraum aufbewahrt werden. Der Hinweis verspricht angemessene Schutzmaßnahmen, lehnt aber vollständige Sicherheit ab, erlaubt es, den Dienst oder die Bedingungen ohne Vorankündigung zu ändern, und lehnt die Haftung für Schäden ab. Diese Bestimmungen gelten für diesen Bot, nicht automatisch für jeden Server oder Netzwerkdienst, aber sie offenbaren den Stil des einzigen öffentlichen Nutzervertrags, der hier gefunden wurde: breites betriebliches Ermessen, begrenzte Zusicherung und keine quantifizierte Wiederherstellungsverpflichtung.

Die Softwareseite ist umfassender dokumentiert als die gehostete Seite. EinTeamFelNull-Launcher-Tutorialerklärt einen angepassten Spiele-Launcher und beschreibt Antiviren-Scans während des Build-Prozesses. DieSERVER-G-Dokumentationsseitekonzentriert sich auf diesen Launcher, Installation und Spielinstanzverwaltung. Dies zeigt eine Gruppe, die in der Lage ist, Anleitungen für Benutzer zu erstellen. Der Kontrast ist bezeichnend: Öffentliche Anleitungen existieren für Client-Software, während gleichwertige Seiten für die Bereitstellung virtueller Maschinen, Speicherfestigkeit, Server-Backups, Missbrauchsbehandlung, Incident-Status und Kontoabwicklung nicht sichtbar sind.

Ein historischer, inoffiziellerJapan Minecraft Servers-Eintragverzeichnet einen „TeamFelNull-24h-Server“, eingereicht im Jahr 2019, mit einer sehr niedrigen aufgezeichneten Betriebszeit und einem Status, der besagt, dass er nicht erreichbar war. Dieser Eintrag kann den Zustand von AS58790 im Jahr 2026 nicht belegen. Er könnte eine andere Maschine, Adresse und Betriebszeit beschreiben, und Drittanbieter-Tests können aus vielen Gründen fehlschlagen. Er ist nur als Marktsignal nützlich: Der Name TeamFelNull war mit einem öffentlichen Spieleserver verbunden, und mindestens ein alter Endpunkt war nicht kontinuierlich erreichbar. Aktuelle Überwachung, ein Incident-Archiv oder eine Betreibererklärung wären erforderlich, um diese Geschichte mit der heutigen Testumgebung zu verbinden.

Die öffentlichen Dienste zeigen auch unterschiedliche Abhängigkeitsmuster. Ein Spieleserver benötigt Rechenleistung, Speicher, Lagerung, versionskompatible Software und eine stabile Route; ein Sprachbot hängt zusätzlich von Discord und Sprach-Engines ab, die außerhalb der Kontrolle von TeamFelNull liegen. Ein Launcher kann auf dem Computer einer Person nutzbar bleiben, selbst wenn der Gemeinschaftsserver verschwindet, aber Downloads, Mod-Pakete oder Authentifizierungsabhängigkeiten möglicherweise nicht. All dies unter „Hosting“ zusammenzufassen, verbirgt, wer welche Störung kontrolliert.

TEAMFELNULL betreibt möglicherweise die Anwendung und einige Server, während SERVER-G oder eine andere Partei das Routing, eine Einrichtung den Strom und externe Plattformen die Identität und Verteilung kontrollieren.

Deshalb sollte „kundenorientierte Kapazität“ hier eng ausgelegt werden. Es gibt Belege dafür, dass Ressourcen Nutzern und Partnergemeinschaften zur Verfügung gestellt werden. Es gibt keine öffentliche Zählung von zahlenden Kunden, aktiven Instanzen, verwalteten Servern, Speichervolumen oder reservierten Kernen. Das korrekte Betriebsbild ist eine Reihe von Gemeinschaftsanwendungen, die von einem Bildungsnetzwerk unterstützt werden, mit einem nicht quantifizierten Pool physischer und virtueller Ressourcen. Jede stärkere Aussage benötigt ein aktuelles Inventar und die Verträge, die dieses Inventar mit der Netzwerkidentität verbinden.

Wo das physische System Tokio berühren könnte

Die Standortspur von AS58790 ist vollständig metropolitan. Die einzelnen Standortseiten von PeeringDB listen die Testumgebung amAT TOKYO CC1/CC2,Equinix TY8,NTT DATA Otemachi BuildingundOtemachi Place West Towerauf. Diese Aufzeichnungen bestätigen die vier Namen im Netzwerkprofil, aber ihre Genauigkeit endet bei der Anwesenheit. Sie zeigen nicht, welches Gebäude in einem kombinierten Campus-Etikett verwendet wird, ob die Verbindung physisch oder remote verlängert ist, oder ob Rechenleistung neben dem Netzwerkport installiert ist.

Die zugrundeliegenden Einrichtungen sind substanziell.AT TOKYOs eigener Berichtsagt, dass CC1 eine Gesamtgrundfläche von 140.000 Quadratmetern hat und beschreibt mehrere Stromversorgungen, USV, Notstromgeneratoren und rund um die Uhr Überwachung in seinen Einrichtungen.Equinix TY8-Spezifikationgibt eine Adresse in Tokio, 40.418 Quadratfuß Fläche, N+1 Stromredundanz und N+20% Kühlungsredundanz an. Equinix‘Betriebsabdeckungstabellesagt, dass TY8 24/7 Vor-Ort-Abdeckung hat.

Am Otemachi Place bewirbt BroadBand TowersNew Otemachi Standortbeschreibungeine Standard-Rack-Leistung von 6 kVA, doppelte 200-Volt-30-Amp-Leitungen, N+1 Generatoren, die bis zu 72 Stunden ohne Betankung laufen können, mehrere Konnektivitätsoptionen und Remote-Support. Ihre separateNetzwerkdiensteseitebietet Design- und Betriebsunterstützung für Router, Speichernetzwerke und Cloud-Verbindungen. Dies sind Einrichtungsbetreiberfähigkeiten, die im Gebäude verfügbar sind. Sie zeigen nicht, dass TEAMFELNULL ein Vollrack, zwei Stromkreise, Remote-Hände oder einen bestimmten Dienst von BroadBand Tower kauft.

Dies ist die Eigentumsgrenze in praktischer Hinsicht. Der Einrichtungsbetreiber kontrolliert die Gebäudehülle, den Energiebezug, Generatoren, Kühlungsanlagen, Zugangskontrolle und die Bedingungen, unter denen Techniker ein Rack erreichen. Ein Colocation-Kunde kontrolliert nur das, was er vertraglich vereinbart hat: vielleicht einen Schrank, ein Teilrack, eine Querverbindung oder einen remote bereitgestellten Port. Der Netzwerkbetreiber kontrolliert seine Router-Konfiguration und Adressankündigungen. Die Anwendungsgruppe kontrolliert Software und Benutzerzustand, soweit sie Zugriff hat.

Das widerstandsfähige Design einer Einrichtung kann eine einzelne Stromversorgung in einem Kundenserver, eine unbezahlte Querverbindung, eine fehlgeschlagene Festplatte ohne Ersatz oder eine Anwendungsdatenbank ohne getestete Wiederherstellung nicht kompensieren.

Die geografische Behauptung ist daher sowohl stärker als auch enger als „global“. Die Dienste können weltweit erreichbar sein, und Internetrouten sind von Natur aus global. Die physischen Nachweise, die hier geprüft wurden, weisen auf Tokio, Japan hin. Sie begründen keine unternehmenseigenen Racks in Europa, Nordamerika, anderen asiatischen Metropolen oder sogar Osaka. Auch schaffen vier Tokio-Namen nicht unbedingt Schutz vor einer metropolitanen Katastrophe, einem gemeinsamen Upstream-Ausfall oder einem einzigen administrativen Fehler.

Die Datenlokalität für die sichtbare Infrastruktur sollte als Tokio-zentriert behandelt werden, bis ein aktuelles Anlagenregister etwas anderes beweist.

Für Nutzer hat diese Lokalität zwei Konsequenzen. Erstens hängt die Latenz von der Entfernung nach Tokio und vom gewählten Upstream-Pfad ab; das Wort „global“ kann die Physik nicht auslöschen. Zweitens sind die maßgeblichen Regelungen für physischen Zugang, Strom und gespeicherte Daten wahrscheinlich japanisch, selbst wenn entfernte Nutzer von anderswo verbinden. Die öffentliche Bot-Mitteilung gibt nicht an, wo ihre Datenbank gehostet wird, und die Standortlisten verknüpfen eine bestimmte Anwendung nicht mit einem bestimmten Gebäude.

Ein Nutzer, der eine Zusicherung des Aufenthaltsorts benötigt, würde schriftliche Platzierungs-, Replikations- und Subunternehmerdetails benötigen, nicht eine Stadt, die aus Routing-Aufzeichnungen abgeleitet wurde.

Warum vier Standorteinträge nicht vier unabhängige Sites bedeuten

Redundanz beginnt mit Unabhängigkeit, nicht mit Zählen. Vier Standortnamen können vier Fehlerdomänen darstellen, aber sie können auch einen Router darstellen, der über mehrere Verbindungsstrukturen erreicht wird, einen Dienst, der zwischen Gebäuden erweitert wird, ruhenden Querverbindungen oder Aufzeichnungen, die für geplanten Zugang gepflegt werden. PeeringDB ist eine wertvolle Branchendatenbank, dennoch werden Netzwerk- und Standorteinträge von Teilnehmern beigetragen.

Der AS58790-Eintrag sagt, dass seine Standortinformationen im Februar 2026 aktualisiert wurden, was Aktualität unterstützt; er legt dennoch nicht die zugrundeliegenden Stromkreisaufträge oder Rackbelegung offen.

Die Geographie selbst lädt zur Vorsicht ein. Zwei Einträge sind in Otemachi, einer ist ein AT TOKYO Campus-Etikett, das CC1/CC2 abdeckt, und einer ist Equinix TY8 in Shinagawa. Der PeeringDB-Eintrag von Otemachi Place vermerkt eine optische Verbindung zum NTT DATA Otemachi Building. Diese Verbindung kann betrieblich nützlich sein, aber sie bedeutet auch, dass zwei Namen in einer Datenbank durch eine physische Erweiterung erreichbar sein können, nicht durch zwei separat mit Strom versorgte TEAMFELNULL-Bereitstellungen. Aus dieser Möglichkeit sollte keine genaue Route abgeleitet werden.

Der Eintrag belegt eine verfügbare Verbindung zwischen den Gebäuden, nicht den Pfad oder die Topologie von AS58790.

Die INIXP-Verbindung fügt eine weitere Ebene hinzu. Der Austausch ist an mehreren Tokio- und Osaka-Einrichtungen vorhanden, aber der AS58790-Eintrag veröffentlicht keine Portposition in seinem Netzwerkprofil. Ein 25-Gbit/s-Austauschsanschluss könnte an einem Standort geliefert und über ein Partnernetzwerk oder eine Metro-Schaltung transportiert werden. Ohne Autorisierungsschreiben, Querverbindungsaufzeichnung, geräteebenen Diagramm und Stromkreisdiversitätsaussage bleibt die physische Übergabe unbekannt.

Die beiden Austauschadressen beweisen eine logische Verbindung; sie lokalisieren den Switch-Port nicht genau genug, um ein Kabel zu kartieren.

Echte Multistandort-Rechen-Resilienz würde mehr Beweise erfordern. Mindestens würde ein aktuelles Inventar mit Strom versorgte Server oder Speicher an mindestens zwei Standorten zeigen; Replikation hätte eine bekannte Richtung und Verzögerung; DNS- oder Routing-Failover hätte einen getesteten Auslöser; Nutzer wüssten, welche Dienste woanders neu gestartet werden können; und der Wiederherstellungsentwurf würde eine gemeinsame Verwaltungsebene vermeiden. Nichts in den öffentlichen Seiten besagt, dass die Minecraft-Umgebungen, Discord-Bot-Daten oder Entwicklungsdienste zwischen Einrichtungen repliziert werden. Es ist möglich, dass sie es sind.

Es ist nicht nachgewiesen.

Die gleiche Vorsicht gilt für die Upstream-Diversität. Ein Router kann mehrere Pfade hören, während der gesamte Kundenverkehr immer noch von einem Transportanbieter, einem Tunnelendpunkt, einer Metro-Endleitung oder einer Konfigurationsinstanz abhängt. SERVER-Gs öffentliche Geschichte beschreibt mehrere Beziehungen im Laufe der Zeit und den Rückzug von einigen überseeischen Community-Austauschen im Dezember 2024. Seine Peering-Politik erlaubt ausdrücklich GRE-, SIT- und WireGuard-Tunnel sowie Verbindungen an Austauschen.

Tunnel sind legitime Werkzeuge für eine Testumgebung, aber ein logisch getrennter BGP-Nachbar über dieselbe zugrundeliegende Zugangsschaltung ist keine physische Diversität.

Eine rigorose Redundanzaussage würde die Ebene identifizieren, auf der Unabhängigkeit existiert. Getrennte BGP-Sitzungen schützen nur dann vor einem Nachbarausfall, wenn ein anderer nutzbarer Pfad bleibt. Getrennte Einrichtungsstromversorgungen schützen ein Rack nur, wenn der Server korrekt angeschlossene doppelte Netzteile hat. Getrennte Gebäude schützen Anwendungen nur, wenn aktuelle Daten in beiden vorhanden sind und Betreiber Nutzer umleiten können. Getrennte Support-Kontakte schützen die Wiederherstellung nur, wenn mehr als eine Person Anmeldeinformationen und physischen Zugang hat.

TEAMFELNULLs öffentliche Nachweise bestätigen keine dieser End-to-End-Kombinationen, daher sollten vier Standortetiketten als Verbindungsreichweite gelesen werden, nicht als Vier-Standort-Dienstkontinuität.

Kapazität: Die einzige harte Zahl liegt am Austauschrand

Kapazität ist nicht eine Zahl. Sie ist ein Stapel von Grenzen, und die niedrigste aktive Grenze bestimmt den Dienst. Der 25-Gbit/s-Austauschport ist installierte logische Netzwerkkapazität an einer Verbindung. PeeringDB kennzeichnet die Verbindung als betriebsfähig, was stärker ist als ein Zukunftsplan. Aber der nutzbare Durchsatz könnte niedriger sein aufgrund von Router-Weiterleitungsgrenzen, Upstream-Politik, Überlastung, Transport zwischen einem Rack und dem Austausch, Paketgröße, Angriffen oder Anwendungsengpässen. Verkaufte Kapazität könnte noch niedriger sein – oder nicht vorhanden, wenn die Testumgebung keine Bandbreite verkauft.

Adressraum ist eine andere Art von Kapazität. PeeringDB listet fünf IPv4-Präfixe und 50 IPv6-Präfixe für AS58790, währendCloudflare Radars AS-Übersichtdas Netzwerk in Japan identifiziert und Verkehrsansichten zeigt, wenn ausreichende Beobachtungen vorhanden sind. Eine separateCloudflare-Routing-Ansichtpräsentiert angekündigten Adressraum, Verbindungen, RPKI-Status und BGP-Aktivität. Präfixzahlen beschreiben Routing-Granularität, nicht Server. Ein /24 kann 256 IPv4-Adressen nummerieren, aber eine Adresse kann ungenutzt sein, einen Router identifizieren, virtuell zugewiesen sein oder vielen Domänen hinter einem Host dienen.

Drittanbieter-Datensätze veranschaulichen, warum ein Datum und eine Definition mit jeder Zahl mitgeliefert werden müssen.IPinfos AS58790-Seitelistet derzeit zwei /24-Blöcke – 44.30.37.0/24 und 44.30.62.0/24 – zusammen mit mehreren beobachteten Upstreams und einer Handvoll Adressen, die auf Tests reagierten. EineCIDR Report-Ansichtzeigt ebenfalls zwei /24-Ankündigungen und 512 originierten IPv4-Adressen in seiner Sammleransicht. Diese Beobachtungen unterstützen aktuelle IPv4-Routing, aber keiner sagt uns, wie viele Maschinen existieren oder ob eine Antwort von Kundenrechner kam.

Andere Aggregatoren widersprechen sich. Einegespiegelte Registrierungsseitereproduziert den JPNIC-AS-Namen und einen IPv6-Bereich 2401:d20:1020::/44, meldet aber keinen IPv4-Bereich.IP2Locations AS-Seitezeigt ein /24 und ein IPv6 /46, währendIPGeolocations Seitenull Routen meldet, obwohl sie die AS-Identität reproduziert. Dies sind keine äquivalenten Schnappschüsse; Sammeldaten, Routensichtbarkeit und Klassifizierungsmethoden unterscheiden sich. Der Widerspruch ist ein Beweis für die Grenzen von Aggregatordaten, kein Grund, die Zahlen zu mitteln.

Keine öffentliche Quelle, die geprüft wurde, gibt CPU-Kerne, Arbeitsspeicher, Bare-Metal-Knoten, virtuelle Maschinen, Festplattenkapazität, Speicherredundanz, reservierte Leistung, durchschnittliche Stromaufnahme oder freie Rack-Einheiten an. Keine Quelle trennt die Entwurfskapazität von installierter, mit Strom versorgter, betriebsfähiger und kundennutzbarer Kapazität. Einrichtungsweite Zahlen können die Lücke nicht schließen. Equinix' 40.418 Quadratfuß an TY8 gehören zur Einrichtung, nicht zu AS58790.

BroadBand Towers Standard-Rack-Spezifikation von 6 kVA ist ein verfügbares Produktmerkmal, kein Beweis für ein TEAMFELNULL-Rack oder eine Berechtigung.

Die wirtschaftlich bedeutsame Kapazität ist das, was einen Ausfall überleben kann, während Verpflichtungen eingehalten werden. Wenn ein Dienst 16 Kerne und 64 GB Arbeitsspeicher benötigt, zählt ein Ersatzhost nur, wenn er kompatibel, mit Strom versorgt, verbunden und nicht bereits reserviert ist. Wenn Speicher repliziert ist, zählt die zweite Kopie nur, wenn sie aktuell und unabhängig wiederherstellbar ist. Wenn 25 Gbit/s einen Austausch erreichen, der Server aber eine 1-Gbit/s-Schnittstelle hat, hat die Anwendung nicht 25 Gbit/s.

Bis TEAMFELNULL diese unteren Schichtzahlen veröffentlicht oder privat bereitstellt, bleibt seine verkaufbare Hosting-Kapazität unbekannt.

Die Upstream-Geschichte ist real, aber nicht sauber dokumentiert

AS58790 ist als Ursprung sichtbar, und mehrere öffentliche Ansichten sehen Routen, die es erreichen. Das ist ein bedeutender Betriebsnachweis. IPinfo listet Hurricane Electric, SDCC Japan-West Area und SERVER-G Group als Upstreams oder Peers, während seine Test-Trace von Juni 2026 zu 44.30.37.1 japanische Netzwerke durchlief, bevor sie AS58790 erreichte. Die CIDR Report-Sammleransicht zeigte AS38074 direkt benachbart zu AS58790 für die beiden sichtbaren /24er. Cloudflares Routing-Seite bietet eine weitere Live-Perspektive. Zusammen unterstützen diese Quellen die Erreichbarkeit, aber sie stimmen nicht in einem stabilen Anbietergraphen überein.

Dafür gibt es mehrere gutartige Gründe. BGP wird von bestimmten Sammlern zu bestimmten Zeiten beobachtet. Eine Beziehung, die von einem Pfad wie ein Upstream aussieht, kann ein Peer, ein Route-Server-Pfad oder ein Dienst sein, der durch ein anderes Netzwerk getragen wird. IPv4 und IPv6 können verschiedene Anbieter verwenden. Eine Sitzung kann konfiguriert, aber inaktiv, selektiv oder nur von einigen Standorten sichtbar sein. Der Austauscheintrag von PeeringDB zeigt die INIXP-Verbindung, markiert AS58790 jedoch als nicht den Route-Server dort nutzend.

Das bedeutet, dass die Anwesenheit allein nicht offenbart, welche bilateralen Sitzungen tatsächlich Produktionsverkehr transportieren.

Die breitere SERVER-G-Geschichte ist informativ, kann aber nicht einfach AS58790 zugeordnet werden. Sie zeichnet AS63800-Beziehungen zu Vultr, Hurricane Electric, SDCC und anderen Netzwerken zu verschiedenen Daten auf, zusammen mit späteren Rückzügen und Ergänzungen. DiePeering-Politikvon AS63800 erfordert globale AS-Nummern, Mindestpräfixgrößen, ROAs, IRR-Datensätze und PeeringDB-Kontakte; sie sagt auch, dass etwas Instabilität toleriert wird, weil das Netzwerk experimentell ist. Dies sind erklärte Politiken für AS63800. Sie deuten auf die Kultur hin, die die Testumgebung umgibt, nicht auf ein verbindliches Betriebszeitversprechen für AS58790.

Die Eigentumsfrage sitzt innerhalb der Routing-Frage. PeeringDB ordnet AS58790 der SERVER-G Group zu und verwendet felnull.dev als Website. Die öffentliche Gruppenseite sagt, dass AS63800 das Kernnetzwerk ist und TeamFelNull mit Ressourcen versorgt. Daher ist es vernünftig, AS58790 als eine von SERVER-G unterstützte TeamFelNull-Testumgebung zu sehen. Es ist nicht vernünftig anzunehmen, dass TeamFelNull jeden Upstream-Vertrag, jede Querverbindung oder die Adressressourcen, die es originiert, besitzt. Ein Kunde muss wissen, welche Partei jede Abhängigkeit erneuern, kündigen oder neu konfigurieren kann.

Routendiversität hat auch eine Kontrollebenen-Komponente. Wenn eine Person, eine Router-Konfiguration oder ein Berechtigungssatz jede Sitzung kontrolliert, schützen mehrere Upstreams nicht vor einem fehlerhaften Routenfilter oder versehentlichem Rückzug. Ein Route-Leak, ungültiger Ursprung, abgelaufene Routenautorisierung oder übermäßig breiter Filter können gesunde Server unerreichbar machen. Die öffentlichen Ansichten zeigen, dass Routing existiert; sie veröffentlichen keine Änderungskontrolle, Out-of-Band-Zugang, Konfigurationssicherungen, Doppelrouter, automatischen Rollback oder eine 24-Stunden-Netzwerkbetriebsrotation.

Was die Frage klären würde, ist spezifisch und bescheiden: aktuelle Briefe oder Rechnungen, die aktiven Transit und Transport belegen; eine Topologie, die zeigt, welche Verbindungen physisch, virtuell oder getunnelt sind; Sammler-Nachweise für beide Adressfamilien; gültige Routenautorisierungsdatensätze; und ein Failover-Test, der zeigt, dass der Verkehr nutzbar bleibt, wenn der primäre Pfad zurückgezogen wird. Bis dahin verdienen die Upstream-Nachweise ein mittleres Vertrauen als Schnappschuss und ein niedriges Vertrauen als Redundanzgarantie.

Strom, Hardware und Hände sind die versteckte Kontrollfläche

Netzwerkaufzeichnungen dominieren tendenziell, weil sie öffentlich sind. Die meisten Hosting-Ausfälle werden jedoch auf einer viel weniger sichtbaren Ebene gelöst: jemand findet das ausgefallene Netzteil, die Festplatte, das Speichermodul, die Optik, den Lüfter oder das Kabel und ersetzt es. TEAMFELNULL veröffentlicht kein Hardware-Inventar, keine Lebenszyklus-Politik oder keinen Bestand an Ersatzteilen. Ein 25-Gbit/s-Port kann vollkommen gesund bleiben, während ein einzelner Anwendungsserver offline ist, weil eine kompatible Komponente fehlt.

Die Widerstandsfähigkeit der Einrichtung hilft nur bis zur Kundenübergabe. AT TOKYO wirbt mit mehreren Einspeisungen, USV, Generatoren und 24-Stunden-Überwachung. Equinix wirbt mit N+1 Strom an TY8 und rund um die Uhr Betriebsabdeckung. BroadBand Tower wirbt mit doppelten Rack-Einspeisungen, N+1-Erzeugung und Remote-Support am New Otemachi. Diese Kontrollen reduzieren das Risiko auf Gebäudeebene für Kunden, die sie kaufen und korrekt nutzen.

Sie offenbaren nicht, ob AS58790-Geräte doppelte Netzteile haben, ob beide Einspeisungen vertraglich vereinbart sind, ob Remote-Support autorisiert ist oder wie schnell TeamFelNull Arbeiten genehmigen kann.

Support-Arbeit ist selbst eine Kapazität. DieKontaktseitevon TeamFelNull leitet Anfragen an Discord weiter. Das kann für eine Gemeinschaft praktisch sein, bietet aber keine öffentliche Schweregradskala, Antwortzeitverpflichtung, Telefon-Eskalation, benannte Dienstrotation oder alternativen Kanal, falls Discord nicht verfügbar ist. Die Seiten von SERVER-G bieten E-Mail- oder Discord-Pfade für Peering, dennoch gibt es keine öffentliche Incident-Hotline, die speziell die Wiederherstellung für gehostete Dienste verspricht. Wenn eine Maschine um 03:00 Uhr ausfällt, ist der Unterschied zwischen „jemand könnte es bemerken“ und „ein autorisierter Techniker muss innerhalb von 30 Minuten reagieren“ der Dienst.

Hardware-Lagerbestand ist besonders wichtig für eine kleine Testumgebung. Große Anbieter verteilen Ersatzteile und Personal auf viele Server; ein Gemeinschaftsbetreiber kann einzigartige Maschinen haben, die zu verschiedenen Zeiten gekauft wurden. Ohne eine Kompatibilitätsliste und eingelagerte Ersatzteile kann ein ausgefallenes Motherboard einen routinemäßigen Austausch in Beschaffung, Reise und Neuaufbau verwandeln. Kein öffentlicher Nachweis sagt, ob Server gespiegelte Boot-Laufwerke, Hot-Swap-Speicher, Out-of-Band-Management, doppelte Netzwerkschnittstellen oder standardisierte Images verwenden.

Es wäre falsch, entweder ein robustes Unternehmensdesign oder improvisierte Hardware anzunehmen.

Abrechnungs- und Anbieterverträge können denselben Ausfall ohne defekte Ausrüstung verursachen. Eine verspätete Colocation-Zahlung, abgelaufene gesponserte Ressource, gekündigte Transportvereinbarung, Domain-Verlängerungsproblem oder geänderte Einrichtungszugangsliste kann einen gesunden Dienst trennen. SERVER-Gs Aussage über finanzielle Grenzen macht diese Abhängigkeit prüfenswert, beweist aber keine aktuelle Notlage. Nachweise würden aktuelle Verträge, Verlängerungsdaten, verantwortliche Parteien und einen Reserve- oder Nachfolgeplan erfordern. In deren Abwesenheit ist die finanzielle Kontinuität einfach unbekannt.

Nutzer sind unterschiedlich betroffen. Ein Spieler kann den Zugang zu einer saisonalen Welt verlieren; ein Entwickler kann einen Build-Dienst verlieren; eine Discord-Gemeinschaft kann die Sprachausgabe verlieren; ein gesponsertes Projekt kann eine Adresse oder Route verlieren. Die Kosten können Unannehmlichkeiten statt Umsatz sein, aber Datenverlust kann dennoch persönlich und irreversibel sein. Der richtige Widerstandsfähigkeitsstandard sollte der versprochenen Nutzung folgen.

Eine Testwelt kann Ausfallzeiten tolerieren, wenn Nutzer informiert sind; eine Datenbank, die Identifikatoren sammelt, oder eine langlebige Gemeinschaftswelt benötigt Backup, Aufbewahrung und Wiederherstellungsregeln, selbst wenn kein Geld den Besitzer wechselt.

Ausfall beginnt mit Mehrdeutigkeit, bevor er das Rack erreicht

Der erste Ausfallpfad ist nicht unbedingt technisch. Es ist die Mehrdeutigkeit darüber, was versprochen wurde. Wenn Nutzer „Serverressourcen“ hören und Rechenzentrumsnamen sehen, nehmen sie möglicherweise Backups, Ersatzhosts und verwaltete Wiederherstellung an. Wenn Betreiber Best-Effort-Zugang zum Spielen und Lernen meinen, können beide Seiten vernünftig handeln und dennoch nach einem Ausfall kollidieren. Die schnellste Risikominderung ist eine klare Dienstbeschreibung, die sagt, was gehostet wird, wer es betreibt, was Best-Effort ist, was gesichert ist und was Nutzer selbst kopieren müssen.

Am Rack ist die Abfolge vertraut. Eine Stromversorgung oder ein Netzteil fällt aus; ein Switch-Port, eine Optik oder eine Netzwerkkarte fällt aus; eine Festplatte oder ein Controller korrumpiert den Zustand; Kühlungsschutz schaltet Hardware ab; oder geplante Arbeit erfordert einen Neustart. Einrichtungsüberwachung kann Umgebungsalarme identifizieren, aber die Anwendungswiederherstellung bleibt beim Kunden, es sei denn, verwaltete Dienste wurden gekauft. Keine der öffentlichen Seiten verknüpft TEAMFELNULL mit einem bestimmten Remote-Support-Paket, Ersatzteillager oder Wartungsfenster.

Auf der Netzwerkebene kann ein Austauschport, eine Metro-Schaltung, ein Tunnelendpunkt, eine Upstream-Sitzung oder eine Routenankündigung ausfallen. Die vier Standorteinträge offenbaren nicht, ob diese Elemente divers sind. Ein 25-Gbit/s-INIXP-Port ist ein nützlicher Pfad, aber der Austausch beschreibt sich selbst als Best-Effort ohne offengelegte Servicebedingungen auf seiner öffentlichen Auflistung. Bilaterales Peering an einem Austausch ist nicht dasselbe wie vollständiger Internet-Transit, und eine Austauschverbindung kann ohne geeignete Peers oder einen Upstream nicht jedes Ziel erreichen.

Ein benutzerorientierter Dienst kann daher für einige Netzwerke ausfallen, während er von anderen erreichbar bleibt.

Auf der Anwendungsebene schaffen Updates ihre eigenen Reparaturfenster. TeamFelNull arbeitet mit modifiziertem Minecraft und angepassten Launchern, bei denen Server- und Client-Versionen übereinstimmen müssen. Ein fehlgeschlagenes Update kann Benutzer stranden lassen, selbst wenn Routing und Hardware gesund sind. Die Launcher-Dokumentation zeigt Aufmerksamkeit für Installation und Migration, aber es gibt keinen öffentlichen Zeitplan für Serverwartung, Rollback, Datenbankkompatibilität oder Aufbewahrung älterer Welten.

Anwendungszustand ist oft der am schwersten zu rekonstruierende Teil, weil eine neue Maschine die verlorene Geschichte nicht neu erstellen kann.

Externe Plattformen fügen korrelierte Abhängigkeiten hinzu. Der Sprachbot ist auf Discord für Identität, Ereignisse und Benutzerzugang angewiesen und kann auf eine oder mehrere Sprach-Engines angewiesen sein. Ein Ausfall oder eine Richtlinienänderung bei diesen Diensten kann den Bot unverfügbar machen, ohne jeden Fehler in AS58790. Der Kontakt ist ebenfalls auf Discord angewiesen, sodass der Dienst und sein primärer öffentlicher Support-Kanal gemeinsam ausfallen können. Eine Statusseite auf einer unabhängig gehosteten Domain plus E-Mail-Eskalation würde diese Pfade trennen.

Die betroffene Bevölkerung ist nicht quantifiziert. Die Startseite lädt eine Gemeinschaft ein; die Bot-Seite zeigt mehrere Bot-Instanzen; der alte Spieleintrag verzeichnet einen öffentlichen Endpunkt. Keiner gibt aktuelle aktive Benutzer, Spitzensitzungen oder die Anzahl abhängiger Projekte an. Das verhindert eine numerische Auswirkungsschätzung. Die qualitative Auswirkung ist klar: Gemeinschaftszugang, gespeicherte Identifikatoren, Spielzustand, Softwareverteilung und gesponserte Ressourcen können alle unterbrochen werden.

Ein wahrheitsgetreuer Incident-Plan würde diese Klassen nennen, ohne eine Kundenzahl zu beanspruchen, die nicht offengelegt wurde.

Wiederherstellung und Portabilität enden an der Anwendungsgrenze

Wiederherstellung hat zwei getrennte Fragen: Kann der Betreiber den Dienst wiederherstellen, und kann der Benutzer gehen? Die öffentliche Aufzeichnung beantwortet weder für gehostete Rechenleistung. Es gibt keine veröffentlichte Backup-Häufigkeit, Aufbewahrungsfrist, Offsite-Kopie, Wiederherstellungstest, Wiederherstellungspunkt oder Wiederherstellungszeit für TeamFelNull-Server. Es gibt auch keinen dokumentierten Export für eine virtuelle Maschine, Datenbank, Spielwelt, Kontoaufzeichnung oder gehostetes Volume.

Ein Benutzer kann nicht sagen, ob eine ausgefallene Festplatte Minuten Rollback, Tage Rekonstruktion oder permanenten Verlust bedeutet.

Es gibt eine schmale, nützliche Ausnahme auf der Client-Seite. Die Launcher-Dokumentation bietet eineInstanz-Export-Prozedur, die ein ZIP aus ausgewählten lokalen Dateien erstellt, und eine separateLauncher-Migrationsanleitungerklärt, wie lokale Instanzordner zwischen Versionen kopiert werden. Diese Anleitungen verbessern die Portabilität für die Client-Umgebung eines Spielers. Sie exportieren keine serverseitigen Welten, Bot-Datenbanken, Anmeldeinformationen, DNS, IP-Adressen oder virtuellen Maschinen.

Diese Grenze ist leicht zu übersehen. Ein Spieler kann Mods und Konfiguration bewahren, aber dennoch die gemeinsame Welt verlieren. Ein Bot-Administrator kann eine Discord-Gemeinschaft behalten, aber gespeicherte Einstellungen verlieren. Ein Entwickler kann Quellcode behalten, aber Build-Artefakte oder Bereitstellungsgeheimnisse verlieren. Ein Netzwerkbenutzer kann ein Anwendungsimage behalten, aber Adressen nicht behalten können, wenn Ressourcenrechte einer anderen Partei gehören. Jede Ebene benötigt ihre eigene Export- und Wiederherstellungsmethode.

Multistandort-Wiederherstellung ist ebenso unbewiesen. Die Standortliste bietet plausible Orte, aus denen Resilienz aufgebaut werden könnte, aber kein öffentlicher Nachweis ordnet einen Dienst zwei Live-Standorten zu oder berichtet Replikationsverzögerung. Selbst wenn eine zweite Maschine existiert, erfordert erfolgreicher Failover aktuelle Daten, Geheimnisse, Routing, DNS, Kapazität und autorisierte Personen. Ein Kalt-Reserve ohne getestete Wiederherstellung kann länger dauern als die Reparatur des Primären. Eine Hot-Replik, die dasselbe Administrationskonto teilt, kann während einer Kompromittierung ausfallen.

Support-Eskalation sollte Teil des Wiederherstellungsdesigns sein, kein nachträglicher Einfall. Discord-only-Kontakt kann während der normalen Gemeinschaftsnutzung funktionieren, aber ein schwerwiegendes Ereignis benötigt einen unabhängigen Pfad, eine verantwortliche Person, Einrichtungsautorisierung und eine Entscheidungsregel für die Ausgabe von Geld für Teile oder Transport. Nachfolge ist ebenfalls wichtig: Mehr als ein vertrauenswürdiger Betreiber sollte in der Lage sein, Domänen zu erneuern, auf Router zuzugreifen, Einrichtungen zu kontaktieren und Backups zu entschlüsseln.

Keine öffentliche Seite belegt diese Abdeckung, daher bleibt es eine Frage, keine Anschuldigung.

Das minimal glaubwürdige Portabilitätspaket wäre einfach: eine Liste benutzereigener Daten; Exportformate; Backup- und Aufbewahrungsgrenzen; Löschzeitpunkt; Ankündigung vor geplanter Schließung; ein Verfahren zur Beschaffung der neuesten Kopie; und ein Test, der zeigt, dass die Kopie anderswo wiederhergestellt werden kann. Für Spieldienste könnte das ein Weltarchiv plus Versionsmanifest sein. Für einen Bot könnte es ein strukturierter Einstellungsexport und Löschbestätigung sein. Für einen virtuellen Server könnte es ein Standard-Festplattenimage und Konfigurationsdatensatz sein.

Ohne diese Verpflichtungen sollten Benutzer ihre eigenen Kopien behalten, wo immer technisch möglich.

Datenlokalität ist Tokio-zentriert, aber Anwendungsdaten bleiben unkartiert.

Die Routing- und Standortnachweise weisen auf Japan, insbesondere Tokio hin. AS58790 ist in Routing-Datensätzen mit einer japanischen Identität registriert, die aufgeführten Verbindungseinrichtungen befinden sich in Tokio, und die beobachteten IPv4-Adressen werden allgemein in Japan geolokalisiert. Das unterstützt eine Tokio-zentrierte physische Bewertung. Es beweist nicht, dass jedes Byte von Anwendungsdaten in Tokio bleibt, weil Softwareabhängigkeiten, Backups, Content Delivery und Drittanbieterdienste Grenzen überschreiten können.

Der Bot ist das klarste Beispiel. Seine Bedingungen besagen, dass Identifikatoren gespeichert und Nachrichten zur Spracherzeugung verarbeitet werden können, aber sie nennen keinen Hosting-Standort, Datenbankanbieter, Sprachanbieter oder Backup-Jurisdiktion. Discord selbst ist eine externe Plattform. Die Standortpräsenz von AS58790 kann nicht beantworten, wo Discord Daten speichert oder wo eine Sprachanfrage verarbeitet wird. Eine Datenaufenthaltsbehauptung würde anwendungsspezifische Dokumentation erfordern, nicht nur einen autonomen System-Ländercode.

Spiel- und Entwicklungsdienste haben ähnliche Unsicherheit. Ein Serverprozess kann auf einer Tokio-Maschine laufen, während Mod-Downloads von einer anderen Plattform kommen, Quellcode auf einem globalen Repository liegt und Backups – falls vorhanden – woanders liegen. Umgekehrt könnte eine von AS58790 originierten Adresse Ausrüstung erreichen, die remote über ein anderes Netzwerk bereitgestellt wird. IP-Geolokalisierung ist eine Schätzung, kein Nachweis eines Racks.

IPinfo warnt ausdrücklich, dass der registrierte oder abgeleitete Standort nicht immer der tatsächlichen Nutzung entspricht, und die Uneinigkeit unter Routing-Aggregatoren zeigt, wie schnell Klassifizierungen abweichen.

Dies ist selbst für einen Gemeinschaftsdienst wichtig. Nutzer könnten sich um rechtlichen Zugang, Löschung, Reaktion auf Verstöße oder einfach um die Latenz einer entfernten Abhängigkeit kümmern. Die öffentliche Datenschutzmitteilung gibt breite Kategorien gesammelter Daten und ein Konzept der notwendigen Aufbewahrung, aber keine feste Aufbewahrungsdauer oder -ort. Sie erlaubt auch Änderungen ohne vorherige Ankündigung. Diese Bedingungen mögen einem kostenlosen Bot angemessen sein, decken jedoch nicht das Bedürfnis eines Käufers nach vertraglicher Souveränität oder Lokalität ab.

Das Etikett „Global“ für den Dienstbereich sollte daher als Reichweite gelesen werden, nicht als Fußabdruck. Eine Website, ein Spieleserver oder ein Discord-Bot können Menschen international von Tokio aus bedienen. Das macht TEAMFELNULL nicht zu einem Multi-Region-Anbieter. Die physische Aufzeichnung unterstützt einen metropolitanen Cluster; die Anwendungsaufzeichnung kartiert keine Datenflüsse. Jede Organisation mit Aufenthaltsanforderungen sollte eine dienstspezifische Datenkarte anfordern, die den primären Host, Repliken, Backups, externe Prozessoren und den Löschpfad nennt.

Es gibt auch einen Widerstandsfähigkeits-Kompromiss. Alle Kopien in Tokio zu behalten kann die Lokalität vereinfachen, setzt sie aber einer metropolitanen Störung aus. Replikation ins Ausland kann die Notfallwiederherstellung verbessern, aber Jurisdiktion und Latenz ändern. Keine Wahl ist von Natur aus richtig. Das Problem ist, dass die aktuellen öffentlichen Nachweise die Wahl nicht offenbaren. Eine vertrauenswürdige Antwort würde angeben, wo jede Kopie residiert, warum, wie oft sie aktualisiert wird und wer sie abrufen kann.

Was Kunden verlangen sollten – und das Due-Diligence-Urteil

Die erste Anfrage sollte ein Asset-und-Service-Plan sein, keine glänzende Netzwerkkarte. Er sollte die Vertragspartei, den angebotenen Dienst, ob Zahlung beteiligt ist, und die genauen Ressourcen identifizieren: Kerne, Arbeitsspeicher, Speicher, Adressraum, Bandbreite und Support. Er sollte dedizierte von gemeinsam genutzten Ressourcen unterscheiden und angeben, welche Mengen installiert, mit Strom versorgt, betriebsfähig, reserviert und noch verfügbar sind. Ein nominaler 25-Gbit/s-Austauschport gehört in den Plan, aber nur als Verbindungskomponente.

Die zweite Anfrage sollte Verantwortlichkeiten kartieren. Welche Organisation besitzt oder least jeden Server? Welche hält das Einrichtungskonto, den Transportkreis und die Upstream-Vereinbarung? Wer kontrolliert die Router von AS58790, DNS, Anwendungsanmeldeinformationen und Abrechnung? Welche Einrichtung kann eine Support-Anfrage von welcher benannten Person annehmen? Die SERVER-G- und TeamFelNull-Zugehörigkeit ist sichtbar, aber die Übergaben sind es nicht. Eine einseitige Verantwortungstabelle würde viel von der aktuellen Unsicherheit beseitigen.

Die dritte Anfrage sollte eine evidenzgestützte Topologie sein. Sie sollte Standorte auf Stadtebene genau anzeigen, sensible Rack-Details vermeiden und physische Schaltungen, virtuelle Schaltungen und Tunnel unterschiedlich markieren. Sie sollte gemeinsame Metro-Endleitungen und Management-Abhängigkeiten identifizieren sowie den Standort, der jeden kritischen Dienst hostet. Ein Failover-Test sollte dann demonstrieren, was passiert, wenn ein Upstream, Austauschport, Router, Server oder Standort entfernt wird. Marketing-Präsenz allein ist kein Testergebnis.

Die vierte Anfrage sollte Strom und Reparatur abdecken. Nutzer müssen wissen, ob Server doppelte Netzteile haben, ob beide Einrichtungseinspeisungen genutzt werden, ob Ersatzteile vorrätig sind und ob Remote-Support vertraglich vereinbart ist. Das Dokument sollte Wartungsankündigung, Schweregrade, Reaktionsziele und einen unabhängigen Eskalationskanal enthalten. Best-Effort-Support kann akzeptabel sein, wenn er klar angegeben wird; das Risiko entsteht dadurch, dass Nutzer aus den Fähigkeiten der Einrichtungsbetreiber auf Unternehmensabdeckung schließen.

Die fünfte Anfrage sollte Daten abdecken. Sie sollte Backup-Häufigkeit, Aufbewahrung, Verschlüsselung, Wiederherstellungstest, Benutzerexport, Löschung und das, was ausgeschlossen ist, angeben. Sie sollte externe Plattformen und die Lokalität von Primär- und Backup-Kopien nennen. Für langlebige Spielwelten oder Gemeinschaftsdatenbanken sollte der Betreiber einen aktuellen Export vor der geplanten Schließung bereitstellen. Für experimentelle Dienste könnte die einfachste ehrliche Regel „kein Backup; behalten Sie Ihre eigene Kopie“ sein, vorausgesetzt, Benutzer können dies tatsächlich tun.

Schließlich sollte der Benutzer aktuelle Betriebsnachweise anfordern, kein historisches Branding. Nützliche Elemente umfassen einen aktuellen Statusverlauf, datierte Routenbeobachtungen, eine Inventarbestätigung, eine Beispiel-Incident-Mitteilung und einen erfolgreichen Wiederherstellungsnachweis. Keines muss Geheimnisse offenlegen. Zusammen würden sie zeigen, dass Kapazität unterhalb des Austauschports existiert und dass Wiederherstellung mehr als eine Absicht ist. Wenn diese Elemente nicht verfügbar sind, bleibt die rationale Klassifizierung Bildungstestumgebung, und Arbeitslasten sollten entsprechend gewählt werden.

Das Urteil: Nützliche Testumgebung, unbewiesene Hosting-Plattform.

TEAMFELNULL SERVER-G Group hat mehr Substanz, als sein spärlicher Unternehmensfußabdruck zunächst vermuten lässt. AS58790 hat eine aktuelle PeeringDB-Identität, eine betriebsfähige 25-Gbit/s-INIXP-Verbindung, aktuelle Standortaktualisierungen und global sichtbare Routen. TeamFelNull unterhält öffentliche Projekte, Nutzerbedingungen und Dokumentation. SERVER-G beschreibt ein fortlaufendes Bildungsnetzwerk und erkennt offen seinen studentengeführten, meist nicht gewinnorientierten Charakter und finanzielle Grenzen an. Dies sind Zeichen von Aktivität, keine leere Registrierung.

Die Beweise bleiben an dem Punkt unzureichend, an dem ein gehosteter Dienst verlässlich wird. Vier Standorteinträge beweisen keine vier Bereitstellungen. Ein 25-Gbit/s-Port beweist keinen Serverdurchsatz oder freie Kapazität. Adressankündigungen zählen keine Maschinen. Einrichtungsresilienz überträgt sich nicht automatisch durch ein unbekanntes Rack-Design. Mehrfach beobachtete Upstreams beweisen keinen physisch diversen Transport. Clientseitige Spielexporte schützen keine serverseitigen Daten. Discord-Kontakt schafft keine Antwortgarantie.

Die angemessene Netzwerkevidenzstufe ist schwach, nicht negativ. „Negativ“ würde die Live-Austauschverbindung, Routen und öffentlichen Dienste ignorieren. „Mittel“ würde implizieren, dass die Betriebskette ausreichend beschrieben ist, um Kapazität und Wiederherstellung zu bewerten. Das ist sie nicht. Die stärksten Beweise liegen am logischen Rand; die schwächsten liegen dort, wo Nutzer Verluste tragen: Hardware-Inventar, Stromberechtigung, Speicherbeständigkeit, Support-Arbeit, Verträge, Backups und Migration.

Für Hobby, Lernen und ausdrückliche Best-Effort-Gemeinschaftsnutzung mag das ein völlig vernünftiges Geschäft sein. Kleine Testumgebungen schaffen Raum, BGP zu lernen, spezialisierte Spiele zu betreiben und Werkzeuge zu bauen, ohne die Wirtschaftlichkeit einer kommerziellen Cloud. Ihr Wert sollte nicht nur an Unternehmenspapieren gemessen werden. Die wesentliche Bedingung ist informierte Einwilligung: Nutzer sollten wissen, dass experimentelle Infrastruktur sich ändern kann, dass Support von einem kleinen Team abhängen kann und dass sie ihre eigenen wiederherstellbaren Kopien benötigen.

Für bezahlte oder folgenreiche Arbeitslasten ist eine private Überprüfung vor der Abhängigkeit erforderlich. Der Betreiber müsste die Ressourcenzuweisung, die rechtliche Gegenpartei, die aktiven Einrichtungs- und Upstream-Vereinbarungen, das Multi-Site- oder Wiederherstellungsdesign und die Datenportabilitätsbedingungen zeigen. Ein Käufer sollte die Wiederherstellung testen, nicht nur die Konnektivität. Wenn diese Beweise existieren, kann die öffentliche Bewertung aufgewertet werden.

Bis dahin ist TEAMFELNULL am besten als Tokio-zentriertes Bildungsnetzwerk mit echten Gemeinschaftsdiensten und einem beeindruckenden Austauschrand zu verstehen – nicht als dokumentierte Multi-Site-Cloud.

Diese Schlussfolgerung respektiert beide Seiten der Beweise. Sie verwandelt fehlende Offenlegung nicht in eine Behauptung des Scheiterns, und sie verwandelt einen gut verbundenen Router nicht in ein Rack mit widerstandsfähiger Rechenleistung. Der sichtbare 25-Gbit/s-Port ist der Anfang der Kapazitätsfrage. Für TEAMFELNULLs Nutzer bleiben die entscheidenden Tatsachen dahinter: welche Maschinen mit Strom versorgt sind, welche Daten wiederhergestellt werden können, welcher Pfad überlebt und wer handelt, wenn das Reparaturfenster sich öffnet.