クラウド管理でのプラットフォーム運用Platform operations in cloud management

インベントリと可視性運用のコンプライアンス、および保護と復旧にわたるクラウド管理ベースラインは、IT ポートフォリオのほとんどのワークロードに十分なレベルのクラウド管理として機能します。A cloud management baseline that spans inventory and visibility, operational compliance, and protection and recovery might provide a sufficient level of cloud management for most workloads in the IT portfolio. ただし、そのベースラインが完全なポートフォリオをサポートできるほど十分なことはほとんどありません。However, that baseline is seldom enough to support the full portfolio. この記事は、クラウド管理の最も一般的な次の手順であるポートフォリオの運用に基づいています。This article builds on the most common next step in cloud management, portfolio operations.

IT ポートフォリオ内の資産を簡単に調べると、サポートされているワークロード全体のパターンが明らかになります。A quick study of the assets in the IT portfolio highlights patterns across the workloads that are being supported. このようなワークロードには一般的なプラットフォームが含まれます。Within those workloads, there will be common platforms. 社内の過去の技術的な決定によっては、こうしたプラットフォームは大きく異なる可能性があります。Depending on the past technical decisions within the company, those platforms could vary widely.

組織によっては、SQL Server、Oracle、またはその他のオープンソース データ プラットフォームへの依存度が高くなります。For some organizations, there will be a heavy dependence on SQL Server, Oracle, or other open-source data platforms. 他の組織では、共通点は、仮想マシン (VM) またはコンテナーのホスティング プラットフォームに根ざしている可能性があります。In other organizations, the commonalities might be rooted in the hosting platforms for virtual machines (VMs) or containers. さらに、SAP、Oracle などのアプリケーションやエンタープライズ リソース プランニング (ERP) システムに共通の依存関係が存在する場合もあります。Still others might have a common dependency on applications or Enterprise Resource Planning (ERP) systems, such as SAP, Oracle, or others.

このような共通点を理解することにより、クラウド管理チームは、優先順位のあるプラットフォームに対してより高いレベルのサポートに特化することができます。By understanding these commonalities, the cloud management team can specialize in higher levels of support for those prioritized platforms.

サービス カタログを確立するEstablish a service catalog

プラットフォーム運用の目的は、信頼性が高く反復可能なソリューションを作成することです。クラウド導入チームはこれを使用して、より高いレベルのビジネス コミットメントを実現するプラットフォームを提供できます。The objective of platform operations is to create reliable and repeatable solutions, which the cloud adoption team can use to deliver a platform that provides a higher level of business commitment. このコミットメントにより、ダウンタイムの可能性または頻度が減少し、信頼性が向上します。That commitment could decrease the likelihood or frequency of downtime, which improves reliability. システム障害が発生した場合、コミットメントによってデータ損失の量や復旧に要する時間を減らすこともできます。In the event of a system failure, the commitment could also help decrease the amount of data loss or time to recovery. こうしたコミットメントには、多くの場合、プラットフォームをサポートするための継続的な集中管理が含まれます。Such a commitment often includes ongoing, centralized operations to support the platform.

クラウド管理チームが特定のプラットフォームに関連する高度な運用管理と専門化を確立すると、それらのプラットフォームは成長するサービス カタログに追加されます。As the cloud management team establishes higher degrees of operational management and specialization related to specific platforms, those platforms are added to a growing service catalog. そのサービス カタログは、特定の構成でのプラットフォームのセルフサービス展開を提供します。これは、実行中のプラットフォーム運用に準拠しています。The service catalog provides self-service deployment of platforms in a specific configuration, which adheres to ongoing platform operations. ビジネスの調整の会話中に、クラウド管理およびクラウド戦略チームは、管理された反復可能なプロセスで信頼性、稼働時間、および復旧のコミットメントを改善するための方法として、サービス カタログ ソリューションを提案できます。During the business-alignment conversation, cloud management and cloud strategy teams can propose service catalog solutions as a way for the business to improve reliability, uptime, and recovery commitments in a controlled, repeatable process.

