Centre of server systems Ltd は、ラック、トランジット、修理ウィンドウに依存するホスティング容量を販売

要約

• Centre of server systems Ltd は検証可能なインターネット ID を持っている。RIPE RDAP は AS201009 を SUPPORTIT-AS として登録し、RIPEstat は 2026年7月14日に AS がアナウンスされていることを示し、可視のアナウンススペースはロシアの IPv4 プレフィックス 109.248.237.0/24 である。
• 同社の Support IT ページ（https://supportit.ru/およびhttps://supportit.ru/...）は、サーバー・ネットワーク管理、データベース管理、ホスティング、サーバー設置、Tier III データセンター内の自社ラック、高速チャネル、24 時間監視を説明しているが、静的ホスティングページの最終更新は 2015 年であり、現在の容量監査ではなく古い公的表明として扱わなければならない。
• 公開ルーティング証拠は公開商業証拠よりも強い。RIPEstat は 1 つの IPv4 プレフィックス、IPv6 プレフィックスなし、326 の IPv4 RIS ピアのうち 325 がルートを確認、2 つの観測されたネイバー、109.248.237.0/24 の RPKI ステータス不明を報告した。一方、PeeringDB は AS に関する交換または施設記録をリストしていなかった。
• 証拠グレードは、ネットワーク ID と現在のルート可視性については中程度だが、ホスティング容量、設備の回復力、電力、予備ハードウェア、モスクワ/ロシアのシグナルを超えたデータローカリティ、顧客の復旧については弱い。依存する事業者は、自社のサービスがどこにあり、どのようにルーティングされ、どのようにバックアップされ、ラック、上流、サポートデスク、修理ウィンドウが失敗したときに何が起こるかを検証すべきである。

企業は可視だが、容量は同じようには可視ではない

Centre of server systems Ltd は、SUPPORTIT-AS の背後にある組織として公開インフラ記録に現れている。RIPE の RDAP レコード（https://rdap.db.ripe.net/autnum/201009）は AS201009 を SUPPORTIT-AS として命名し、アクティブとマークし、Centre of server systems Ltd に関連付ける。組織レコード（https://rdap.db.ripe.net/エンティティ/ORG-COSS2-RIPE）は同じ会社名とモスクワの住所を提供する。割り当てられた IPv4 ネットワークレコード（https://rdap.db.ripe.net/ip/109.248.237.0/24）は 109.248.237.0 から 109.248.237.255 を SUPPORTIT-NET、国 RU として識別し、Centre of server systems Ltd を指名する remark が含まれている。

これらのレコードは実際に機能する。同社を、単なるリセラーのショーウィンドウにすぎない一般的なホスティングブランドから区別する。登録された AS とルーティングされた /24 は、オペレーターが少なくとも可視のルーティング ID、公開アドレスブロック、および上流ネットワークまたはルート仲介者との関係を持っていることを意味する。RIPEstat の AS 概要（https://stat.ripe.net/data/as-overview/data.json?resource=AS201009）は、照会時点の 2026年7月14日に AS がアナウンスされていると報告した。そのアナウンス済みプレフィックスエンドポイント（https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201009）は、同時に終了する 2 週間のウィンドウで 109.248.237.0/24 を可視プレフィックスとして示した。

公開企業サイトが商業的なストーリーを提供する。ランディングページ（https://supportit.ru/）は Support IT をシステム・ネットワーク管理、データベース管理、ホスティングとサーバー設置、テクニカルサポートのプロバイダーとして提示する。サーバーとネットワークを管理サービスの責任範囲として説明し、ハードウェア・ソフトウェアのメンテナンス、障害診断、耐障害性機器の選定と購入、セキュリティ作業と監査を挙げている。データベースセクションは Oracle、MS-SQL、MySQL、PostgreSQL を挙げている。サポートセクションは 24 時間対応で、インシデントは継続的なケース記録を通じて処理されると述べている。ページはカスタマー入口（https://supportit.ru/otrs/customer.pl）にリンクしており、その HTTP ヘッダーはこのレビュー中に OTRS カスタマーログインページを返した。

ホスティングの主張はより具体的だが、より古い。ワンページのランディングセクションは、同社が Tier III データセンター内に自社ラック、高速チャネル、24 時間監視、設置とサービスへの個別アプローチ、2 つの 2015 年の通信ライセンス番号、仮想サーバーの低月額料金、物理サーバーの低月額料金を持っていると述べている。別の静的ページ（https://supportit.ru/...）は、より conventional なサイトシェルで同じテーマを繰り返している。Tier III データセンター内の自社ラックへのサーバー設置、高速チャネル、回復力のあるホスティング組織、24 時間監視、2015年2月5日付の 2 つのライセンス番号。HTTP ヘッダーは 2015年2月13日の最終更新タイムスタンプを示した。

