要約
- White Sky Hosting は現在の公開サービス面を持つ：メインウェブサイトはゲームおよび専用サーバーホスティングを販売し、VPS ページは具体的な CPU、メモリ、ストレージ、価格帯をリストし、専用サーバーページはベアメタル容量を販売し、請求ストアは在庫のある専用サーバーの注文を公開している。
- ネットワーク層も稼働中。ARIN はAS46177、23.136.228.0/24、2602:f696::/40を White Sky Hosting に登録。RIPE は31.56.65.0/24を同じ組織に記録。RIPEstat は AS46177 が 2026年7月15日に 2つの IPv4 プレフィックスと 1つの IPv6 プレフィックスを宣告していることを示す。
- 最も強力なインフラ手がかりは公開ナレッジベースである。Tenantos 請求/プロビジョニング統合、Proxmox VM ノード、Juniper スイッチ自動化、port-security バインディング、仮想 MAC、VLAN 許可リスト、スイッチバックアップ手順を説明している。これは一般的なホスティングパンフレットよりも運用上の詳細である。
- 証拠グレードは中である。White Sky は可視的に運用されルーティング可能であるが、その公開記録は施設住所、電源供給、ラック数、上流契約、DDoS 容量証明、復元テスト履歴、予備ハードウェアプール、スタッフの深さ、顧客ワークロードの独立した災害復旧サイトを特定していない。
有用なストーリーは、可視的な可動部品を持つ小規模ホスト
White Sky Hosting は単なるディレクトリ名ではない。BTW ディレクトリページは同社を AS46177 にリンクし、ARIN のAS46177 RDAP レコードはリソース WHITE-SKY-HOSTING を命名し、White Sky Hosting と関連付け、登録コメントに公開ウェブサイトを含める。ARIN のWTL-119 組織レコードは組織をワシントン州マウントバーノンに置き、AS46177、1つの直接 IPv4 割り当て、1つの直接 IPv6 割り当てにリンクする。
その登録層は稼働中の商用層によって支えられている。White Sky Hosting ホームページは、信頼性の高いネットワーク上でのゲームおよび専用サーバーホスティング、エンタープライズグレードのハードウェアとサポートを説明している。ホスティング、ゲーム、サポート、請求、ゲームパネル、専用パネル、ナレッジベース、ステータス面へのリンクがある。サイトは静的プレースホルダーではない。製品、カートリンク、アクティブなサブドメインを持つ現在の小売フロントエンドである。
ドメインインフラもプロバイダ自身のルーティングスペースを指している。ローカル DNS 観測により、whiteskyhosting.com と billing.whiteskyhosting.com は 31.56.65.55、docs.whiteskyhosting.com は 31.56.65.35、panel.whiteskyhosting.com は 31.56.65.80、dedicated.whiteskyhosting.com は 31.56.65.75、2つの権威ネームサーバーは 31.56.65.50 と 31.56.65.51 に解決された。RIPE の31.56.65.0/24 RDAP レコードは White Sky Hosting をそのプレフィックスのエンドユーザー組織として識別する。これにより、サイトとコントロールプレーンのホスト名は CDN のみのマーケティングプレゼンスよりも意味のあるものになる。
したがって、最初の結論は肯定的だが限定的である：White Sky Hosting は現在の小規模ホスティング事業者であり、ライブのウェブ、請求、ドキュメント、ステータス、ルーティングの証拠がある。単なる忘れられたレジストリ行ではない。2つ目の結論はより慎重である：公開証拠はまだ White Sky を完全に監査されたインフラプロバイダにはしていない。事業者を示すが、その背後にあるすべての物理的および契約上の依存関係を示すわけではない。
その区別は重要である。なぜなら、プロバイダは顧客がインフラとして扱うかもしれないサービスを販売しているからだ。Minecraft サーバー、VPS、専用 Ryzen マシン、ウェブサイトパッケージ、コントロールパネルアカウントは実際のビジネス依存関係になり得る。注文が簡単であることはサービスが重要でないことを意味しない。物理インフラが小売単位にパッケージ化されていることを意味する。
カタログは経済性を明らかにするほど具体的
White Sky のVPS ホスティングページは異常に具体的である。小規模な Xeon E5-2697v2 プラン（DDR3 ECC メモリ、HDD または SSD ストレージ）、およびより高性能な Ryzen 5900x と Ryzen 7900x プラン（DDR4 または DDR5 メモリ、NVMe ストレージ）をリストしている。公開価格は小さな 3 ドルインスタンスから大きな月額 58 ドルプランまでである。無制限の帯域幅を宣伝しており、顧客にとって魅力的だが、物理的な主張ではなく商業ポリシーとして読むべきである。
ハードウェアの組み合わせはビジネスモデルについて何かを語っている。古い Xeon ノードは低コストのエントリープランをサポートできる。新しい Ryzen ノードはパフォーマンス重視のワークロードをサポートする。HDD、SSD、NVMe の階層により、プロバイダは予算、ストレージ重視、レイテンシ重視の顧客をセグメント化できる。これは典型的な小規模ホスティングの最適化である：異なる世代のハードウェアを使用して異なる価格帯にマッチさせ、すべてのワークロードが同じ最新プラットフォームを受け取るふりをしない。
専用ホスティングページはベアメタルサーバーを説明し、いくつかのクロスサービス主張を繰り返している：Arbor DDoS 保護、99.95% の稼働時間、エキスパートサポート、ハードウェア監視、オフサイトバックアップ、高度な接続性。請求カートの専用サーバーカテゴリはより具体的で、6コア12スレッド、64 GB DDR4、2 x 500 GB NVMe、1 Gbps の計測なしアップリンク、完全ルート、IPMI、カスタム ISO サポートを備えた Ryzen 5 5600x プランを在庫ありと表示している。また、1つの IPv4 と 1つの IPv6 アドレス、DDoS 保護、KVM アクセス、即時セットアップをリストしている。
ゲームサーバー側は顧客ベースを広げる。ゲームページは Minecraft、Valheim、Satisfactory サーバーを低月額価格で販売している。Minecraft ページはさらに進んで、AMD Ryzen 9 ノード、NVMe Gen4 ストレージ、自社所有運用の Tier-3 施設、複数の Tier-1 トランジットプロバイダを介した BGP マルチホーミング、ラックレベルでの 100 Gbps DDoS 保護、90 秒未満での展開を主張している。これらは強力な主張である。顧客が冗長性の証明として扱う前に独立した確認が必要な種類の主張でもある。
請求カートの Minecraft カテゴリはマーケティングページの背後にある商業的現実を示している：RAM とストレージ階層のある小規模プラン、カートに追加アクション、製品説明、アップグレードロジック。Valheim カートカテゴリは少なくとも 1つのシンプルな Valheim 製品を示している。これはサイトが単なるランディングページではなく請求フローに接続されていることを証明するため重要である。未販売在庫の量、実際の展開時間、障害時にノードが吸収できる顧客数は証明しない。
したがって、カタログは中程度の証拠グレードを支持する。White Sky は公開では純粋なリセラーシェルではない。製品、カート、パネル、ドキュメントがある。しかし、利用可能な容量は依然として宣伝されたプランと等しくない。利用可能な容量とは、ホストノードが故障し、アップストリームがダウンし、スイッチポートが設定ミスされ、DDoS 攻撃が発生し、顧客が復元を必要とし、更新期限前に移行が発生しなければならないときに残るものである。
ルーティング層は現在だが、監査には十分小さい
AS46177 は現在の公開ルーティングデータで可視である。RIPEstat のAS46177 の AS 概要は 2026年7月15日に WHITE-SKY-HOSTING が宣告されたと報告した。announced-prefixes エンドポイントはその日までの 2週間のウィンドウに対して 3つのプレフィックスを示した：31.56.65.0/24、23.136.228.0/24、2602:f696::/40。routing-status エンドポイントは 2つの可視の IPv4 プレフィックス、1つの可視の IPv6 プレフィックス、完全な RIS ピア可視性、4つの観測されたネイバーを報告した。
これは強力な現在のルートシグナルである。White Sky の AS が単に登録されているだけでなく、公開コレクタから可視であることを示している。また、可視のフットプリントがコンパクトであることも示している。2つの /24 IPv4 ルートと 1つの /40 IPv6 ルートは実際の小規模ホストをサポートできるが、ハイパースケール容量を意味しない。焦点を絞ったプラットフォームとして扱うべきである：現在の運用には十分だが、無限の成長や即時フェイルオーバーの証明ではない。
ネイバーデータは最初の依存関係マップを提供する。RIPEstat のAS46177 ネイバーレスポンスは観測されたネイバーとして AS27563、AS32505、AS197924、AS401111 をリストした。公開ルートパス（RIPEstat を通じてサンプリング）は AS46177 へのトラフィックが AS32505 と AS27563 を含むアップストリームチェーンを介して到達することも示した。これは複数の可視のルートパスの考えを支持する。すべてのラック、すべてのサービス、すべてのプレフィックスがフル負荷でクリーンにフェイルオーバーできることを証明しない。
ここで小規模ネットワークのデューデリジェンスが抽象的ではなく実用的になる。顧客はリスクを理解するために White Sky がすべての商業契約を公開する必要はない。アップストリームミックスがワークロードに十分多様か、各プレフィックスが同じエッジからアドバタイズされているか、ルートフィルタが変更前にテストされているか、IPv6 が IPv4 と同じくらい真剣に監視されているか、サポートがサーバー問題とルーティング問題を迅速に区別できるかを知る必要がある。公開ルーティングレコードはこれらの質問を具体的にする。会話を「ネットワークはありますか」から「1つのパスが不健康な場合、ネットワークのどの部分が独立していますか」に絞り込む。
プレフィックス登録は 2つのカテゴリに分かれる。ARIN は23.136.228.0/24と2602:f696::/40を White Sky Hosting に直接登録している。RIPE は31.56.65.0/24を RIPE データベースオブジェクトを通じて White Sky Hosting に割り当て、エンドユーザー組織の備考とジオフィードリンクを含めて記録している。この組み合わせにより、プロバイダは ARIN と RIPE の両方のコンテキストでアドレスリソースを持つ。
ルーティング層には開示ギャップもある。PeeringDB のAS46177 ネットワーク API レコードは White Sky Hosting を命名し、ウェブサイトをリストし、ネットワークを NSP / Network Services と説明し、トラフィックを 1-5 Gbps 帯域と報告し、北米の範囲を与える。しかし、PeeringDB のnetfac API クエリはファシリティ行を返さず、netixlan API クエリは交換 LAN 行を返さなかった。PeeringDB のファシリティ開示は任意であるため、これはインフラの反証ではない。ファシリティと交換プレゼンスの公開証明が欠けている。
顧客にとって、ルート層は真剣な評価を正当化するのに十分良い。質問を省略するには十分ではない。今日各プレフィックスを運んでいるアップストリームはどれか？物理的に多様か？別々のルータとクロスコネクト上にあるか？IPv6 は IPv4 と同じ運用上の注意で運ばれているか？調査中に観測された多くの公開ホスト名がそのプレフィックスを指していることを考えると、31.56.65.0/24 に問題が発生したらどうなるか？
公開ナレッジベースは運用機構を暴露
White Sky の最も価値のある公開証拠はマーケティング用語ではない。ナレッジベースのインフラセクションである。そのページは Tenantos 請求/プロビジョニング統合、Proxmox VM ノード、Juniper スイッチ自動化に接続されたインフラプラットフォームを説明している。IP 割り当てまたは削除イベントがスイッチ設定変更をトリガーでき、スイッチ、仮想 MAC、Proxmox、VLAN 許可リスト、バックアップ、設定の管理パネルを説明している。
port-security ページはさらに詳細を与える。Tenantos 割り当てイベント、API コール、スイッチポート更新、セキュアアクセスポートバインディングを説明している。専用サーバーと VM ノードは異なる扱いを受ける：専用サーバーは独自のスイッチポートを持ち、VM ノードは Proxmox ノード上の VM からの MAC、IP、VLAN バインディングを集約する。これは運用上具体的であり、一般的なウェブホスティングの埋め草と間違えるのは難しい。
スイッチ管理ページはスイッチ変更前の自動バックアップ、スケジュールバックアップ、手動バックアップ、保持制限、復元手順を説明している。また、バックアップの復元がスイッチ上で完全な設定上書きを実行することに言及している。これはまさに現実のリスクを明らかにする種類の詳細である。スイッチ自動化は手動ドリフトを防ぐのに役立つが、悪いプッシュや誤った復元は多くの顧客に影響を与える可能性がある。
仮想 MAC ページは、専用サーバー上の複数の IP が Juniper セキュアアクセスポート設定で別々の仮想 MAC アドレスを必要とする理由を説明している。VMAC 使用ガイドは仮想 MAC バインディングの生成、取り消し、バッチ処理、移行を説明している。これは復元可能性にとって重要である。追加 IP を持つ顧客はサーバーが起動するだけでなく、スイッチが正しい MAC/IP/VLAN 状態を受け入れる必要がある。
これらのドキュメントは、White Sky がスイッチ、Proxmox、プロビジョニングイベント、VLAN、バックアップの観点で考えていることを示すため、信頼性を高める。また、特定の障害モードを露出させるため、デューデリジェンスの負担を増やす。Tenantos イベントが失敗すると、IP 割り当てがスイッチに到達しない可能性がある。Proxmox ゲストテレメトリが間違っていると、VM バインディングが不完全になる可能性がある。VLAN 許可リストが設定ミスされると、正当なバインディングがスキップされる可能性がある。スイッチバックアップ復元が広範囲に及ぶと、無関係なポートが影響を受ける可能性がある。VMAC 移行が誤って処理されると、サーバー自体が正常でも顧客の到達可能性が失われる可能性がある。
これは光沢のある信頼性の主張と実際のインフラ表面の違いである。White Sky のドキュメントは顧客により良い質問をするための語彙を与える。自動化がどのくらいの頻度でテストされているか、変更がどのように承認されるか、ロールバックがどのように検証されるか、管理システムが顧客向けネットワークから独立しているかどうかの完全な公開監査は提供しない。
自社施設の主張は重要であり公開では未検証
Minecraft ページには最も強い物理的主張が含まれている：自社所有運用する Tier-3 施設のハードウェアであり、コロケーションからリースされたものではなく、アップストリームから再販されたものでもない。また、プロバイダがラックとスイッチを制御しているとも述べている。もし真実なら、有意義な差別化要因となる。多くの小規模ホスティング企業はサードパーティ施設のスペースを借り、リモートハンズに大きく依存している。施設の所有または直接運用は一部の依存関係を減らし、説明責任を高めることができる。
しかし、ここでレビューされた公開記録は施設住所、認証機関、電源トポロジ、発電機配置、冷却設計、ラック数、消火システム、セキュリティモデル、保守履歴を特定していない。ARIN は組織をワシントン州マウントバーノンの住所に置いている。サービスページは信頼性の高いインフラについて大まかに語っている。PeeringDB は公開施設をリストしていない。ステータスページはサービスとホスト名をリストしており、施設ではない。ナレッジベースはスイッチとプロビジョニング操作を示しているが、建物の所有権文書ではない。
適切な扱いは慎重である。自社施設の主張は企業の主張として報告され、デューデリジェンスのターゲットとして使用されるべきである。公開ソースで独立に証明されたものとして扱うべきではない。重要なワークロードを置く顧客は、必要に応じて非開示の下で施設の概要を求めるべきである：場所、電力供給、UPS と発電機の設計、ラック密度、アップストリームエントリポイント、保守ウィンドウ、物理的セキュリティ、リモートアクセス、保険またはコンプライアンスの証拠。
同じことが Minecraft ページの 100 Gbps DDoS と Tier-1 トランジットの文言、および請求カートの Arbor by NETSCOUT の表現にも当てはまる。DDoS 保護は実際に機能し価値がある可能性があるが、顧客はどこで適用されるか、すべての製品をカバーするか、軽減がレイテンシに影響するか、ゲームトラフィックがウェブトラフィックと異なるフィルタリングされるか、IPv6 が保護されるか、攻撃がサービスレベルを超えた場合に何が起こるかを知る必要がある。製品ページの数字はテストされたインシデントレポートと同じではない。
White Sky の公開ルート可視性はこれらの質問を原則として答えられるようにする。顧客は traceroute をテストし、発信元 AS を観察し、パスを監視し、主張をパケット動作と比較できる。しかし、施設と DDoS の主張は依然として契約上または運用上の証明を必要とする。公開ルートコレクタは電力冗長性、スタッフの存在、スクラバ容量を示さない。
コントロールプレーンの集中は実際の監視ポイント
調査中に観測されたいくつかの White Sky ホスト名は 31.56.65.0/24 に解決される。メインウェブサイト、請求パネル、cPanel ホスト名は 31.56.65.55 に解決された。ドキュメントホストは 31.56.65.35 に、ゲームパネルは 31.56.65.80 に、専用パネルは 31.56.65.75 に、権威ネームサーバーは 31.56.65.50 と 31.56.65.51 に解決された。対照的に、ステータスページは観測された AS46177 プレフィックス外の 158.69.154.132 に解決された。
これはほとんど肯定的である。プロバイダ自身のインフラが RIPE が White Sky Hosting に関連付けるプレフィックス内でアクティブであることを示している。また、集中の問題を生み出す。31.56.65.0/24 またはそれらのホスト名をサポートするラックに問題がある場合、ウェブサイト、請求、ドキュメント、パネル、権威 DNS が障害ドメインを共有する可能性がある。外部に置かれたステータスページは役立つが、顧客は顧客パネル、サポートデスク、またはネームサーバーが障害時にそれが有用であり続けるかどうかを知る必要がある。
権威 DNS は特に重要である。ns1 と ns2 が同じ /24 にある場合、別々のホスト名であっても完全に独立しているとは限らない。White Sky の DNS を本番環境で使用している顧客は、ネームサーバーの背後に追加の anycast またはオフネットワーク DNS があるか、2つのサーバーが別々のマシンと電源経路にあるか、ゾーンエクスポートが利用可能かを尋ねるべきである。
サポートパスも検査が必要である。請求ポータルは WHMCS スタイルの顧客エリアであり、チケット送信ページはキャプチャ付きの公開サポートリクエスト作成を許可し、サーバーステータスルートは認証されていないユーザーをログインにリダイレクトした。これは通常の商業パターンである。認証されていない外部ユーザーは一部のサポート表面を見ることができるが、詳細なネットワークステータスパネルを監査することはできない。
公開ステータスページはより有用である。すべてのシステムが運用中、90日間の平均稼働率 99.890%、メインウェブサイト、請求パネル、ゲームパネル、専用パネル、ステータスページ、cPanel、TenantOS ホスト、統計コレクタ、権威 DNS の個別ステータスブロックを報告した。サマリー JSONは調査時点で 18 のコンポーネントにわたって運用状態を報告した。ステータスページはまた、サンプルデータを表示しており、ライブチェックが自動的に接続していると述べており、顧客が 90日間のチャートにどの程度の重みを置くべきかを和らげるべきである。
結果は実用的な見解である。White Sky は可視のコントロールプレーンを持っている。その一部は White Sky 自身のルーティングプレフィックス内にあるように見える。ステータスを含む一部は外部にあるように見える。これはコントロールプレーンがないよりはましである。それでも、請求、サポート、DNS、パネルがルーティング、電力、またはスイッチイベント中に独立して到達可能かどうかの疑問が残る。
分割は移行パスも形作る。顧客のサーバーが到達不能でもステータスサイトが到達可能なら、顧客はインシデントが存在することを知ることができる。ステータスサイトが到達可能でも請求ポータル、DNS、パネルがすべて障害なら、顧客はデータのエクスポート、ゾーンの変更、認証済みチケットの開始に必要なツールを欠く可能性がある。成熟したホストは、帯域外サポートチャネル、緊急 DNS オプション、プライマリホスティングプレフィックスが劣化してもオンラインのままの最小サービスを文書化することでそれを解決する。White Sky の公開記録はそのようなパスの材料を示しているが、完成したランブックは示していない。
冗長性の証明はそれらの材料をテストされたシーケンスに接続するだろう。例えば、有用な公開インシデントノートは、どのコンポーネントが故障したか、どのルートまたはラックが影響を受けたか、顧客にどのように通知されたか、サポートが到達可能のままだったか、DNS 変更が必要だったか、復旧にどのくらいかかったかを言うだろう。有用なプライベート顧客概要はさらに進み、コントロールプレーンを別々の電力、スイッチ、アップストリーム依存関係にマッピングするだろう。その証拠がなければ、より安全な読み方は冗長性が部分的に存在し、完全に文書化された顧客復旧の約束としては存在しないということである。
サポートと利用規約はリスクの一部を顧客に戻す
White Sky の利用規約は共有ホスティングと専用ホスティングを定義し、中断のないサービスの提供を目指すと述べる一方、サービスが常に利用可能または中断がないことを保証しないと述べている。そのバランスは正常である。プロバイダは合理的な運用を約束しながら、メンテナンス、悪用、支払い、制御外のイベントの除外を保持できる。
利用規約はまた、アカウント資格情報、合法的な使用、コンテンツの責任をユーザーに課している。これは運用上重要である。アカウントの侵害、悪意のあるトラフィック、マルウェア、スパム、未払い請求書は、電力イベントと同じくらい確実にダウンタイムを引き起こす可能性がある。ゲームコミュニティ、VPS、ウェブサイト、専用サーバーを運用している顧客は、アカウントセキュリティ、連絡先衛生、悪用対応を可用性エンジニアリングの一部として扱うべきである。
プライバシーポリシーは、White Sky が名前、メールアドレス、電話番号、請求情報、使用データ、IP アドレス、ブラウザタイプ、オペレーティングシステム、訪問したページ、訪問タイミングを収集する可能性があり、サービスプロバイダと共有したり法的要件の下で共有したりする可能性があると述べている。これは珍しくないが、データローカリティと顧客コンプライアンスにとって重要である。ワークロードは White Sky のハードウェアで実行される一方、請求、分析、メール、サポート、その他のサービスプロバイダデータは他の場所に移動する可能性がある。
公開ドキュメントは完全なデータ処理マップを提供していない。バックアップがどこに保存されているか、サポートデータがどこで処理されるか、どのサブプロセッサが使用されるか、ゲームパネルデータがプライマリ環境を離れるか、ログがどのくらい保持されるかを特定していない。サイトはオフサイトバックアップと保護されたデータを販売しているが、規制対象または機密性の高いワークロードを持つ顧客は、プライマリデータ、バックアップデータ、請求データ、サポートチケット、ログ、分析を分離する書面による声明が必要である。
サポートは存在するが完全には測定されていない。サイトは繰り返しエキスパートサポートを提供し、請求ポータルはチケット作成を公開し、サイトは Discord にリンクし、ステータスページはコンポーネントを分離している。公開ソースは現在のスタッフ時間、エスカレーション目標、時間外エンジニアリング権限、インシデントコミュニケーションポリシー、SLA 違反後の返金メカニズムを示していない。顧客は収益重視のワークロードを展開する前に尋ねるべきである。
重要な点は、White Sky の小売フレンドリーさが顧客の責任を取り除かないことである。顧客が低コストのゲームサーバーや VPS を購入し、ワールド、データベース、ウェブサイトの唯一のコピーをそのサービスに保存する場合、復旧はプロバイダだけに依存しない。バックアップ、資格情報、DNS 制御、エクスポート権、顧客自身の復元プラクティスに依存する。
インストール容量と利用可能容量はストレス時に乖離する可能性がある
White Sky の製品ページはインストール済みまたは販売可能ユニットを示している：RAM、vCPU、ディスク、CPU、価格、ポート、ゲームプラン。請求カートは少なくとも在庫のある専用サーバープランを示している。ステータスページは監視対象コンポーネントを示している。ルートテーブルは到達可能なプレフィックスを示している。これらは重要なインストール容量シグナルである。
利用可能容量はストレス時に残るものである。Ryzen ノードが故障した場合、White Sky はゲームサーバーを IP/MAC/VLAN バインディングを壊さずに別のノードに移動できるか？Proxmox ホストがストレージを失った場合、バックアップはローカルか、オフサイトか、両方か？Juniper スイッチのコミットが失敗した場合、ロールバックは自動か、手動か、スタッフのアクセスに依存するか？DDoS イベントが Minecraft ノードを襲った場合、軽減はゲームポートだけでなくパネル、請求、DNS も保護するか？31.56.65.0/24 にルーティング問題がある場合、顧客サポートとネームサーバーはまだ機能できるか？
ナレッジベースはこれらの問題の一部が認識されていることを示すことで役立つ。スイッチバックアップは存在する。VMAC ライフサイクルは存在する。ポートセキュリティ自動化は存在する。VLAN 許可リストは存在する。それは良いことだ。また、顧客はそれらの制御のための制御を尋ねるべきであることを意味する。誰がスイッチ復元を承認するか？誰が VLAN 許可リストを上書きできるか？自動イベントは広範な展開前にどのようにテストされるか？バックアップはチェックされているか、単に保存されているか？Proxmox と Tenantos は独立して監視されているか？
2つ目の容量の区別がある：インストールされたアドレス空間は展開可能なサービス空間と同じではない。/24 の IPv4 はレジストリページでは寛大に見えるかもしれないが、インフラアドレス、ルーターインターフェース、パネル、ネームサーバー、顧客割り当て、隔離範囲、逆 DNS 委任、予備プール、レピュテーション管理がすべてその一部を消費する。1つの IPv4 アドレスを含む専用サーバープランは販売が簡単である。後日さらに多くのアドレス、クリーンなメールレピュテーション、別個の管理アクセス、緊急再番号付けが必要な顧客は、プロバイダに十分な余裕があるかどうかを明らかにできる。IPv6 はアドレッシングを容易にするが、多くのゲーム、ウェブ、レガシー顧客が依然として感じる IPv4 の圧力を取り除くわけではない。
直接の IPv4 と IPv6 の割り当ても容量に影響を与える。23.136.228.0/24はインフラ予約前に 256 の IPv4 アドレスを与える；2602:f696::/40はかなりの IPv6 プールを与える。RIPE 割り当ての31.56.65.0/24は可視のコントロール表面の多くを運んでいるように見える。アドレス空間は有用だが、専用サーバー割り当て、顧客アドオン、インフラ、悪用隔離、レピュテーションセグメンテーションによって使い果たされる可能性がある。顧客は追加 IP がどのように割り当てられるか、逆 DNS がどのように処理されるかを尋ねるべきである。
帯域幅の文言も同じ注意が必要である。VPS プランは無制限の帯域幅と言っている。専用プランは 1 Gbps の計測なしアップリンクを宣伝している。PeeringDB はトラフィックを 1-5 Gbps 帯域と報告している。これらは共存できるが、同じ指標ではない。顧客はすべてのサーバーがアップストリーム障害中に 1 Gbps を無期限に維持できると推測できない。契約はポート速度、トラフィックポリシー、公正使用、輻輳対応、攻撃処理を定義すべきである。
修復容量はより難しい公開不明点である。請求カートはサーバーが在庫にあることを示せるが、予備のマザーボード、電源、ブートデバイス、NVMe ドライブ、スイッチポート、光学モジュール、訓練された技術者が顧客が復旧を必要とする時間に利用可能かどうかを示せない。専用プランの IPMI とカスタム ISO サポートは、顧客がハンズオンアクセスを待たずに一部の復旧作業を実行できるため有用である。物理的なスペアに代わるものではない。本格的な使用のために、購入者は何がその場で修理され、何が移行され、何が新しいプロビジョニングを必要とし、障害後に古いストレージがどのくらい保持されるかを尋ねるべきである。
これは White Sky に固有の批判ではない。小規模インフラの経済性がそう動く。プロバイダは有限のハードウェア、有限のルーティング、有限のサポートを手頃なプランにパッケージ化する。顧客はスタックを自分で構築する必要がないため価値を得る。スタックがストレスを受けたときにプロバイダの制限も引き継ぐ。
White Sky が悪い日を迎えたときに影響を受ける人
関係者はカタログから可視である。ゲームサーバーの顧客は Minecraft、Valheim、Satisfactory のワールド、コミュニティイベント、Discord リンク管理、プレイヤーの信頼を失う可能性がある。短い停止でも、トーナメント、有料コミュニティイベント、ストリーマーセッション中に発生した場合問題になる。長い停止は、バックアップとシャットダウン処理が弱い場合、ワールドを破損させる可能性がある。
VPS 顧客はウェブサイト、ボット、開発環境、監視エンドポイント、小規模データベース、VPN、セカンダリサービスを実行する可能性がある。彼らにとって、主なリスクはダウンタイムだけではない。状態の復旧である：VM イメージが一貫しているか、スナップショットが存在するか、顧客がデータをエクスポートできるか、DNS を移動できるか、ファイアウォールルールと資格情報が文書化されているか。
専用サーバーの顧客は、ゲームネットワーク、収益を生むウェブサイト、ストレージ重視のワークロード、エージェンシープロジェクトのためにシングルテナントハードウェアに依存する可能性がある。彼らはシャーシ、ディスク、電源、ネットワークポートの交換パスを知る必要がある。カートの在庫あり Ryzen プランは魅力的だが、顧客は販売用だけでなく修理用に予備の同等ハードウェアが存在するか尋ねるべきである。
ウェブサイトパッケージの顧客は、White Sky のウェブホスティング製品を使用する場合、cPanel、DNS、メール、請求に大きく依存する可能性がある。ステータスページは cpanel-01 をコンポーネントとしてリストし、メインサイトはウェブサイトパッケージにリンクしている。これらの顧客は技術的でなく、データを迅速にエクスポートする準備ができていない可能性がある。彼らはバックアップがどこに保持されているか、プロバイダまたはコントロールパネルが障害時にサイトを移動する方法を知るべきである。
プロバイダ自身も暴露されている。可視の公開ホスト名が 31.56.65.0/24 にクラスタリングされているため、そのプレフィックスに影響するインシデントは急速に評判になる可能性がある。外部ステータスページは役立つが、会社は影響を受けるシステムに完全に依存しない帯域外サポート通信、DNS 復旧、顧客メッセージングを必要とするだろう。
より広いインターネットへの影響はおそらく控えめである。White Sky は公開証拠ではハイパースケールプラットフォームとして提示されていない。影響はその顧客とそのユーザーの間に集中している。それは些細なことではない。小規模インフラプロバイダは、しばしば独自の冗長性を構築する準備が最もできていないコミュニティや小規模ビジネスを正確にホストしている。
証拠グレードを上げるもの
White Sky はコンパクトな公開運用ページで中から強に移行できる。機密図を公開すべきではないが、プライマリ施設の都市または地域、施設が所有かリースか、そこでどのサービスが実行されるか、顧客ラックに何本の独立した電力経路がサービスを提供するか、発電機がテストされているか、メンテナンス中にリモートアクセスがどのように機能するかを述べることができる。
ネットワークページが役立つだろう。AS46177 の現在のアップストリーム、ルートセキュリティプラクティス、プレフィックスポリシー、DDoS 軽減範囲、IPv6 サポート、ピアリング目標、計画メンテナンスチャネルをリストできる。ルート層の多くはすでにRIPEstat ルーティングステータス、アナウンスされたプレフィックス、PeeringDBを通じて可視である。プロバイダ所有の概要は曖昧さを減らすだろう。
バックアップドキュメントは特に価値があるだろう。White Sky のページは保護されたバックアップまたはオフサイトバックアップに言及しているが、顧客は製品ごとの詳細を必要としている：どのプランにバックアップが含まれるか、バックアップ頻度、保持期間、保存場所、復元コスト、復元ターゲット、顧客エクスポートパス、最終テスト日。ゲームワールド、VPS ディスク、専用サーバーデータ、ウェブサイトパッケージは同じ復元モデルを持たない。
ステータスとインシデントの証拠は改善できる。ステータスページは良いスタートであり、JSON サマリーは有用である。実際のメンテナンスノート、影響を受けたコンポーネント、開始時刻と終了時刻、根本原因、是正措置を含む公開インシデントアーカイブは、稼働時間の主張を信頼しやすくするだろう。また、顧客に何か問題が発生したときにプロバイダがどのように通信するかを示すだろう。
最後に、ナレッジベースは顧客向けガイダンスと事業者専用の例を分離すべきである。現在、有用なアーキテクチャ概念とプレースホルダー的な例を公開している。その開放性はデューデリジェンスに役立つが、顧客は公開ドキュメントがどの部分が実際の本番動作で、どの部分が例で、どの部分が顧客設定不可かを明確にする必要がある。明確なドキュメントはインシデント中のサポート混乱を減らすだろう。
購入者の実践的質問
購入者はルート質問から始めるべきである。私のサービスはどのプレフィックスを使用するか：31.56.65.0/24、23.136.228.0/24、2602:f696::/40、または別のブロックか？公開コレクタからどの発信元 AS が見えるか？IPv4 と IPv6 の両方が製品でサポートされているか？誰が逆 DNS とルート認証を制御しているか？
次に施設質問を尋ねる。サーバーは物理的にどこでホストされているか？White Sky が自社所有運用すると言う施設か？この文脈で Tier-3 は何を意味するか？ラックに A/B 電源はあるか？別々のアップストリーム出入り口はあるか？リモートハンズまたはスタッフ対応モデルは何か？計画された電気または冷却作業中に何が起こるか？
次にハードウェア質問を尋ねる。VPS の場合、どのハイパーバイザージェネレーション、ストレージバックエンド、フェイルオーバーモデルが適用されるか？専用サーバーの場合、購入したクラスのどの交換在庫が存在するか？ゲームサーバーの場合、ワールドはどのようにバックアップおよび復元されるか？ウェブサイトホスティングの場合、顧客は cPanel データ、DNS ゾーン、メールボックスをどのようにエクスポートできるか？
次にスイッチと自動化質問を尋ねる。サービスが追加 IP、VMAC、ポートセキュリティバインディングを使用する場合、変更はどのようにテストおよびロールバックされるか？Tenantos、Proxmox、またはスイッチ自動化が故障した場合どうなるか？手動の緊急パスはあるか？
次にサポート質問を尋ねる。どのチャネルが緊急グレードか：請求チケット、Discord、メール、または別のパスか？時間外にスタッフはいるか？99.95% の稼働時間約束は何をカバーするか？DDoS イベントはサポートパスを変更するか？ステータスページはネットワークインシデント中も独立を保つか？
次に出口質問を尋ねる。顧客はイメージ、データ、バックアップ、ログ、DNS を持って退去できるか？新旧のサービスはどのくらい重複できるか？プロバイダ割り当て IP アドレスはポータブルか？そうでない場合、再番号付け、終了、アドレスポリシー変更の前にどのくらいの通知が与えられるか？
これらの質問は White Sky の強みに一致する。プロバイダは詳細な質問を価値あるものにする十分な公開証拠を持っている。また、それらの質問を必要とする十分な未開示の依存関係も持っている。
最終結論
White Sky Hosting はライブで検査可能な小規模ホスティングプロバイダである。公開証拠には AS46177、現在のルート可視性、ARIN と RIPE のアドレスレコード、商用ウェブサイト、WHMCS スタイルの請求、公開サポートチケット作成、ステータスページ、ゲームおよび専用サーバープラン、VPS プランテーブル、ルーティングプレフィックス内の権威 DNS、Juniper スイッチ、Proxmox ノード、Tenantos プロビジョニング、ポートセキュリティ、VMAC、VLAN 許可リスト、スイッチバックアップについて議論するナレッジベースが含まれる。
それは休眠ディレクトリカードよりもはるかに強い。中程度の証拠グレードと実際の運用プロファイルを支持する。顧客は名前から推測するのではなくサービスを評価するのに十分見ることができる。
公開記録は依然としてレジリエンスの証明には至らない。主張された自社施設、Tier-3 ステータス、電源設計、ラック多様性、アップストリーム契約、DDoS 容量、バックアップ独立性、復元テスト、予備ハードウェアレベル、サポートスタッフ、クロスサイト災害復旧を独立に検証していない。PeeringDB にはネットワークレコードがあるが、公開ファシリティや交換行はない。ステータスページは役立つが、完全なインシデントアーカイブではない。いくつかのコントロールプレーンホスト名が 1つのプレフィックスに集中しているように見える。
正しい結論は警戒的でも信用過剰でもない。White Sky Hosting は実際のホスティングインフラを運用し、多くの同業者よりも多くの運用詳細を公開しているように見える。その顧客は依然としてサービスが物理的であるかのように設計すべきである：ラック、スイッチ、IP バインディング、アップストリームルート、電力、サポートキュー、バックアップジョブはすべて故障する可能性がある。最も安全な購入者は、価格と証拠に一致するワークロードに White Sky を使用し、独自のバックアップ、DNS 制御、監視、移行パスをプロバイダ外に保持する。