参考までに、一部の組織では、初期段階のサービス カタログを "承認済みリスト" と呼びます。For reference, some organizations refer to an early-stage service catalog as an approved list. 主な違いは、サービス カタログには、クラウドのセンター オブ エクセレンス (CCoE) による継続的な運用コミットメントが付随することです。The primary difference is that a service catalog comes with ongoing operational commitments from the cloud center of excellence (CCoE). 承認済みリストは、チームがクラウドで使用できる事前に承認されたソリューションのリストを提供するという点で似ています。An approved list is similar, in that it provides a preapproved list of solutions that a team can use in the cloud. ただし、通常、承認済みリストのアプリケーションに関連する運用上の利点はありません。However, typically there isn't an operational benefit associated with applications on an approved list.

一元化された IT と CCoE 間の議論と同様に、違いは優先事項の 1 つです。Much like the debate between centralized IT and CCoE, the difference is one of priorities. サービス カタログは意図が正しいことを前提としていますが、イノベーションを促進する運用、ガバナンス、およびセキュリティのガードレールを提供します。A service catalog assumes good intent but provides operational, governance, and security guardrails that accelerate innovation. 承認済みリストは、ソリューションの運用、コンプライアンス、およびセキュリティ ゲートに合格するまで、イノベーションの妨げになります。An approved list hinders innovation until operations, compliance, and security gates can be passed for a solution. どちらのソリューションも実行可能ですが、企業はイノベーションやコンプライアンスへの投資を増やすために、微妙な優先順位付けを行う必要があります。Both solutions are viable, but they require the company to make subtle prioritization decisions to invest more in innovation or compliance.

サービス カタログを構築するBuild the service catalog

クラウド管理は、サイロ内でサービス カタログを提供することはほとんどありません。Cloud management is seldom successful at delivering a service catalog in a silo. カタログの適切な開発には、中央 IT チームまたは CCoE 全体のパートナーシップが必要です。Proper development of the catalog requires a partnership across the central IT team or the CCoE. このアプローチは、IT 組織が CCoE レベルの成熟度に達している場合に最も成功する傾向がありますが、さらに早期に実装することもできます。This approach tends to be most successful when an IT organization reaches a CCoE level of maturity, but could be implemented sooner.

CCoE モデル内でサービス カタログを構築する場合、クラウド プラットフォーム チームは目的の状態プラットフォームを構築します。When it's building the service catalog within a CCoE model, the cloud platform team builds out the desired-state platform. クラウド ガバナンスとクラウド セキュリティ チームは、展開内のガバナンスとコンプライアンスを検証します。The cloud governance and cloud security teams validate governance and compliance within the deployment. クラウド管理チームは、そのプラットフォームの継続的な運用を確立します。The cloud management team establishes ongoing operations for that platform. また、クラウド オートメーション チームは、スケーラブルで反復可能な展開のためにプラットフォームをパッケージ化します。And the cloud automation team packages the platform for scalable, repeatable deployment.

プラットフォームをパッケージ化すると、クラウド管理チームは拡大するサービス カタログに追加できるようになります。After the platform is packaged, the cloud management team can add it to the growing service catalog. クラウド導入チームは、そこからそのパッケージまたはカタログ内の他のパッケージを展開中に使用できます。From there, the cloud adoption team can use the package or others in the catalog during deployment. ソリューションが運用に移行すると、ビジネスには運用管理の改善とビジネスの中断が減る可能性という追加のメリットが得られます。After the solution goes to production, the business realizes the extra benefits of improved operational management and potentially reduced business disruptions.

注意

