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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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