そのタイムスタンプが読み方を変える。古いホスティングページは、サイトが構築されたときに同社がどのようにインフラを位置づけたかったかを示す有用な証拠である。2026年7月に同じラック、施設グレード、監視範囲、ライセンスステータス、価格設定、予備ハードウェア、顧客在庫が存在するという現在の証明ではない。より新しいように見えるインデックスページ（https://supportit.ru/index.html）は 2019年3月に最終更新され、同じサービスメニューを公開し続けているが、読者に現在の製品在庫、公開ステータスページ、日付入りのインシデント記録、データセンター名、施設住所、ネットワーク図、バックアップポリシー、サポート範囲メトリクスを提供していない。

それが中心的な区別である。企業は可視である。ルートは可視である。公開サイトは自社のアドレス空間から到達可能である。カスタマー入口は可視である。しかし、販売可能なホスティング容量は同じように可視ではない。在庫のある公開プラングリッド、日付入りの可用性レポート、施設証明書、公開メンテナンスアーカイブ、アクティブな顧客の表明、古いページの低価格がまだ適用されるという証明はない。慎重な買い手は、Centre of server systems Ltd を、不完全な公開運営開示を持つ運用インフラエンティティとして扱うべきであり、製品カタログから容量を評価できるクラウドプラットフォームとして扱うべきではない。

資産は小さく、具体的で、モスクワ中心である

公開記録の中で最も具体的な資産は単一の IPv4 /24 である。RIPEstat のプレフィックス概要（https://stat.ripe.net/data/prefix-overview/data.json?resource=109.248.237.0/24）は、109.248.237.0/24 が AS201009 によってアナウンスされ、ホルダーは SUPPORTIT-AS Centre of server systems Ltd であると報告した。RIPEstat のルーティングステータスエンドポイント（https://stat.ripe.net/data/routing-status/data.json?resource=AS201009）は、1 つの IPv4 プレフィックス、256 の IPv4 アドレス、ゼロの IPv6 プレフィックス、ゼロの IPv6 スペース、2 つの観測されたネイバー、および 2026年7月14日の照会時点で 326 の IPv4 RIS ピアのうち 325 からの可視性を報告した。これは 1 つのプレフィックスとしては健全なルート可視性シグナルである。同時に狭いフットプリントでもある。

狭いフットプリントは重要である。/24 は多くのサービスをホストできるが、大規模なクラウドリージョンではない。公開ウェブサイト、DNS、メールシステム、カスタマーサーバー、管理ホスト、サポートツールを運ぶことができる。それだけではラック数、物理的多様性、バックアップの分離、顧客がプロバイダー自身の運用からセグメント化されているかどうかを示すことはできない。同じ /24 にプロバイダーのウェブサイト、DNS ホスト、サポートシステム、顧客ワークロードが含まれている場合、顧客はそのアドレススペース、上流経路、境界設定、施設ファブリックに問題が発生したときに何が起こるかを尋ねなければならない。

DNS 証拠はフットプリントをより具体的にする。RIPEstat の DNS チェーンエンドポイント（https://stat.ripe.net/data/dns-chain/data.json?resource=supportit.ru）は、supportit.ru が 109.248.237.96 に解決され、権威ネームサーバーが cns1.supportit.ru、cns2.supportit.ru、cns3.supportit.ru であることを示した。cns1 のクエリ（https://stat.ripe.net/data/dns-chain/data.json?resource=cns1.supportit.ru）は、cns1.supportit.ru が 109.248.237.69 に解決されることを示した。OTRS サポートホストのクエリ（https://stat.ripe.net/data/dns-chain/data.json?resource=otrs.supportit.ru）は、otrs.supportit.ru が 109.248.237.87 に解決されることを示した。ローカル DNS チェックでも supportit.ru の A レコード 109.248.237.96、AAAA レコードなし、同じドメイン内の Support IT ネームサーバー、メール用の Google メール交換器が返された。

これらの観測は 2 つの結論を支持する。第一に、Support IT のウェブおよびカスタマーサポートの表面は、観測された経路上でサードパーティの CDN によって単にフロントされているわけではない。それらは同社に関連付けられた同じルーテッドアドレスブロック内に存在する。これは汎用コンテンツ配信プロバイダーにのみ解決されるサイトよりも強力なインフラ証拠である。第二に、公開されている制御面は同じ /24 内に集中しているように見える。これは小規模プロバイダーとしては正常かもしれないが、依存性の問題を引き起こす。プレフィックスがフィルタリングされた場合、AS がルート可視性を失った場合、プロバイダーの DNS ホストが利用できなくなった場合、顧客チケットシステムが到達不能になった場合、顧客はサービス到達性とサポートへの最も簡単な経路の両方を失う可能性がある。

