設計の原則と高度な運用の適用
最初の 3 つのクラウド管理規範では、管理ベースラインについて説明しています。 ビジネスの中断を最小限に抑え、サービスが中断した場合に復旧を迅速化するために、管理ベースラインには、少なくとも標準のビジネス コミットメントを含める必要があります。 ほとんどの管理ベースラインでは、"インベントリと可視性"、"運用のコンプライアンス"、"保護と復旧" を維持することに規範的な重点を置いています。
管理ベースラインの目的は、サポート対象のすべてのワークロードに対して最小限のレベルのビジネス コミットメントが提供される一貫したオファリングを作成することです。 共通の繰り返し可能な管理オファリングのこのベースラインにより、チームは逸脱を最小限に抑えて、高度に最適化された運用管理を実現できます。 しかし、その標準のオファリングでは、充実した十分なビジネス コミットメントが提供されない場合があります。
次のセクションの図は、管理ベースラインの範囲を超える 3 つの方法を示しています。
管理ベースラインでは、ポートフォリオで最も重要度の低いワークロードの 80% で求められる最小限のコミットメントを満たす必要があります。 ミッション クリティカルなワークロードにベースラインを適用することはできません。 また、ワークロード間で共有される共通のプラットフォームにも適用することはできません。 これらのワークロードでは、設計の原則と高度な運用に重点を置く必要があります。
高度な運用オプション
次の図に示すように、管理ベースラインを超えてビジネス コミットメントを改善するために推奨される 3 つのパスがあります。
管理ベースラインの拡張
Azure 管理ガイドで概説するように、拡張された管理ベースラインでは、クラウドネイティブなツールを使用してアップタイムを改善し、復旧時間を短縮します。 改善は重要ですが、ワークロードまたはプラットフォームの特化ほど重要ではありません。 管理ベースラインを拡張することで得られる利点は、同等に重要なコストおよび実装時間の削減です。
管理のための特化
ワークロードおよびプラットフォームの運用上、設計とアーキテクチャの原則を変更することが必要になる場合があります。 これらの変更には時間がかかる可能性があり、運用経費が増加する場合があります。 このような投資を必要とするワークロードの数を削減するために、管理ベースラインを拡張することにより、ビジネス コミットメントを十分に高められる可能性があります。
ビジネス コミットメントを満たすためにより多くの投資を必要とするワークロードの場合、運用を特化することが重要です。
管理のための特化領域
特化する領域としては、次の 2 つがあります。
- プラットフォームの特化: 共有プラットフォームの継続的な運用に投資し、その投資を複数のワークロード間に分散します。
- ワークロードの特化: 特定のワークロードの継続的な運用に投資します。通常、ミッション クリティカルなワークロード用に予約されます。
中央 IT チームまたはクラウドのセンター オブ エクセレンス (CCoE)
プラットフォームの特化とワークロードの特化のどちらを選択するかは、各ワークロードの重要度と影響に基づきます。 ただし、この決定は、中央 IT チームと CCoE のどちらの組織モデルを選択するかという、より大きな文化の決定でもあることを示しています。
ワークロードの特化は、多くの場合、文化的な変化をもたらします。 従来の IT と一元化された IT は共に、大規模なサポートを提供できるプロセスを構築します。 管理ベースラインまたは拡張ベースラインだけでなくプラットフォームの運用でも見られる繰り返し可能なサービスの場合、スケール サポートの方が、実現可能性が高くなります。 ワークロードの特化では、多くの場合、スケーリングされません。 このようにスケール機能がないため、集中化された IT 組織が組織の規模に制限されることなく必要なサポートを提供することは困難です。
一方、クラウドのセンター オブ エクセレンス アプローチでは、責任の意図的な委任と選択的な集中化により、スケーリングを行います。 ワークロードの特化は、CCoE の委任された責任アプローチを使用した方がより適切に配置される傾向があります。
CCoE における役割の自然な配置の概要を次に示します。
- クラウド プラットフォーム チームは、複数のクラウド導入チームをサポートする共通プラットフォームの構築を支援します。
- クラウド自動化チームは、それらのプラットフォームをサービス カタログの展開可能な資産に拡張します。
- クラウド管理は、管理ベースラインを一元的に提供し、サービス カタログの使用をサポートするのに役立ちます。
- しかし、ビジネス ユニット (ビジネス DevOps チームまたはクラウド導入チームの形式) には、ワークロード、パイプライン、またはパフォーマンスの日常的な運用に対する責任があります。
管理領域の配置に関して、中央 IT チーム モデルと CCoE モデルでは、通常、文化的な変化を最小限に抑えて、プラットフォームの特化を実現できます。 中央 IT チームでは、ワークロードの特化の実現が複雑になる可能性があります。
管理のための特化プロセス
各特化では、次の 4 つのステップから成るプロセスが規範的な反復アプローチで実行されます。 このアプローチでは、クラウド導入、クラウド プラットフォーム、クラウド自動化、クラウド管理の各エキスパートが連携して、実行可能で情報に基づいたフィードバック ループを作成する必要があります。
- システム設計を改善する: 中断を効果的に最小限に抑えるために、共通システム (プラットフォーム) または特定のワークロードの設計を改善します。
- 修復を自動化する: 一部の改善は費用効果が高くありません。 このような場合、修復を自動化し、中断の影響を抑える方が合理的です。
- ソリューションをスケーリングする: システム設計と自動修復が改善されたら、サービス カタログを使用してそれらの変更を環境全体に拡張できます。
- 継続的な改善: さまざまな監視ツールを使用して、システム設計、自動化、スケーリングの次のパスで対処する段階的な改善点を見つけることができます。
システム設計を改善する
システム設計の改善は、どの共通プラットフォームでも運用を改善する上で最も効果的なアプローチです。 システム設計の改善により、安定性を高め、ビジネスの中断を減らすことができます。 個々のシステムの設計は、クラウド導入フレームワークを介して実行される環境ビューの範囲外です。
このフレームワークを補完するものとして、Microsoft Azure Well-Architected Framework では、プラットフォームまたは特定のワークロードの品質向上のための基本原則が提供されます。 フレームワークでは、アーキテクチャ エクセレンスの 5 つの要素の向上に重点を置いています。
- コストの最適化: もたらされる価値が最大になるようにコストを管理します。
- オペレーショナル エクセレンス: 運用環境でのシステムの動作を維持するオペレーショナル プロセスに従います。
- パフォーマンス効率: 負荷の変化に合わせてシステムをスケーリングします。
- 信頼性: 障害から回復して動作を続行するようにシステムを設計します。
- セキュリティ: 脅威からアプリケーションとデータを保護します。
ほとんどのビジネス中断は、何らかの形の技術的負債が発生しているか、またはアーキテクチャに欠陥があることを意味します。 既存のデプロイの場合、システム設計の改善は、既存の技術的負債の返済と見なすことができます。 新しいデプロイの場合、システム設計の改善は、技術的負債の回避と見なすことができます。 次のセクションでは、対処できない、または対処すべきではない技術的負債に対処する方法を示します。
システムの設計を改善するには、Microsoft Azure Well-Architected Framework の詳細をご覧ください。 システム設計が改善されたら、この記事に戻り、改善を行って改善点を環境全体に拡張できる新たな機会を見つけてください。
自動修復
技術的負債の中には、対処できない (またはその必要がない) ものがあります。 解決策のコストが高くなりすぎて修正できない可能性があります。 また、解決策を計画しても、プロジェクト期間が長くなる可能性もあります。 ビジネスの中断がビジネスに大きな影響を与えない場合もあれば、ビジネス上、回復性への投資ではなく、迅速な回復が優先される場合もあります。
技術的負債の解決が望ましい方法ではない場合、通常は、自動修復が必要な次の手順になります。 自動修復では、Azure Automation と Azure Monitor を使用して傾向を検出し、自動修復を提供することが最も一般的なアプローチです。
自動修復に関するガイダンスについては、Azure Automation とアラートに関する記事をご覧ください。
サービス カタログを使用したソリューションのスケーリング
プラットフォームの特殊化とプラットフォームの運用の基礎は、管理の行き届いたサービス カタログです。 これは、システムの設計の改善と修復が環境全体でどのようにスケーリングされるかを示しています。 クラウド プラットフォーム チームおよびクラウド自動化チームは、どの環境でも最も一般的なプラットフォームに繰り返し可能なソリューションを作成するために配置されます。 ただし、これらのソリューションが一貫した方法で適用されていない場合、クラウド管理では、ベースライン オファリング以上のものは提供されない可能性があります。
最適化されたプラットフォームを最大限に導入し、メンテナンスのオーバーヘッドを最小限に抑えるには、そのプラットフォームをサービス カタログに追加する必要があります。 カタログ内の各アプリケーションは、サービス カタログを介した内部使用のため、または外部の消費者向けのマーケットプレース オファリングとしてデプロイすることができます。
サービス カタログに発行する方法については、サービス カタログへの発行に関する一連の記事をご覧ください。
継続的な改善
プラットフォームの特化とプラットフォームの運用は共に、導入、プラットフォーム、自動化、および管理の各チーム間で作成される強力なフィードバック ループに依存します。 各チームは、データ内のこのフィードバック ループを基にすることで、より賢明な意思決定を行うことができます。 プラットフォームの運用で長期的なビジネス コミットメントを実現するには、一元化されたプラットフォームに固有の分析情報を利用することが重要です。 コンテナーと SQL Server は、最も一般的に使用されている 2 つの一元管理型プラットフォームであるため、以下の記事をよく調べ、改善データの継続的収集を始めることを検討してください。