要約
- CyrusOne は、データセンター、コロケーション、ハイパースケールインフラストラクチャの依存関係としてカバーできます。その公開ページはサービスサーフェスと企業コンテキストを説明しています。
- 主要な運用上の問いは、施設の責任がどこで終わり、顧客のワークロードの責任がどこから始まるかです。特に、電力、スペース、物理的セキュリティ、ネットワーク設計、データローカリティ、監視、復旧計画に関してです。
ディレクトリリンク:cyrusone-llc
データセンター依存関係が不可視のインフラではない理由
ソフトウェアチームは、クラウドや SaaS サービスが物理インフラストラクチャの上に浮かんでいるかのように語ることがよくあります。データセンタープロバイダーは、その抽象化を再び可視化します。CyrusOne のデータセンター、ソリューション、コロケーション、ハイパースケール、ビルド・トゥ・スーツのサービスカテゴリに関する公開ページは、デジタルサービスの基盤となる物理的および運用上の基盤に関するプロフィールをサポートします。会社概要とリソースのページがコンテキストを追加し、お問い合わせと採用情報のページは、サービスサーフェスを支える運用組織を示しています。
重要な境界は責任です。データセンタープロバイダーは、施設スペース、電力、冷却、物理的セキュリティ、運用プロセス、および関連するインフラサービスを提供する場合があります。顧客は依然として、アーキテクチャ、アプリケーション、冗長モデル、監視、バックアップ、インシデント対応を選択します。ハイパースケールまたはコロケーションの取り決めでは、この境界は複雑になる可能性があります。施設が機能している間に顧客のワークロードが失敗することがあります。顧客のシステムが適切に設計されていても、施設レベルのイベントが重要になることがあります。
これが、CyrusOne に関する記事が単なる不動産プロフィールになるべきではない理由です。運用上の問題は、施設の決定がどのようにソフトウェアの信頼性の決定になるかです。場所、電力設計、ネットワークアクセス、物理的制御はすべて顧客のリスクを形成しますが、アプリケーションエンジニアリングに取って代わるものではありません。
共有責任としてのコロケーション
コロケーションは、すべての顧客に施設全体を所有させることなく物理インフラを提供するため、魅力的です。顧客が機器を設置し、ネットワークに接続し、ハードウェアの選択を制御し、独自のデータセンターを構築することを避けるのに役立ちます。CyrusOne のコロケーションページはそのカテゴリをサポートしています。
残された作業は重要です。顧客は、どの機器を設置するか、どのように接続するか、リモートアクセスをどのように保護するか、どのように監視するか、どのように交換するか、ハードウェアや接続が失敗した場合にどのように復旧するかを決定する必要があります。プロバイダーは建物と関連施設サービスを管理するかもしれませんが、顧客自身のシステムは依然としてアーキテクチャとメンテナンスを必要とします。
成熟したコロケーションプランには、リモートハンドの前提、アクセス手順、予備機器戦略、ネットワーク冗長性、バックアップ場所、文書化、エスカレーションルールが含まれます。これらがなければ、コロケーションは誰も迅速に変更できない重要な機器で満たされた遠隔の部屋になる可能性があります。ポイントはコロケーションが弱いということではありません。安全に使用するためのコストを計上しなければならないということです。
ハイパースケールとビルド・トゥ・スーツが賭け金を変える
ハイパースケールとビルド・トゥ・スーツのページは、異なる運用レンズを作り出します。大規模な顧客は、厳しい容量、レイアウト、接続性、または成長要件に合った施設を求める場合があります。公開ページは、これらのサービスカテゴリが企業サーフェスに存在することを示すことができます。特定の顧客のビルドの詳細を確立するわけではありません。
依存関係が大きければ大きいほど、事前のコミットメントの証拠が重要になります。顧客は、納期、電力、冗長性、アクセス、コンプライアンス、ネットワークオプション、将来の拡張に関する前提をテストする必要があります。また、出口戦略と継続計画も必要です。施設の選択はソフトウェアの世代よりも長く続く可能性があります。そのため、調達プロセスは不動産交渉だけでなく、運用上の決定となります。
ハイパースケール依存関係は集中リスクも生み出します。顧客は、カスタマイズされた環境にインフラを集中することで効率を得るかもしれません。地域、プロバイダー関係、または施設レベルの前提が変わると、エクスポージャーが増加する可能性もあります。正しい答えは、マルチサイト設計、ハイブリッドクラウド計画、またはプロバイダーの混合かもしれません。各選択肢はコストと調整を追加します。
データローカリティと証拠のギャップ
データ主権とローカリティは、物理的な場所がデータセンターの決定の中心であるため、この記事に含まれます。しかし、データセンターのページだけでは、顧客のコンプライアンス態勢を証明することはできません。購入者は、システムがどこにあるか、バックアップとログがどこに行くか、誰が機器にアクセスできるか、どのネットワークがデータを運ぶか、契約が義務について何を言っているかを理解する必要があります。
同じ区別が施設のセキュリティにも当てはまります。公開企業ページはサービスやソリューションを説明するかもしれませんが、顧客の管理が正しいことを証明するものではありません。顧客は依然として、アイデンティティ、アプリケーションアクセス、暗号化、ロギング、インシデント対応を管理します。施設のセキュリティが強固でもソフトウェアの管理が弱い場合や、ソフトウェアの管理が強固でも物理的な依存関係が十分に文書化されていない場合があります。
したがって、公開 CyrusOne 情報源の適切な使用は、サービスと依存関係のカテゴリを特定することです。より強い主張にはより強力な証拠が必要です。顧客の開示、監査済み資料、技術文書、契約、または測定されたパフォーマンスなどです。
ステータス、リソース、運用記憶
リソースページは購入者がプロバイダーのフレーミングを理解するのに役立ちますが、顧客は独自の運用記憶が必要です。どの施設またはサービスがどのワークロードをサポートしているか?どのチームがプロバイダーに連絡できるか?どの変更に事前通知が必要か?どの監視信号が施設の問題を明らかにするか?どのワークロードを別の場所に移動できるか?これらは運用記録であり、マーケティング成果物ではありません。
企業はデータセンタープロバイダーに何年も依存する場合があります。スタッフが変わり、アーキテクチャが進化し、文書化が陳腐化します。依存関係は、それを選んだ人々が去った後も残ります。これが、データセンターの関係に定期的な見直しが必要な理由です。かつてワークロードに適合していたプロバイダー関係も、成長、コンプライアンスの変更、新しい顧客要件、またはクラウド戦略のシフトの後には再評価が必要になる場合があります。
電力と容量の表現も慎重に扱う必要があります。データセンターの顧客は当然両方を気にしますが、公開ソリューションページは測定された可用性や特定のホールの契約と同じではありません。購入者には、エンジニアリングの証拠、法的コミットメント、運用連絡先、前提が変わった場合の計画が必要です。その証拠がなければ、容量は公表された結論ではなく、計画トピックのままです。
物理的アクセス制御はもう一つの共有境界です。プロバイダーは施設アクセス手順を運用するかもしれませんが、顧客が自社の機器に誰が触れるか、リモート作業を誰が承認するか、どの変更が文書化されるか、緊急アクセスがイベント後にどのようにレビューされるかを決定します。顧客の内部記録が弱ければ弱いほど、後の障害が施設の状態、顧客の機器、ネットワーク設計、または手続き上のミスのどれによって引き起こされたかを知ることが難しくなります。
出口計画は施設関係において特に重要です。なぜなら、インフラの移動はソフトウェアのサブスクリプション変更よりも遅いからです。顧客は、新しいスペース、クロスコネクト、ハードウェアの出荷、データ同期、契約の重複、並行テストの期間を必要とする場合があります。これらのステップは、最初の展開前に理解されるべきであり、プロバイダー関係が緊張したときだけではありません。離脱のコストは参入のコストの一部です。
これにより、施設依存関係はエンジニアリング問題と同様に管理問題になります。最高の技術設計でも、契約所有者、ネットワークチーム、アプリケーション所有者、セキュリティレビュー担当者が責任のマップを共有していなければ失敗する可能性があります。公開ページはプロバイダーのサーフェスを特定します。顧客はそのマップを提供する必要があります。
競争と代替手段
CyrusOne は、他のデータセンター事業者、クラウドプロバイダー、コロケーション企業、内部施設、エッジプロバイダー、ハイブリッド設計と競合しています。各代替手段は制御とコストを変えます。パブリッククラウドは施設管理を削減しますが、プラットフォームと価格設定の依存関係を生み出します。内部施設は制御を増やしますが、資本、人員、専門的な運用を必要とします。マルチプロバイダー設計は集中を減らしますが、より複雑なアーキテクチャ、監視、契約を必要とします。
経済的テストは、単にラック価格、電力価格、契約サイズではありません。施設選択、ネットワーク設計、ハードウェアライフサイクル、セキュリティレビュー、アクセス管理、復旧計画を計上した後の、信頼性のあるワークロードあたりのコストです。データセンタープロバイダーは、重要なインフラストラクチャをより専門的でスケーラブルにすることができます。顧客の回復力アーキテクチャを決定することはできません。
ソフトウェアリーダーにとっての実践的な教訓は、施設の証拠をサービス設計の近くに保つことです。アプリケーションがデータセンターの選択に依存する場合、その依存関係はアーキテクチャレビュー、継続計画、ベンダーリスクノートに現れるべきです。そうでなければ、物理層は危機のときだけ戻ってきます。それを理解する時間が最も少ないときです。
未証明のまま残ること
公開情報源セットは、CyrusOne の非公開顧客リスト、施設容量、稼働時間、電力可用性、持続可能性結果、セキュリティ成果、インシデント記録、収益、または特定のハイパースケールビルドの詳細を確立しません。これらの事実はより強力な証拠を必要とします。この記事はそれらを公開サービスページから推測すべきではありません。
有用な結論は情報源に束縛されています。CyrusOne は、その公開ページがデータセンター、コロケーション、ハイパースケール、ビルド・トゥ・スーツのインフラサービスを説明しているため、クラウドサービス依存関係の対象に属します。すべての購入者にとって未解決の質問は、プロバイダーの施設責任が顧客自身のアーキテクチャ、監視、ガバナンス、復旧作業にどのように接続するかです。
画像の境界と帰属
注目の画像は、一般的な編集用コンテキストとしてのみ使用される実際の Wikimedia Commons のサーバーインフラストラクチャ写真です。CyrusOne、その施設、スタッフ、顧客、機器、電力システム、ネットワーク状態、インシデント、またはサービス品質を示すものではありません。この記事の主張は、引用された CyrusOne の公開ページに基づいており、画像から得られたものではありません。
出典
- https://www.cyrusone.com/
- https://www.cyrusone.com/data-centers
- https://www.cyrusone.com/solutions
- https://www.cyrusone.com/solutions/colocation
- https://www.cyrusone.com/contact
- https://www.cyrusone.com/company
- https://www.cyrusone.com/company/about-us
- https://www.cyrusone.com/resources
- https://www.cyrusone.com/solutions/hyperscale
- https://www.cyrusone.com/solutions/build-to-suit
- https://www.cyrusone.com/company/careers