地理位置情報シグナルもロシア、具体的にはモスクワを指しているが、施設監査ではない。RIPEstat の地理位置情報エンドポイント（https://stat.ripe.net/data/geoloc/data.json?resource=109.248.237.0/24）および MaxMind ビュー（https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=109.248.237.0/24）は両方ともプレフィックスをロシア・モスクワに位置付けた。IPinfo の認証なしページ（https://ipinfo.io/109.248.237.96）も AS201009 Centre of server systems Ltd とモスクワを識別した。これらはトラフィックと登録インフラが存在するように見える場所を示す有用な地域シグナルである。実際のフロア、ケージ、キャビネット、電力供給、または顧客ワークロードのバックアップ場所を証明するものではない。

したがって、同社は特定のカテゴリに位置する。小さいながらも実際のアドレスおよびルーティング資産を持つインフラサポート・ホスティングプロバイダーである。これはそれ自体では弱点ではない。多くの回復力のあるニッチプロバイダーはコンパクトなネットワークを運用している。問題は、コンパクトなネットワークは冗長性の明示的な証拠を要求することである。単一の IPv4 /24 は適切にエンジニアリングされている場合もあれば、脆弱な場合もある。違いは物理的多様性、ルートポリシー、監視、バックアップ、人員、顧客の退出オプションにある。公開記録は /24 とモスクワのシグナルを確認する。残りを確認するものではない。

自己申告のホスティングの約束は古く、グレードダウンが必要である

Support IT の公開コピーは物理的依存性について異常に率直である。ホスティングセクションは抽象的なクラウドを販売していない。同社は Tier III データセンター内に自社ラック、高速チャネル、24 時間監視、サーバー設置とサービスへの個別アプローチを持っていると述べている。この表現は、ホストされたサーバーが実際に必要とするもの、すなわちラックスペース、電力、冷却、ネットワークアクセス、リモートハンズ、監視、サポートに直接マッピングされる。

したがって、古いページは有用だが、証拠のグレードダウンが必要である。エンコードされたホスティング URL のページは 2015 年の最終更新日を示した。初期の商業パンフレットのように見えるスタイルで書かれていた。短いサービス説明、ライセンス番号、電話番号、Skype、メール、カスタマー入口リンク。メインページは 2019 年に最終更新され、同じ主張を維持し、さらに多くのサービスカテゴリを追加している。どちらのページも現在の日付、現在のデータセンター事業者、現在の価格表、アクティブな注文リンク、契約条件、SLA テキスト、メンテナンス通知、ルートポリシーページ、公開サービスステータスページ、またはアップタイム履歴を示していない。

古いプロバイダーページは真実のままである場合も、部分的に真実になる場合も、削除されずに歴史的になる場合もある。同社は 2015 年に宣伝したラックをまだ持っている可能性がある。施設を移転した可能性がある。上流を変更した可能性がある。物理サーバーの販売をやめてサポート契約のみにした可能性がある。リテールホスティングから少数のクライアント向け管理インフラに移行した可能性がある。内部またはプライベートの顧客ワークロードのみを保持した可能性がある。公開証拠はこれらの可能性の中から選択するものではない。正しい読み方はページを破棄することではなく、各容量主張を現在形の確認としてマークすることである。

ライセンスの参照も同じ扱いが必要である。Support IT ページは 2 つの 2015 年ロシア通信ライセンス番号をリストしている。公開ページは、同社がホスティングコピーにそれらの番号を表示したという記述を支持できる。それだけでは、ライセンスが依然として有効である、同じサービスをカバーしている、すべてのホストされたワークロードをカバーしている、または 2026 年のすべての顧客コンプライアンス要件に十分であるという記述を支持できない。規制データや通信エクスポージャーを持つ顧客は、現在のライセンス抽出、範囲、有効期限ステータス、およびサービス契約の背後にある正確な法的エンティティ関係を要求すべきである。

顧客ロゴページはさらに慎重さを要する。ランディングページと「私たちについて」ページ（https://supportit.ru/%D0%BE-%D0%BD%D0%B0%D1%81.html）はクライアントロゴギャラリーを表示し、同社の目標はパートナーがコアビジネスに集中し、専門スタッフが IT インフラサービスを処理できるようにすることであると述べている。これは貴重な公開ポジショニングである。現在の顧客リストではなく、サービスの推奨ではなく、ライブホスティングの証明ではなく、名前のある組織がまだ Support IT インフラを使用しているという証明でもない。唯一安全な推測は、Support IT がビジネスクライアント向けにアウトソーシング IT およびホスティングパートナーとして公にマーケティングしてきたことである。

連絡先ページ（https://supportit.ru/%D0%BA%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D1%8B.html）は、いくつかの方法で 24 時間年中無休で連絡可能であると述べている。OTRS エンドポイントはライブログインヘッダーを返した。この組み合わせは、2015 年のホスティングコピーよりも現在のサポートサーフェスの主張をより強く支持する。それでも、人員レベル、応答時間、エスカレーション権限、ハードウェア交換在庫、障害通知、または同じサポートデスクがホストサーバー、オフィス IT、データベース管理、ネットワークインシデントをカバーしているかどうかを証明するものではない。

