要約
- TEAMFELNULL の最も明確な現在のインフラ事実は、東京の INIXP における AS58790 の運用中 25 Gbps 接続です。これはネットワークエッジ容量であり、25 Gbps の顧客トラフィック、サーバー在庫、ストレージ、または販売可能なクラウド容量の証拠ではありません。
- 4つの東京施設リストはテストベッドを物理的に plausible にしますが、4つの独立したラック、4つの稼働中デプロイメント、別々の障害ドメイン、または基盤となるデータセンター事業者が宣伝する復元力への権利を確立するものではありません。
- 公開サービス面はゲームサーバー、ソフトウェアプロジェクト、Discord ボットのコミュニティであり、商用条件、サポート保証、バックアップ、復旧目標、課金保護、ホスティングデータのエクスポートは文書化されていません。ユーザーは、プライベートな証拠がそれを超えることを証明しない限り、環境を教育用テストベッドとして扱うべきです。
25 Gbps ポート、4つの施設名、そして1つの重要な沈黙
TEAMFELNULL に関連する最大の数字は 25 Gbps です。これは現在のPeeringDB の AS58790 レコードに表示され、"SERVER-G TestBed TeamFelNull" が Japan Community IX (INIXP) への運用中接続を示しています。エクスチェンジ自身の PeeringDB ページは AS58790 の横に 25 Gbps エントリを繰り返し、1つの IPv4 と 1つの IPv6 エクスチェンジアドレスを示しています。Internet Society Pulse の同じエクスチェンジメンバーシップのビューはネットワークを教育/研究用と特徴づけ、同様に 25 Gbps ポートを報告しています。これらの記録は、これほど小さな公開フットプリントとしては異常に具体的です。
しかし、これらは誤解されやすいものです。ポート速度はエクスチェンジアタッチメントの公称レートです。これは持続トラフィックの測定値、利用可能な顧客コミット、またはルーターの背後にあるマシンのスループットではありません。物理サーバーの台数、健全なストレージ量、予約されたラック電力、またはホストが別の仮想マシンを受け入れられるかどうかについては何も示しません。PeeringDB は AS58790 のトラフィックレベル、トラフィック比率、地理的範囲を明示的に非公開にしています。アドレスファミリーと相互接続の事実を報告しますが、販売負荷、利用曲線、サービスレベルコミットメントは報告しません。
同じプロファイルは4つの施設をリストしており、すべて東京にあります: AT TOKYO CC1/CC2、Equinix TY8、NTT DATA 大手町ビル、大手町プレイス ウエストタワー。これは説得力のあるメトロポリタンネットワークの概要を作り出します。しかし、それはあくまで概要です。相互接続データベースの施設リストは、物理ポート、クロスコネクト、他社経由のアクセス、またはリモートで提供されるサービスを反映する場合があります。それ自体では、TEAMFELNULL 所有のサーバー、リースされたフルラック、電源回路、または各場所のストレージレプリカを明らかにしません。レコードはポート識別子、ラック数量、電力消費、リース相手、サーバーシリアルを公開していません。
この区別が物語の中心です。TEAMFELNULL は、AS58790 が単なる放棄されたウェブページ上の名前ではないことを示すのに十分な可視ネットワーク証拠を持っています。しかし、従来のクラウドプロバイダーとしての解釈を支持するのに十分な公開運用証拠はありません。クラウド顧客はチェーンの利用可能な部分を購入します: コンピュート、メモリ、ストレージ、電力、冷却、ネットワークパス、交換ハードウェア、サポート労力、課金継続性、復旧または移行の手段。25 Gbps の数字はそのチェーンの1つのリンクだけを説明します。
したがって、沈黙は見出しの数字よりも重要です。このプロファイルのためにレビューされた公開ページは、TEAMFELNULL 名の下に VPS、ベアメタル、またはマネージドホスティングプランの現在のカタログを提供していません。保証された稼働時間、サポート応答時間、復旧ポイント、復旧時間、スペアパーツポリシー、バックアップ境界、データエクスポート形式、メンテナンス通知期間、補償ルールを述べているものはありません。この欠如は、それらの取り決めがプライベートに存在しないことを証明するものではありません。それは、将来のユーザーが公開証拠からそれらを推測できず、エクスチェンジポートラベルを代替品として扱うべきでないことを意味します。
名前はテストベッドを説明しており、従来のクラウドベンダーではない
AS58790 の公開アイデンティティには、最も有用な警告ラベルが含まれています: "TestBed"。PeeringDB はそれを教育/研究ネットワークとして分類し、SERVER-G Group 組織の下に置き、TeamFelNull を別名としています。公開TeamFelNull ホームページは、季節ごとの改造 Minecraft サーバーを運営し、ゲームをプレイし、改造を開発し、オープンソースソフトウェアを適応させるコミュニティを説明しています。これは共有された実験と楽しみの説明であり、エンタープライズプロダクションワークロードを移行する企業を対象とした販売資料ではありません。
より広いグループ自身の言葉はその解釈を強化します。SERVER-G グループページは、長期的に遊び、学び、開発するための環境を提供すると述べています。AS63800 をコアネットワークと呼び、TeamFelNull をネットワークとサーバーリソースを開発、運用、プレイのために受け取るパートナーグループと説明しています。この表現は重要です。なぜなら、少なくとも3つの混同されうるものを分離するからです: 傘グループ、AS63800 バックボーン活動、AS58790 に関連する TeamFelNull テストベッド。公開記録は提携とリソースサポートを示します。それらはラック、ルーター、またはサーバーの所有権を TeamFelNull に譲渡する契約を開示しません。
SERVER-G のAS63800 公開履歴は、バックボーンをインターネット技術を学ぶために構築された非営利ネットワークと呼んでいます。その年表は実験的であることを率直に述べています: アドレスリソースの取得、アップストリームの発見、コミュニティエクスチェンジの試行、接続性の変更、ルート監視ツールの構築。グループの about ページは、主な活動場所を東京とし、目的として接続性、学習、構築、技術開発を含めています。これらのページは AS63800 と SERVER-G Group に関するものであり、AS58790 の別途文書化された企業バランスシートではありません。TEAMFELNULL 周辺の環境を説明するのに役立ちますが、すべての AS63800 資産またはポリシーがテストベッドに属することを証明するものではありません。
この境界は、「グループ」という言葉が法的または運用上の保証と誤解されるたびに重要です。TEAMFELNULL の公開サイトは「TeamFelNull」と「FelNull」を使用します。ルーティングレコードは「TeamFelNull」、「SERVER-G Group」、「SERVER-G TestBed TeamFelNull」を使用します。ボットの利用規約は FelNull を組織として説明します。レビューされたどのページも、従来のホスティング会社登録、インフラサービスの契約上の法的名称、請求先住所、または顧客にサービス credit を負う当事者を特定していません。ブランド名だけでそれらの詳細を推測するのは安全ではありません。
SERVER-G のバックボーン説明でさえ、コミュニティ活動と限定された商用利用の間に線を引いています。ネットワークは学生主導で基本的に非営利であり、財務的制限を挙げ、一部のアドレス使用が活動と運用の資金調達に役立つと述べています。また、それらの商用アドレスは AS63800 から伝搬または使用されないとも述べています。これは混合経済コンテキストの証拠であり、AS58790 が標準的な商用ホスティング製品を提供する証拠ではありません。契約レベルの明確化がより必要になります: 誰が請求するのか、誰がハードウェアを所有するのか、誰のネットワークがサービスを運ぶのか、一部が故障したときに誰が責任を負うのか?
テストベッドは技術的に有能で有用であり得ます。実際の接続性を提供し、価値あるサービスをホストし、洗練されたプロバイダーが隠す教訓をオペレーターに教えることができます。しかし、そのリスク配分は異なります。非公式なサポートは、ボランティアが利用可能なときは速く、勉強、仕事、生活が介入すると遅くなります。ハードウェアは機会的に購入されるかもしれません。ネットワークパスはスポンサーシップやコミュニティ関係の変化に応じて変わります。その取引を理解するユーザーは、それが完全に適切だと感じるかもしれません。「25G」と4つの施設名を見たためにエンタープライズ継続性を想定するユーザーは、公開記録が行っていない約束を購入していることになります。
TeamFelNull が実際にユーザーに提供するもの
最も可視的なサービスは具体的でコミュニティ向けです。TeamFelNull のサイトは季節限定の Minecraft 改造サーバー、ソフトウェア開発、小さな公開プロジェクトを提供しています。Discord 音声ボットページはテキスト読み上げボットの複数インスタンスを宣伝し、Reversi ページは Discord のゲームアクティビティを提供します。これらは実際のユーザーサーフェスです: 人々は接続し、コンテンツを送信し、状態がある期間持続することを期待し、サービスが消えると気づきます。これらは、「クラウド」という一般的な主張よりも運用目的のより良い証拠です。
ボットの利用規約とプライバシー通知はデータ境界の貴重なビューを提供します。ユーザー、サーバー、チャンネル識別子がサービス機能維持のために保存される可能性があり、音声生成のためにユーザー名、ニックネーム、メッセージが収集され、必要な期間のみ保持されることが述べられています。通知は合理的な保護措置を約束しますが、完全なセキュリティを否認し、サービスまたは条件が予告なく変更される可能性を認め、損害に対する責任を否認します。これらの規定はそのボットに適用され、すべてのサーバーまたはネットワークサービスに自動的に適用されるわけではありませんが、ここで見つかった唯一の公開ユーザー契約のスタイルを明らかにします: 広範な運用裁量、限定された保証、定量化された復旧コミットメントなし。
ソフトウェア側はホスト側よりも完全に文書化されています。TeamFelNull ランチャーチュートリアルはカスタマイズされたゲームランチャーを説明し、ビルドプロセス中のウイルススキャンについて説明します。SERVER-G ドキュメンテーションサイトはそのランチャー、インストール、ゲームインスタンス処理に焦点を当てています。これはユーザー向けの指示を作成できるグループを示しています。対照的です: クライアントソフトウェアのための公開ガイダンスが存在する一方、仮想マシンプロビジョニング、ストレージ耐久性、サーバーバックアップ、不正使用処理、インシデントステータス、アカウント終了に関する同等のページは見えません。
歴史的で非公式なJapan Minecraft Servers リストは、2019年に提出された「TeamFelNull-24h-Server」を記録しており、非常に低い記録された稼働時間とダウンを示すステータスを持っています。このエントリは2026年の AS58790 の状態を確立することはできません。異なるマシン、アドレス、運用期間を説明する可能性があり、サードパーティのプローブは多くの理由で失敗する可能性があります。これは市場シグナルとしてのみ有用です: TeamFelNull の名前は公開ゲームサーバーに関連付けられており、少なくとも1つの古いエンドポイントは継続的に到達可能ではありませんでした。現在の監視、インシデントアーカイブ、またはオペレーターの声明が、その履歴を今日のテストベッドに結びつけるために必要です。
公開サービスは異なる依存関係パターンも露出させます。ゲームサーバーはコンピュート、メモリ、ストレージ、バージョン互換ソフトウェア、安定したルートを必要とします。音声ボットはさらに、TEAMFELNULL の制御外の Discord と音声エンジンに依存します。ランチャーは、コミュニティサーバーがなくなっても個人のコンピュータで使用可能ですが、ダウンロード、改造パック、認証依存関係はそうでないかもしれません。これらすべてを「ホスティング」にまとめると、誰がどの障害を制御しているかが隠れます。TEAMFELNULL はアプリケーションと一部のサーバーを運用するかもしれませんが、SERVER-G または別の関係者がルーティングを制御し、施設が電力を制御し、外部プラットフォームがアイデンティティと配布を制御します。
そのため、「顧客向け容量」はここでは狭く解釈されるべきです。リソースがユーザーとパートナーコミュニティに提供されている証拠はあります。有料顧客、アクティブインスタンス、管理サーバー、ストレージボリューム、予約コアの公開カウントはありません。正しい運用像は、定量化されていない物理および仮想リソースのプールを備えた教育ネットワークに支えられた一連のコミュニティアプリケーションです。それ以上の強い主張には、現在の在庫とその在庫をネットワークアイデンティティに結びつける契約が必要です。
物理システムが東京に触れる可能性のある場所
AS58790 の施設トレイルは完全に首都圏内です。PeeringDB の個別施設ページは、AT TOKYO CC1/CC2、Equinix TY8、NTT DATA 大手町ビル、大手町プレイス ウエストタワーにテストベッドをリストしています。これらの記録はネットワークプロファイルの4つの名前を裏付けますが、その精度は存在で止まります。複合キャンパスラベルのどの建物が使用されているか、アタッチメントが物理的かリモート拡張か、ネットワークポートの横にコンピュートが設置されているかは示しません。
基盤となる施設は大規模です。AT TOKYO 自身の説明によると、CC1 は総床面積140,000平方メートルであり、複数の電源、UPS、非常用発電、施設全体の24時間監視を備えています。Equinix の TY8 仕様は東京の住所、40,418平方フィートのスペース、N+1 電力冗長性、N+20% 冷却冗長性を示しています。Equinix の運用カバレッジ表は TY8 が24時間365日オンサイトカバレッジを持つと述べています。
大手町プレイスでは、BroadBand Tower の新大手町サイト説明は標準の 6 kVA の実際のラック電力、デュアル200V 30A ライン、無給油で最大72時間稼働可能な N+1 発電機、複数の接続オプション、リモートサポートを宣伝しています。別のネットワークサービスページはルーター、ストレージネットワーク、クラウド接続の設計と運用サポートを提供しています。これらは建物内で利用可能な施設オペレーターの能力です。TEAMFELNULL が BroadBand Tower からフルラック、2回路、リモートハンズ、または特定のサービスを購入していることを示すものではありません。
これが実用的な所有権の境界です。施設オペレーターは建物のシェル、ユーティリティ取り入れ、発電機、冷却プラント、アクセス制御、技術者がラックに到達する条件を制御します。コロケーション顧客は契約したものだけを制御します: キャビネット、フラクショナルラック、クロスコネクト、またはリモートで提供されるポートかもしれません。ネットワークオペレーターはルーター設定とアドレスアナウンスを制御します。アプリケーショングループは、アクセス権限がある範囲でソフトウェアとユーザー状態を制御します。施設の復元力設計は、顧客サーバーの単一電源、未払いのクロスコネクト、交換部品のない故障ディスク、テストされていない復元を持つアプリケーションデータベースを補うことはできません。
したがって、地理的主張は「グローバル」よりも強く、かつ狭いです。サービスは世界中から到達可能かもしれません。インターネットルートは本質的にグローバルです。ここでレビューされた物理的証拠は東京、日本を指しています。ヨーロッパ、北米、他のアジア都市、または大阪に会社運用のラックがあることは確立していません。また、4つの東京の名前が必ずしも首都圏の災害、共通のアップストリーム障害、または単一の管理ミスに対する保護を作り出すわけではありません。可視インフラのデータローカリティは、現在の資産レジスタがそうでないと証明するまで、東京中心として扱われるべきです。
ユーザーにとって、そのローカリティには2つの結果があります。第一に、レイテンシは東京までの距離と選択されたアップストリームパスに依存します。「グローバル」という言葉は物理学を消し去ることはできません。第二に、物理アクセス、電力、保存データに関する統治取り決めは、リモートユーザーが他の場所から接続しても、実際には日本的である可能性が高いです。公開ボット通知はデータベースがどこでホストされているかを述べておらず、施設リストは特定のアプリケーションを特定の建物に結び付けていません。居住性保証が必要なユーザーは、ルーティングレコードから推測された都市ではなく、書面による配置、複製、下請け業者の詳細を求める必要があります。
4つの施設記録が4つの独立したサイトと等しくない理由
冗長性は数のカウントではなく、独立性から始まります。4つの施設名は4つの障害ドメインを表すことができますが、複数の相互接続ファブリックを介して到達される1つのルーター、建物間で拡張された1つのサービス、休眠中のクロスコネクト、または計画アクセスのために維持されたレコードを表すこともできます。PeeringDB は貴重な業界データベースですが、ネットワークと施設のエントリは参加者によって提供されます。AS58790 レコードは施設情報が2026年2月に更新されたと述べており、最近性を支持します。それでも基礎となる回線注文やラック占有を公開しません。
地理自体が注意を促します。2つのリストは大手町にあり、1つは CC1/CC2 をカバーする AT TOKYO キャンパスラベル、1つは品川の Equinix TY8 です。大手町プレイスの PeeringDB エントリは NTT DATA 大手町ビルへの光相互接続に言及しています。そのリンクは運用上有用ですが、データベース内の2つの名前が、別々に電源供給された TEAMFELNULL デプロイメントではなく、1つの物理的拡張を介して到達可能であることも意味します。その可能性から正確なルートを推測すべきではありません。記録は建物間の利用可能な相互接続を確立しますが、AS58790 のパスやトポロジは確立しません。
INIXP 接続は別のレイヤーを追加します。エクスチェンジは東京と大阪の複数の施設に存在しますが、AS58790 リストはネットワークプロファイルにポートの場所を公開していません。25 Gbps のエクスチェンジアタッチメントは、1つのサイトで提供され、パートナーネットワークまたは首都圏回線を介して運ばれる可能性があります。許可証、クロスコネクト記録、デバイスレベル図、回線多様性ステートメントがなければ、物理的なハンドオフは不明のままです。2つのエクスチェンジアドレスは論理アタッチメントを証明します。ケーブルをマッピングするのに十分な精度でスイッチポートを特定しません。
真のマルチサイトコンピュート復元力にはさらなる証拠が必要です。最低限、現在の在庫は少なくとも2つのサイトで電源投入されたサーバーまたはストレージを示すはずです。レプリケーションには既知の方向と遅延があるはずです。DNS またはルーティングフェイルオーバーにはテスト済みトリガーがあるはずです。ユーザーはどのサービスが別の場所で再起動できるかを知っているはずです。復旧設計は共有管理プレーンを避けるはずです。公開ページでは、Minecraft 環境、Discord ボットデータ、開発サービスが施設間でレプリケーションされているとは述べられていません。可能性はありますが、実証されていません。
同じ注意がアップストリーム多様性にも適用されます。ルーターは複数のパスを聞くことができますが、すべての顧客トラフィックは依然として1つのトランスポートプロバイダー、1つのトンネルエンドポイント、1つのメトロテール、または1つの設定権限に依存する可能性があります。SERVER-G の公開履歴は時間経過とともに複数の関係を説明し、2024年12月に一部の海外コミュニティエクスチェンジからの撤退を説明しています。そのピアリングポリシーは、エクスチェンジでの接続と同様に GRE、SIT、WireGuard トンネルを明示的に許可しています。トンネルはテストベッドにとって正当なツールですが、同じ基盤アクセス回線上の論理的に別々の BGP ネイバーは物理的多様性ではありません。
厳密な冗長性ステートメントは、独立性が存在するレイヤーを特定します。別々の BGP セッションは、別の使用可能なパスが残っている場合にのみネイバー障害から保護します。別々の施設電源は、サーバーが適切に接続されたデュアル電源を持っている場合にのみラックを保護します。別々の建物は、両方に現在のデータが存在し、オペレーターがユーザーをリダイレクトできる場合にのみアプリケーションを保護します。別々のサポート連絡先は、複数の人が資格情報と物理アクセスを持っている場合にのみ復旧を保護します。TEAMFELNULL の公開証拠はこれらのエンドツーエンドの組み合わせのいずれも確認していません。したがって、4つの施設ラベルは相互接続到達性として読まれるべきであり、4サイトのサービス継続性としては読まれないべきです。
容量: 唯一のハードナンバーはエクスチェンジエッジにある
容量は1つの数字ではありません。それは制限のスタックであり、最も低いアクティブ制限がサービスを支配します。25 Gbps エクスチェンジポートは、1つの相互接続における設置済み論理ネットワーク容量です。PeeringDB は接続を運用中とラベル付けしており、将来計画よりも強いです。しかし、使用可能なスループットは、ルーター転送制限、アップストリームポリシー、輻輳、ラックとエクスチェンジ間の転送、パケットサイズ、攻撃、アプリケーションボトルネックにより低くなる可能性があります。販売済み容量は、テストベッドが帯域幅を販売していない場合、さらに低いか、存在しない可能性があります。
アドレススペースは別の種類の容量です。PeeringDB は AS58790 の5つの IPv4 プレフィックスと50の IPv6 プレフィックスをリストしています。Cloudflare Radar の AS 概要は日本のネットワークを特定し、十分な観測がある場合にトラフィックビューを公開します。別のCloudflare ルーティングビューはアナウンスされたアドレススペース、接続、RPKI ステータス、BGP アクティビティを提示します。プレフィックス数はルーティング粒度を説明し、サーバーではありません。1つの /24 は256の IPv4 アドレスを持つことができますが、アドレスは未使用、ルーター識別、仮想割り当て、または1つのホスト背後で多くのドメインにサービスする可能性があります。
サードパーティのデータセットは、なぜ日付と定義がすべての数字に付随しなければならないかを示しています。IPinfo の AS58790 ページは現在、2つの /24 ブロック（44.30.37.0/24 と 44.30.62.0/24）といくつかの観測されたアップストリーム、プローブに応答した少数のアドレスをリストしています。CIDR Report ビューもコレクタービューで2つの /24 アナウンスと512のオリジネートされた IPv4 アドレスを示しています。これらの観測は現在の IPv4 ルーティングを支持しますが、どちらも存在するマシンの数や応答が顧客コンピュートからのものかを教えてくれません。
他のアグリゲーターは矛盾しています。ミラーリングされた登録ページは JPNIC AS 名と 2401:d20:1020::/44 IPv6 範囲を再現しますが、IPv4 範囲を報告しません。IP2Location の AS ページは1つの /24 と IPv6 /46 を示す一方、IPGeolocation のページは AS アイデンティティを再現するもののゼロルートを報告します。これらは同等のスナップショットではありません。収集日、ルート可視性、分類方法が異なります。矛盾はアグリゲーターデータの限界についての証拠であり、数字を平均化する理由ではありません。
レビューされた公開ソースは、CPU コア、メモリ、ベアメタルノード、仮想マシン、ディスク容量、ストレージ冗長性、予約電力、平均電力消費、空きラックユニットを述べていません。設計容量と設置済み、電源投入、運用中、顧客使用可能容量を分離するソースはありません。施設全体の数字はギャップを埋めることができません。Equinix の TY8 の40,418平方フィートは施設に属し、AS58790 には属しません。BroadBand Tower の標準 6 kVA ラック仕様は利用可能な製品特性であり、TEAMFELNULL ラックや権利の証拠ではありません。
経済的に意味のある容量は、コミットメントを尊重しながら障害を生き残れるものです。サービスに16コアと64 GB メモリが必要な場合、スペアホストは互換性があり、電源投入され、接続され、まだ予約されていない場合にのみカウントされます。ストレージがレプリケーションされている場合、2番目のコピーは最新で独立して復元可能な場合にのみカウントされます。25 Gbps がエクスチェンジに到達してもサーバーが1 Gbps インターフェースを持つ場合、アプリケーションは25 Gbps を持ちません。TEAMFELNULL がそれらの下位レイヤーの数字を公開または非公開で提供するまで、その販売可能なホスティング容量は不明のままです。
アップストリームの話は現実的だが、きれいに文書化されていない
AS58790 はオリジンとして可視であり、いくつかの公開ビューはそれに到達するルートを見ています。これは意味のある運用証拠です。IPinfo は Hurricane Electric、SDCC Japan-West Area、SERVER-G Group をアップストリームまたはピアとしてリストし、2026年6月のプローブトレースは 44.30.37.1 に達する前に日本のネットワークを通過しました。CIDR Report のコレクタービューは、2つの可視 /24 に対して AS38074 が AS58790 に直接隣接していることを示しました。Cloudflare のルーティングページは別のライブ視点を提供します。これらを合わせると、到達可能性を支持しますが、安定したプロバイダーグラフについては一致しません。
これにはいくつかの無害な理由があります。BGP は特定のコレクターから特定の時間に観測されます。あるパスからアップストリームに見える関係は、ピア、ルートサーバーパス、または別のネットワークを介して運ばれるサービスである可能性があります。IPv4 と IPv6 は異なるプロバイダーを使用できます。セッションは設定されているがアイドル、選択的、または一部の場所からのみ可視である可能性があります。PeeringDB のエクスチェンジレコードは INIXP アタッチメントを示しますが、AS58790 がそこでルートサーバーを使用していないとマークしています。これは、存在だけではどの双方向セッションが実際にプロダクショントラフィックを運ぶかを明らかにしないことを意味します。
より広い SERVER-G 履歴は有益ですが、単純に AS58790 に割り当てることはできません。それはさまざまな日付での Vultr、Hurricane Electric、SDCC および他のネットワークとの AS63800 関係、後の撤退および追加を記録しています。AS63800 のピアリングポリシーはグローバル AS 番号、最小プレフィックスサイズ、ROA、IRR レコード、PeeringDB 連絡先を要求し、ネットワークが実験的であるためある程度の不安定性は許容されるとも述べています。これらは AS63800 の表明されたポリシーです。テストベッドを取り巻く文化を示唆しますが、AS58790 の拘束力のある稼働時間の約束ではありません。
所有権の問題はルーティング問題の内部にあります。PeeringDB は AS58790 を SERVER-G Group の下に置き、ウェブサイトとして felnull.dev を使用します。公開グループページは AS63800 がコアネットワークであり、TeamFelNull にリソースを提供すると述べています。したがって、AS58790 を SERVER-G がサポートする TeamFelNull テストベッドと見なすのは合理的です。TeamFelNull が各アップストリーム契約、各クロスコネクト、またはそれがオリジネートするアドレスリソースを所有していると仮定するのは合理的ではありません。顧客は、各依存関係を更新、キャンセル、または再構成できる当事者を知る必要があります。
ルート多様性にはコントロールプレーンコンポーネントもあります。1人、1つのルーター設定、または1つの資格情報セットがすべてのセッションを制御する場合、複数のアップストリームは誤ったルートフィルターや偶発的な撤回から保護しません。ルートリーク、無効なオリジン、期限切れのルート認証、または過度に広いフィルターは、健全なサーバーに到達不能にさせる可能性があります。公開ビューはルーティングが存在することを示します。変更管理、帯域外アクセス、設定バックアップ、デュアルルーター、自動ロールバック、または24時間ネットワーク運用ローテーションを公開しません。
問題を解決するものは、具体的で控えめです: アクティブなトランジットとトランスポートを確立する現在のレターまたは請求書。どの接続が物理的、仮想的、またはトンネル化されているかを示すトポロジ。両方のアドレスファミリーのコレクター証拠。有効なルート認証レコード。プライマリパスが撤回されたときにトラフィックが使用可能なままであることを実証するフェイルオーバーテスト。それまで、アップストリーム証拠はスナップショットとしては中程度の信頼性、冗長性保証としては低い信頼性に値します。
電力、ハードウェア、人手が隠された制御面
ネットワーク記録は公開されているため支配的になりがちです。しかし、ホスティング障害のほとんどは、はるかに可視性の低いレイヤーで解決されます。誰かが故障した電源、ディスク、メモリモジュール、光モジュール、ファン、ケーブルを見つけて交換します。TEAMFELNULL はハードウェア在庫、ライフサイクルポリシー、スペア在庫を公開していません。25 Gbps ポートは完全に健全である一方、1つの互換性のあるコンポーネントがないために単一のアプリケーションサーバーがオフラインになる可能性があります。
施設の復元力は顧客への引き渡しポイントまでしか役立ちません。AT TOKYO は複数の給電、UPS、発電機、24時間監視を宣伝しています。Equinix は TY8 で N+1 電力と24時間運用カバレッジを宣伝しています。BroadBand Tower は新大手町でデュアルラック給電、N+1 発電、リモートサポートを宣伝しています。これらの制御は、それらを購入して正しく使用する顧客にとって建物レベルのリスクを低減します。AS58790 機器がデュアル電源を持つか、両方の給電が契約されているか、リモートサポートが許可されているか、TeamFelNull が作業を承認する速さを明らかにしません。
サポート労力自体が容量です。TeamFelNull の連絡先ページは問い合わせを Discord に誘導します。コミュニティにとっては便利ですが、公開の重大度尺度、応答時間コミットメント、電話エスカレーション、指名された当番ローテーション、または Discord が利用できない場合の代替チャネルを提供しません。SERVER-G のページはピアリングのためにメールまたは Discord パスを提供しますが、ホスティングサービスの復元を具体的に約束する公開インシデントデスクはありません。マシンが03:00に故障したとき、「誰かが気づくかもしれない」と「認定技術者が30分以内に対応しなければならない」の違いがサービスです。
ハードウェア在庫の故障は小さなテストベッドにとって特に重要です。大規模プロバイダーは多くのサーバーにスペアパーツとスタッフを分散します。コミュニティオペレーターは異なる時期に購入されたユニークなマシンを持つ可能性があります。互換性リストと在庫交換部品がなければ、故障したマザーボードはルーチンの交換を調達、移動、再構築に変える可能性があります。サーバーがミラーリングされたブートドライブ、ホットスワップストレージ、帯域外管理、デュアルネットワークインターフェース、標準化されたイメージを使用するかどうかについての公開証拠はありません。堅牢なエンタープライズ設計か即興のハードウェアのいずれかを想定するのは間違いです。
請求とプロバイダー契約は、壊れた機器なしで同じ停止を引き起こす可能性があります。コロケーションの支払い遅延、期限切れのスポンサーリソース、キャンセルされたトランスポート契約、ドメイン更新問題、変更された施設アクセスリストは、健全なサービスを切断する可能性があります。SERVER-G の財務制限に関する声明はこの依存関係を検討する価値あるものにしますが、現在の苦境を証明するものではありません。証拠には、現在の契約、更新日、責任者、準備金または継承計画が必要です。それらがない場合、財務的継続性は単に未知です。
ユーザーは異なる影響を受けます。プレイヤーは季節限定のワールドへのアクセスを失うかもしれません。開発者はビルドサービスを失うかもしれません。Discord コミュニティは音声出力を失うかもしれません。スポンサープロジェクトはアドレスまたはルートを失うかもしれません。コストは収益ではなく不便かもしれませんが、データ損失は個人的で不可逆的であり得ます。適切な復元力基準は約束された使用法に従うべきです。テストワールドは、ユーザーが知らされていればダウンタイムを許容できます。識別子を収集するデータベースや長期間のコミュニティワールドは、たとえ金銭が絡まなくても、バックアップ、保持、復旧ルールが必要です。
障害はラックに達する前に曖昧さから始まる
最初の障害パスは必ずしも技術的ではありません。それは約束されたことについての曖昧さです。ユーザーが「サーバーリソース」を聞き、データセンター名を見ると、バックアップ、スペアホスト、管理された復旧を想定するかもしれません。オペレーターが遊びと学習のためのベストエフォートアクセスを意味する場合、双方が合理的に行動しても、停止後に衝突する可能性があります。最速のリスク軽減は、何がホストされているか、誰が運用するか、何がベストエフォートか、何がバックアップされているか、ユーザーが自分でコピーしなければならないかを述べた平易なサービス説明です。
ラックでは、シーケンスはよく知られています。電源フィードまたは電源ユニットが故障。スイッチポート、光モジュール、ネットワークカードがダウン。ディスクまたはコントローラーが状態を破損。冷却保護がハードウェアをシャットダウン。または計画作業が再起動を必要とする。施設監視は環境アラームを特定できますが、アプリケーション復旧は管理サービスが購入されない限り顧客に残ります。公開ページのいずれも TEAMFELNULL を特定のリモートサポートパッケージ、スペアパーツストア、またはメンテナンスウィンドウに結び付けていません。
ネットワークレイヤーでは、エクスチェンジポート、メトロ回線、トンネルエンドポイント、アップストリームセッション、またはルートアナウンスが故障する可能性があります。4つの施設エントリはそれらの要素が多様かどうかを明らかにしません。25 Gbps の INIXP ポートは有用なパスですが、エクスチェンジは公開リストでサービス条件を開示せず、ベストエフォートと自己を説明しています。エクスチェンジでの双方向ピアリングはフルインターネットトランジットと同じではなく、エクスチェンジ接続は適切なピアやアップストリームなしですべての宛先に到達できません。したがって、ユーザー向けサービスは一部のネットワークでは故障するが、他のネットワークからは到達可能なままである可能性があります。
アプリケーションレイヤーでは、更新が独自の修復ウィンドウを作成します。TeamFelNull は改造 Minecraft とカスタマイズされたランチャーで動作し、サーバーとクライアントのバージョンが一致する必要があります。失敗した更新は、ルーティングとハードウェアが健全でもユーザーを stranded にする可能性があります。ランチャードキュメンテーションはインストールと移行に注意を払っていますが、サーバーメンテナンス、ロールバック、データベース互換性、古いワールドの保持に関する公開スケジュールはありません。アプリケーション状態は、新しいマシンが失われた履歴を再作成できないため、再構築が最も難しい部分であることがよくあります。
外部プラットフォームは相関依存関係を追加します。音声ボットはアイデンティティ、イベント、ユーザーアクセスを Discord に依存し、1つ以上の音声エンジンに依存する可能性があります。それらのサービスでの停止またはポリシー変更により、AS58790 に障害がなくてもボットが利用できなくなる可能性があります。連絡先も Discord に依存するため、サービスとその主要な公開サポートチャネルが一緒に故障する可能性があります。独立してホストされたドメイン上のステータスページとメールエスカレーションがそれらのパスを分離します。
影響を受ける人口は定量化されていません。ホームページはコミュニティを招待します。ボットページは複数のボットインスタンスを示します。古いゲームリストは公開エンドポイントを記録します。現在のアクティブユーザー、ピークセッション、依存プロジェクトの数を与えるものはありません。これにより数値的な影響の推定が妨げられます。質的影響は明確です: コミュニティアクセス、保存された識別子、ゲーム状態、ソフトウェア配布、スポンサーリソースがすべて中断される可能性があります。正直なインシデント計画は、開示されていない顧客数を主張せずにこれらのクラスを挙げるでしょう。
復旧と移植性はアプリケーション境界で止まる
復旧には2つの別々の質問があります: オペレーターはサービスを復元できるか、ユーザーは離れることができるか？公開記録はホスティングされたコンピュートについてどちらも答えていません。TeamFelNull サーバーの公開バックアップ頻度、保持期間、オフサイトコピー、復元テスト、復旧ポイント、復旧時間はありません。仮想マシン、データベース、ゲームワールド、アカウントレコード、ホスティングされたボリュームの文書化されたエクスポートもありません。ユーザーは、故障したディスクが数分のロールバック、数日の再構築、または永久的な損失を意味するかを知ることができません。
クライアント側には狭く有用な例外があります。ランチャードキュメンテーションは、選択されたローカルファイルから ZIP を作成するインスタンスエクスポート手順と、ローカルインスタンスフォルダをバージョン間でコピーする方法を説明する別のランチャー移行ガイドを提供します。これらの指示はプレイヤーのクライアント環境の移植性を向上させます。サーバーサイドのワールド、ボットデータベース、資格情報、DNS、IP アドレス、仮想マシンをエクスポートしません。
その境界は見逃されやすいです。プレイヤーは改造と設定を保存しても、共有ワールドを失う可能性があります。ボット管理者は Discord コミュニティを保持しても、保存された設定を失う可能性があります。開発者はソースコードを保持しても、ビルドアーティファクトやデプロイメントシークレットを失う可能性があります。ネットワークユーザーはアプリケーションイメージを保持しても、リソース権利が別の当事者に属する場合アドレスを保持できない可能性があります。各レイヤーには独自のエクスポートと復元方法が必要です。
マルチサイト復旧も同様に未証明です。施設リストは復元力を構築できる可能性のある場所を提供しますが、サービスを2つの稼働サイトにマッピングしたり、レプリケーション遅延を報告したりする公開証拠はありません。たとえ2台目のマシンが存在しても、成功したフェイルオーバーには現在のデータ、シークレット、ルーティング、DNS、容量、許可された人々が必要です。テストされていない復元を持つコールドスペアは、プライマリの修理よりも時間がかかる可能性があります。同じ管理アカウントを共有するホットレプリカは、侵害時に故障する可能性があります。
サポートエスカレーションは復旧設計の一部であるべきであり、後付けではありません。Discord のみの連絡先は通常のコミュニティ使用では機能するかもしれませんが、深刻なイベントには独立したパス、責任者、施設許可、部品や輸送に資金を使うための決定ルールが必要です。継承も重要です: 複数の信頼できるオペレーターがドメインを更新し、ルーターにアクセスし、施設に連絡し、バックアップを復号できるべきです。公開ページはそのカバレッジを確立していないため、それは非難ではなく質問のままです。
最小限の信頼できる移植性パッケージは単純です: ユーザー所有データのリスト、エクスポート形式、バックアップと保持境界、削除タイミング、計画された閉鎖前の通知、最新コピーを取得する手順、コピーが別の場所で復元できることを示すテスト。ゲームサービスでは、ワールドアーカイブとバージョンマニフェストかもしれません。ボットでは、構造化された設定エクスポートと削除確認かもしれません。仮想サーバーでは、標準ディスクイメージと設定レコードかもしれません。これらのコミットメントがなければ、ユーザーは技術的に可能な限り自分自身のコピーを保持すべきです。
データローカリティは東京中心ですが、アプリケーションデータはマッピングされていません。
ルーティングと施設の証拠は日本、特に東京を指しています。AS58790 はルーティングデータセットで日本のアイデンティティで登録され、リストされた相互接続施設は東京にあり、観測された IPv4 アドレスは一般的に日本に地理配置されています。これは東京中心の物理的評価を支持します。アプリケーションデータのすべてのバイトが東京に留まることを証明するものではありません。ソフトウェア依存関係、バックアップ、コンテンツ配信、サードパーティサービスが国境を越える可能性があるからです。
ボットが最も明確な例です。その利用規約は識別子が保存され、音声生成のためにメッセージが処理される可能性があると述べていますが、ホスティング場所、データベースプロバイダー、音声プロバイダー、バックアップ管轄区域を指定していません。Discord 自体は外部プラットフォームです。AS58790 の施設存在は、Discord がデータをどこに保存するか、音声要求がどこで処理されるかに答えられません。データ居住性の主張には、自律システム国コードだけでなく、アプリケーションレベルの文書が必要です。
ゲームおよび開発サービスにも同様の不確実性があります。サーバープロセスは東京のマシンで実行される一方、改造ダウンロードは別のプラットフォームから来たり、ソースコードはグローバルリポジトリに置かれたり、バックアップ（もしあれば）が別の場所に置かれたりする可能性があります。逆に、AS58790 がオリジネートするアドレスは別のネットワークを介してリモートで配信される機器に到達する可能性があります。IP ジオロケーションは推定であり、ラックの証明ではありません。IPinfo は、登録または推測された場所が常に実際の使用と一致するとは限らないと明示的に警告し、ルーティングアグリゲーター間の不一致は分類がどれほど速くドリフトするかを示しています。
これはコミュニティサービスにとっても重要です。ユーザーは法的アクセス、削除、違反対応、または遠く離れた依存関係のレイテンシを気にするかもしれません。公開プライバシー通知は収集データの広いカテゴリと必要な保持の概念を与えますが、固定された保持期間や場所はありません。また、事前通知なしの変更を許可します。これらの条件は無料のボットには釣り合うかもしれませんが、契約上の sovereignty または locality に対する買い手のニーズを満たしません。
したがって、「グローバル」なサービスエリアラベルは、フットプリントではなく到達性として読まれるべきです。ウェブサイト、ゲームサーバー、Discord ボットは東京から国際的に人々にサービスできます。それは TEAMFELNULL をマルチリージョンプロバイダーにするわけではありません。物理的記録は1つの首都圏クラスターを支持します。アプリケーション記録はデータフローをマッピングしません。居住性要件を持つ組織は、プライマリホスト、レプリカ、バックアップ、外部プロセッサ、削除パスを特定するサービス固有のデータマップを求めるべきです。
復元力のトレードオフもあります。すべてのコピーを東京に保持することは locality を簡素化するかもしれませんが、首都圏全体の混乱にさらします。海外にレプリケーションすることは災害復旧を改善するかもしれませんが、管轄区域とレイテンシを変更します。どちらの選択も本質的に正しいわけではありません。問題は、現在の公開証拠が選択を明らかにしていないことです。信頼できる答えは、各コピーがどこに存在するか、なぜか、どのくらいの頻度で更新されるか、誰が検索できるかを述べます。
顧客が要求すべきこと—そしてデューデリジェンスの評決
最初の要求は、資産・サービス明細書であり、華やかなネットワークマップではありません。契約当事者、提供されるサービス、支払いの有無、正確なリソース（コア、メモリ、ストレージ、アドレススペース、帯域幅、サポート）を特定する必要があります。専用リソースと共有リソースを区別し、どの数量が設置、電源投入、運用、予約、まだ利用可能かを述べる必要があります。名目上の25 Gbps エクスチェンジポートは明細書に属しますが、相互接続コンポーネントとしてのみです。
2番目の要求は責任のマッピングです。どの組織が各サーバーを所有またはリースしていますか？どの組織が施設アカウント、トランスポート回線、アップストリーム契約を保持していますか？誰が AS58790 のルーター、DNS、アプリケーション資格情報、請求を制御していますか？どの施設がどの指名された人物からのサポート要求を受け入れられますか？SERVER-G と TeamFelNull の提携は可視ですが、ハンドオフは可視ではありません。1ページの責任表が現在の不確実性の多くを除去するでしょう。
3番目の要求は証拠に基づくトポロジです。都市レベルの精度で施設を示し、機密のラック詳細を露出させず、物理回線、仮想回線、トンネルを異なるマークで示す必要があります。共有メトロテールと管理依存関係、および各重要なサービスをホストするサイトを特定する必要があります。フェイルオーバーテストは、1つのアップストリーム、エクスチェンジポート、ルーター、サーバー、またはサイトが削除されたときに何が起こるかを実証する必要があります。マーケティングプレゼンスだけではテスト結果ではありません。
4番目の要求は電力と修理をカバーする必要があります。ユーザーはサーバーがデュアル電源を持つか、両方の施設給電が使用されるか、スペアが手元にあるか、リモートサポートが契約されているかを知る必要があります。文書にはメンテナンス通知、重大度レベル、応答目標、独立したエスカレーションチャネルを含める必要があります。ベストエフォートサポートは、明確に述べられていれば許容可能です。リスクは、ユーザーが施設オペレーターの能力からエンタープライズカバレッジを推測することから生じます。
5番目の要求はデータをカバーする必要があります。バックアップ頻度、保持、暗号化、復元テスト、ユーザーエクスポート、削除、除外を述べる必要があります。外部プラットフォームとプライマリおよびバックアップコピーの locality を指名する必要があります。長期間のゲームワールドやコミュニティデータベースでは、オペレーターは計画された閉鎖前に最近のエクスポートを提供する必要があります。実験的サービスでは、最も単純な正直なルールは「バックアップなし、自分自身のコピーを保持」かもしれません。ただし、ユーザーが実際にそうできる場合に限ります。
最後に、ユーザーは過去のブランディングではなく現在の運用証明を求めるべきです。有用な項目には、最近のステータス履歴、日付入りのルート観測、在庫証明、サンプルインシデント通知、成功した復元記録があります。いずれもシークレットを開示する必要はありません。それらはまとめて、エクスチェンジポートの下に容量が存在し、復旧が意図以上のものであることを示します。それらの項目が利用できない場合、合理的な分類は教育用テストベッドのままであり、ワークロードはそれに応じて選択されるべきです。
評決: 有用なテストベッド、未証明のホスティングプラットフォーム。
TEAMFELNULL SERVER-G Group は、そのまばらな会社フットプリントが最初に示唆するよりも実質的です。AS58790 は現在の PeeringDB アイデンティティ、運用中の 25 Gbps INIXP アタッチメント、最近の施設更新、グローバルに可視のルートを持っています。TeamFelNull は公開プロジェクト、ユーザー用語、ドキュメンテーションを維持しています。SERVER-G は継続的な教育ネットワークを説明し、その学生主導でほとんど非営利の性格と財務的制限を率直に認めています。これらは活動の兆候であり、空の登録ではありません。
証拠は、ホスティングサービスが信頼可能になるポイントでまだ不足しています。4つの施設リストは4つのデプロイメントを証明しません。25 Gbps ポートはサーバースループットや予備容量を証明しません。アドレスアナウンスはマシンをカウントしません。施設の復元力は未知のラック設計を自動的に通過しません。複数の観測されたアップストリームは物理的に多様なトランスポートを証明しません。クライアント側のゲームエクスポートはサーバーサイドデータを保護しません。Discord 連絡先は応答保証を作成しません。
適切なネットワーク証拠グレードは弱く、否定的ではありません。「否定的」はライブエクスチェンジ接続、ルート、公開サービスを無視するでしょう。「中」は運用チェーンが容量と復旧を評価するのに十分に説明されていることを意味します。そうではありません。最も強い証拠は論理エッジにあります。最も弱いものはユーザーが損失を被る場所にあります: ハードウェア在庫、電力権利、ストレージ耐久性、サポート労力、契約、バックアップ、移行。
趣味、学習、明示的にベストエフォートのコミュニティ使用では、それは完全に sensible な取引かもしれません。小さなテストベッドは、商用クラウドの経済性なしに BGP を学び、特殊なゲームを実行し、ツールを構築するスペースを作り出します。その価値はエンタープライズ書類だけで測定されるべきではありません。本質的な条件は informed consent です: ユーザーは実験的インフラが変更される可能性があり、サポートは小さなチームに依存する可能性があり、自分自身の復元可能なコピーが必要であることを知るべきです。
有料または重要なワークロードの場合、依存の前にプライベート検証が必要です。オペレーターは、リソース割り当て、法的相手方、アクティブな施設とアップストリームの取り決め、マルチサイトまたは復元設計、データ移植性条件を示す必要があります。買い手は接続性だけでなく復旧をテストすべきです。それらの証明が存在する場合、公開評価はアップグレードできます。それまで、TEAMFELNULL は、実際のコミュニティサービスと印象的なエクスチェンジエッジを持つ東京中心の教育ネットワークとして最もよく理解されます—文書化されたマルチサイトクラウドとしては理解されません。
その結論は証拠の両側を尊重します。それは開示の欠如を失敗の主張に変えず、よく接続されたルーターを復元力のあるコンピュートのラックに変えません。可視の 25 Gbps ポートは容量質問の始まりです。TEAMFELNULL のユーザーにとって、決定的な事実はその背後にあります: どのマシンが電源投入されているか、どのデータが復元可能か、どのパスが生き残るか、修復ウィンドウが開いたときに誰が行動するか。