サービス カタログの構築には、複数のチームによる多大な労力と時間が必要です。Building a service catalog requires a great deal of effort and time from multiple teams. ゲート メカニズムとしてサービス カタログまたは承認済みリストを使用すると、イノベーションが遅れます。Using the service catalog or approved list as a gating mechanism will slow innovation. イノベーションが優先事項である場合は、他の導入作業と並行してサービス カタログを開発する必要があります。When innovation is a priority, service catalogs should be developed parallel to other adoption efforts.

独自のプラットフォーム運用を定義するDefine your own platform operations

管理ツールとプロセスはプラットフォームの運用を改善するために役立ちますが、多くの場合、安定性と信頼性の望ましい状態を達成するには十分ではありません。Although management tools and processes can help improve platform operations, that is often not enough to achieve the desired states of stability and reliability. 真のプラットフォーム運用では、アーキテクチャ エクセレンスの要素に焦点を当てる必要があります。True platform operations requires a focus on pillars of architecture excellence. あるプラットフォームについて、運用へのさらなる投資が妥当と判断する場合、プラットフォームをサービス カタログに含める前に、次の 5 つの要素を考慮します。When a platform justifies a deeper investment in operations, consider the following five pillars before the platform becomes a part of any service catalog:

  • コストの最適化: もたらされる価値が最大になるようにコストを管理します。Cost optimization: Manage costs to maximize the value delivered.
  • オペレーショナル エクセレンス: 運用環境でのシステムの動作を維持するオペレーショナル プロセスに従います。Operational excellence: Follow operational processes that keep a system running in production.
  • パフォーマンス効率: 負荷の変化に合わせてシステムをスケーリングします。Performance efficiency: Scale systems to adapt to changes in load.
  • 信頼性: 障害から回復して動作を続行するようにシステムを設計します。Reliability: Design systems to recover from failures and continue to function.
  • セキュリティ: 脅威からアプリケーションとデータを保護します。Security: Protect applications and data from threats.

Microsoft Azure Well-Architected Framework では、全体的な運用の改善を支援するために、これらの重要な要素への準拠について特定のワークロードを評価するアプローチを提供します。The Microsoft Azure Well-Architected Framework provides an approach to evaluating specific workloads for adherence to these pillars, in an effort to improve overall operations. これらの重要な要素は、プラットフォームの運用とワークロードの運用の両方に当てはめることができます。These pillars can be applied to both platform operations and workload operations.

特定のプラットフォームの概要Get started with specific platforms

以下のセクションで説明するプラットフォームは、一般的な Azure のお客様に共通であり、プラットフォーム運用への投資の妥当性を簡単に判断できます。The platforms discussed in the next sections are common to typical Azure customers, and they can easily justify an investment in platform operations. クラウド管理チームは、プラットフォーム運用の要件または完全なサービス カタログを作成する際に、このようなものから始める傾向があります。Cloud management teams tend to start with them when they're building out platform operations requirements or a full service catalog.

PaaS データ操作PaaS data operations

多くの場合、データはプラットフォーム運用への投資を保証する最初のプラットフォームです。Data is often the first platform to warrant platform operations investments. サービスとしてのプラットフォーム (PaaS) 環境でデータがホストされている場合、業務の利害関係者はデータ損失を最小限に抑えるために目標復旧時点の短縮を求める傾向があります。When data is hosted in a platform as a service (PaaS) environment, business stakeholders tend to request a reduced recovery point objective (RPO) to minimize data loss. アプリケーションの性質によっては、目標復旧時間 (RTO) の削減も必要になる場合があります。Depending on the nature of the application, they might also request a reduction in recovery time objective (RTO). どちらの場合でも、PaaS ベースのデータ ソリューションをサポートするアーキテクチャでは、管理サポートのレベルのある程度の向上には容易に対応できます。In either case, the architecture that supports PaaS-based data solutions can easily accommodate some increased level of management support.

