プラットフォームとワークロードの特殊化の管理

• 10 分

ワークロードの特殊化

通常、ワークロード固有の管理には、特定のワークロードに関する詳細な知識が必要です。そのため、多くの場合、ワークロード チームまたは開発チームがそれを行います。 ワークロード固有のソリューションを他のワークロードにすばやくスケールすることはできません。 IT を一元化することで、運用でワークロードに特化したチームを指導し、知識を共有することができます。

プラットフォームの特殊化

分散されたワークロード固有の運用は、企業全体での拡張性がありませんが、多くの場合、ポートフォリオを調査すると、これらのワークロードが実行されている一般的なプラットフォームを特定できます。 これらのテクノロジ プラットフォーム (テクノロジ スタックとも呼ばれます) は、多くの場合、ワークロード固有のインシデントの中核になります。 優先順位の高いワークロードが共通のテクノロジ プラットフォームを共有している場合、中央の IT 部門が、そのプラットフォームの運用向上に注力することで、ワークロード固有の運用を削減または回避する方が有益な可能性があります。

テクノロジ プラットフォームの例としては、データ プラットフォーム、分析プラットフォーム、コンテナー プラットフォーム、Azure Virtual Desktop プラットフォーム、エンタープライズ リソース プランニング (ERP) プラットフォーム、さらにはメインフレームなどがあります。

高度な運用

プラットフォームおよびワークロードの特殊化は、反復的なアプローチにおいて、次の 4 つのプロセスの規範的な実行で構成されます。

• システム設計を改善する: 技術的負債とアーキテクチャの欠陥は、ほとんどのビジネス ワークロード停止の根本原因です。 プラットフォームまたはワークロードの設計を見直すと、安定性を向上させることができます。 Azure Well-Architected フレームワークには、プラットフォームまたは特定のワークロードの品質向上のための推奨事項が含まれています。
• 修復を自動化する: 技術的負債は、改善するにはコストが高すぎたり複雑すぎたりする場合があるため、一部の設計の改善はコスト効率に優れていません。 このような場合、修復を自動化し、中断の影響を抑える方が合理的です。
• ソリューションを拡張する: システムの設計と自動修復が改善されると、それらの変更をサービス カタログを介して環境全体に拡張できます。 Azure Managed Applications センター内で最適化されたプラットフォームとソリューションを公開して、他のワークロードや外部の顧客が簡単に再利用できるようにできます。
• 継続的な改善: ユーザー、管理者、顧客からフィードバックを集めることで、次回のシステム レビューのための貴重な情報が得られます。 クリティカルなシステム ログとパフォーマンス データの収集と視覚化も重要です。 フィードバックと収集したデータの両方が、将来のシステム改善について新たに決定を下すための基盤として使用されます。

次の表は、ワークロード固有の管理に使用されるツールを示しています。