買い手にとって、実際的な影響は単純である。プロバイダーに、現在の事実とレガシーブロシュアの事実を分離するよう依頼せよ。どのデータセンターが現在の顧客サーバーをホストしているか？ラックは所有、リース、または再販されているか？サイトはまだ Tier III 認証を受けており、誰によってか？どのリンクがアクティブか？どのサービスが 24 時間監視されているか？物理サーバー障害時のサポート目標は？仮想サーバーと物理サーバーは宣伝価格でまだ販売されているか？同社はまだ新しいホスティング顧客を受け入れているか？公開証拠はその会話を開始できるが、完了することはできない。

ルート可視性は到達可能性を証明するには十分だが、回復力を証明するには不十分である

AS201009 の現在のルート可視性は、多くの薄いフットプリントのホスティング名よりも優れている。RIPEstat はアナウンスされていることを示す。アナウンス済みプレフィックスエンドポイントは、現在の 2 週間ウィンドウで 109.248.237.0/24 を示す。ルーティングステータスエンドポイントは、照会時点でほぼ完全な IPv4 RIS ピア可視性を示す。Hurricane Electric の BGP Toolkit ネットワークページ（https://bgp.he.net/net/109.248.237.0/24）は、AS201009 を起点、Centre of server systems Ltd を登録者として指名し、範囲内の多くの DNS レコードをリストする。BGP.tools（https://bgp.tools/as/201009）は、ネットワークをアクティブとして識別し、1 つの IPv4 プレフィックス、IPv6 プレフィックスなし、2 つの上流、3 つのピアをそのビューに持つ。

これらは有用な確認である。ネットワークが登録されているだけでなく、公開ルーティングデータで見られていることを示す。RIPEstat の最強の現在のパスは、ほぼすべての IPv4 RIS ピアから /24 が見えることを示す。ルート履歴（https://stat.ripe.net/data/routing-history/data.json?resource=AS201009）は、109.248.237.0/24 を 2015 年から 2026 年 7 月までの長期にわたる起点ルートとして示し、初期の年に短命のより具体的な履歴と、2020 年の無関係に見える 46.8.152.0/24 タイムラインが 1 つある。長いルート履歴はサービス品質と同じではないが、ネットワークを新しく作成されたり散発的に可視な AS よりも一時的でないものにする。

限界も同様に重要である。RIPEstat の asn-neighbours エンドポイント（https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201009）は、最新の利用可能な 2026年7月14日の観測で 2 つの観測されたネイバー（AS12695 と AS9002）を報告した。RIPE whois ビュー（https://stat.ripe.net/data/whois/data.json?resource=AS201009）は、AS12695 と AS57304 の import および export エントリを示した。一方、as-routing-consistency エンドポイント（https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201009）は、AS12695 を BGP と whois の両方で、AS57304 を whois のみで、AS9002 を BGP のみで見つけた。この不一致は必ずしも危険ではないが、読者に 1 つのデータソースから完全に文書化されたトランジット設計を推測しないように伝える。

RPKI ももう一つの注意点である。RIPEstat の RPKI 検証エンドポイント（https://stat.ripe.net/data/rpki-validation/data.json?resource=201009&prefix=109.248.237.0/24）はステータス不明を返し、検証 ROA はなかった。不明は無効ではない。そのビューでルートが検証 ROA によって保護されていなかったことを意味する。小規模なホスティングネットワークにとって、RPKI ステータス不明はルートフィルタリングの規律、IRR オブジェクト、上流設定の重要性を高める。顧客が安定したアドレス到達可能性に依存する場合、プロバイダーが ROA を公開する予定があるかどうか、上流がプレフィックスをどのようにフィルタリングするかを尋ねるべきである。

PeeringDB も制約である。ネットワーク API（https://www.peeringdb.com/api/net?asn=201009）には、AS201009 の Centre of server systems ネットワークオブジェクトが含まれており、2021 年に作成され 2022 年に更新されたが、トラフィックレベル、開示された範囲、IX 数、施設数、ウェブサイト、ルックアップグラス、ルートサーバーを報告していない。netixlan エンドポイント（https://www.peeringdb.com/api/netixlan?asn=201009）は空のデータ配列を返した。netfac エンドポイント（https://www.peeringdb.com/api/netfac?net_id=26979）も空の配列を返した。これは同社に施設や相互接続がないことを意味するわけではない。多くの事業者は完全な PeeringDB プロファイルを維持していない。しかし、公開相互接続・施設証拠が弱いことを意味する。

