Best Practices für die Zusammenarbeit mit Customer Care

In diesem Leitfaden finden Sie Best Practices für das Verfassen einer effektiven Supportanfrage. Wenn Sie diese Best Practices einhalten, können wir Ihre technische Supportanfrage schneller bearbeiten.

Eine Supportanfrage erstellen

Bevor Sie eine Supportanfrage erstellen, prüfen Sie bekannte Probleme, um festzustellen, ob bereits ein entsprechender Fall eingereicht wurde.

Damit es nicht zu Verwirrung kommt und wir Ihre Anfrage an einem zentralen Ort nachverfolgen können, erstellen Sie bitte eine Supportanfrage pro Problem. Alle doppelten Supportanfragen werden geschlossen.

Beschreiben Sie Ihr Problem

Wenn Sie eine detaillierte Supportanfrage erstellen, ist es für das Customer Care-Team leichter, Ihnen schnell und effizient zu antworten. Wenn in Ihrer Supportanfrage wichtige Details fehlen, müssen wir Sie um weiteren Informationen bitten, was zusätzliche Zeit in Anspruch nimmt.

Die besten Supportanfragen sind sowohl detailliert als auch spezifisch. Aus ihnen geht hervor, was passiert ist und was Sie erwartet haben. Geben Sie in Ihrer Supportanfrage die folgenden Details an:

• Zeit: Der spezifische Zeitstempel, als das Problem begann.
• Produkt: Die Produkte und Funktionen, die mit dem Problem verbunden sind.
• Standort: Die Zonen, in denen das Problem auftritt.
• Kennzeichnungen: Die Projekt-ID oder die Anwendungs-ID und andere konkrete Kennzeichnungen, die uns helfen, das Problem zu untersuchen.
• Nützliche Artefakte: Alle Details, die Sie angeben können, um uns bei der Diagnose des Problems zu helfen.
• Problemtyp: Tritt das Problem unregelmäßig, vorübergehend oder konsistent auf.

In den folgenden Abschnitten sind diese Konzepte detaillierter beschrieben.

Zeit

Teilen Sie uns mit, wann Sie das Problem erstmals bemerkt haben und wie lange das Problem bestand. Verwenden Sie dabei für die Angabe des Datums und Zeitstempels das ISO 8601-Format.

Beispiele:

• Beginn am 2017-09-08T15:13:06+00:00 und nach 5 Minuten vorbei: Wir haben beobachtet, dass...
• Periodisch auftretend seit dem 2017-09-10 und 2- bis 5-mal bemerkt: Wir haben beobachtet, dass...
• Durchgehend seit 2017-09-08T15:13:06+00:00...
• Vom 2017-09-08T15:13:06+00:00 bis 2017-09-08T15:18:16+00:00...

Der Customer Care-Mitarbeiter, der das Problem bearbeitet, befindet sich höchstwahrscheinlich nicht der gleichen Zeitzone wie Sie. Daher erschweren relative Aussagen wie die folgenden die Diagnose des Problems:

• „Das hat irgendwann gestern angefangen...“ (Zwingt uns, das implizierte Datum abzuleiten.)
• „Wir haben das Problem am 9/8 bemerkt...“ (Mehrdeutig, da dies als 8. September oder 9. August interpretiert werden kann.)

Produkt

Obwohl Sie im standardmäßigen Fallformular nach einem Produktnamen gefragt werden, benötigen wir spezifische Informationen darüber, welche Funktion des Produkts von dem Problem betroffen ist. Im Idealfall verweist Ihr Bericht auf bestimmte APIs oder Google Cloud Console-URLs (oder Screenshots). Für APIs können Sie eine Verknüpfung zur Dokumentationsseite erstellen, die den Produktnamen in der URL enthält.

Informieren Sie uns auch über den Mechanismus, den Sie zum Initiieren der Anfrage verwenden (z. B. REST API, Google Cloud CLI, Google Cloud Console oder möglicherweise ein Tool wie Cloud Deployment Manager). Wenn mehrere Produkte verwendet werden, geben Sie jeden Namen extra an.

Beispiele:

• „Die Google Compute Engine-REST API hat folgende Fehler zurückgegeben...“
• „Die BigQuery-Abfrageschnittstelle in console.cloud.google.com hängt...“

Die folgenden Angaben sind nicht spezifisch genug, um zu wissen, wo bei der Problemdiagnose nachgesehen werden muss:

• „Es können keine Instanzen erstellt werden...“ (Informationen darüber, welche Methode Sie zum Erstellen von Instanzen verwenden, sind zwingend erforderlich.)
• „Der Befehl gcloud compute create instances ergibt einen Fehler...“ (Die Befehlssyntax ist fehlerhaft, daher können wir ihn nicht selbst ausführen, um den Fehler zu reproduzieren. Außerdem wissen wir nicht, welchen Fehler Sie tatsächlich gesehen haben.)

Standort

Wir müssen die Region und Zone Ihres Rechenzentrums kennen, da wir Änderungen oft für jeweils eine Region oder Zone bereitstellen. Die Region und Zone stehen stellvertretend für die Versionsnummer der zugrunde liegenden Software. Diese Informationen helfen uns, zu erkennen, ob wichtige Änderungen in einer bestimmten Version unserer Software Auswirkungen auf Ihre Systeme haben.

