Best Practices für die Zusammenarbeit mit dem Kundenservice

In diesem Leitfaden finden Sie Best Practices für das Erstellen effektiver Supportanfragen. Wenn Sie diese Best Practices umsetzen, können wir Ihre Supportanfrage schneller bearbeiten.

Supportanfrage erstellen

Bevor Sie eine Supportanfrage erstellen, sollten Sie sich die bekannten Probleme ansehen, um herauszufinden, ob bereits eine Supportanfrage eingereicht wurde.

Um Unklarheiten zu vermeiden und damit Ihre Anfrage an einem zentralen Ort verfolgen zu können, erstellen Sie bitte eine Supportanfrage pro Problem. Alle doppelten Fälle werden geschlossen.

Beschreibung des Problems

Wenn Sie einen detaillierten Supportfall erstellen, ist es für das Customer Care-Team leichter, Ihnen schnell und effizient zu antworten. Wenn in Ihrer Supportanfrage kritische Details fehlen, müssen wir nach weiteren Informationen fragen, was zusätzliche Zeit in Anspruch nimmt.

Die besten Supportanfragen sind detailliert und spezifisch. Aus ihnen geht hervor, was passiert ist und was Sie erwartet haben. Beschreiben Sie das Problem in Ihrer Supportanfrage:

  • Zeit: Der spezifische Zeitstempel, als das Problem begann.
  • Produkt:Die Produkte und Funktionen, die mit dem Problem verknüpft sind.
  • Standort:Die Zonen, in denen das Problem auftritt.
  • Kennzeichnungen: Die Projekt-/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.
  • Art des Problems:Ist das Problem zeitweise, vorübergehend oder konsistent?

In den folgenden Abschnitten sind diese Konzepte detaillierter beschrieben.

Uhrzeit

Teilen Sie uns mit, wann Sie das Problem erstmals bemerkt haben und wie lange es andauerte. Verwenden Sie dazu das ISO 8601-Format für den Datums- und Zeitstempel.

Beispiele:

  • Ab 2017-09-08T15:13:06+00:00 endet 5 Minuten später...
  • 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-Spezialist, der das Problem löst, befindet sich wahrscheinlich nicht in Ihrer Zeitzone. Daher erschweren relative Aussagen wie die folgenden das Problem:

  • "Das hat irgendwann gestern angefangen..." (Zwingt uns, das implizierte Datum abzuleiten.)
  • "Wir haben das Problem am 9/8 bemerkt..." (Mehrdeutig, da manche dieses Datum als 8. September interpretieren, andere als 9. August.)

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 bezieht sich 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, mit dem Sie die Anfrage initiieren (z. B. REST API, Google Cloud CLI, Google Cloud Console oder ein Tool wie Cloud Deployment Manager). Wenn mehrere Produkte involviert sind, gib jeden Namen an.

Beispiele:

  • „Compute Engine REST API hat folgende Fehler zurückgegeben...“
  • „Die BigQuery-Abfrageoberfläche in console.cloud.google.com ist hängen...“

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

  • "Es können keine Instanzen erstellt werden..." Wir müssen wissen, welche Methode Sie zum Erstellen von Instanzen verwenden.
  • „Der Befehl gcloud compute create instances gibt einen Fehler aus...“ (Die Syntax für den Befehl ist falsch. Wir können ihn also nicht selbst ausführen, um den Fehler zu reproduzieren. Außerdem wissen wir nicht, welchen Fehler Sie tatsächlich gesehen haben.)

Zone

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-a..."
  • "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. Wir müssen immer die alphanumerische Projekt- oder Anwendungs-ID kennen. 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-Adresse mit einer Compute-Instanz, einem Load-Balancer, einer benutzerdefinierten Route oder einem API-Endpunkt verbunden ist. Teilen Sie uns auch mit, ob die IP-Adresse nicht mit den Systemen von Google zusammenhängt, z. B. wenn sie für Ihr Internet zu Hause, einen VPN-Endpunkt oder ein externes Monitoringsystem gilt.

Beispiele:

  • "Im Projekt robot-name-165473 oder my-project-id..."
  • "Über mehrere Projekte hinweg (darunter my-project-id)..."
  • „Verbindung über externes IP von Google Cloud 218.239.8.9 von unserem Unternehmensgateway 56.56.56.56 läuft...“

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.
  • Stellen Sie für webbasierte Schnittstellen eine .HAR-Datei (Http ARchive) zur Verfügung. Das HAR-Analysetool bietet Anleitungen für drei wichtige Browser.
  • Fügen Sie tcpdump-Ausgaben, Log-Snippets oder Beispiel-Stacktraces an.

