お客様のストーリー
"概要" モジュールでは、Tailwind Traders のストーリーを紹介しました。 Tailwind Traders の集中運用チームとプラットフォーム チームは、会社の既存データセンターの管理経験が豊富です。 データセンターのうち 2 つを Azure に移行するプロジェクトが進行中ですが、その中で、社内の現在のスキル セットでは対応できないクリティカルな学習曲線がいくつか、既に明らかになっています。
重要な制約
現時点で、ビジネスは、移行と、データセンターからの移行および時間的制約を満たすことを重視しています。 このようなビジネスの優先順位があるので、ビジネス チームと IT チームは、コア クラウド プラットフォームの開発が完了するまで、長期的なセキュリティとコンプライアンスの要件の優先順位を下げました。
Tailwind Traders はクラウドを初めて利用するため、運用、プラットフォーム、IT 管理の各チームにはクラウドの経験があるメンバーがほとんどいません。 会社は、最新の運用、セキュリティ、ガバナンスに徐々に移行したいと考えていますが、それらの重要度が高まっているため、ニーズに合わせてスケールできるクラウド基盤が必要です。
Tailwind Traders はこれまで集中運用の観点から運用してきました。 その結果、ワークロード チームは運用環境とやりとりすることができません。 会社には資産 (仮想マシン、データ、アプリ) を定義済みのワークロードにマップする簡単な方法がないので、各ワークロードの境界が不明確になることがあります。
Azure ランディング ゾーンに合わせた調整
運用チームとプラットフォームのチームは、次のような調整に同意しました。
- Azure ランディング ゾーンの概念アーキテクチャは、クラウド環境の将来の状態に対する長期的なビジョンとして機能します。 影響を受けるすべてのチームは、クラウド スキルの構築とクラウド環境の構成の基礎としてそのアーキテクチャを使います。
- チームは、環境の構成を開始するために Azure ランディング ゾーン アクセラレータを使用します。
- チームは将来的に環境をカスタマイズする必要が出てきた場合は、初期のアクセラレータベースのデプロイに合わせた、またはそれを拡張するカスタム実装オプションのいずれかを使います。
標準的な Azure ランディング ゾーンのガイダンスからの逸脱
次の一覧では、制約によって Tailwind Traders が Azure ランディング ゾーンの設計原則からどのように逸脱したか、また各決定が及ぼす影響について概説します。
ポリシー主導のガバナンス: Tailwind Traders は、これまで企業ポリシーを自動化していませんでした。 データセンターを迅速に移行する必要があるというプレッシャーがあるため、同社はランディング ゾーンの初期デプロイに含め、ガバナンスの量を最小限に抑えることを選択しました。
また、同社は、初期環境を構成した後、クラウド導入フレームワークのガバナンス手法に関する Learn モジュールを完了することにも取り組みました。 クラウド移行に専念する IT スタッフの制限は、この逸脱の大きな要因です。 本格的なクラウド ガバナンス (つまり "Azure Ops") に対するビジネスと IT の抵抗がこの逸脱をさらに助長します。
サブスクリプションの民主化: 中央運用チームは、すべてのワークロードに対して運用の説明責任を負います。 そのチームがワークロード チームに運用環境へのアクセス権を付与することはほとんどないため、サブスクリプションの民主化の設計原則には従っていません。
ワークロード チームが逸脱を要求する場合、中央運用チームは、ケースバイケースで個々の各ワークロード専用ランディング ゾーンを検討します。 そうでない場合、Tailwind Traders は集中運用の維持を厳守し、分離された運用環境 (つまりアプリケーション ランディング ゾーン) にワークロードのインスタンスを制限します。
アプリケーション中心のサービス モデル: 停止関連のプロセスでは、特にミッションクリティカルなワークロードをサポートする資産については、ワークロードを考慮する場合があります。 ただし、停止を除くと、集中運用チームは、運用管理プロセスについて、ワークロードかアプリケーションかを区別しません。 そのチームの主なプロセスは、ワークロードの境界またはアーキテクチャに関係なく、すべてのリソースを同じ方法で運用、管理、変更、最適化することです。 この移行に関する時間の制約を考えると、Tailwind Traders チームがアプリの境界を定義し、アプリ中心のサービス モデルを確立することは現実的ではありません。
上記の一覧にある多くの用語については、この Learn モジュールの次のユニットで説明します。 その一部については、学習するきっかけとなるように、注意事項に記載します。
これらの逸脱は、調整アグリーメントを損なうものではありません。 ただし、Azure ランディング ゾーン アクセラレータのデプロイ時に、これらの逸脱の影響を受けるオプションが存在します。 これらの逸脱は、資産をクラウドに移行し始めた後にデプロイする個々のアプリケーション ランディング ゾーンの設計にも影響があります。
また、このような逸脱がある場合、Tailwind Traders チームは、初期環境のデプロイ後に CAF の管理、セキュリティ、ガバナンスに関する Learn モジュールを完了する必要があります。
その他の制約
次の追加の制約は、Tailwind の決定に影響する可能性があります。
操作
集中運用チームでは、ポートフォリオ全体を管理するための一連のプロセスと統制を有機的に構築しました。 チームは、運用のベースラインに関して、System Center Operations Manager と Microsoft Configuration Manager に依存しています。
さらに、チームでは、ツールの中でも特に、仮想マシン管理、インシデントと構成管理の追跡、ネットワークの監視、セキュリティ運用、ガバナンス統制のための最適な組み合わせのツールを統合しています。 これらのツールのほとんどに Azure との統合が組み込まれており、会社のプライマリのクラウド プロバイダーとして Azure を使用するという決定に影響を及ぼしました。 これらのツールの運用には、スタッフの労力と資本がふんだんに必要です。
運用ツール
(ハイパーバイザーを含む) 運用管理ツールのライセンスが、20% を超える IT の固定費用予算を占めています。 新しい最高情報責任者 (CIO) は、チームに、これらのツールとプロセスを再評価してクラウドファーストまたは統合運用の代替案を見つけるよう求めました。 この CIO は、この移行の成功の早期指標として、ツールへの支出の削減を注視していくとみられます。
運用プロセス
IT マネージャーから、集中運用チームのサポート要員として 2 人の新規採用の要望がありました。 この要員は、重圧にさらされていたチームの負荷の軽減に役立つでしょう。 特に、事業継続とディザスター リカバリー (BCDR) のプラクティスとパッチ コンプライアンス プロセスをサポートすることになります。
ビジネスは、特にミッションクリティカルなアプリケーションについて、クラウドネイティブ運用への全面移行の準備ができていません。 CIO は、クラウドネイティブの運用ツールに投資すれば、それらの責務の一部がクラウド プロバイダーに移管され、集中運用チームの負担を軽減できると考えています。
CIO は、運用の移管による従業員満足度の向上と、集中運用チーム全体の負荷軽減を注視していくとみられます。 さらに、導入計画が BCDR とパッチ適用の作業に及ぼす影響について、頻繁な近況報告を要求するとみられます。
サービス レベル アグリーメント
運用に関わるすべての多大な労力と費用にもかかわらず、プライマリ データセンター内のミッションクリティカルなシステムについて、90% のアップタイム サービス レベル アグリーメント (SLA) をチームが満たせない事態が定期的に発生しています。 これは、CIO と最高経営責任者 (CEO) にとって代償が大きい懸念事項です。 データセンターでは、古くなったハードウェアや期限切れの更新サイクルが原因で、短時間の停止が頻繁に発生しています。
会社ではこの SLA を不本意ながら受け入れてきましたが、新しい CIO は快く思っていません。 財政面の削減効果とは別の問題として、CIO は移行後にもっと高い水準の SLA を集中運用チームが達成することを期待しています。
小売イノベーション
"概要" モジュールの顧客のストーリーでは、Tailwind Traders 社内の小売イノベーション チームを紹介しました。 このチームは元々、Tailwind Traders によって買収されたスタートアップ企業でした。 スタートアップ企業の元の CEO は現在、Tailwind の最高技術責任者 (CTO) です。 その CTO は現在もスタートアップ企業のように部門を運営しており、実験とイノベーションを優先しています。
運用管理の現在のプロセスでは、このチームが発案した新しいイノベーションはすべて、リリース プロセスを通過する必要があります。 IT 部門内の集中運用チームは、セキュリティ、ガバナンス、運用管理上の懸念に関してアーキテクチャをレビューします。 チームがソリューションに満足すると、ソリューションが、集中管理される運用環境にリリースされます。 クラウドでもこのプロセスは継続すると想定されています。
ID 管理
Tailwind Traders のデータセンター全体で、Active Directory は ID ストアであり、認証とアクセス制御のためのプライマリ ツールでもあります。 同社では、いくつかのシステムを最適に組み合わせて、ID を多要素認証ソリューションに拡張してきました。 また会社では、Microsoft 365 ソリューションをデプロイするために ID のフェデレーションを使用してきました。 以上を踏まえてなお、Active Directory が Tailwind Traders で ID を管理する手段です。
クラウドによって、会社は Microsoft Entra ID やサービスとしてのインフラストラクチャ (IaaS) インフラストラクチャで実行される Microsoft Entra Domain Services などのその他の選択肢も持つようになりました。 集中運用チームでは、選択肢を比較して、自社のクラウド導入計画に最適な ID ソリューションを選ぶのに苦労しています。
ネットワーク トポロジと接続
Tailwind Traders では、マルチプロトコル ラベル スイッチング (MPLS) 回線を使用して自社データセンターと実店舗を接続しています。 すべてのインターネット トラフィックは、"じょうご" のようにプライマリ データセンターを通過します。 2 つのデータセンター間のインターネット プロトコル (IP) 競合により、トラフィックは分離され、ルーティングは複雑なルーティング テーブルに依存しています。 データセンターまたは会社オフィスへの外部接続は、仮想プライベート ネットワーク経由で提供されています。 この接続は制限されており、推奨されていません。
プライマリとセカンダリのデータセンターには、明確に管理され、整理された、一貫性のある IP アドレス スキーマがあります。 3 番目のデータセンターには、ほとんど一貫性がなく、整理やセグメント化に向けた明確な計画がない、50 の異なる IP ブロックが含まれています。 継続的イノベーションのサイクルは 3 番目のデータセンターに限定されていますが、クラウドへのネットワーク トポロジとルーティングの定義で問題が発生するおそれがあります。
リソースの編成
各データセンター間のリソースのセグメント化では、ワークロードの各コレクションを資産の大きなブロックとして扱っていました。 次に、各コレクションをリスク プロファイルによって分割し、分離および統制されたセグメントを作成して、ワークロード間では限られたネットワーク フローしか許可しないようにしていました。 保護されていないネットワークからのイングレス ネットワーク接続を必要とするワークロードは、各データセンターの 1 つまたは複数の境界ネットワーク セグメントに分離されます。
その基本構成を超えた部分では、構成管理データベースに不整合があるため、どの資産がどのワークロードに関連付けられているかの判別が困難です。 ワークロードの所有者およびインシデント エスカレーション チェーンは、ミッションクリティカルなワークロードに対しては明確に定義されていますが、他のほとんどのワークロードには存在しません。
クリティカルでないワークロードについては、Tailwind Traders の元従業員が所有者として特定されることがよくあります。 多くの場合、もう使用されていない仮想マシンが構成マッピングで参照されます。 同様に、30% を超えるサポート対象の資産は、単一のワークロードに明確にマップされていません。 会社には、移行の間に、依存関係分析と適切なリソース編成が確実に行うための手法が必要です。