結果は分割グレードである。ルート到達可能性は 1 つの IPv4 プレフィックスについては良好である。回復力証拠は薄い。公開記録は、AS201009 に物理的に独立した 2 つのルーター、2 つの独立したクロスコネクト、別々のミートミールーム内の 2 つの上流、多様なファイバーパス、予備のラインカード、テスト済みフェイルオーバー、DDoS スクラビング、ルート監視、24 時間 NOC 人員配置、顧客向けステータス通信があるかどうかを示さない。2 つの観測された BGP ネイバーは到達可能性を向上させる可能性があるが、施設の多様性や運用の独立性を自動的に証明するものではない。

依存する事業者にとって、ルートの質問は具体的であるべきである。今日、顧客プレフィックスを運んでいる上流はどれか？AS12695 と AS9002 は両方とも顧客のトラフィックにアクティブに使用されているか、それとも一部の観測パスにのみ現れるか？AS57304 はまだ契約パスか、歴史的な whois エントリか、間接的な関係か？アナウンスされたすべてのプレフィックスにルートオブジェクトがあるか？プロバイダーは RPKI ROA を公開する予定か？主要施設または 1 つの上流が故障した場合、DNS、サポート、顧客サービスは到達可能か？これらは学術的な質問ではない。ルーテッド /24 が回復力のあるプラットフォームであるか、単に公開到達可能性のある小さなアドレスブロックであるかを決定する。

施設と電力の主張は最も薄い公開証拠の背後にある

最も強い施設の声明は依然として自己申告のもの、すなわち Tier III データセンター内の自社ラックである。それは Support IT ページに現れ、ホスティングにとって重要な種類の主張である。ホストされたサーバーは、電力、冷却、物理的アクセス、ラック設計、上流ハンドオフ、スイッチファブリック、スペアパーツロジスティクスによって成否が決まる。同社が適切に回復力のあるデータセンター環境で自社ラックを実際に運用している場合、それは重要である。

問題は、公開記録が施設を特定していないことである。データセンター事業者、キャンパス、認証機関、部屋、都市、電力トポロジー、冷却設計、発電機配置、UPS 設計、クロスコネクトキャリア、リモートハンズ契約を命名していない。地理位置情報はモスクワを指す。組織住所はモスクワにある。ルートパスにはロシアの上流証拠が含まれる。DNS およびカスタマーサポートホストは 109.248.237.0/24 内にある。これらすべてがモスクワ中心の読み方を合理的にする。ラックが特定のモスクワ施設にあること、施設が現在 Tier III であること、すべての顧客ワークロードがそこにあることを証明するものではない。

電力は隠れた障害経路である。プロバイダーは、アナウンスされたプレフィックスと動作する DNS を持ちながら、1 つの電気室、1 つのラック PDU チェーン、1 つの発電機メンテナンスウィンドウ、または単一のオンサイト介入経路に依存している可能性がある。HTTP 到達可能性のみを監視している顧客は、サービスが停止した後にのみ障害を見ることになる。古い Support IT ホスティングコピーは、ラック、高速チャネル、監視に関連して「耐障害性」の表現を使用している。これは設計の願望として有用である。現在の公開証拠は、障害テスト、測定された可用性、電力インシデント、メンテナンス通知、バッテリー自律時間、発電機テスト結果、またはサービス信用条件を示さない。

ハードウェアは 2 番目の隠れた経路である。Support IT のページは仮想サーバーと物理サーバーの価格を宣伝しているが、現在のサーバータイプ、ストレージ設計、RAID ポリシー、ハイパーバイザープラットフォーム、バックアップシステム、スペアホスト、物理的在庫、交換タイミングを示していない。物理サーバーの提供は、シャーシ、ディスク、RAM、電源、ネットワークインターフェース、リモート管理アクセスに依存する。仮想サーバーの提供は、ホストのオーバーサブスクリプション、ストレージ冗長性、スナップショットポリシー、移行機能、ホスト障害時にサービスを復元できるスタッフに依存する。安価な物理サーバーまたは VPS プランは多くのワークロードに完全に適している可能性がある。リスクは、それを示さないブロシュアからエンタープライズの予備容量を想定することである。

監視は 3 番目の経路である。サイトは 24 時間監視を主張する。カスタマーサポートページは OTRS を示す。しかし、公開ステータス、インシデント履歴、エスカレーションポリシーがない監視は、外部者が適切に運営された NOC とアラートを見ている小さなサポートチームを区別することを不可能にする。正しい質問は監視が存在するかどうかではない。何が監視されているか、監視がどこにあるか、誰がアラートを受信するか、ネットワーク障害と顧客 OS 障害にどの応答時間が適用されるか、顧客が施設またはルートの劣化を検出したときに積極的な通知を受信するかどうかである。

Support IT はこれらの質問に強い答えを持っているかもしれない。公開記録は単にそれらを公開していない。だからこそ、この記事は同社を信頼できないと呼ぶべきではない。公開容量証拠が不完全であると呼ぶべきである。小規模プロバイダーは、限界を認識し、明確に通信し、顧客の復旧経路を正直に保つ場合、回復力を持つことができる。小規模プロバイダーは、顧客が動作する /24 と古いホスティングページを現在の冗長インフラの証明と誤解したときにリスクになる。