Problemtyp

  • Verbindungsprobleme: Verbindungsprobleme treten nach dem Zufallsprinzip ohne regelmäßige Fehlermuster auf. Verbindungsprobleme sind schwer zu beheben, da es aufgrund ihrer Unregelmäßigkeit schwierig ist, während 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 wiederholt auftreten und wenn Ihr Dienst dafür ausgelegt ist, vorübergehende Fehler zu tolerieren. 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) wurde für Fehler bei kleinen Paketverlusten und Latenzspitzen entwickelt und kann diese Probleme effektiv beheben, 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 die Schritte zum Reproduzieren des Problems, damit unsere Customer Care-Experten die Umgebung replizieren und das Problem für Sie beheben können.

Beispielbeschreibungen

Beispiel

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 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.

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 der Supportanfrage.

Definition der Priorität Beispielsituation
P1 – Kritische Auswirkungen – Dienstnutzung in Produktion nicht möglich Die Anwendung oder Infrastruktur kann in der Produktion nicht genutzt werden und weist eine erhebliche Anzahl von Fehlern auf, die den Nutzer direkt betreffen. Die geschäftlichen Auswirkungen sind entscheidend (Umsatzverlust, potenzielles Datenintegritätsproblem usw.).
P2 – Starke Auswirkungen – Dienst stark eingeschränkt Die Infrastruktur ist nur eingeschränkt in der Produktion verfügbar und weist eine beträchtliche Anzahl von Fehlern auf, die den Nutzer direkt betreffen, oder ist nicht in der Lage, ein neues Produktionssystem zu erstellen. Die Geschäftsauswirkungen sind mittelschwer (potenzieller Umsatzverlust, möglicher Produktivitätsverlust usw.).
P3 – Mittlere Auswirkungen – Dienst teilweise eingeschränkt Das Problem ist nicht besonders weitreichend und/oder schwerwiegend. Das Problem hat keine sichtbaren Auswirkungen auf den Nutzer. Die Geschäftsauswirkungen sind gering (z. B. Unannehmlichkeiten oder geringfügige Geschäftsprozesse).
P4 – Geringe Auswirkungen – Dienst vollständig nutzbar Kaum oder gar keine geschäftlichen oder technischen Auswirkungen. Empfohlen für Beratungstickets, bei denen eine umfassende Analyse, Fehlerbehebung oder Beratung einer häufigeren Kommunikation bevorzugt wird.

Wann muss die höchste Priorität eingestellt werden?

Wenn Sie ein Problem haben, das geschäftskritische Dienste betrifft und sofortige Aufmerksamkeit von Google erfordert, wählen Sie "P1" als Priorität. Erklären Sie ausführlich, warum Sie P1 ausgewählt haben. Beschreiben Sie kurz, welche Auswirkungen dieses Problem auf Ihr Unternehmen hat. Beispielsweise können Sie ein Problem mit einer Entwicklerversion als P1 betrachten, auch wenn keine Endnutzer direkt betroffen sind, da es ein kritisches Sicherheitsupdate blockiert.

Wenn ein Fall als P1 festgelegt ist, wird ein diensthabendes Supportteam sofort benachrichtigt, um den richtigen Experten zu finden, der sich ausschließlich mit diesem Problem befassen wird. Sie erhalten eine schnelle erste Antwort. Danach erhältst du regelmäßig Neuigkeiten.

Wir schätzen detaillierte Kommentare zur ausgewählten Priorisierungsstufe, weil sie uns helfen, angemessen zu reagieren.

Antwortzeiten

Problemprioritätsstufen haben vordefinierte Antwortzeiten, die in den Richtlinien für technische Supportdienste für die Google Cloud Platform definiert sind. Wenn Sie zu einem bestimmten Zeitpunkt eine Antwort benötigen, teilen Sie uns dies bitte in der Berichtsbeschreibung mit. Wenn ein P1-Problem rund um die Uhr bearbeitet werden muss, können Sie „Sun folgen“ anfordern. Diese Anfragen werden mehrmals täglich einem aktiven Customer Care-Spezialisten zugewiesen.

Eskalieren

Wenn sich die Umstände ändern, müssen Sie unter Umständen ein Problem eskalieren. Gute Gründe für die Eskalierung sind:

  • Steigerung der geschäftlichen Auswirkungen
  • Aufschlüsselung des Lösungsprozesses. Es ist beispielsweise nicht der Fall, dass Sie im vereinbarten Zeitraum keine Aktualisierungen erhalten haben oder das Problem nach dem Austausch mehrerer Nachrichten „nicht hängt“.