ほとんどのシナリオでは、ミッション クリティカルではないアプリケーションであっても、管理のコミットメントを向上させるコストは容易に妥当と判断されます。In most scenarios, the cost of improving management commitments is easily justified, even for applications that are not mission critical. このプラットフォーム運用の改善は非常に一般的なので、多くのクラウド管理チームは、それを真のプラットフォーム運用の改善のように扱うのではなく、強化されたベースラインと認識しています。This platform operations improvement is so common that many cloud management teams see it more as an enhanced baseline, rather than as a true platform operations improvement.

IaaS データ操作IaaS data operations

従来のサービスとしてのインフラストラクチャ (IaaS) ソリューションでデータがホストされている場合、RPO と RTO を改善するための作業は大幅に多くなる可能性があります。When data is hosted in a traditional infrastructure as a service (IaaS) solution, the effort to improve RPO and RTO can be significantly higher. ただし、管理のコミットメントを向上させるという業務の利害関係者の要望が PaaS と IaaS の決定に影響を受けることはほとんどありません。Yet the business stakeholders' desire to achieve better management commitments is seldom affected by a PaaS versus IaaS decision. どちらかといえば、アーキテクチャの基本的な違いを理解すると、企業は、PaaS ソリューションか、PaaS ソリューションで使用できるものと一致するコミットメントかを求めることになる可能性があります。If anything, an understanding of the fundamental differences in architecture might prompt the business to ask for PaaS solutions or commitments that match what's available on PaaS solutions. IaaS データ プラットフォームの最新化は、プラットフォーム運用の最初のステップとして検討する必要があります。Modernization of any IaaS data platforms should be considered as a first step into platform operations.

最新化が選択肢に入らない場合、通常、クラウド管理チームは、サービス カタログで最初に必要なサービスとして IaaS ベースのデータ プラットフォームを優先します。When modernization isn't an option, cloud management teams commonly prioritize IaaS-based data platforms as a first required service in the service catalog. スタンドアロンのデータ サーバーとクラスター化された高可用のデータ ソリューションのいずれかを選択できるようにすることで、ビジネス コミットメントの会話がはるかに容易になります。Providing the business with a choice between standalone data servers and clustered, high-availability, data solutions makes the business commitment conversation much easier to facilitate. 運用の改善とコストの増加についての基本的な理解によって、企業はビジネス プロセスとサポート ワークロードに対して最適な決定を下すことができるようになります。A basic understanding of the operational improvements and the increased costs will arm the business to make the best decision for the business processes and supporting workloads.

その他の一般的なプラットフォーム運用Other common platform operations

データ プラットフォームに加え、仮想マシン ホストは、運用を改善するための共通のプラットフォームとなる傾向があります。In addition to data platforms, virtual machine hosts tend to be a common platform for operations improvements. ほとんどの場合、クラウド プラットフォームおよびクラウド管理チームは、VMware ホストまたはコンテナー ソリューションの機能強化に投資しています。Most commonly, cloud platform and cloud management teams invest in improvements to VMware hosts or container solutions. このような投資によって、VM をサポートするホストの安定性と信頼性が向上し、その結果、ワークロードが強化されます。Such investments can improve the stability and reliability of the hosts, which support the VMs, which in turn power the workloads. 1 つのホストまたはコンテナーに対する適切な運用によって、複数のワークロードの RPO や RTO を向上させることができます。Proper operations on one host or container can improve the RPO or RTO of several workloads. このアプローチでは、ビジネス コミットメントは向上しますが、投資は分散されます。This approach creates improved business commitments, but distributes the investment. コミットメントの向上とコストの削減の両方により、クラウド管理とプラットフォーム運用の向上を妥当と判断する方がはるかに簡単です。Improved commitments and reduced costs combine to make it much easier to justify improvements to cloud management and platform operations.

次のステップNext steps

プラットフォーム運用の向上と並行して、クラウド管理チームは、運用ワークロードの上位 20% 以内に関するワークロード運用の向上にも重点を置きます。In parallel with improvements to platform operations, cloud management teams also focus on improving workload operations for the top 20 percent or less of production workloads.