カスタマーケアの使用に関するおすすめの方法

このガイドでは、効果的なサポートケースを記述するためのベスト プラクティスを紹介します。これらのベスト プラクティスを実践することで、テクニカル サポートケースを迅速に解決できます。

サポートケースの作成

サポートケースを作成する前に、既知の問題を確認して、ケースがすでに提出されていないかどうかを確認してください。

混乱を防ぎ、リクエストを 1 つのポイントで追跡できるように、問題ごとに 1 つのサポートケースを作成します。重複するケースが作成された場合は、クローズされます。

問題の説明

サポートケースを詳細に記述することで、カスタマーケア チームがお客様にすばやく効率的に対応できるようになります。サポートケースに重要な詳細がない場合、Google はお客様から追加情報を確認する必要があり、解決までの時間が長くなります。

理想的なサポートケースは、詳細かつ具体的であり、何が起こったのか、何が起こると予想されるのかが報告されています。サポートケースで問題を説明する際は、次の詳細を含めてください。

  • 時刻: 問題が発生した具体的なタイムスタンプ。
  • プロダクト: 問題に関連するプロダクトと機能。
  • ロケーション: 事象が発生しているゾーン。
  • 識別子: プロジェクト ID、またはアプリケーション 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 や Google Cloud コンソールの URL（またはスクリーンショット）が報告されていると理想的です。API の場合、URL にプロダクト名が含まれているドキュメント ページにリンクできます。

さらに、リクエストを開始するために使用しているメカニズムについて教えてください（たとえば REST API、Google Cloud CLI、Google Cloud コンソール、Cloud Deployment Manager などのツール）。複数のプロダクトが関係する場合、それぞれの名前を具体的に知らせてください。

例:

  • 「Compute Engine の REST API から次のエラーが返されました...」
  • 「console.cloud.google.com で BigQuery クエリ インターフェースがハングしています...」

次のような文章は、問題を診断する際にどこを調べるかを特定するために十分ではありません。

  • 「インスタンスを作成できない...」（インスタンスを作成するために使用しているメソッドの情報が必要です）。
  • 「gcloud compute create instances コマンドでエラーが発生した...」（コマンドの構文が正確でないため、コマンドを実行してエラーを再現できません。さらに、実際に発生した具体的なエラーがわかりません）。

ロケーション

Google では変更を一度に 1 つのリージョンまたはゾーンにロールアウトするため、お客様のデータセンターのリージョンとゾーンを知る必要があります。リージョンとゾーンは、基になるソフトウェアのバージョン番号のプロキシです。この情報は、特定のバージョンのソフトウェアの変更がシステムに影響を与えているかどうかを判断するのに役立ちます。

例:

  • 「us-east1-b で...」
  • 「リージョン 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 から Google Cloud 外部 IP 218.239.8.9 に接続する際に...」

次のような一般的な説明は、問題を診断するには詳細が不足しています。

  • 「インスタンスの 1 つに接続できません...」
  • 「インターネットから接続できません...」

有用な資料

問題に関連する資料を提供していただくことで、お客様の問題をより正確に把握できるため、トラブルシューティングをスピードアップできます。

例:

  • 表示内容を正確に伝えるには、スクリーンショットを使用する。
  • ウェブベースのインターフェースの場合は、.HAR（Http ARchive）ファイルを提供する。HAR Analyzer には、3 つの主要なブラウザ用の手順が用意されている。
  • tcpdump の出力、ログのスニペット、サンプルのスタック トレースを添付する。

問題のタイプ

  • 断続的な問題: 断続的な問題はランダムに発生し、決まったパターンの障害はありません。断続的な問題は、障害発生時にデータを収集するのが困難なため、トラブルシューティングが困難です。この場合は、アーキテクチャのボトルネックを特定し、リソースが最大しきい値の使用状況に達していないかどうかを確認してください。自動化を使用してスケジュールされたジョブで頻繁にチェックを実行し、失敗した場合は障害発生時のデバッグ情報を収集してください。このタイプの障害には、DNS 解決の障害やパケットロスなどがあります。

  • 一時的な問題: 一時的な問題は瞬間的なものであるか、短い期間に発生します。問題がわずか数マイクロ秒の間に発生する場合は、マイクロバーストのトラフィックやリソースのピーク使用状況を確認します。通常、一時的な問題は、繰り返し発生しない場合や一時的な障害に耐えられるように設計されている場合は無視できます。このような障害の例としては、数マイクロ秒の間に発生するネットワーク レイテンシの急増や、タイムアウトの原因となる少量のパケットロスなどがあります。伝送制御プロトコル（TCP）は少量のパケットロスやレイテンシの急増といった障害を効果的に処理できるよう設計されていますが、アプリケーションがレイテンシに影響されやすい場合は、処理が失敗する場合があります。

  • 定型的な問題: 定型的な問題とは、ウェブサイトがダウンしている場合など、機能が完全に停止する問題です。定型的な問題は再現が可能なため、トラブルシューティングが比較的容易です。この場合は、カスタマーケア スペシャリストが環境を複製して問題を解決できるように、問題の再現手順を説明します。