Beispiele:

• „In us-east1-b…“
• „Ich habe die Regionen us-east1 und us-central1 ausprobiert...“

Kennzeichnungen (IDs)

Spezifische Kennzeichnungen helfen uns, zu ermitteln, welches Ihrer Cloud-Projekte von dem Problem betroffen ist. Angaben zur alphanumerischen Projekt- oder Anwendungs-ID sind zwingend erforderlich. Projektnamen sind nicht hilfreich. Wenn das Problem mehrere Projekte betrifft, geben Sie alle betroffenen IDs an.

Zusätzlich zu Projekt- oder Anwendungs-IDs helfen uns verschiedene andere Kennzeichnungen, Ihren Fall zu diagnostizieren:

• Instanz-IDs
• BigQuery-Job-IDs oder Tabellennamen
• IP-Adressen

Wenn Sie eine IP-Adresse angeben, geben Sie auch den Kontext an, in der sie verwendet wird. Geben Sie beispielsweise an, ob die IP mit einer Compute-Instanz, einem Load Balancer, einer benutzerdefinierten Route oder einem API-Endpunkt verbunden ist. Machen Sie auch Angaben, wenn die IP-Adresse nicht mit den Google-Systemen in Verbindung steht (z. B. wenn die IP-Adresse für Ihr privates Internet, einen VPN-Endpunkt oder ein externes Überwachungssystem gilt).

Beispiele:

• „Im Projekt robot-name-165473 oder my-project-id...“
• „Über mehrere Projekte hinweg (darunter my-project-id)...“
• „Zur Google Cloud externen IP-Adresse 218.239.8.9 über unser privates Gateway 56.56.56.56 verbinden...“

Allgemeine Aussagen wie die folgenden sind zu allgemein, um bei der Problemdiagnose hilfreich zu sein:

• „Eine unserer Instanzen ist nicht erreichbar...“
• „Wir können keine Verbindung über das Internet herstellen...“

Nützliche Artefakte

Die Bereitstellung von Artefakten, die mit dem Problem zusammenhängen, beschleunigt die Fehlerbehebung, da wir so genau das sehen können, was Sie sehen.

Beispiel:

• Verwenden Sie einen Screenshot, um genau zu zeigen, was Sie sehen.
• Geben Sie für webbasierte Oberflächen alle relevanten Browser-Trace-Informationen an.
• Fügen Sie tcpdump-Ausgaben, Log-Snippets oder Beispiel-Stacktraces an.

Problemtyp

• Verbindungsprobleme: Verbindungsprobleme treten nach dem Zufallsprinzip ohne feste Fehlermuster auf. Verbindungsprobleme sind schwer zu beheben, da es aufgrund ihrer Unregelmäßigkeit schwierig ist, während des Auftretens des Fehlers Daten zu erfassen. In diesem Fall sollten Sie versuchen, Engpässe in der Architektur zu ermitteln und zu überprüfen, ob die Nutzung Ihrer Ressourcen den maximalen Schwellenwert erreicht hat. Sie können auch häufige Prüfungen in einem geplanten Job mithilfe von Automatisierung ausführen. Wenn die Prüfung fehlschlägt, erfassen Sie Debugging-Informationen während des Fehlers. Beispiele für diese Art von Fehlern sind DNS-Auflösungsfehler und Paketverluste.

• Vorübergehende Probleme: Diese Art von Problemen halten nur für einen kurzen Zeitraum an. Bei Problemen, die nur für eine Sekunde oder einige Mikrosekunden auftreten, können Sie nach Mikro-Bursts von Traffic- oder Ressourcenspitzenauslastungen suchen. In den meisten Fällen können vorübergehende Probleme ignoriert werden, wenn sie nicht häufig auftreten und wenn Ihr Dienst tolerant gegenüber vorübergehenden Fehlern ist. Beispiele für diese Art von Fehlern sind Netzwerk-Latenzspitzen, die nur für wenige Mikrosekunden auftreten, und kleine Paketverluste, die Zeitüberschreitungen verursachen. Das Transmission Control Protocol (TCP) ist auf Fehler wie kleine Paketverluste und Latenzspitzen ausgelegt und kann diese Probleme effektiv verarbeiten, sofern Ihre Anwendung nicht empfindlich auf Latenz reagiert.

• Konsistente Probleme: Diese Probleme führen zu einem vollständigen Ausfall, z. B. wenn Ihre Website nicht verfügbar ist. Konsistente Probleme lassen sich relativ einfach beheben, da sie reproduziert werden können. Teilen Sie uns in diesem Fall mit, wie das Problem reproduziert werden kann, damit unsere Customer Care-Spezialisten die Umgebung replizieren und das Problem für Sie beheben können.

Beispielbeschreibungen

Die folgenden Beispiele enthalten detaillierte Beschreibungen für Supportanfragen.

Beispiel eins

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.

Beispiel zwei

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.

Priorität bestimmen und eskalieren

Die Priorität hilft uns, die Auswirkungen dieses Problems auf Ihr Unternehmen nachzuvollziehen und beeinflusst, wie schnell wir reagieren, um das Problem zu lösen. Prioritäten sind in der folgenden Tabelle definiert. Weitere Informationen finden Sie unter Priorität von Supportanfragen.