クラウド変更管理のベストプラクティス

クラウドでは、オンプレミスよりも変更管理が複雑になる可能性があります。企業がクラウド環境を導入する場合、管理すべきサービスが多数存在します。さらに、開発者がさまざまな地域にわたってアプリケーションを簡単かつ迅速に導入および更新する必要があるため、この課題はさらに複雑になります。

[[284284]]

ただし、クラウドの変更管理は不可能ではありません。適切な計画を立てることで、企業はこれらのサービスの使用方法を自動化するプロセスを開発し、反復的な展開モデルをコードとしてのインフラストラクチャなどのテクノロジーと組み合わせることができます。変更管理の技術的な側面に加えて、企業は従業員の調整も考慮し、全員が同じことを理解できるようにします。

ITを超えて

データ センターでは、IT 管理者は変更管理を使用して IT リソースの消費と操作を制御します。通常、ITIL などのサービス管理フレームワークを通じて規範的なアプローチを採用します。多くの場合、変更諮問委員会がリクエストとその潜在的な影響を検討し、リクエストを簡素化または最適化する方法を提案することがあります。

デロイト コンサルティングのプリンシパル、エドワード・メジャーズ氏は、クラウドにおける変更要求の最大の違いはスピードだと述べた。クラウド ユーザーは、データ センターよりも速く変更をスケジュールして本番環境に展開できます。

「物事が急速に変化しているため、変更管理はもはや単なる IT 領域ではありません」とメジャーズ氏は言います。

クラウド変更管理を正常に実装するには、企業は影響を受けるグループ間でコミュニケーションを維持し、従業員が変更の期待、利点、影響を理解できるようにする必要があります。

もっと計画を立てる

柔軟でオンデマンドの IT リソースにより、クラウド ユーザーはマイクロサービスなどの分散型で弾力的にスケーラブルなワークロードを展開できます。

クラウドコンサルティング会社 ServerCentral Turing Group のクラウドソリューション担当シニアディレクター、ジョシュ・クイント氏は、このモデルを使用するとクラウドサービスの数が劇的に増加すると述べています。その結果、開発者や IT エンジニアは、単一の管理コンソールから作業するのではなく、変更を加えるために複数の場所 (場合によっては複数のプロバイダー) に移動する必要がある場合があります。さらに、これらの変更は同時に行う必要がある場合があり、手動での再構成や構成は非現実的になります。

企業は、変更を標準のビルド、統合、および展開プロセスの一部にする必要があります。これにより、リリースがより頻繁に展開されても一貫性が確保されます。コードの作成、配信、およびデプロイメントのための制御された CI/CD パイプラインにより、チーム間の通信ポイントも標準化されます。各ステップのパラメータを中心に CI/CD パイプラインを構築することで、クラウド チームはクラウドでホストされるアプリケーションに対して実行されるすべての変更に対する正しいアプローチを文書化できます。

この標準化された CI/CD プロセスは、オンプレミス展開で一般的なゲートレビューを必要とせずに、クラウド内のすべての変更を管理します。また、クラウド チームは変更管理に自動化を導入できるようになります。 AWS CodePipeline、Jenkins、Azure DevOps などの一般的な CI/CD ツールは、展開前のテストやレビューなど、変更リリースのあらゆる段階でコードの実行を自動化します。これらの手順により、変更に関する情報が生成され、チームはそれを変更のドキュメントとしてキャプチャする必要があります。

「コアプロセスに関する詳細なドキュメントと構造を提供することで得られる実現されていないメリットこそが、自動化がもたらす真の価値です」とクイント氏は言います。このようなドキュメントには明確なパスがあり、誰が関与すべきか、誰が関与すべきでないかが明確に特定されるため、変更要求の確認と展開が容易になります。

利害関係者のフィードバックに基づいて反復する

IT チームが、依然として一般的なウォーターフォール開発アプローチから、CI/CD パイプラインを通じて小さな変更をリリースする反復的なアプローチに移行する際には、利害関係者のフィードバックに注意を払う必要があります。

IT コンサルティング会社 TetraVX のカスタマー エクスペリエンス担当ディレクターの Sean Kendall 氏は、IT チームは新しい展開で複数のテストを実行して、さまざまな関係者からのフィードバックを同時に処理できると説明しています。

この反復プロセス中に取り組むべき重要な質問には、次のようなものがあります。

• ユーザーはソフトウェアにアクセスできますか?
• 高可用性とフェイルオーバーは実施されていますか?
• クラウド プロバイダーのデータ センターからどのくらい離れていますか? また、これはレイテンシーに影響しますか?

ケンドール氏は、フィードバックに基づいてソフトウェアをレビューおよび調整するアジャイルなアプローチが、特定のツールよりも重要であると指摘しました。

インフラストラクチャ・アズ・コード

クラウドコンサルティング会社SADAのクラウドプラットフォーム担当ディレクター、サイモン・マーゴリス氏は、企業がインフラストラクチャをコードとして設定する努力をすれば、変更管理はより簡単になると述べた。特定の変更に対して、IT リソースとホスティングの両方の側面が自動化され、これらのインフラストラクチャ構成の追跡、複製、操作が容易になります。開発者は、リリース前にテストするためにインフラストラクチャ コードから複製された環境をすばやく立ち上げることもできますが、これはコストの関係でオンプレミスでは必ずしも可能ではありません。

Margolis 氏は、インフラストラクチャをコードとして扱うために HashiCorp Terraform を使用することを推奨しています。多くのパブリック クラウドで実行されており、多くの IT エンジニアや開発者によく知られています。 AWS CloudFormation や Google Cloud Deployment Manager など、特定のプラットフォームに固有のクラウドネイティブ オプションもあります。

コーディネーター

すべての関係者がクラウドの変更に注意を払う必要があるため、Asana、Trello、Basecamp などの作業管理ツールを使用して共同作業を行い、リアルタイムの進捗状況と更新を確認し、変更を計画および追跡することも重要です。 「すべての点をチェックするツールを見つけ、チーム全体がそのツールを使用していることを確認する必要があります」とマーゴリス氏は語った。

フローチャートは、全員が同じことを理解できるようにするのにも役立ちます。クラウドの変更とその展開プロセスを視覚的に表示すると、潜在的な問題についてエンジニアと会話を始めるのに役立ちます。

失敗に備える

クラウドコンサルティング会社 Nebulaworks の CTO、ロブ・ヘルナンデス氏は、企業はクラウド環境を運用する際には障害に備えるべきだと述べた。これには必ずしもハイブリッドまたはマルチクラウドのアプローチは必要ありません。クラウド ユーザーは、多くの場合、可用性ゾーン全体にデプロイし、インスタンスを自動的にフェイルオーバーして再構成するように設計することで、回復力を実現できます。

ヘルナンデス氏は、可用性ゾーンにまたがるマシンの役割がデフォルトの動作モードになるべきだと述べた。これには、単一リージョン構成以上の作業は必要なく、クラウド プロバイダーに問題がある場合に大きな利点が得られます。

大規模なクラウド プロバイダーは、手動による介入なしに作業を再展開して再開するためのインスタンス オプションを提供します。たとえば、AWS では、Auto Scaling グループにより、アベイラビリティーゾーンに障害が発生した場合でも、グループ内のインスタンスの数が一定になることを保証できます。