データローカリティはデータポータビリティよりも明確である

マニフェストは、ホスティング容量がグローバルに到達可能であるため、この記事をグローバルクラウドサービスカテゴリに分類している。しかし、証拠はロシア中心である。会社記録はロシア語。サイトはロシア語。住所と地理位置情報シグナルはモスクワを指す。可視のアナウンス済みプレフィックスは RIPE スペースと国 RU 内にある。DNS とサポートホストは会社のロシア /24 内に解決される。EU、北米、アジア太平洋、またはその他の非ロシア拠点のサーバーの公開証拠はない。

これはデータ主権にとって重要である。ロシア国外のユーザーは技術的にこのネットワークでサービスをホストまたは到達できるが、グローバル到達可能性はグローバルローカリティと同じではない。規制データを持つ顧客は、ウェブサイトが世界中から到達可能であるという事実からマルチリージョンオプションや外国データ居住を推測すべきではない。プロダクションサーバー、バックアップストレージ、ログ、監視システム、管理アクセスの物理的な場所を尋ねるべきである。また、サポートスタッフ、契約業者、サードパーティのメール/ヘルプデスクプロバイダーが顧客データにアクセスできるかどうかも尋ねるべきである。

supportit.ru の Google MX レコードは顧客データが Google に保存されていることを意味しないが、少なくともプロバイダーのドメインメールパスが Google ホストのメール交換器を使用していることを示す。OTRS カスタマー入口はプロバイダー自身のアドレス範囲にある。DNS ネームサーバーは supportit.ru の下にあり、同じ /24 に解決される。この混合は普通であるが、データローカリティが 1 つのオブジェクトではない理由を示している。メール、チケット、バックアップ、DNS、監視、ホストされたサーバーはそれぞれ異なる場所と法的エクスポージャーを持つ可能性がある。

データポータビリティはさらに可視性が低い。公開サイトは、仮想サーバーをエクスポートできるかどうか、物理サーバーの顧客がディスクイメージを受け取るかどうか、バックアップがプロバイダー管理かどうか、スナップショットがセルフサービスかどうか、解約後にデータがどのくらい保持されるか、紛争中に顧客がクリーンな復元アーカイブを受け取れるかどうかを説明していない。古いサービスの表現は個別アプローチを強調しているが、個別アプローチはポータビリティの保証ではない。小規模プロバイダーが関与する場合、最も安全な想定は、顧客が独自のバックアップを所有し、プロバイダー外部で復元をテストしなければならないことである。

DNS の集中は関連するポータビリティリスクを生み出す。顧客ドメインが 109.248.237.0/24 内の Support IT ホスト DNS を使用している場合、プレフィックスまたはネームサーバーの障害により、トラフィックを他の場所にリダイレクトすることが難しくなる。アプリケーションサーバー、サポートチケット、DNS がすべて同じネットワークに結び付けられている場合、顧客はバンド外の制御、すなわちレジストラ資格情報、外部監視、ネットワーク外の DNS オプション、ネットワーク外のバックアップストレージ、プロバイダーのカスタマーポータルに閉じ込められていない文書を必要とする。

より広いポイントは、クラウドサービス依存性はコンピュート依存性だけではないということである。それは ID、DNS、メール、チケット、バックアップ、資格情報、請求書、ライセンス、サポートである。Centre of server systems Ltd は、それらの依存性を可視にするのに十分な公開インフラを公開している。それらをデフォルトで安全にするのに十分な公開ポリシーを公開していない。

ホスティング経済学は魅力とリスクの両方を説明する

Support IT の公開価格言語は非常に低コストである。ランディングページはルーブルでの月額仮想サーバー価格と月額物理サーバー価格を挙げており、2015 年の静的ホスティングページは手頃さを提供の一部として位置づけている。低コストホスティングは価値がある。中小企業、代理店、ローカルサービス、内部ツールに、ハイパースケール価格を支払ったり、フルタイムのインフラスタッフを雇用したりせずに実行する場所を提供する。データベースの専門知識、ネットワーク管理、ローカルサポートを持つプロバイダーは、グローバルな抽象化よりも実用的なヘルプを必要とする組織にとって魅力的であり得る。

同じ経済性が、余裕のマージンを狭める。プロバイダーが安価なホスティング容量を販売する場合、すべての予備（スペアサーバー、未使用のラックスペース、追加の電力供給、セカンド上流、リモートハンズ契約、バックアップストレージ、追加スタッフ、時間外カバレッジ）にはコストがかかる。宣伝されたサーバーが安ければ安いほど、顧客はどの予備レイヤーが含まれ、どれが含まれていないかを明確に尋ねるべきである。低価格は欠陥ではない。価格設定されていない想定が欠陥である。