記述例

例 1

JobName:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source:

S3_avl-transfer

Destination:

CloudStorage: avl-transfer

Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT

End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT

I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.

Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.

例 2

Start time (ISO 8601 format): 2017-05-12 at 11:03:43

End time (ISO 8601 format): The issue is still happening as of the time of this
report.

Issue summary:

`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.

We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:

`[error trace]`

Please advise if the issue is with the API or our implementation and let us
know next steps.

優先度の設定とエスカレーション

優先度は、この問題がお客様のビジネスに及ぼす影響を理解するのに役立ち、Google が問題の解決にどれだけ迅速に対応するかに影響します。次の表に優先度の定義を示します。詳しくは、サポートケースの優先度をご覧ください。

優先度の定義 事例
P1: 重大な影響 – 本番環境でサービスを使用できない 本番環境でアプリケーションまたはインフラストラクチャが使用できず、ユーザー側でエラーが大量に発生している。ビジネスに与える影響が重大である（収益損失、データの整合性に影響する可能性のある問題など）。
P2: 影響が大きい – サービスの使用が大幅に損なわれている 本番環境でインフラストラクチャの機能が低下していて、ユーザー側でエラーが非常に高い割合で発生している、あるいは新しい本番システムの稼働が難しい。ビジネスに与える影響が中程度である（収益損失や運用性低下などの恐れがある）。
P3: 中程度の影響 – サービスの使用が部分的に損なわれている 問題の範囲または重大度は限定的である。この問題によりユーザーの目に見えるような影響は発生していない。ビジネスに与える影響は低い（不便を感じる、業務に少し影響があるなど）。
P4: 影響が小さい – サービスはすべて使用できる ビジネスへの影響や技術的影響は低いか、まったくない。詳細な分析や、トラブルシューティング、コンサルタントで何度もやり取りする場合には、コンサルティング チケットをおすすめします。

どのような場合に最高優先度を設定するか

ビジネスにとってクリティカルなサービスに影響を及ぼす問題が発生し、Google からの緊急な対応が必要な場合は、優先度として「P1」を選択してください。P1 を選択した理由を詳細に説明してください。この問題がお客様のビジネスにもたらす影響を簡単に説明してください。たとえば、エンドユーザーが直接影響を受けていない場合でも、重要なセキュリティ修正がブロックされている場合、開発バージョンを P1 であるとみなすことができます。

ケースを P1 に設定すると、問題の対応に専念できるエキスパートに直ちにアラートが送信されます。初期レスポンスがすぐに返され、Google Meet でライブ トラブルシューティング コールに参加するよう求められます。組織で Google Meet を使用できない場合は、エキスパートが参加するためのビデオ会議ソフトウェアへのリンクを記載します。その後、ケースを通じて定期的に最新情報を受け取ります。

適切に対応できるように、選択された優先度レベルの理由についてはできるだけ詳細にお知らせください。

P1 ケースのサポートで期待できること

  • 新しい P1 ケース

    • サポート エキスパートが Google Meet またはお客様が指定した他のブリッジを介してお客様に連絡します。15～30 分以内に電話にご参加ください。なんらかの理由で通話に参加できない場合は、サポート担当者に伝えます。
    • デフォルトでは、ケースは「フォロー ザ サン」です。つまり、ケースが軽減されるか優先度が下がるまで、サポート エキスパートは 24 時間対応します。特定の地域でケースの軽減に取り組むのが適切である場合は、そのケースを特定のタイムゾーンにロックできます。この効果についてご希望をお知らせください。

  • 優先度 P1 の引き上げ

    • 問題が本番環境に影響し始めている場合や、影響し始めようとしている場合は、既存の P2～P4 ケースの優先度を P1 に引き上げることができます。
    • 既存のケースの優先度を P1 に上げると、サポートケースが再割り当てされ、空いているサポート エキスパートがすぐに対応できるようになります。

  • 非本番環境への影響

    必要に応じて適切なリソースが割り当てられるように、本番環境に影響を与えていない、またはビジネスに大きな影響を与えていない P1 としてマークされたケースを再評価するために、サポートがお客様に連絡することがあります。

回答までの時間

問題の優先度レベルには、Google Cloud Platform 技術サポート サービス ガイドラインで回答までの時間があらかじめ定義されています。特定の時間までに回答が必要な場合は、レポートの説明でお知らせください。P1 の問題を 24 時間体制で処理する必要がある場合、「フォローザサン」サービスをリクエストできます。これらのケースは、アクティブなカスタマーケア スペシャリストに 1 日に複数回割り当てられます。 Google が P1 ケースのトラブルシューティングを行う間、効率的なコミュニケーションを促進するために、解決するまで質問に回答することをおすすめします。3 時間以上応答がない場合は、再び応答するまでケースの優先度を P2 に下げることがあります。

エスカレーション

状況の変化に伴って、問題をエスカレーションする必要がある場合があります。エスカレーションの妥当な理由として、次のようなものが考えられます。

  • ビジネスへの影響の増大。
  • 解決プロセスの詳細。たとえば、合意された時間内に更新を受け取っていない場合や、複数のメッセージをやりとりした後に問題が「行き詰っている」場合です。

影響の大きい問題が発生している場合は、エスカレーションするのではなく、ケースを適切な優先度に設定して十分な時間を確保することが最善の解決策です。エスカレーションしてもケースをより速く解決できるとは限りません。優先度の変更直後にエスカレーションすると、ケースの解決がより遅くなる可能性さえあります。詳しくは、エスカレーションのタイミングの動画をご覧ください。

ケースをエスカレーションする方法については、ケースをエスカレーションするをご覧ください。

必要なタイムゾーンにケースをルーティングする

カスタマーケアの提供状況に基づく要因により、お客様の営業時間外に対応するカスタマーケア スペシャリストに、サポートケースが割り当てられる可能性があります。特定のタイムゾーンの営業日内でカスタマーケアを利用することもできます。このような場合は、お客様の都合に合わせてタイムゾーンにサポートケースを転送するようカスタマーケアに依頼することをおすすめします。このリクエストは、ケースの説明またはレスポンスに追加できます。例: Please route this case to the Pacific time zone (GMT-8)P1 のケースはフォローザサンのため、次のリージョンのカスタマーケアに引き継がれます。他のケースは現在のケースオーナーのままで、翌日に作業が持ち越されます。

CES アンケートに関するフィードバックを提供する

ケースが解決されると、プロセスの進行状況について意見を求めるカスタマー エフォート スコア（CES）アンケートがメールで送信されます。大変お手数ですが、アンケートにご協力いただき、ご意見やご感想をお聞かせください。

すべてのフィードバック フォームがカスタマー エクスペリエンス チームによって手動で審査され、今後のアクション向上のために使用されます。スコアは 5 点満点となります。スコアが 3 以下の場合は、お客様にとって難問であると見なされます。一方、スコア 4 以上の場合、操作は難しいものではなく、ポジティブなエクスペリエンスと見なされます。

詳しくは、CES で Google Cloud サービスのフィードバックを送信する方法の動画をご覧ください。

長期的または難しい問題

解決に時間がかかる問題では、混乱が生じ、情報が古くなる場合があります。これを防ぐ最善の方法は、長期化問題のテンプレートを使用して情報を収集し、最新の状態を最上部に要約しておくことです。

テンプレートを使用するには、上記のリンクを開いてコピーを作成してください。すべての関連するケースと内部のトラッキング バグへのリンクを含めてください。この文書をアカウント チームのグループと共有します。また特定のカスタマーケア スペシャリストと共有するようにメンバーに依頼します。

このドキュメントには次の内容が含まれます。

  • 上部に要約された現在の状態。
  • 正しいと考えられる仮説のリスト。
  • 各仮説をテストするために使用するテストまたはツール。

それぞれのケースで 1 つの問題に集中し、ケースを再オープンして新しい問題を提起しないようにしてください。

本番環境の停止を報告する

問題により、アプリケーションのユーザーへのトラフィックの配信が停止されたり、同じレベルの重大な影響がビジネスに及んだりしている場合、これは本番環境の停止と見なすことができます。そのような場合はお早目にご連絡ください。これとは対照的に、少数のデベロッパーがブロックされるような問題は、本番環境の停止とは見なされません。

本番環境の停止の報告を受けた場合、Google では次のように迅速に状況を分類します。

  • Google Cloud インフラストラクチャに影響を与える既知の問題をすぐに確認します。
  • 問題の性質を確認します。
  • コミュニケーション チャネルを確立します。

次の内容を含む簡単なメッセージがお客様に返信されます。

  • 複数のお客様に影響する、関連する既知の問題。
  • 報告された問題を確認できたこと、または追加情報のリクエスト。
  • お知らせ方法

時刻、プロダクト、識別子、およびロケーションを含むケースをすばやく作成し、詳細なトラブルシューティングを開始することが重要です。組織で定義されているインシデント管理プロセスがある場合、このステップは、プロセス開始後すぐに実行してください。

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 など）を使って練習し、必要になる前にインストールしておいてください。