Wenn es bei Ihnen zu schwerwiegenden Problemen kommt, sollten Sie für den Fall auf angemessenen Zeitraum entsprechende Zeit einsparen, anstatt ihn eskalieren zu lassen. Eine Eskalierung führt nicht zwangsläufig dazu, dass der Fall schneller gelöst wird. Eine Eskalierung kurz nach der Prioritätsänderung kann sogar dazu führen, dass die Anfrage langsamer bearbeitet wird. Eine ausführlichere Erläuterung findet ihr im Video Wann sollte ich eskalieren?.

Weitere Informationen zum Eskalieren eines Falls finden Sie in diesem Hilfeartikel.

Fälle an die erforderliche Zeitzone weiterleiten

Aufgrund der Faktoren, auf denen die Customer Care-Verfügbarkeit basiert, kann Ihre Supportanfrage einem Customer Care-Spezialisten zugewiesen werden, der außerhalb Ihrer Geschäftszeiten arbeitet. Es ist auch möglich, dass Sie sich während der Geschäftszeiten einer bestimmten Zeitzone an den Kundendienst wenden. In solchen Fällen empfehlen wir, den Kundendienst zu kontaktieren, damit er Ihre Supportanfrage an eine für Ihren Fall geeignete Zeitzone weiterleitet. Sie können diese Anfrage in der Fallbeschreibung oder der Antwort hinzufügen. Beispiel: Please route this case to the Pacific time zone (GMT-8). P1-Fälle werden an die nächste Customer Care-Region übergeben, da diese dem So. folgt, während andere Fälle beim aktuellen Eigentümer bleiben, um am nächsten Tag weiter an dem Fall zu arbeiten.

Feedback über CES-Umfrage geben

Wenn ein Fall gelöst wird, wird eine CES-Umfrage (Customer Effort Score) in Bezug auf Ihre Meinung zum Verlauf des Prozesses per E-Mail gesendet. Wir würden uns sehr freuen, wenn Sie sich einige Minuten Zeit nehmen und uns mitteilen, was wir gut gemacht haben und welche Herausforderungen es gab, um diese Aspekte zu verbessern.

Jedes Feedbackformular wird manuell vom Customer Experience-Team geprüft und führt zu entsprechenden Maßnahmen zur Verbesserung des Supports in der Zukunft. Die Punktzahl liegt zwischen 1 und 5 ermittelt. Eine Punktzahl von 3 oder niedriger wird von Kundenseite als schwierig erachtet und wir werden Ihnen diesbezüglich antworten. Auf der anderen Seite bedeutet ein Wert von 4 oder höher, dass die Interaktion für den Kunden einfach (ohne Mühe) war und als positiv bewertet wurde.

Weitere Informationen finden Sie im Video So senden Sie Feedback zu Google Cloud-Diensten mit CES.

Lange andauernde oder schwierige Probleme

Probleme, deren Lösung lange dauert, können verwirrend werden und veralten. Der beste Weg, dies zu verhindern, ist das Erfassen von Informationen mithilfe unserer Vorlage für lange andauernde Probleme, wobei der neueste Status oben zusammengefasst ist.

Um die Vorlage zu verwenden, öffnen Sie einfach den vorherigen Link und erstellen Sie eine Kopie. Fügen Sie Links zu allen relevanten Fällen und internen Tracking-Fehlern hinzu. Teilen Sie dieses Dokument mit der Gruppe Ihres Account-Management-Teams und bitten Sie es, es für bestimmte Customer Care-Spezialisten freizugeben.

Dieses Dokument enthält Folgendes:

  • Eine oben aufgeführte Zusammenfassung des aktuellen Status
  • Eine Liste der Hypothesen, die möglicherweise wahr sind
  • Die Tests oder Tools, die Sie zum Testen jeder Hypothese verwenden möchten

Versuchen Sie, den Schwerpunkt eines Falls auf ein einzelnes Problem zu beschränken und vermeiden Sie es, einen Fall wieder zu öffnen, um ein neues Problem zu melden.

Einen Produktionsausfall melden

Wenn das Problem dazu geführt hat, dass Ihre Anwendung keinen Traffic mehr für Nutzer bereitstellt, oder ähnliche geschäftskritische Auswirkungen hat, könnte dies ein Produktionsausfall sein. Wir möchten dies so schnell wie möglich wissen. Probleme, die nur wenige Entwickler blockieren, erachten wir jedoch nicht als Produktionsausfälle.

