概況
- Spidernet のウェブサイトは複数のビジネス向けホスティングを宣伝しているが、データセンター建物、施設運営者、クラウドプラットフォーム、ハードウェア構成、電力トポロジー、キャリアセット、サービスレベルコミットメント、または公のインシデント履歴を一切明示していない。提案は見えているが、運用設計は見えない。
- APNIC は2026年4月17日に Spidernet の AS154632 を登録し、4月20日に
162.4.2.0/23（512 IPv4 アドレス）を割り当てた。7月12日時点で AS154632 はルートを発信しておらず、一方162.4.2.0/24は Go2Cloud Solutions の AS151988 を通じてグローバルに可視化されていた。もう半分の162.4.3.0/24は可視化されなかった。 - アクティブな Spidernet プレフィックスへのすべてのサンプルされたパブリックパスは
AS18229 AS151988で終わっており、CtrlS が Go2Cloud の直接上流で、Go2Cloud が Spidernet のブロックを発信している。これは、そのチェーンを通じた到達可能性を証明するが、物理的なルート多様性、予備帯域幅、第2のサイト、または特定の形態の直接的商業関係を証明するものではない。 - 公開されている販売ページは、実質的に2021年に最後に構成され、別の企業である Surchi Infotech を繰り返し記述している。現在の仕様、価格、バックアップ条件、復旧目標、または移行手順ではなく、一般的なサービス説明を提供している。
- 証拠のグレードは「弱い」である。購入者は、回復不能なワークロードをサービスに置く前に、名称のあるホスティング場所、契約エンティティ、施設とネットワークの運営者、テスト済みの復旧ポイントと復旧時間、バックアップの所有権、サポートエスカレーション、メンテナンスルール、データエクスポート手順、および第2の障害ドメインを要求すべきである。
インフラマップのないクラウドカタログ
Spidernet Cloud Solutions は、見慣れた中小企業向けホスティングの提案を提示している。ナビゲーションにはクラウドデータベースホスティング、メールホスティング、クラウド ERP、ファイルホスティング、Tally ホスティング、ウェブサイトホスティング、サーバーメンテナンスが並ぶ。ホームページではソフトウェア・アプリケーション開発も提供している。額面通りに受け取れば、これは一つの製品ではなく、コンピュート、ストレージ、データベース、メッセージング、ビジネスアプリケーション、パブリックウェブ配信、人的サポートというスタックである。
各レイヤーには物理的なコストが伴う。ホストされたデータベースはメモリ、プロセッサ時間、永続ストレージを消費する。メールにはストレージ、フィルタリング、レピュテーション管理、信頼性の高い DNS が必要だ。Tally や ERP セッションにはサーバー、ソフトウェア使用権、安定したレイテンシ、障害後にスタッフを再接続する手段がいる。ウェブサイトにはアドレス、ルーティング、ウェブサーバー、証明書が必要である。これらすべては最終的にデータセンター内の電力供給されたハードウェア、上流ネットワークへのクロスコネクト、交換部品、サービスの修理や移動を許可された担当者に依存している。
Spidernet はその基盤マップを公開していない。どのサービスページもホスティングの都市、施設、ラック運営者、ハードウェアプラットフォーム、ストレージアーキテクチャ、ハイパーバイザー、アベイラビリティゾーン、上流キャリア、ディザスタリカバリサイトを特定していない。お問い合わせページには Karol Bagh のオフィス住所、電話番号1件、メールアドレスが記載されている。顧客サーバーがその住所に設置されているとは述べておらず、オフィスの住所をデータセンターの場所と誤認してはならない。
この区別は些細ではない。Spidernet が他のクラウドから仮想マシンをリースするのか、専用サーバーをレンタルするのか、自社ホストをコロケーションするのか、パートナーのインスタンスを再販するのか、顧客所有の機器を管理するのかによって、あらゆる修理を誰が制御するかが変わる。故障したドライブを誰が交換できるか、誰がトラフィックを迂回できるか、誰がバックアップを所有するか、誰がインシデントチケットを受け取るか、誰が緊急アクセスを許可するか、あるサプライヤーが別のサプライヤーを非難したときに誰が責任を負うか、すべてが変わる。公開ページはこれらの運用モデルのいずれも選択していない。
クラウドの抽象化は、キャパシティが場所から切り離されているように見せかけることがある。NIST のクラウドコンピューティング定義は、抽象化が依然としてサーバー、ストレージ、ネットワークリソースの物理層の上に成り立っていることを明示している。また、顧客が場所を国、州、データセンターといった高次のレベルでのみ知り得る可能性にも言及している。Spidernet のページは、提供サービスについてその高次の配置さえも一貫して提供していない。
したがって最初の所見は控えめながら重要だ。Spidernet には実在するサービスカタログと連絡可能なビジネス窓口があるが、そのカタログは運用資産の一覧へと変換できない。見込み客は同社が販売したいものを見ることはできるが、サービスがどこで実行され、どれだけのキャパシティが確保され、どのコンポーネントが共有されているかは見ることができない。
公的な身元確認には、名前の一致ではなく署名された契約が必要
現在最も強固な身元記録は地域インターネットレジストリからのものである。APNIC の AS154632 レコードは Spidernet Cloud Solutions を名指しし、同社ウェブサイトで使われている Karol Bagh 住所を記載し、同じ電話番号を提示している。管理および技術担当として Lalit Jain を指名し、spidernet.net.inのメールアドレスを使用している。この一致により、ウェブサイトと APNIC 組織は一貫した運用主体として成り立っている。
類似の名称を持つ法人もインドの会社情報サービスに登場する。ZaubaCorp のプロファイルは、Spidernet Cloud Solutions LLP（番号 AAQ-6356）を2019年9月にデリーで設立されたものとして記録している。しかし、このプロファイルの登録住所は Pitampura であり、指定パートナーは Kumar Roshan と Jatin Kumar である。これらの詳細は APNIC レコードの Karol Bagh 住所や Lalit Jain 連絡先と一致しない。
名称の一致はシグナルではあるが、LLP が現在のホスティング事業の契約相手である証拠にはならない。企業はオフィスを移転し、スタッフを任命し、ブランド名で取引し、サービス住所を使用することができる。レジストリアグリゲーターは遅延する場合がある。これらのいずれも、顧客が法的つながりを前提とすることを許さない。請求書、注文書、税務登録、サービス契約書には、契約当事者、登録番号、住所が明記されるべきである。同じ文書に、当該当事者が機器を所有するのか、再販業者として行動するのか、他社のインフラ上で管理を提供するのかが記載されるべきだ。
同社のウェブサイトはこの必要性を極めて切実にしている。会社概要ページは「Surchi Infotech」が記載されたサービスを提供すると述べている。データベース、メール、ERP、ファイル、Tally、ウェブサイトホスティング、メンテナンスの各ページは Surchi の名前を繰り返す。プライバシーポリシーページはsurchiinfotech.comを参照し、免責事項は声明と責任を Surchi Infotech に帰属させている。一方、ヘッダー、連絡先詳細、ドメインは Spider Net を提示している。
これはサイト構築時に流用された古いコンテンツか、以前の取引形態か、単純な編集ミスかもしれない。公開された証拠はどちらとも決定しない。しかし、それらのページができないことも明らかだ。クラウドサービスを約束する当事者や適用される条件を確実に特定できないのである。別のドメインのために書かれたプライバシー声明は、Spidernet の顧客の個人データを誰が管理するかに答えられない。別の事業者を指す免責事項は、Spidernet のダウンタイムに対する責任を定義できない。
資料の古さがこの注意を強化する。Spidernet のデータベースページの公開 WordPress レコードや、ほとんどのクラウドおよびサーバーサポートページの対応レコードは、最終更新日を2021年6月としている。フッターにはコピーライト2021と表示されている。ネットワーキングレコードはそれからほぼ5年後の2026年4月に到来した。企業はウェブサイトを再構築せずにインフラを追加できるが、購入者は古い一般的なコピーを最新の技術スケジュールとして扱うべきではない。
この境界はリカバリにとって重要である。平穏な月には、顧客は馴染みの営業担当者やサポートエンジニアとだけやり取りするかもしれない。障害が発生した時は、権限は契約に従う。顧客関係を持つ当事者がラックを管理していないかもしれない。ラックを管理する当事者がネットワークを管理していないかもしれない。アドレス所有者がルート発信者ではないかもしれない。ディスクを交換できる人物が4番目の会社に所属しているかもしれない。共有されたブランド名よりも署名された責任分担表の方がはるかに価値がある。
4月の番号資源は移行中の運用を示す
Spidernet のネットワークフットプリントは、稼働開始のシーケンスとして読み取れるほど新しい。APNIC は2026年4月7日に組織ORG-SCS6-APを登録した。4月17日に AS154632 を登録。4月20日に162.4.2.0から162.4.3.255、512 IPv4 アドレスを含むポータブルな/23を割り当てた。レジストリレコードはアクティブであり、Spidernet のドメイン、住所、連絡先詳細を使用している。
アドレス割り当てから数時間後、1つのより具体的なルートが現れた。RIPE NCC の162.4.2.0/24のルーティングステータス履歴は、2026年4月20日16:00 UTC に AS151988 によって発信されたこのプレフィックスを初めて観測した。7月12日の観測時点では、RIPE RIS サンプルの326の全 IPv4 フルテーブルピアに可視化されていた。ROA 検証では、AS151988 がその/24を発信するための有効な認可が確認された。
これらは意味のあるコントロールである。ポータブルアドレス空間は、Spidernet に単なるウェブホスティングアカウントから借りたものではないアドレス資産を与える。有効なルート認可は、偶発的または不正な発信の一形態を減少させる。グローバルな可視性は、そのルートが僅かなネットワークにしか見えないローカルな実験ではなかったことを意味する。アクティブな/24は、測定されたインターネット上でルーティング目的地として到達可能だった。
限界も同様に具体的である。RIPEstat の AS154632 ビューは、7月12日時点で最初のルートも最後のルートも、IPv4 または IPv6 アドレス空間も、観測されたネイバーも示さなかった。そのアナウンスされたプレフィックスリストは空だった。別のCIDR レポートも同様に、この ASN はアナウンスされておらず、トランジット AS として可視化されていないと記述していた。
したがって Spidernet は自律システムを保有していたが、それを可視的なルート発信元として使用していなかった。同社のライブプレフィックスは Go2Cloud Solutions Private Limited の AS151988 によって発信されていた。Spidernet の割り当てのもう半分の162.4.3.0/24はグローバルテーブルで可視化されなかった。スナップショットでは Spidernet の ASN に関連付けられた IPv6 プレフィックスはなかった。
このパターンは完全に正当な場合がある。顧客が自前のルーターを準備する間、トランジットまたはホスティングプロバイダーにポータブル空間の発信を依頼することがある。プロバイダー管理の BGP を好むかもしれない。必要なアドレスだけを意図的にアナウンスするかもしれない。予備の/24を拡張、移行、または第2のサイトのために予約しているかもしれない。このパターンが証明できないのは、AS154632 が独立したトランジットを持つこと、未使用の/24が待機機器に設定されていること、または障害後に第2のデータセンターがそれをアナウンスできることである。
運用ステータスの結論は「何も存在しない」でも「クラウドネットワークが完全に稼働している」でもない。Spidernet の1つのプレフィックスはライブで、グローバルに可視化され、適切に認可されていた。Spidernet 自身のルーティング ID は休眠状態だった。これは若い、あるいはプロバイダー依存のネットワーク構成のように見え、現在のネットワーク設計がそうでないことを示すまで、そのように評価されるべきである。
1つのライブプレフィックスが1つの可視化されたプロバイダーチェーンに従う
アクティブなプレフィックスはまた、どこで管理が Spidernet を離れるかを明らかにする。Hurricane Electric の AS151988 ビューは発信元を Go2Cloud Solutions Private Limited と特定し、162.4.2.0/24を Spidernet Cloud Solutions のアドレス空間としてリストしている。RIPEstat の AS151988 スナップショットは、そのネットワークが3つの IPv4/24を発信し、IPv6 ルートがなく、観測されたネイバーが1つであることを示した。
Spidernet のプレフィックスに対する公開ルッキンググラスパスでは、最後の2つのネットワークは一貫して AS18229 に続いて AS151988 だった。AS18229 は CtrlS のものである。言い換えれば、ルートコレクタは Go2Cloud が Spidernet プレフィックスを発信し、CtrlS を通じてより広いインターネットに直接到達しているのを観測した。CtrlS より上流のパスはさまざまであったが、プレフィックスに最も近い可視エッジは変わらなかった。
これはネットワークの証拠であり、所有権の宣言ではない。BGP パスは、どの企業がサーバーを所有しているか、誰がクロスコネクトの費用を支払っているか、どのような商業契約が存在するか、どの建物にルーターがあるかを明らかにしない。プライベートなバックアップセッションが設定されているが非アクティブかどうかも示さない。示しているのは、サンプリングされたすべてのパブリックルートが発信元として AS151988、その直接の上流として AS18229 に依存していたことである。
このチェーンは少なくとも3つの異なる障害の疑問を生じさせる。第一に、Spidernet は発信元プロバイダーとの契約が停止、誤設定、または更新されなかった場合に事業を継続できるか。第二に、CtrlS の接続や関連ルーターに障害が発生した場合、Go2Cloud は別の上流に到達できるか。第三に、BGP が健全であってもデータセンターの問題で顧客サービスは存続できるか。ルートテーブルはこれらのいずれにも冗長性をもって答えない。
ポートフォリオの主張が問題を曖昧にすることがある。CtrlS は実質的なデータセンターおよびネットワーク事業者であり、Go2Cloud は管理サーバーやクラウドインフラを公に販売している。その能力が自動的に Spidernet のための2サイト設計に移行するわけではない。有能な施設内の単一の仮想マシンは単一の仮想マシンのままである。大規模キャリアを通じたルートは、同じワークロードに対して別の独立してテストされたエッジが存在しない限り、1つの可視エッジにとどまる。
AS154632 も AS151988 も、チェック時にSpidernet 用の PeeringDB APIやGo2Cloud 用の PeeringDB APIにパブリックネットワークプロファイルを持っていなかった。PeeringDB は任意であるため、不在はエンジニアリング不良の証拠ではない。しかし、分散フットプリントを裏付ける施設、交換ポイント、トラフィック規模、相互接続ポリシー、ネットワーク運用連絡先の運用者管理の公的なインベントリが存在しないことを意味する。
購入者は Spidernet にグローバルバックボーンの運用を求める必要はない。正直なサービス境界が必要だ。もしすべてのトラフィックが1つのサイトの1つのプロバイダーを経由するなら、サービスは単一プロバイダーサービスとして価格設定され、バックアップされ、契約されるべきだ。Spidernet が冗長トランジットを主張するなら、第2の上流を明示し、第2の BGP パスを示し、生き残るキャパシティを述べ、物理的な入口と電源経路が分離しているか説明すべきだ。
割り当てられたアドレスは利用可能なクラウドキャパシティではない
/23の割り当ては魅力的な見出し数字を生み出す：512の IPv4 アドレス。これは512の販売可能なサーバー、512のアクティブな顧客、あるいは512の利用可能なホストアドレスと同じではない。ネットワークおよびブロードキャストの慣例、ゲートウェイ割り当て、インフラ機器、アビューズ制御、顧客のサブネット化が利用可能空間を減少させる。より重要なことに、7月12日のスナップショットでは1つの/24のみがルーティングされていた。
256のルーティングされたアドレスでさえ、コンピュートについてほとんど語らない。プロバイダーは1つのアドレスの背後に多数のウェブサイトを置いたり、1つのファイアウォールに複数のアドレスを割り当てたり、将来の顧客のためにアドレスを予約したり、空のサブネットをルーティングしたりできる。逆に、プライベートアドレスが割り当てられた仮想マシンは小さなパブリックエッジの背後に位置することがある。IP アドレスの数はプロセッサコア、メモリ、ストレージ、I/O 性能、オーバーサブスクリプションを開示しない。
外部からの測定は乏しい。IPinfo の Spidernet プレフィックスページは、範囲を同社および AS151988 と関連付けたが、最近の ping スキャンに応答したホストはなく、ホストされたドメインも報告しなかった。ホストは意図的に ICMP をブロックすることができ、ドメイン帰属はプライベートまたは新たに展開されたサービスを見逃す可能性がある。これらの否定的な観測結果は空のネットワークを証明しない。公的データが実質的なアクティブな顧客基盤を実証していないことを補強するだけである。
同社自身の販売サイトも新しいブロックの証拠にはならない。チェック時点で、spidernet.net.inはHostinger の AS47583に関連付けられた82.180.143.143に解決され、Spidernet のポータブル割り当てには向かわなかった。メールエクスチェンジは Rediffmail Pro を指し、権威 DNS はサードパーティのネームサーバーを使用していた。企業ウェブサイト、メール、DNS をアウトソーシングすることは普通である。それは単に、それらのサービスが新しいネットワークの使用を証明するワークロードとして数えられないことを意味する。
設置済みキャパシティは複数の層で測定されなければならない。アドレス層では、1つの/24がグローバルルーティングに設置され、1つはそうでなかった。ルーティング層では、同社自身の ASN はアクティブな発信元として設置されていなかった。サーバー層では、パブリックなホスト数やハードウェアインベントリは利用できなかった。ストレージ層では、生のまたは利用可能な容量は公開されていなかった。復元力の層では、顧客データの現在のコピーを保持する第2のサイトの証拠はなかった。
利用可能なキャパシティはさらに小さい。20台のサーバーを搭載したラックは、すべてが満杯であるか、退避用の予備ホストがないか、ストレージ再構築が残りの I/O マージンを消費する場合、20台分の安全な顧客キャパシティではない。第2のトランジット回線は、通常のピークを搬送できない場合、利用可能な冗長性ではない。バックアップは、復元が一度も計時されていない場合、利用可能なリカバリキャパシティではない。Spidernet はこれらの使用率やヘッドルームの指標を一切公開していない。
これにより経済性が不透明になる。低コストホスティングはしばしばハードウェア、帯域幅、サポート労働力をプールすることによって機能する。プールすることは本質的に悪い慣行ではなく、多くのクラウドコンピューティングの基盤である。リスクは、プロバイダーが予備リソースを保持せずに弾力性や復元力を販売するときに現れる。顧客は、支払う料金が予約された割り当てなのか、フェアシェアプールなのか、ベストエフォートサービスなのか、他社からの管理インスタンスなのかを知る必要がある。
各製品は異なる障害パスを持つ
Spidernet のサービスメニューはクラウドというラベルの下にいくつかのワークロードをグループ化しているが、それらの復旧要件は異なる。サーバーが維持されているという一般的な保証では、これらすべてをカバーできない。
ホストされたデータベースにとって、重大な問題はトランザクション境界である。1日1回取得されるサーバースナップショットは、ほぼ24時間分の変更を失う可能性がある。レプリケートされたデータベースは損失を減らせるが、それはレプリカが最新で、同じストレージ障害から隔離され、伝播する誤削除から保護されている場合に限る。データベースホスティングページは PostgreSQL、MySQL、SQL Server に言及し、マネージドサービスを説明しているが、復旧ポイント目標、復旧時間、バージョンサポート、レプリケーション設計、バックアップ保持、エクスポート形式は提供していない。
メールは異なる依存関係チェーンを持つ。受信メッセージは DNS、メールエクスチェンジレコード、アドレスレピュテーション、アンチスパムシステム、ストレージ、アカウント認証に依存する。ストレージ障害は古いメールにアクセスできなくする一方、新しいメールは他でキューイングされ続ける可能性がある。DNS エラーは配送を迂回させ、乗っ取られたアカウントはスパムを送信し、共有アドレスのレピュテーションに損害を与える可能性がある。Spidernet のメールホスティングページは専用サーバーとスパムフリーの環境を主張するが、メールボックスクォータ、冗長性設計、ジャーナリング、保持、認証基準、継続性方法、復旧目標を提供していない。
ファイルホスティングはビジネスレコードを共有ストレージに集中させる。可用性はディスクの冗長性だけでなく、メタデータ、ID サービス、権限、プライマリ障害ドメイン外の破損していないコピーに依存する。Spidernet のファイルホスティングページは共有クラウドファイルシステムの一般的な考え方を説明しているが、ファイルがどこに存在するか、ストレージがレプリケートされているか、バージョンがどのように保持されるか、削除された素材がどのように復旧されるか、大規模なデータセットをどれだけ早くエクスポートできるかを明記していない。
ERP および Tally ホスティングはセッションとライセンスの依存関係を追加する。スタッフはパブリックインターネット経由でリモートデスクトップやアプリケーションサーバーに到達するかもしれない。ルートが失敗すると、基礎となるデータが無傷であっても、会計、在庫、給与、注文処理が停止しうる。ソフトウェアの更新はハードウェア障害と同じくらい破壊的になり得る。ERP ページは実装とサポートを約束し、Tally ページは標準的なバックアップとデータ保護に言及している。いずれもアプリケーションのバージョン、ライセンス責任、メンテナンスウィンドウ、ユーザー同時実行数、データベース所有権、バックアップ頻度、復元テスト、またはローカル運用への復帰経路を特定していない。
ウェブサイトホスティングは、顧客がコード、データベース、DNS を管理していれば再作成が容易かもしれない。プロバイダーが現在のデータベース、証明書鍵、ドメイン認証情報を保持する唯一の当事者である場合、困難になる。Spidernet のウェブサイトホスティングページは、Spidernet のプランスケジュールではなく、商用ホストを選択するための導入である。ストレージ、トラフィック、ランタイム、コントロールパネル、バックアップ、セキュリティ、可用性の仕様を一切提供していない。
共通の教訓は、「バックアップ」と「クラウド」は復旧設計ではないということだ。各製品は、名前付きの損失単位、テスト済みの復元シーケンス、それを開始する権限を与えられた担当者を必要とする。5分のルート障害、死んだマザーボード、破損したストレージ、ランサムウェアイベント、サプライヤー契約の終了は、異なる対応を必要とする。
ラック、電力、部品は隠れた基盤のまま
Spidernet 所有のデータセンター、あるいは162.4.2.0/24を提供するパートナー施設を特定した公開情報源はなかった。Go2Cloud と CtrlS を経由するルートは相互接続が存在する場所を示唆するかもしれないが、BGP は顧客ハードウェアの位置を特定できない。ジオロケーションデータベースは有用な手がかりとなり得るが、建物レベルではしばしば誤りがある。責任ある結論は、物理的な場所は未検証のままであるということだ。
名称付きサイトがなければ、電力の復元力を評価できない。本格的な施設スケジュールは、ユーティリティ給電、無停電電源装置、発電機トポロジー、燃料自律性、メンテナンスバイパス、注文されたサーバーまたはラックへの A/B パスを記述するだろう。それは、デュアルコードサーバーの両方の電源が別々の配電チェーンに到達するかどうかを説明するだろう。Spidernet はこれらのいずれも公開しておらず、クラウドホスティングの一般的な説明はこれに代われない。
冷却も同じ不透明さを持つ。部屋の冷却、ラックのエアフロー、またはローカルファンが故障したために、サーバーはスロットリングまたはシャットダウンしつつ給電され続ける可能性がある。高い外気温、保守ミス、密集したラックがヘッドルームを奪うことがある。顧客は実際の部屋に結びついたアラーム、動作範囲、対応計画を必要とする。そのようなデータは Spidernet の提案について公開されていない。
ハードウェア在庫は小規模プロバイダーにとって特に現実的な制約である。仮想化は、互換性のあるキャパシティを持つ別のホストがあり、共有ストレージが利用可能である場合にのみ、故障したホストからゲストを移動させることができる。専用サーバーは同じ方法でライブマイグレーションできない。交換は、在庫のあるディスク、電源、メモリ、コントローラー、または完全な予備シャーシに依存する。同社はハードウェアカタログ、在庫ポリシー、交換目標を公開していない。
サーバーメンテナンスページは、コンポーネントが劣化し、ダウンタイムを減らすにはメンテナンスが必要であることを認めている。しかし、メンテナンスを一般的な計画として枠付け、再び Surchi Infotech を名指ししている。Spidernet が顧客サーバーを監視しているのか、サポートがリモートかオンサイトか、どの時間帯がカバーされるか、何が緊急事態を構成するか、技術者がどれだけ早くラックに到着できるかを述べていない。
修理窓口はしたがって第一級のサービス機能である。「24/7」はしばしば単にチケット提出を説明するために使われ、保証された介入ではない。顧客は応答時間、診断時間、現地アクセス時間、部品配送時間、復旧時間を区別すべきである。週末や祝日がそれぞれの目標を変更するかどうかを尋ねるべきだ。施設運営者がリモートハンズを提供する場合、Spidernet がどのようにエスカレーションし、誰が緊急作業の費用を支払うかを契約書に明記すべきである。
計画メンテナンスにもルールが必要だ。ファームウェア、ハイパーバイザー、ネットワーク、電力、冷却のメンテナンスはすべてリスクを伴う恐れがある。成熟したサービスは通知期間、停止日、最大期間、作業中の冗長性、顧客の異議申し立て権を明示する。Spidernet の公開サイトはメンテナンスカレンダー、ステータスページ、サービスレベルスケジュールを提供していない。
サポートの集中は障害を長時間の停止に変え得る
公開されている連絡窓口は狭い：電話番号1件、一般的なメールアドレス、郵便住所。APNIC のレコードは1名の管理および技術担当者を特定している。これは組織に連絡するには十分だが、スタッフが配置されたオペレーションセンター、オンコールローテーション、または別個のエスカレーションパスの証拠ではない。
サポートの集中は、インシデントの最初の数分間が診断に充てられるため、重要である。顧客は、アプリケーションエラーとストレージ障害、ルート撤回、期限切れライセンス、枯渇したディスク、請求停止を区別できる人物を必要とする。すべての問題が1つの一般的な受信箱から始まる場合、プロバイダーは内部で適切なオペレーターを呼び出す方法を必要とする。そのような構造は公開されていない。
別のネットワークがアドレスブロックを発信する場合、連鎖はさらに長くなる。接続性インシデントは、顧客が Spidernet に連絡し、Spidernet が Go2Cloud に連絡し、Go2Cloud が施設または上流に連絡することを要求するかもしれない。各当事者は独自の深刻度定義と証拠要件を持つかもしれない。顧客が提供する traceroute だけでは不十分な場合があり、上流はルーターログを欲しがるかもしれず、施設は許可された連絡を待つかもしれない。契約境界で分単位の時間が積み重なる。
プロバイダー契約の失敗は機器の故障よりも大きな損害を与え得る。請求書が争われたり、再販業者アカウントが停止されたりすると、ハードウェアが健全であってもサーバーとルートが消える可能性がある。Spidernet のプレフィックスが現在 AS151988 によって発信されているため、継続性はそのアナウンスを維持または移管する権利に依存する。ポータブルアドレスは、Spidernet が認証情報、ルートオブジェクト、認可、そしてそれを喜んでアナウンスする別の準備のできたネットワークを持っている場合にのみ助けになる。
請求条件は Spidernet サイトに公開されていない。猶予期間、停止手順、解約後のデータ保持期間、払い戻しルール、紛争中のエクスポートアクセスの約束は見当たらない。顧客はこれらの保護を推測すべきではない。特にアクセスが停止した瞬間に緊急となる会計やメールのワークロードについては、注文書でこれらを入手すべきである。
同じことはアビューズ苦情にも当てはまる。ホスティングネットワークはスパム、スキャン、侵害されたウェブサイト、違法コンテンツに関する報告を受け取る。プロバイダーは広範なネットワークを保護するためにアドレスを null ルーティングしたり、サーバーを停止するかもしれない。顧客契約は通知、調査、緊急措置、不服申し立てを明記すべきである。APNIC はアビューズメールボックスをリストしており、これは有用な運用連絡先だが、メールボックスだけでは誤ったまたは悪意のある苦情がどのように処理されるかを定義しない。
リカバリには同じラック内の2つ目のコピーではなく第2の障害ドメインが必要
公開証拠はマルチサイトキャパシティの主張を支持しない。Spidernet の未使用の162.4.3.0/24は最終的に別の展開をサポートできるかもしれないが、アナウンスされていないサブネットはリカバリサイトではない。同様に、同じストレージアレイ内の別のディスクにあるバックアップはアレイ障害を生き残れない。同じ部屋内のレプリカは電力や冷却の喪失を生き残れないかもしれない。1つのプロバイダーを共有する2つのネットワークセッションはそのプロバイダーの障害を生き残れない。
最小限の復元力設計は障害ドメインから始まる。ビジネス影響がそれらの障害からの保護を要求する場合、プライマリとリカバリのコピーは同じホスト、ストレージコントローラー、ラック電源、部屋、アクセスルーター、施設を共有すべきではない。リカバリサイトへのネットワークパスは独立して到達可能であるべきだ。リカバリサイトをアクティブにするために必要な ID および DNS サービスは、障害が発生したサイトだけに依存すべきではない。
リカバリ目標は数値でなければならない。復旧ポイント目標（RPO）はどれだけのデータが失われ得るか、復旧時間目標（RTO）はサービスがどれだけ長く利用不可であり得るかに答える。これらはバックアップ頻度と同一ではない。毎時間取得されるバックアップでも、プロバイダーがプロセスを一度もリハーサルしたことがないか、予備ハードウェアが不足している場合、復元に2日かかるかもしれない。
NIST の緊急時計画ガイダンスは、事業影響分析、予防的統制、リカバリ戦略、必要に応じた代替サイト、テスト、継続的なメンテナンスを推奨している。連邦情報システム向けに書かれているが、このシーケンスはあらゆる購入者に有用である。それは「バックアップを取っている」を、何が保護され、どのように復帰し、誰がそれが機能することを証明するのかという一連の質問に変える。
Spidernet にとって、決定的な証拠は日付入りの復元報告書であろう。それは、隔離されたコピーから復元された代表的なデータベースまたはアプリケーション、失われたデータ量、経過時間、リカバリ場所で利用可能なキャパシティ、手動ステップを示すべきだ。ネットワークテストは、プライマリの発信元構成なしでリカバリエンドポイントが到達可能であることを示すべきである。結果は公開される必要はないが、真剣な顧客にはレビューが許可されるべきである。
顧客はまた自身のエクスポートを保持すべきである。データベースダンプ、メールアーカイブ、ファイルシステムスナップショット、アプリケーション構成、DNS ゾーン、ライセンスレコードは、文書化された形式で取得可能であるべきだ。暗号鍵は故障したプロバイダーなしで利用可能でなければならない。エクスポート間隔はビジネスの許容度を反映すべきであり、復元は Spidernet の環境外のどこかでテストされるべきである。
データポータビリティは技術的な統制であると同時に経済的な統制でもある。安価に参入できるが退出にコストがかかるサービスは、顧客を価格上昇や弱いサポートに固定する可能性がある。契約書はエクスポート帯域幅、料金、支援、形式、タイミング、退出後の削除を明記すべきである。公開された製品ページのいずれもこれらの条件を提供していない。
地域性は未解決であり、一部の顧客は無視できない
Spidernet は APNIC のインド地域に登録され、ニューデリーの連絡先を提示している。ライブルートはインドの組織を通過する。これらの事実のいずれも、顧客データ、バックアップ、サポートアクセスがインドに留まることを証明しない。IP 登録国は管理的属性であり、サーバールームの座標ではない。プロバイダーはインドのアドレス空間を別の都市や国にルーティングすることができ、管理チームはサーバーにリモートアクセスできる。
同社のホストされたデータベース、ファイル、メール、ERP、Tally の提案は、個人情報、財務情報、運用情報を含み得る。したがって購入者は、プライマリサイト、バックアップサイト、ログストレージ、サポートアクセス場所、サブプロセッサーをリストしたデータ所在地スケジュールを必要とする。「インドのクラウド」は、デリーの電話番号からの推測ではなく、名前付きの国へのコミットメントを意味すべきである。
インドの法的立場もまた、データローカリゼーションという大まかなスローガンよりも具体的である。2023年デジタル個人データ保護法は段階的な施行であり、中心的義務は異なる日付に発効する。それはすべてのワークロードがインドに留まらなければならないという単純な一律ルールを作成するものではない。顧客はクラウドという言葉に頼るのではなく、自らの役割とデータに関して、該当する時点で施行されている条項を評価しなければならない。
セクター別のルールはより狭く、より厳しい場合がある。インド準備銀行の決済システムデータに関する2018年の指示は、対象となるシステムプロバイダーに対し、決済システムに関連するデータ全体を、外国取引レグの定められた取り扱いを前提として、インド国内のシステムにのみ保存することを要求している。この要件は規制された決済の文脈に適用され、自動的にすべての Spidernet 顧客に適用されるわけではない。ホストされたデータベースや ERP を検討している決済システム参加者は、不特定の場所を受け入れることはできない。
運用上の義務も関連する。CERT-In のサイバーセキュリティ指示ページは、インシデント報告、時刻同期、ログ保持、加入者検証を含む、サービスプロバイダー、データセンター、VPS プロバイダー、クラウドプロバイダーに影響する要件をリンクしている。指示そのものは、記録とインシデント対応に真の重要性を置いている。購入者は、必要なログをどの当事者が保持するか、それらがどこに保存されるか、クロックがどのように同期されるか、誰がインシデントを報告するかを尋ねるべきである。
Spidernet はホスティングサービスについて、データ処理契約、サブプロセッサーリスト、場所リスト、保持スケジュール、インシデント通知条件を一切公開していない。そのプライバシーページは異なるドメインと会社を名指ししている。現在の契約が不足情報を提供するまで、データ主権の証拠は弱いままである。
顧客にとっての障害の様相
公的記録に特定の Spidernet の停止は見つからなかったが、主な障害パスは理論上のものではない。
ラックまたはホストの障害は、まずその機器上の仮想マシンまたは専用サーバーに影響するだろう。顧客はフリーズしたセッション、利用不可能なウェブサイト、データベースタイムアウトを目にするかもしれない。復旧は、予備のコンピュート、ストレージの整合性、およびワークロードを別の場所で再起動できる技術者またはオーケストレーションシステムに依存する。公開されたホスト退避設計なしには、顧客は自動移動を前提にできない。
上流またはルート発信元の障害は、健全なサーバーを到達不能にするだろう。アクティブなプレフィックスは AS151988 によって発信され、AS18229 を通じて可視的に出ているため、いずれかの境界でのエラーがパブリックアクセスを奪う可能性がある。同じプレフィックスとパスを使用する第2のアプリケーションコピーは同時に失敗するかもしれない。復旧には、別のアナウンス、別のプロバイダー、異なるアドレス、DNS 変更、または顧客がすでに設定したアプリケーションレベルのフェイルオーバーが必要になるだろう。
ストレージまたはバックアップの障害はより静かかもしれない。アプリケーションは動作し続けるがバックアップが停止し、削除や破損イベントまで弱点が発見されない。顧客はその時点で、名目上の保持が不完全であるか、復元認証情報が欠落していることを知る。唯一の信頼できる防御は、監視されたバックアップ完了と定期的な復元テストである。
サポートの障害は他のあらゆるイベントを長引かせる。権限のある担当者が応答しない場合、10分のハードウェア操作が数時間の中断になる。再販業者が上流のチケットを待たなければならない場合、優先度はそのサプライヤーとの契約に依存する。したがって顧客向け応答目標は、単に Spidernet の確認時間ではなく、プロバイダーチェーンを含むべきである。
請求または契約の障害は突然サービスを奪う可能性がある。自動更新エラー、争われた利用量、ライセンス期限切れ、上流のアカウント残高が停止を引き起こすかもしれない。顧客は通知ラダー、緊急連絡先、猶予期間、読み取り専用エクスポート権を必要とする。財務記録とメールについては、アクセスの喪失がデータが物理的に失われる前に法的および運用上の結果を生む可能性がある。
移行の障害は、それ以外は計画された退出中に顧客を閉じ込める可能性がある。データベースのバージョンが異なるかもしれず、メールアーカイブは不完全かもしれず、ファイル権限がマッピングされないかもしれず、Tally 環境はホストが保持する構成やライセンスに依存しているかもしれない。関係が健全なうちに移行パスをリハーサルすべきである。
影響を受けるのは購入者の IT チームだけではない。従業員は会計や ERP セッションを失うかもしれない。顧客は注文をしたりメッセージを受け取れなくなるかもしれない。仕入先は発注書を受け取れないかもしれない。財務スタッフは申告や照合の期限を逃すかもしれない。小さなホストされたワークロードが驚くほど大きなビジネスプロセスの上に座っていることがある。
購入者が求めるべき証拠
Spidernet へのデューデリジェンス要求は、公開されたギャップが明らかであるため簡潔にできる。
第一に、契約を特定すること。注文書には、法的な契約相手方、税務詳細、準拠条件、サービス場所、施設運営者、ネットワーク発信元プロバイダー、およびあらゆるクラウドまたはハードウェアサプライヤーを明記すべきである。Surchi Infotech への言及を解決し、どのプライバシーおよび責任条件が実際に適用されるか述べるべきである。
第二に、資産を特定すること。プロバイダーは顧客が共有ホスティング、仮想マシン、マネージドクラウドインスタンス、専用サーバー、コロケーションのいずれを受け取るかを述べるべきである。プロセッサ、メモリ、ストレージクラス、ネットワークコミットメント、アドレス割り当て、オーバーサブスクリプションポリシーをリストすべきだ。専用機器については交換部品の目標を提示すべきだ。仮想サービスについては退避キャパシティを述べるべきだ。
第三に、障害ドメインを特定すること。購入者はプライマリサービスとリカバリコピーのための都市と施設、ならびに電力、冷却、ストレージ、ネットワーク分離の説明を受け取るべきである。2つのサイトが存在するという声明は、両方が1つの発信元構成に依存しているか、レプリケーションが一度もテストされたことがない場合、不十分である。
第四に、リカバリを定義すること。契約には復旧ポイントおよび復旧時間目標、バックアップ頻度、保持、不変性、暗号化、復元テスト、顧客エクスポートを含めるべきである。クレジットは、プロバイダーがサービスがどのように復帰するかを説明した後にのみ有用である。小さなクレジットは失われたアカウントやトランザクションを回復しない。
第五に、運用を定義すること。スケジュールにはサポート時間、深刻度レベル、確認および介入目標、エスカレーション連絡先、メンテナンス通知、緊急メンテナンス権、インシデント報告、インシデント後レビューを提示すべきである。Spidernet のアクションと施設または上流サプライヤーによって実行されるものとを区別すべきである。
第六に、ネットワークを証明すること。Spidernet が自律性を提供するために AS154632 を意図しているなら、いつ ASN がルートを発信し、どの上流がそれを提供し、フェイルオーバーがどのようにテストされるかを示すべきである。プロバイダー発信ルーティングが恒久的なモデルであるなら、ポータブル/23の移管および緊急発信手順を文書化すべきである。IPv6 の可用性は想定ではなく明示されるべきである。
最後に、退出をテストすること。本番使用前に、顧客はデータをエクスポートし、独立した環境に復元すべきである。テスト DNS 名を移動し、ユーザーアクセスを検証し、転送時間を測定し、必要な認証情報を記録すべきである。この演習は、修復する時間がまだあるうちに隠れた依存関係を発見する最も明確な方法である。
ライブプレフィックスはスタートであり、耐障害性証明ではない
Spidernet Cloud Solutions は、時代遅れのウェブサイトだけが示唆するよりも多くの運用証拠を持っている。APNIC は同社に組織レコード、自律システム、ポータブル IPv4 空間を発行した。その空間の半分は割り当てから数時間以内にグローバルに可視化され、7月12日のルーティングスナップショットでも有効な ROA と共に完全に可視化されたままであった。これらはネットワークサービスへの真のステップである。
しかし、可視化された設計は狭い。AS154632 はアクティブではなかった。1つの/24は Go2Cloud の AS151988 を通じてアナウンスされ、その唯一の観測された直接ネイバーは CtrlS の AS18229 だった。もう一方の/24はルーティングされていなかった。第2のサイト、第2の発信元、IPv6、新しいブロック上のアクティブなホストドメイン、施設レベルの復元力、予備ハードウェア、テスト済みのリカバリを確立する公的な証拠はなかった。
商用ページは、それらのギャップを埋めることなく主張を拡大している。それらはいくつかの重要なビジネスワークロードを宣伝するが、古く、クロスブランドの説明を提供し、現在のサービススケジュールはない。場所、ハードウェア、サポート、バックアップ、退出に関する沈黙は、それらの能力が存在しない証拠ではない。それは、署名された仕様書に現れ、テストされるまで顧客がそれらに依存できないことの証拠である。
Spidernet は新しいネットワークを構築中であるか、意図的にプロバイダー発信モデルを使用しているか、インフラが公的に測定できない顧客にサービスを提供している可能性がある。公正な証拠グレードは「弱い」であり、新しいポータブルリソースと有効なライブルートに対する肯定的な注記がある。アップグレードパスは単純明快である：運用境界を公開または開示し、ASN 戦略をアクティブ化または説明し、第2の障害ドメインを証明し、顧客が復元し退出できることを示すこと。それまでは、クラウドの提案は無名のラック、1つの可視トランジットチェーン、および Spidernet の公開境界を部分的に超えて制御される修理窓口に依存したままである。