アプリケーションを Google Cloud の本番環境にデプロイすると、使用するインフラストラクチャの変更が必要になる場合があります。たとえば、VM のマシンタイプの変更や、Cloud Storage バケットのストレージ クラスの変更が必要になる場合があります。Google Cloud インフラストラクチャ信頼性ガイドのこのパートでは、インフラストラクチャ リソースの信頼性リスクを軽減するために使用できるチェンジ マネジメント ガイドラインについて概説します。このパートでは、Google Cloud インフラストラクチャの可用性をモニタリングする方法についても説明します。
インフラストラクチャの変更を段階的にデプロイする
Google Cloud インフラストラクチャを変更する必要がある場合は、可能な限り、変更を本番環境に段階的にデプロイします。たとえば、VM のマシンタイプを変更する必要がある場合は、1 つのゾーン内のいくつかの VM に変更をデプロイし、変更の影響をモニタリングします。問題が発生した場合は、インフラストラクチャを迅速に以前の安定した状態に戻します。問題を診断して解決し、段階的なデプロイ プロセスを再開します。ワークロードが想定どおりに実行されていることを確認したら、すべてのインフラストラクチャに対して変更を徐々にデプロイします。
Google Cloud インフラストラクチャとアプリケーションの変更を確実にテストしてデプロイするための戦略については、アプリケーションのデプロイとテストの戦略をご覧ください。
グローバル リソースに対する変更を制御する
VPC ネットワークやグローバル ロードバランサなどのグローバル リソースを変更する場合は、本番環境にデプロイする前に十分に注意して変更を確認してください。
グローバル リソースはゾーンとリージョンの停止に対する復元性を備えているため、アーキテクチャで特定のグローバル リソースの単一インスタンスを使用する場合もあります。このようなデプロイでは、グローバル リソースが単一障害点になる可能性があります。たとえば、グローバル ロードバランサの転送ルールを誤って構成した場合、フロントエンドでユーザー リクエストの受信または処理が停止される可能性があります。この場合、バックエンドに影響はありませんが、ユーザーは実質的にアプリケーションを使用できなくなります。このような状況を回避するには、グローバル リソースに対する変更を厳密に制御します。たとえば、変更レビューのプロセスでは、グローバル リソースに対する変更を、追加のレビュー担当者による検証と承認を必要とする高リスクの変更として分類できます。
Google Cloud インフラストラクチャの可用性をモニタリングする
Google Cloud Service Health ダッシュボードを使用すると、すべてのリージョンの Google Cloud サービスの現在のステータスをモニタリングできます。各サービスのインフラストラクチャ障害（インシデントと呼ばれます）の履歴を表示することもできます。履歴ページには、インシデントの期間、影響を受けるゾーンとリージョン、影響を受けるサービス、推奨される回避策など、各インシデントの詳細が表示されます。
また、Personalized Service Health を使用して、プロジェクトに関連するインシデントを参照することもできます。Service Health を使用すると、API を使用してプロジェクトごとまたは組織ごとにインシデント情報をリクエストすることや、アラートを構成することもできます。
Google は、次回の更新の予想時間など、各インシデントのステータスに関する更新情報を定期的に提供しています。RSS フィードを使用して、インシデントのステータスの更新をプログラムで取得できます。詳細については、インシデントと Google Cloud Service Health ダッシュボードをご覧ください。