現在の証拠は、Centre of server systems Ltd が現代のリテールクラウドよりも、管理インフラおよびローカルサポートプロバイダーに近い可能性があることを示唆している。サイトはシステム管理、ネットワーク管理、データベース管理、サポート、個別サーバー設置を強調している。自動化されたクラウドコントロールパネル、API 駆動のプロビジョニング、公開オブジェクトストレージ、マルチゾーンアーキテクチャ、公開マシンタイプ、ライブ在庫、セルフサービス移行ツールを示していない。それは同社の価値を減少させるものではない。デューデリジェンスモデルを変える。顧客は同社をコモディティクラウドではなく、ハンズオンインフラパートナーとして評価すべきである。

公開ルート資産もそのモデルに適合する。1 つの /24 は、選択された顧客、DNS、メールリレー、ゲートウェイ、PBX システム、ウェブサイト、管理ホストをホストするフォーカスされたプロバイダーにとって十分である。Hurricane Electric の DNS タブ（https://bgp.he.net/net/109.248.237.0/24）は、範囲全体に多くの PTR および A レコードの関連付けを示し、プロバイダーのホスト名とサードパーティと思われるドメインを含んでいた。これらの DNS レコードは、空の割り当てではなく、居住されたアドレススペースを示唆している。どのホストが現在の顧客か、どれがレガシーレコードか、どれが内部サービスか、どれがまだトラフィックを運んでいるかを証明するものではない。DNS はシグナルであり、顧客名簿ではない。

したがって、経済的デューデリジェンスは平易であるべきである。顧客が非クリティカルなワークロードに対して単一の安価なサーバーを必要とする場合、重要な質問はバックアップ、サポート、退出である。顧客がプロダクションインフラを必要とする場合、質問は電力、上流、監視、インシデント通信、法的エンティティ、データ所在地、予備容量、復旧目標に拡大する。リセラーがプロバイダー上に構築したい場合、在庫、プロビジョニング速度、契約権限、滥用処理を検証しなければならない。同じプロバイダーがあるユースケースに適していて、別のユースケースに不適切である可能性がある。

システム障害時に影響を受けるのは誰か

影響を受けるのは直接のホスティング顧客だけではない。DNS レコードとサイトの主張は、より広範なサポート役割、すなわちネームサーバー、カスタマーチケット、ホストされたウェブサイト、メール関連名、PBX と思われる名前、ゲートウェイ、アプリケーションホストを指している。小規模プロバイダーのラック、上流、DNS、サポートスタックが障害を起こした場合、その影響は複数のレイヤーに同時に及ぶ可能性がある。エンドユーザーはウェブサイトがダウンするのを見るかもしれない。従業員は内部ツールを失うかもしれない。メール配信はキューイングされるかもしれない。顧客はサポートチケットを開けないかもしれない。管理者はサービス復旧に必要なシステムへのリモートアクセスを失うかもしれない。

その複合障害経路は小規模インフラ環境では一般的である。プロバイダーを有用にする同じ能力、すなわちサーバーからネットワーク、データベース運用まですべてを処理することは、共有された運用面も生み出す可能性がある。顧客は復旧経路のあまりに多くを同じプロバイダーにアウトソースするかもしれない。アプリケーションはそこにあり、バックアップはそこにあり、DNS はそこを指し、監視はそこにアラートを送り、ヘルプデスクはそこにある。プロバイダーがルートまたは施設の問題を抱えたとき、顧客は自分の脱出経路が影響を受けたシステム内にあることを発見する。

救済策はすべての小規模プロバイダーを避けることではない。コストが重要なところで独立性を設計することである。ドメインがクリティカルな場合、権威 DNS またはセカンダリ DNS をプロバイダー外部に維持する。バックアップを別のアカウントに保存し、復元をテストする。レジストラアクセスをプロバイダーメール外部に維持する。デプロイメント手順をホストサーバー外部に維持する。プロバイダーのネットワーク外部から監視する。どの IP アドレスがプロバイダー割り当てであり、移行中に変更しなければならないかを把握する。カスタマーポータルのみに依存しない直接のサポートエスカレーションパスを維持する。

Centre of server systems Ltd にとって、公開記録はいくつかの具体的なテストを妥当にする。顧客は割り当てられた IP をトレースし、現在の起点 AS を確認すべきである。シミュレートされた DNS 変更中に cns1、cns2、cns3 が到達可能なままであるかをテストすべきである。ワークロードが仮想ホストか物理サーバーか、交換パスが異なるかを尋ねるべきである。公開開示が不可能な場合、少なくとも NDA の下で現在のデータセンター名を要求すべきである。営業時間外にサポートがどのように人員配置されているか、OTRS ホストが到達不能な場合にインシデントがどのように通信されるかを尋ねるべきである。

