クラウド変更管理戦略を適応するための 3 つのルール

変更に関しては、変更管理戦略を立てることでリスクを最小限に抑えることができます。クラウドの変更管理戦略とクラウドのコンプライアンスを調整するには、次のルールに従ってください。

ほとんどの企業では、データ センター アプリケーションに関する基本的なコンプライアンスおよび変更管理ポリシーが導入されています。主にソフトウェアの変更に焦点を当て、変更管理とコンプライアンス ポリシーをクラウド コンピューティングに適合させるための新しいルールがあります。

コンプライアンス 情報システム、データの保存および使用に関連する規制および社内ポリシーへの準拠を確保します。

変更管理により、アプリケーションやデータベースに加えられた変更が影響を受ける関係者によって適切にレビューされ、問題が解決されます。

従来の変更管理戦略は開発プロセスと関連しており、リポジトリベースのガバナンスにもますます関連しています。あらゆるレベルのソフトウェアの変更、およびミドルウェアやオペレーティング システムの変更は、リポジトリ プロセスを通じて開発およびテストされます。その後、企業は変更管理を適用して、影響を受ける可能性のある関係者に通知することができます。

GitOps は DevOps のサブセットであり、リポジトリ主導のコンプライアンスをデプロイメントに拡張したものです。これにより、アプリケーションのエクスペリエンス品質 (QoE) が変化する可能性があります。また、アプリケーションに影響を与える可能性のある新しいツールと API も導入されています。さらに、企業は GitOps モデルを、当時は主に IaaS またはコンテナベースであったクラウド アプリケーションに適用しました。

企業は新しいサービス機能にアクセスするためにパブリック クラウド プロバイダーの API を使い始めていますが、変更管理戦略を拡張して新しい機能を組み込むことに失敗することがよくあります。したがって、変更管理は失敗しました。 CIMI は、今日でも、企業の変更管理プラクティスのほぼ半数がクラウド ホスト機能の変更をカバーしていないことを発見しました。

変更管理とコンプライアンス戦略をクラウド コンピューティングに適応させるには、次のルールに従ってください。

現在のプロセスにルールを適応させる

ルール1: 既存のリソースを活用する

新しい変更管理およびコンプライアンスのポリシーとプログラムを作成するのではなく、現在の変更管理およびコンプライアンスのポリシーとプログラムを採用します。現在の計画の問題点は、その実行ではなく、その範囲にあります。クラウド導入では、アプリケーションの安定性と QoE に影響を与える要因が、クラウド導入前には現れなかった可能性があります。私たちの目標は、これらの要素が確実に含まれるようにすることです。

ルール2: すべての変更を記録する

クラウド変更管理戦略では、クラウド サービス契約、サービス コミットメント、クラウド内の課金対象の変更に関するすべての変更を把握する必要があります。すべてのクラウドの変更にソフトウェアまたはリポジトリ制御のミドルウェアの変更が必要なわけではなく、定期的にテストされないものもあります。たとえば、クラウド ホスティング リージョンやスケーリング制限を変更しても、ソフトウェアには影響はありませんが、QoE は低下します。すべてのクラウドの変更をソフトウェアの変更として扱い、同じレベルの利害関係者の関与を求めます。このルールに従うには、クラウド サービスの責任をソフトウェア テスト プロセスに明確にリンクする必要があります。

ルール3: ワークフローを評価する

変更管理戦略ではワークフローの変更を検討してください。ワークフローは、ユーザーからアクセスされたアプリケーションへのメッセージの交換と、それらのメッセージ交換をサポートするために必要なネットワーク接続を表します。クラウド アプリケーションは通常、複数のコンポーネントで構成されます。クラウド バーストやフェイルオーバーの設定、およびサービス メッシュなどのより複雑なテクノロジの使用により、一部のコンポーネントはクラウドに出入りします。これらを変更すると、安定性、セキュリティ、QoE に直接影響する可能性があります。ネットワーク接続はクラウド プロバイダー、インターネット、企業 VPN、またはこれらの組み合わせによって提供されるため、サービス品質が第 2 レベルの影響を及ぼす可能性があります。

クラウド以外の変更管理プラクティスでは見逃される可能性のある変更ソースをカバーしたら、それらを統合する方法も決定する必要があります。目標は、現在の慣行と手順を変更することです。良い出発点は、アプリケーションの開発、テスト、および展開のサイクルを計画することです。変更管理が現在適用されている各ポイントのプロセスに矢印を配置します。次に、新しい変更ソースを取得し、ストリーム内の各変更ソースをマップする場所を決定します。

テストを実行する

クラウドの変更管理がユニットテストに基づいて行われると、関係者の経験が失われます。アプリケーションの設計と展開モデルによっては、役立つサブシステム テストが存在する場合があります。

これが当てはまるかどうかを確認するには、次の手順に従います。

ステップ 1 では、変更管理プロセスの早い段階で、アプリケーション統合テスト ポイントから各テスト ポイントを遡って実行します。

ステップ 2 では、十分な機能ポートフォリオが存在し、新しいクラウド関連の変更にさらされて、利害関係者のレビューに有意義な結果を示すことができるかどうかを評価します。

ステップ 3 は、正しくなくなった時点で停止します。

このプロセスに従えば、実際の変更管理プログラムで過度の変更が必要になる可能性は低くなります。