サポートケースを詳細に記述することで、Google サポートチームがお客様にすばやく効率的に対応できるようになります。サポートケースに重要な詳細がない場合、Google はお客様から追加情報を確認する必要があり、解決までの時間が長くなります。このガイドでは、技術サポートのケースを迅速に解決するために必要な情報について説明します。
問題の説明
適切な問題レポートは詳細かつ具体的です。何が起こったのか、何が起こると予想されるのかが報告されています。適切な問題レポートには、次の詳細が記載されています。
- 時刻: 問題が発生した具体的なタイムスタンプ。
- プロダクト: 問題に関連するプロダクトと機能。
- ロケーション: 問題が発生しているゾーン。
- 識別子: プロジェクト / アプリケーション ID と、問題の調査に役立つ具体的な識別子。
- 有用な資料: 問題の診断に役立つ詳細情報。
- 問題のタイプ: 問題が断続的なものか、一時的なものか、あるいは定型的なものか。
次のセクションで、これらのコンセプトについて詳しく説明します。
時刻
ISO 8601 形式の日付とタイムスタンプを使用して、問題に最初に気付いたのはいつか、また問題がどのくらい続いたかを報告してください。
例:
- 2017-09-08T15:13:06+00:00 に開始し、5 分後に終了、...が観測された
- 2017-09-10 以降に開始し、...が 2 回から 5 回断続的に観測された
- 2017-09-08T15:13:06+00:00 から現在も継続中...
- 2017-09-08T15:13:06+00:00 から 2017-09-08T15:18:16+00:00...
問題を解決するサポート エンジニアはお客様と同じタイムゾーンにいない可能性が非常に高いため、次のような相対的な説明では問題を診断するのが難しくなります。
- 「問題は昨日から始まった...」（暗示された日付を推論せざるを得ない）
- 「9/8 に問題に気付きました...」（9 月 8 日と解釈する人もあれば、8 月 9 日と解釈する人もいるのであいまい）
プロダクト
基本ケースフォームではプロダクト名を指定する必要がありますが、そのプロダクトのどの機能に問題があるのかについて具体的な情報が必要です。具体的な API や Cloud Console の URL（またはスクリーンショット）が報告されていると理想的です。API の場合、URL にプロダクト名が含まれているドキュメント ページにリンクできます。
さらに、リクエストを開始するために使用しているメカニズムについて教えてください（たとえば REST API、gcloud ツール、Cloud Console、Deployment Manager などのツール）。複数のプロダクトが関係する場合、それぞれの名前を具体的に知らせてください。
例:
- 「Google Compute Engine の REST API から次のエラーが返されました...」
- 「console.cloud.google.com で BigQuery クエリ インターフェースがハングしています...」
次のような文章は、問題を診断する際にどこを調べるかを特定するために十分ではありません。
- 「インスタンスを作成できない...」（インスタンスを作成するために使用しているメソッドの情報が必要です）。
- 「
gcloud compute create instancesコマンドでエラーが発生した...」（コマンドの構文が正確でないため、コマンドを実行してエラーを再現できません。さらに、実際に発生した具体的なエラーがわかりません）。
ロケーション
Google では変更を一度に 1 つのリージョンまたはゾーンにロールアウトするため、お客様のデータセンターのリージョンとゾーンを知る必要があります。リージョンとゾーンは、基になるソフトウェアのバージョン番号のプロキシです。この情報は、特定のバージョンのソフトウェアの変更がシステムに影響を与えているかどうかを判断するのに役立ちます。
例:
- 「us-east1-a で...」
- 「リージョン us-east1 と us-central1 を試してみましたが...」
識別子
具体的な識別子は、どの Cloud プロジェクトで問題が発生しているかを特定するのに役立ちます。必ず英数字のプロジェクト ID またはアプリケーション ID を知らせてください。プロジェクト名は役に立ちません。問題が複数のプロジェクトに影響を与えている場合は、影響を受けているすべての ID を含めてください。
プロジェクト ID またはアプリケーション ID に加えて、次のような ID がケースの診断に役立ちます。
- インスタンス ID
- BigQuery のジョブ ID またはテーブル名
- IP アドレス
IP アドレスを指定する場合は、IP アドレスを使用するコンテキストも説明してください。たとえば、IP がコンピューティング インスタンス、ロードバランサ、カスタムルート、または API エンドポイントに接続されているかどうかを指定します。また、IP アドレスが Google のシステムに関連していないかどうかを教えてください（たとえば、IP アドレスが自宅のインターネット、VPN エンドポイント、外部モニタリング システムの場合など）。
例:
- 「プロジェクト robot-name-165473 または my-project-id で...」
- 「複数のプロジェクト間（my-project-id を含む）で...」
- 「自社のゲートウェイ 56.56.56.56 から GCP 外部 IP 218.239.8.9 に接続する際に...」
次のような一般的な説明は、問題を診断するには詳細が不足しています。
- 「インスタンスの 1 つに接続できません...」
- 「インターネットから接続できません...」
有用な資料
問題に関連する資料を提供していただくことで、お客様の問題をより正確に把握できるため、トラブルシューティングをスピードアップできます。
例:
- 表示内容を正確に伝えるには、スクリーンショットを使用します。
- ウェブベースのインターフェースの場合は、.HAR（Http ARchive）ファイルを提供します。HAR Analyzer には、3 つの主要なブラウザ用の手順が用意されています。
- tcpdump 出力、ログのスニペット、サンプルのスタック トレースを添付します。
問題のタイプ
断続的な問題: 断続的な問題はランダムに発生し、決まったパターンの障害はありません。断続的な問題は、障害発生時にデータを収集するのが困難なため、トラブルシューティングが困難です。この場合は、アーキテクチャのボトルネックを特定し、リソースが最大しきい値の使用状況に達していないかどうかを確認してください。自動化を使用してスケジュールされたジョブで頻繁にチェックを実行し、失敗した場合は障害発生時のデバッグ情報を収集してください。このタイプの障害には、DNS 解決の障害やパケットロスなどがあります。
一時的な問題: 一時的な問題は瞬間的なものであるか、短い期間に発生します。問題がわずか数マイクロ秒の間に発生する場合は、マイクロバーストのトラフィックやリソースのピーク使用状況を確認できます。通常、一時的な問題は、繰り返し発生しない場合や一時的な障害に耐えられるように設計されている場合は無視できます。このような障害の例としては、数マイクロ秒の間に発生するネットワーク レイテンシの急増やタイムアウトの原因となる少量のパケットロスなどがあります。伝送制御プロトコル（TCP）は少量のパケットロスやレイテンシの急増といった障害を効果的に処理できるよう設計されていますが、アプリケーションがレイテンシに影響されやすい場合は、処理に失敗する場合があります。
定型的な問題: 定型的な問題とは、ウェブサイトがダウンしている場合など、機能が完全に停止する問題です。定型的な問題は再現することが可能であるため、トラブルシューティングが比較的容易です。この場合は、サポート エンジニアが環境を複製して問題を解決できるように、問題の再現手順を説明します。
優先度の設定とエスカレーション
優先度は、この問題がお客様のビジネスに及ぼす影響を理解するのに役立ち、Google が問題の解決にどれだけ迅速に対応するかに影響します。次の表に優先度の定義を示します。詳細については、Cloud のサポート手順をご覧ください。
| 優先度の定義 | 事例 |
|---|---|
| P1: 重大な影響 – 本番環境でサービスを使用できない | 本番環境でアプリケーションまたはインフラストラクチャが使用できず、ユーザー側でエラーが大量に発生している。ビジネスに与える影響が重大である（収益損失、データの整合性に影響する可能性のある問題など）。 |
| P2: 影響が大きい – サービスの使用が大幅に損なわれている | 本番環境でインフラストラクチャの機能が低下していて、ユーザー側でエラーが非常に高い割合で発生している、あるいは新しい本番環境システムの稼働が難しい。ビジネスに与える影響が中程度である（収益損失や運用性低下などの恐れがある）。 |
| P3: 中程度の影響 – サービスの使用が部分的に損なわれている | 問題の範囲または重大度は限定的である。この問題によりユーザーの目に見えるような影響は発生していない。ビジネスに与える影響が低い（不便を感じる、ビジネス処理に小さい影響を与える、など）。 |
| P4: 影響が小さい – サービスはすべて使用できる | ビジネスへの影響や技術的影響は低いか、まったくない。頻繁なやり取りよりも、詳細な分析やトラブルシューティングが必要な場合や、コンサルティングを希望される場合は、コンサルティング チケットをおすすめします。 |
どのような場合に最高優先度を設定するか
ビジネスにとってクリティカルなサービスに影響を及ぼす問題が発生し、Google からの緊急な対応が必要な場合は、優先度として「P1」を選択してください。P1 を選択した理由を詳細に説明してください。この問題がお客様のビジネスにもたらす影響を簡単に説明してください。たとえば、エンドユーザーが直接影響を受けていない場合でも、重要なセキュリティ修正がブロックされている場合、開発バージョンを P1 であるとみなすことができます。
ケースを P1 に設定すると、問題の対応に専念できる適切なエキスパートを探すように、担当のサポートチームのメンバーに直ちにアラートが送信されます。最初の回答がすぐに届きます（企業のお客様の場合は 15 分以内、ロールベース サポートの本番環境の役割が割り当てられているお客様の場合は 1 時間以内）。その後、更新情報が定期的な届きます。
適切に対応できるように、選択された優先度レベルの理由についてはできるだけ詳細にお知らせください。
回答までの時間
問題の優先度レベルには、Google Cloud Platform 技術サポート サービス ガイドラインで回答までの時間があらかじめ定義されています。特定の時間までに回答が必要な場合は、レポートの説明でお知らせください。P1 の問題を 24 時間体制で処理する必要がある場合、「フォローザサン」サービスをリクエストできます。これらのケースは、アクティブなサポート エンジニアに 1 日に複数回割り当てられます。
エスカレーション
状況の変化に伴って、問題への迅速な対応のためにエスカレーションが必要になる場合があります。エスカレーションの妥当な理由として、次のようなものが考えられます。
- ビジネスへの影響の増大。
- 問題をより早く解決する必要がある。
- 何度かメッセージをやりとりしたが、問題が進捗することなく行き詰っている。
GCP サポートのケースがエスカレーションされると、サポート マネージャーにすぐに通知され、1 時間以内に回答が届きます。問題が解決するまで、エスカレーション マネージャーがエスカレーションのオーナーになります。マネージャーは、エスカレーションの根本原因を特定して対応し、今後の類似したエスカレーションが発生しないように予防措置を報告します。
ケースをエスカレーションするには、ケースの作成の 60 分後に表示される [ケースのエスカレーション] ボタンをクリックする必要があります。
長期的または難しい問題
解決に時間がかかる問題では、混乱が生じ、情報が古くなる場合があります。これを防ぐ最善の方法は、長期化問題のテンプレートを使用して情報を収集し、最新の状態を最上部に要約しておくことです。
テンプレートを使用するには、上記のリンクを開いてコピーを作成してください。すべての関連するケースと内部のトラッキング バグへのリンクを含めてください。この文書をアカウント チームのグループと共有し、特定のサポート エンジニアと共有するように依頼してください。
この文書には次が含まれます。
- 上部に要約された現在の状態。
- 正しいと考えられる仮説のリスト。
- 各仮説をテストするために使用するテストまたはツール。
それぞれのケースで 1 つの問題に集中し、ケースを再オープンして新しい問題を提起しないようにしてください。
本番環境の停止を報告する
問題により、アプリケーションのユーザーへのトラフィックの配信が停止されたり、同じレベルの重大な影響がビジネスに及んだりしている場合、これは本番環境の停止と見なすことができます。そのような場合はお早目にご連絡ください。これとは対照的に、少数のデベロッパーがブロックされるような問題は、本番環境の停止とは見なされません。
本番環境の停止の報告を受けた場合、Google では次のように迅速に状況を分類します。
- GCP インフラストラクチャに影響を与える既知の問題をすぐに確認します。
- 問題の性質を確認します。
- コミュニケーション チャネルを確立します。
次の内容を含む短いメッセージがお客様に送信されます。
- 複数のお客様に影響する、関連する既知の問題。
- 報告された問題を確認できたこと、または追加情報のリクエスト。
- 連絡方法（電話、ハングアウト、ケースなど）。
時刻、プロダクト、識別子、およびロケーションを含むケースをすばやく作成し、詳細なトラブルシューティングを開始することが重要です。組織で定義されているインシデント管理プロセスがある場合、このステップは、プロセス開始後すぐに実行してください。
Google のインシデント管理プロセスでは、インシデント コマンダーという重要な役割が定義されています。インシデント コマンダーは適切な関係者を召集し、最新のステータスを継続的に収集して、問題の状態を定期的に要約します。トラブルシューティングや変更の適用を他者に委任します。この委任によって、複数の仮説の並行調査が可能になります。お客様の組織内でも同様のプロセスを確立することをおすすめします。ケースをオープンした人は、通常、最も情報を得ているため、インシデント コマンダーの候補として最適です。
ネットワークの問題を報告する
Google のネットワークの規模と複雑さのため、問題の原因となっているチームを特定できない場合があります。ネットワークの問題を診断するには、具体的な根本原因を特定する必要があります。ネットワークのエラー メッセージは汎用的な場合がよくあるため（「サーバーに接続できません」など）、考えられる仮説を絞り込むために詳細な診断情報を収集する必要があります。
パケットフロー図は、問題レポートの優れた構造となります。これらの図は、パケットが送信元から宛先までの経路で通過する重要なホップと、その途中の重要な変換を示します。
影響を受けるネットワーク エンドポイントを、インターネット IP アドレスまたは RFC 1918 プライベート アドレスとネットワークの識別子で識別します。たとえば、Compute Engine プロジェクトのデフォルト ネットワーク上の 2.3.4.5 または 10.2.3.4 です。
エンドポイントについて、次のような情報を記録します。
- 誰がそれを制御しているか。
- DNS ホスト名に関連付けられているかどうか。
- VPN トンネリング、プロキシ、NAT ゲートウェイなどの中間カプセル化や間接化。
- ファイアウォール、CDN、WAF などの中間フィルタリング。
大きなレイテンシや断続的なパケット損失として現れる問題の多くでは、診断のために経路分析またはパケット キャプチャ（あるいはその両方）が必要になります。
- 経路分析は、パケットが通過するすべてのホップのリストで、「traceroute」としてよく知られています。Google では診断力に優れた MTR や tcptraceroute がよく使用されます。これらのツールに慣れておくことをおすすめします。
- パケット キャプチャ（ライブラリ「libpcap」の名前から「pcap」とも呼ばれます）は、実際のネットワーク トラフィックのモニタリングです。両方のエンドポイントで同時にパケット キャプチャをとることが重要ですが、それには多少の経験が必要です。必要なツール（tcpdump や Wireshark など）を使って練習し、必要になる前にインストールしておいてください。
サンプルケース
例 1
ジョブ名:
A_ATL_BIG1toBQ_big_04)201704202
00045_491
ソース:
S3_avl-transfer
宛先:
CloudStorage: avl-transfer
開始時刻（ISO 8601 形式）: 2017-04-20 20:14:43 PDT
終了時刻（ISO 8601 形式）: 2017-04-21 の 10:03:44 PDT
transfer API を使用して 2017-04-20 の 20:14:43 PDT にファイル転送を開始しました。このジョブは通常 10 分で完了しますが、この場合、翌日にジョブをキャンセルしたときにまだジョブは実行中でした（2017-04-21 の 10:03:44 PDT）。これは独立した事象ではなく、transfer API に関係するその他のいくつかのジョブで、断続的な大幅な遅延がありました。
遅れの原因を調査し、今後これらの問題が発生しないように実施できるベスト プラクティスについて助言してください。
例 2
開始時刻（ISO 8601形式）: 2017-05-12 の 11:03:43
終了時刻（ISO 8601形式）: このレポートの時点で問題はまだ発生しています。
問題の概要:
App Engine タスクキュー API を使用した /cron/payments-service/sync-v2-batch cron の実行が、2017-05-12 の 11:03:43 以降停止しています。支払いを正しく処理するためにこのジョブが必要です。
データストアとキューのエラーが発生した後に、cron の実行が停止しました。cron.xml を再アップロードして問題を解決しようとしましたが、うまく行きませんでした。エラートレースを添付します。
[error trace]
問題が API と実装のどちらにあるのか、また必要な今後の手順について教えてください。