プロバイダー自身の 24 時間サポート表現は有用だが、サポート表現は運用化されなければならない。オンコールは誰か？何がウェイクアップをトリガーするか？どの障害ドメインがプロバイダーの責任で、どれが顧客の責任か？管理データベース契約にはバックアップ検証が含まれているか？物理サーバー契約には一定時間内のディスク交換が含まれているか？サーバー設置にはパワーサイクルサポートが含まれているか？ネットワーク管理には DDoS 対応が含まれているか？これらの区別は、障害が短い修理ウィンドウになるか、長時間の停止になるかを決定する。

証拠グレードを上げ下げするもの

現在の証拠グレードはネットワーク ID については中程度である。なぜなら、複数の独立した公開情報源が AS、組織、プレフィックス、現在のルート可視性で一致しているからである。ホスティング容量については弱い。なぜなら、公開サイトは古く、施設の詳細は開示されておらず、PeeringDB には施設や IX のエントリがなく、アクティブな販売可能在庫や回復力テストを示す公開情報源がないからである。

グレードは、同社が現在のサービス、データセンターリージョン、Tier III ラックの主張がまだ適用されるかどうか、現在の上流、サポート時間、サービスステータスの可視性、バックアップオプション、顧客エクスポートオプション、インシデント通信を説明する日付入りのインフラページを公開した場合に向上する。AS201009 が 109.248.237.0/24 に対して現在の RPKI ROA を持っている場合に向上する。PeeringDB または他の公開相互接続記録が現在の施設および交換参加を示した場合に向上する。同社がホストされたサービスと同じ障害ドメイン外に顧客向けステータスページを公開した場合に向上する。

グレードは、AS201009 がルート可視性を失った場合、supportit.ru が割り当てられた範囲内での解決を説明なしに停止した場合、DNS と OTRS が長時間到達不能になった場合、同社が現在の連絡先パスを削除した場合、または公開記録がホストされたサービスに直接影響するライセンス、法的、または滥用処理の問題を示した場合に低下する。また、プロバイダーが 2015 年時代のホスティングページに依存し続けながら、現在の施設および復旧事実を顧客に確認することを拒否した場合にも低下する。

最も重要な注視点は AS の存在ではない。それは可視である。AS の背後にある運用境界である。1 つのルーテッド /24 は、効率的で注意深く管理された小規模ホスティング環境であり得る。また、DNS、サポート、顧客ワークロードの単一障害点にもなり得る。公開データはどちらかを決定しない。現在の運用証明が決定する。

依存する事業者への最終的な結論

Centre of server systems Ltd は、アクティブなモスクワ中心の公開ルートと、オンラインを維持している Support IT サービス面を持つ、現実の小規模インフラ企業として読まれるべきである。その証拠は、ディレクトリスタブよりも強く、完全に文書化されたホスティングプラットフォームよりは弱い。同社は、観測可能な AS、可視の /24、動作する自己申告のウェブおよびサポートエンドポイント、ラック、ホスティング、監視に関する古いが具体的な主張を持っている。現在の容量、ラック数、電力設計、ルート多様性、RPKI 保護、バックアップポリシー、ライブ顧客在庫、テスト済み復旧の公開証明は持っていない。

現在の顧客にとって、即時のタスクは検証である。割り当てられた IP 範囲、ルート起点、物理的または仮想的配置、バックアップ場所、DNS 依存性、サポートエスカレーションパス、復旧手順を特定する。プロバイダーの /24、DNS、またはサポートポータルが到達不能な場合に顧客が復旧できるかどうかを確認する。データを迅速にエクスポートできるかどうか、プロバイダー側のバックアップがホスティング環境から分離されているかどうかを尋ねる。

新しい買い手にとって、公開記録は無条件のプロダクション依存性には十分ではない。会話をサポートするが、それ自体で購入決定をサポートするものではない。現在のサービス可用性、施設場所、上流多様性、サポート範囲、ライセンスステータス、契約条件、バックアップオプション、インシデント通知、移行権利の声明を要求せよ。プロバイダーが正確な答えを提供する場合、小さなフットプリントは一部のワークロードに完全に受け入れられる可能性がある。プロバイダーが現在の事実を古いサイトコピーから分離できない場合、ホスティング提供を反証されるまでリスクとして扱え。

教訓は一社よりも広い。ホスティング容量は常に物理システム、すなわちラック、電力、ケーブル、ルーター、アドレス、DNS、サポートスタッフ、スペアパーツ、修理ウィンドウに戻る。Centre of server systems Ltd はそれらのレイヤーをミニチュアで示している。ルートは本物である。古いホスティングの主張は具体的である。欠けている部分は、主張の背後にある物理的および運用レイヤーが、顧客がそれらに置きたい依存性に対してまだサイズ設定され、人員配置され、冗長であるという現在の証明である。