Wenn wir von einem Produktionsausfall erfahren, prüfen wir die Situation schnell durch:

  • Sofortige Prüfung auf bekannte Probleme, die sich auf die Google Cloud-Infrastruktur auswirken.
  • Überprüfung der Art des Problems
  • Einrichtung von Kommunikationskanälen

Sie erhalten eine Antwort mit einer kurzen Nachricht, die Folgendes enthält:

  • Alle damit verbundenen bekannten Probleme, die mehrere Kunden betreffen
  • Eine Bestätigung, dass wir das von Ihnen gemeldete Problem sehen können, oder eine Anfrage für weitere Details
  • Wie wir kommunizieren möchten.

Daher ist es wichtig, schnell einen Fall zu erstellen, der Zeit, Produkt, Kennzeichnungen und Ort enthält, und dann mit einer umfassenderen Fehlerbehebung zu beginnen. Möglicherweise hat Ihr Unternehmen einen Vorfallmanagement-Prozess definiert, und dieser Schritt sollte möglichst zu Beginn ausgeführt werden.

Der Vorfallmanagement-Prozess von Google definiert eine Schlüsselrolle: den Incident Commander. Diese Person sorgt dafür, dass die richtigen Personen einbezogen werden, erfasst kontinuierlich den aktuellen Status und fasst den Status des Problems regelmäßig zusammen. Sie delegiert an andere, um Fehler zu beheben und Änderungen vorzunehmen. Diese Delegation ermöglicht es uns, mehrere Hypothesen parallel zu untersuchen. Wir empfehlen Ihnen, einen ähnlichen Prozess in Ihrer Organisation einzurichten. Die Person, die den Fall erstellt hat, ist normalerweise die beste Wahl, um als Incident Commander zu fungieren, da sie den meisten Kontext hat.

Ein Netzwerkproblem melden

Aufgrund der Größe und Komplexität des Netzwerks von Google kann es schwierig sein, zu ermitteln, welches Team für das Problem verantwortlich ist. Um Netzwerkprobleme zu diagnostizieren, müssen wir sehr spezifische Ursachen identifizieren. Da Netzwerk-Fehlermeldungen oft allgemein sind (wie "Verbindung zum Server nicht möglich"), müssen wir detaillierte Diagnoseinformationen erfassen, um die möglichen Hypothesen einzugrenzen.

Paketflussdiagramme bieten eine hervorragende Struktur für den Problembericht. Diese Diagramme beschreiben die wichtigen Hops, die ein Paket entlang eines Pfades von der Quelle zum Ziel nimmt, zusammen mit signifikanten Transformationen auf dem Weg.

Ermitteln Sie zuerst die betroffenen Netzwerkendpunkte nach Internet-IP-Adresse oder nach RFC 1918 privater Adresse und einer Kennung für das Netzwerk. Beispiel: 2.3.4.5 oder 10.2.3.4 im Standardnetzwerk des Compute Engine-Projekts.

Notieren Sie sinnvolle Informationen zu den Endpunkten, z. B.:

  • Wer sie kontrolliert
  • Ob sie einem DNS-Hostnamen zugeordnet sind
  • Zwischenkapselungen und/oder Umwege, z. B. VPN-Tunneling, Proxys und NAT-Gateways
  • Jede Zwischenfilterung, wie Firewalls oder CDN oder WAF

Viele Probleme, die sich durch hohe Latenz oder zeitweisen Paketverlust bemerkbar machen, erfordern eine Pfadanalyse und/oder eine Paketerfassung zur Diagnose.

  • Die Pfadanalyse ist eine Liste aller Hops, die Pakete durchlaufen, und ist als "Traceroute" bekannt. Wir verwenden oft MTR und/oder tcptraceroute, weil diese Tools eine bessere Diagnosekraft haben. Machen Sie sich daher mit diesen Tools vertraut.
  • Die Paketerfassung (auch als „pcap“ aus dem Namen der Bibliothek „libpcap“ bezeichnet) ist eine Beobachtung des echten Netzwerk-Traffics. Es ist wichtig, für beide Endpunkte gleichzeitig eine Paketaufnahme zu erstellen, was schwierig sein kann. Wir empfehlen, mit den erforderlichen Tools (z. B. tcpdump oder Wireshark) zu üben und zu prüfen, ob sie installiert werden, bevor Sie sie benötigen.