Google Cloudの障害を調べる手順|プロジェクト・リージョン別の影響と対処

Google Cloud上の業務システムが止まった時は、サービス名、プロジェクト、リージョンを特定してから調べます。公開ステータスが正常でも、自社プロジェクトだけの問題や限定的な障害は残るため、ログと個別のService Healthを組み合わせて確認します。

【要点】製品・地域・プロジェクトを揃える

• Compute Engine、Cloud SQLなど、影響している製品を区別します。
• 利用中のリージョンと公式発表の対象を照合します。
• 管理者はPersonalized Service Healthとアプリのログを確認します。
• リソースの削除・再作成やIAM権限の拡大を最初の対処にしません。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

Google Cloudの公開情報を表示しています。全世界の製品・地域が含まれ、自社プロジェクトへの影響を自動判定した表示ではありません。

公開情報と自社の状態の違い

最初に記録する項目

1. 障害が出た業務画面、操作、時刻を控えます。
2. 担当者がプロジェクトID、製品、リージョン・ゾーン、対象リソースを確認します。
3. アプリのエラーと直前のデプロイ・設定変更を照合します。
4. 管理権限を持つ担当者がService Healthを確認し、該当するイベントと自社のログを比較します。

Personalized Service Healthは、プロジェクトに関係する情報を調べるための仕組みです。公開ダッシュボードと範囲が異なります。公開情報を使う場合の公式説明も確認し、「公開障害がないからアプリが悪い」と即断しないでください。

403・429・5xxを分けて調べる

403などの権限エラーでは、呼び出しているアカウント、IAM、組織ポリシーを確認します。必要な権限を特定せずOwner権限を与えることは避けます。429など制限を示す場合は、割り当てと実際のリクエスト数を確認し、急な増加や再試行ループがないかを調べます。意味は製品ごとのレスポンス本文と仕様を優先します。

5xxやタイムアウトは基盤側だけでなく、自社アプリ、ロードバランサー、接続先でも生じます。正常だった時刻とのエラー率、遅延、リソース使用量を比較します。ログの一行だけで結論を出さず、同じ時間帯の関連サービスを照合します。

利用者と運用担当者の役割

業務利用者は、繰り返し送信する前に注文・申請・保存の結果を担当者へ確認します。管理コンソールへ入れないからといって、アプリのデータも消えたとは限りません。認証情報や顧客データを一般の掲示板へ送らないようにしてください。

運用担当者は、既存の復旧手順がある場合に限り切り替えや再起動を判断します。別リージョンへの移行にはデータの整合性、依存先、アクセス権、利用規程の確認が必要です。原因未確定のままリソースを削除して作り直すと、障害より大きな損失になる可能性があります。

管理画面は開くのに業務アプリだけ失敗する場合

コンソールへ入れたことは、利用するすべての製品・リージョンが正常という意味ではありません。アプリのエラー時刻から、呼び出したAPI、認証主体、対象リソースを特定します。特定の処理だけ失敗するなら、その依存先を調べます。ブラウザでログインし直しても、アプリが使うサービスアカウントの権限や割り当ては変わりません。

直前の設定変更がある場合は、変更前後のログを比べます。障害の可能性があるからといってIAMを広く付与することは避けてください。別リージョンへの切り替えも、データの複製状態、接続先、費用、データ保管要件を確認した上で行う運用判断です。復旧後は失敗した書き込みの結果を照合し、読み取りが通っただけで通常運転へ戻さないようにします。

復旧後の確認とまとめ

アプリの応答、ジョブの残件、失敗処理の再実行、重複登録、データの整合性を確認します。サポートにはプロジェクト・地域・時刻・リクエストID・実施済みの確認をまとめます。Google Cloudでは「どの製品のどの地域か」を揃え、公開障害と自社ログを組み合わせることが復旧判断の基本です。

国内の通信・アプリ・企業システム障害のまとめを見る