サービスが中断することは避けられませんが、何が起きているのかを評価し、関係者に情報を提供し続け、ビジネスへの影響を最小限に抑えるために行動を起こすには、透明性の高い早期のコミュニケーションが不可欠です。
信頼性の高いクラウド アプリケーションの運用は、Google Cloud とアプリケーション デベロッパーの間で責任を分担します。サービスが中断した場合、Google Cloud はインシデントを迅速に伝え、影響評価を提供することを目的としています。通知の受信方法、新しいインシデントへの対応方法、アプリケーションへの影響を管理する方法について評価する必要があります。
このプロセスには Personalized Service Health が役立ちます。さまざまな方法で統合して、新しいインシデントを確認したり、アプリケーションへの影響を評価したり、 Google Cloudから最新情報を受け取ったりできます。このドキュメントでは、Google Cloudからサービス中断のシグナルを受信する方法の概要と、統合に関する推奨事項について説明します。
統合する場所を決める
Google Cloud Google Cloud プロダクトの健全性を把握するために、次のプロダクトが用意されています。
- Google Cloud Service Health - すべてのロケーションのすべてのGoogle Cloud プロダクトのプラットフォーム全体の概要を提供します。大規模で深刻なインシデントを対象とし、次の場所で利用できます。
- Personalized Service Health - プロジェクトまたは組織全体で使用されているプロダクトのパーソナライズされたビューを表示します。 Google CloudGoogle Cloud Service Health に投稿されるインシデントよりも幅広いインシデントに対応しています。Personalized Service Health は次の環境で利用できます。
- コンソール ダッシュボード。Google Cloud コンソールからアクセスできます。
- アラート
- Service Health API
最も広範なカバレッジと統合オプションを利用できるように、Personalized Service Health と統合することをおすすめします。
| 統合ポイント | ユースケース | メリット | 依存関係 |
| コンソール ダッシュボード（Personalized Service Health） | アクティブなサービス停止を表示する | プロジェクトに合わせてパーソナライズされ、デフォルトで利用可能 | Identity and Access Management（IAM） Google Cloud コンソール |
| アラート（Personalized Service Health） | パーソナル通知 | プロジェクトに合わせてパーソナライズされ、便利で先を見越した機能 | IAM Cloud Logging Cloud Monitoring |
| API（パーソナライズド サービス ヘルス） | 別のシステムやツールと統合する | プロジェクトまたは組織に合わせてパーソナライズされた | IAM |
Personalized Service Health の操作方法を選択する
目的のオペレーション、モニタリング、インシデント対応モデルのコンテキストで Personalized Service Health を検討する必要があります。インシデント発生時とその前後にチームがシグナルを使用する方法を評価することで、Personalized Service Health の使用方法を決定できます。
次の表に、Personalized Service Health の設定に応じて、Personalized Service Health を操作する方法を示します。
| 組織でのシナリオ例 | Personalized Service Health との統合 | 統合するツールの例 |
| 数個のアプリケーションのオンコール デベロッパー | 個々のプロジェクトのアラート コンソール ダッシュボード |
Google Cloud Observability、PagerDuty |
| 組織全体のインシデント対応の集中化 | OrganizationEvents API（v1、v1beta）を使用した既存システムとの API 統合 | PagerDuty、カスタム ダッシュボード |
| クラウド リソースとオペレーションを管理する内部プラットフォーム | Service Health API 個々のプロジェクトのアラート Service Health API と内部デベロッパー プラットフォームの統合 |
Backstage、Terraform |
| プログラムで構成および管理される多数のプロジェクト（例: 1,000 件以上） | Service Health API API ベースの自動通知 |
Backstage、Terraform、PagerDuty |
インシデント中に Personalized Service Health を使用する
Personalized Service Health と統合してアラート通知を受け取ると、Personalized Service Health から、影響の管理に役立つ Google Cloudサービス中断に関する情報が提供されます。
インシデントを検出して範囲を特定する
この段階で確認すべき点としては、次のようなものが挙げられます。
- 本当に問題ですか？
- 影響を確認できますか？
- どのような症状ですか？
- 影響を受けるユーザー、サービス、ビジネスの部分はどれですか？どの地域ですか？
Personalized Service Health を使用すると、問題がプロジェクトに起因するものか Google に起因するものかを把握できるため、適切なインシデント対応を実装できます。イベント情報を検索して表示できるため、プロジェクトに影響するイベント、影響を受けるプロダクト、場所をモニタリングできます。
次の手順を試すことができます。
- アラートが設定されている場合は、アラートを確認します。
- このアラートが発生した原因は何ですか？
- これらのアラートは、プロダクト固有の可能性のある他のすべてのアラートに対応していますか？
- プロジェクトまたは組織の Service Health ダッシュボードにアクセスします。イベント、影響を受けるプロダクト、場所をひと目で確認し、次の質問に回答できます。
- 影響を受けるプロジェクト
- プロジェクトが依存しているプロダクトはどれですか？
- イベントは、これらのロケーション内の特定のリソースに影響していますか？
- イベントを確認し、そのスコープ、影響、プロジェクトとの関連性を把握します。
- 発生している問題に関連していると思われるイベントを特定します。
- 確認手順、緩和策（利用可能な場合）、イベントの解決にかかる見込み時間を確認します。
Personalized Service Health を使用すると、プロジェクトまたは組織に影響を与えているインシデントの現在の状態と影響を把握できるため、インシデントを効率的に管理して対応できます。たとえば、優先度が最も高いインシデントを正確に特定することで、優先度を効果的に設定できます。
インシデントを軽減、解決、エスカレーションする
この段階で確認すべき点としては、次のようなものが挙げられます。
- インシデントを回避するにはどうすればよいですか？
- 直接修正できますか？
- 今すぐフェイルオーバーを開始すべきか、もう少し待つべきか
- 修正を依頼する相手
Personalized Service Health を使用すると、プロジェクトとリソースに対するインシデントの影響を把握し、利用可能な回避策を把握し、解決にかかる見積もり時間を最新情報として受け取ることができます。
インシデントの解決に向けた進捗状況をモニタリングする
Service Health ダッシュボードのイベントの概要には、軽減に必要な症状や回避策などの重要な情報が示され、状態が変化した日時も示されます。これらの詳細情報を使用すると、次のことができます。
- 状況の変化に応じて、潜在的な影響の概要をモニタリングします。
- 最新情報や次回の連絡または更新の予定については、最新情報をご確認ください。
- 症状が公開された日時を確認する。
- 回避策が特定されたら、その旨を記載します。
- ステータスが [解決済み] に変わったときを確認します。
進行状況をモニタリングしながら、次の操作を行うことができます。
- 回避策（利用可能な場合）を確認します。
- プロジェクトまたは組織に適したインシデント対応を実装します。
- イベントが軽減または解決されるまで、引き続きモニタリングします。
サポートに連絡すべき状況
Google は、Service Health ダッシュボードに表示されるイベントを認識しています。イベントについて Google が行っている対応を確認するには、イベントを選択して詳細を表示します。
ダッシュボードのイベントに問題が表示されない場合は、サポートにお問い合わせください。
インシデント情報の他のソースと Personalized Service Health を使用する
組織の設定に関係なく、インシデントの影響を評価する際に、Personalized Service Health を追加のシグナルとして使用します。データと証拠に基づいて次のステップを決定できるように、インシデント情報の複数のソースを確認できるようにしてください。
インシデント情報の複数のソースを使用する理由は次のとおりです。
- Google Cloud プロダクトが特定のロケーションでインシデントが発生している場合でも、プロジェクトが別のロケーションにあるため、影響を受けない場合があります。
- サービング システムに別々のゾーンに 2 つの完全なレプリカがあり、1 つのゾーンの重要な Google Cloud プロダクトで障害が発生した場合、パーソナライズされた Service Health はその障害を通知します。ただし、ユーザーに実際に影響が及んでいない場合は、直ちに対応する必要はありません。
- プロジェクトがロケーション内の多くの Google Cloud プロダクトに依存している場合、Personalized Service Health は次の情報を把握できません。
- プロジェクトですべてのプロダクトが機能している必要がある場合。
- 1 つのプロダクトが失敗した場合にプロジェクトが引き続き機能するかどうか。
- 1 つ以上のプロダクトが失敗した場合に、アプリケーション全体が影響を受ける場合。
- Personalized Service Health 自体が低下したり障害が発生したりすることもあります。確認するには、ステータスを確認します。
設定に応じて、Personalized Service Health からのシグナルを解釈する必要があります。