Diese Seite wurde von der Cloud Translation API übersetzt.

Best Practices für die Zusammenarbeit mit dem Kundenservice

In diesem Leitfaden finden Sie Best Practices für das Verfassen eines effektiven Supports. Fall. Die Einhaltung dieser Best Practices hilft uns dabei, den technischen Support schneller Fall.

Supportanfrage erstellen

Bevor Sie eine Supportanfrage erstellen, lesen Sie sich die bekannten , um zu sehen, wurde bereits eingereicht.

Um Verwechslungen zu vermeiden und Ihre Anfrage zentral zu verfolgen, pro Problem eine Supportanfrage erstellen. Alle doppelten Fälle, die erstellt werden, geschlossen.

Problem beschreiben

Wenn Sie einen detaillierten Supportfall erstellen, ist es für das Customer Care-Team leichter, Ihnen schnell und effizient zu antworten. Wenn Ihre Supportanfrage wenn wichtige Details fehlen, müssen wir um weitere Informationen bitten. zusätzliche Zeit.

Die besten Supportanfragen sind sowohl detailliert als auch spezifisch. Aus ihnen geht hervor, was passiert ist und was Sie erwartet haben. Wenn Sie Ihr Problem in Ihrem Supportfall an, geben Sie die folgenden Informationen an:

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.
Kennungen: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 zeitweise, vorübergehend oder dauerhaft auf.

In den folgenden Abschnitten sind diese Konzepte detaillierter beschrieben.

Zeit

Sie verwenden das Format ISO 8601. das Datum und den Zeitstempel, geben Sie an, wann Sie dieses Problem zum ersten Mal bemerkt haben und wie wie lange es dauerte.

Beispiele:

Ab 2017-09-08T15:13:06+00:00 und bis fünf Minuten später beobachtet...
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 Kundendienst-Spezialist, der das Problem löst, ist höchstwahrscheinlich nicht Ihre Zeitzone, sodass relative Aussagen wie die folgenden das Problem erschweren zur Diagnose:

"Das hat irgendwann gestern angefangen..." (Zwingt uns, das implizierte Datum abzuleiten.)
"Wir haben das Problem am 9/8 bemerkt..." (Mehrdeutig, da einige dies interpretieren könnten, da es sich um den 8. September handelt, in anderen wird der 9. August als Datum interpretiert.

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.

Teilen Sie uns auch mit, mit welchem Mechanismus Sie die Anfrage initiieren (für z. B. die REST API, die Google Cloud CLI, die Google Cloud Console oder ein Tool wie Cloud Deployment Manager Wenn mehrere Produkte involviert sind, geben Sie bitte jedes Namen geben.

Beispiele:

"Compute Engine REST API hat folgende Fehler zurückgegeben..."
„Die BigQuery-Abfrageschnittstelle unter 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..." (Wir müssen darüber informiert werden, welche Methode Sie zum Erstellen von Instanzen verwenden.)
„Der Befehl gcloud compute create instances gibt einen Fehler aus...“ (Der Befehlssyntax ist falsch, daher können wir sie nicht selbst ausführen, um Fehler. 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-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. 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. Für ob die IP-Adresse mit einer Compute-Instanz, einem Load-Balancer, eine benutzerdefinierte Route oder einen API-Endpunkt. Teilen Sie uns auch mit, wenn die IP-Adresse nicht die mit den Systemen von Google zusammenhängen (z. B., wenn die IP-Adresse für Ihr Zuhause Internet, VPN-Endpunkt oder externes Überwachungssystem).

Beispiele:

"Im Projekt robot-name-165473 oder my-project-id..."
"Über mehrere Projekte hinweg (darunter my-project-id)..."
„Verbindung zur externen Google Cloud-IP-Adresse 218.239.8.9 von unserem Unternehmen Gateway 56.56.56.56..."

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 Oberflächen ein .HAR (Http) ARchive). Das HAR Analyse-Tool für die drei wichtigsten 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 und wenn Ihr Dienst tolerant gegenüber temporären Ereignissen ist, Störungen. 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 ausgelegt z. B. Paketverluste und Latenzspitzen, und kann diese es sei denn, Ihre Anwendung reagiert empfindlich auf Latenz.
Konsistente Probleme: Diese Probleme führen zu einem vollständigen Ausfall, z. B. wenn Ihre Website nicht verfügbar ist. Konstante Probleme lassen sich da sie reproduziert werden können. Teilen Sie uns in diesem Fall mit, um das Problem zu reproduzieren, damit unsere Kundendienstmitarbeiter die Umgebung zu replizieren und das Problem für Sie zu beheben.

Beispielbeschreibungen

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 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 Supportanfrage Priorität

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äftsauswirkungen sind kritisch (Umsatzverlust, potenzielles Datenintegritätsproblem usw.).
P2 – Starke Auswirkungen – Dienst stark eingeschränkt	Die Infrastruktur ist in der Produktion eingeschränkt und hat eine spürbare Rate Fehler oder Schwierigkeiten beim Hochfahren eines neuen Produktionssystems zu betonen. 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äftlichen Auswirkungen sind gering (z. B. Unannehmlichkeiten, oder geringfügig betroffenen 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 aufwendigen Kommunikation mit vielen Nachrichten vorgezogen 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 es uns in warum Sie sich für P1 entschieden haben. Beschreiben Sie kurz die Auswirkungen dieses Problems. auf Ihr Unternehmen hat. Sie könnten z. B. ein Problem mit der Entwicklung P1 zu sein, selbst wenn keine Endnutzer direkt betroffen sind, wenn sie ein kritisches Sicherheitsupdate.

Wenn ein Fall als P1 festgelegt ist, wird ein Experte sofort darauf hingewiesen, sich ausschließlich an die Arbeit zu beteiligen. zu diesem Thema. Sie erhalten eine erste Antwort, wenn Sie einem Livestream beitreten möchten Probleme bei einem Anruf über Google Meet beheben. Wenn Ihre Organisation keine Google Meet: Fügen Sie einen Link zur Videokonferenzsoftware Ihrer Wahl hinzu. bis der Experte dazukommt. Danach erhalten Sie regelmäßig Updates über die Fall.

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

Was Sie vom Support für P1-Supportfälle erwarten können

Neues P1 Case
- Ein Supportmitarbeiter wird sich über Google Meet oder eine andere von Ihnen bereitgestellter Brücke. Wir erwarten, dass Sie innerhalb von 15 bis 30 Tagen Minuten. Informieren Sie den Supportexperten, wenn Sie aus irgendeinem Grund nicht am Anruf teilnehmen können. Grund.
- Der Fall „folgt der Sonne“ ist standardmäßig aktiviert. Das bedeutet, dass die Supportexperten 24 Stunden am Tag zu arbeiten, bis der Fall gemindert oder herabgestuft wird. Fall ist eine Abhilfemaßnahme in einer bestimmten Region am besten. in einer bestimmten Zeitzone. Sie können uns gerne mitteilen, ob Sie diesen Effekt bevorzugen.
P1-Prioritätserhöhung
- Wenn das Problem erste Auswirkungen auf Ihre Produktionsumgebung hat können Sie die Priorität eines vorhandenen P2- bis P4-Falls auf P1 erhöhen.
- Wenn Sie die Priorität eines bestehenden Falls auf P1 erhöhen, wird die Supportanfrage kann neu zugewiesen werden, damit ein verfügbarer Support-Experte Aufmerksamkeit.
Auswirkungen der Nicht-Produktion

Um sicherzustellen, dass angemessene Ressourcen bei Bedarf zugewiesen werden, kann der Support sich mit Ihnen in Verbindung setzen, um Anfragen, die als P1 gekennzeichnet wurden und keine Auswirkungen haben, neu zu bewerten oder große Auswirkungen auf das Geschäft haben.

Antwortzeiten

Problemprioritätsstufen haben vordefinierte Antwortzeiten, die in den Google Cloud Platform-Richtlinien für technische Supportdienste. Bei Bedarf eine Antwort bis zu einem bestimmten Zeitpunkt erhalten, teilen Sie uns dies in Ihrer Berichtsbeschreibung mit. Wenn ein P1- Problem rund um die Uhr bearbeitet werden muss, "folgen Sie der Sun"-Dienst abrufen. Diese Anfragen werden mehrmals täglich einem aktiven Customer Care-Team spezialisiert hat. Während wir uns um die Behebung Ihres P1-Falls kümmern, empfehlen wir Ihnen, bis zur Klärung der Fragen bereit sind, Kommunikation. Wenn Sie länger als drei Stunden nicht reagieren, verringern wir möglicherweise die Priorität des Falls auf P2 zu übertragen, bis Sie ihn wieder kontaktieren.

Eskalieren

Wenn sich die Umstände ändern, müssen Sie möglicherweise ein Problem eskalieren. Gute Gründe zur Eskalation:

Steigerung der geschäftlichen Auswirkungen
Aufschlüsselung des Lösungsprozesses. Wenn Sie beispielsweise keine E-Mail innerhalb des vereinbarten Zeitraums aktualisieren oder das Problem ohne zwischen dem Austausch mehrerer Nachrichten.

Bei einem schwerwiegenden Problem besteht die beste Lösung darin, nicht innerhalb eines angemessenen Zeitraums und es eskaliert. Eine Eskalation löst den Fall nicht unbedingt schneller und Eine Eskalation kurz nach der Prioritätsänderung kann sogar dazu führen, langsamer sein. Eine ausführlichere Erläuterung finden Sie im Artikel Wann sollten Sie Video eskalieren.

Informationen zum Eskalieren eines Falls finden Sie unter Eskalieren eines .

Supportanfragen an die erforderliche Zeitzone weiterleiten

Aufgrund der Faktoren, bei denen der Kundendienst Verfügbarkeit basiert, kann die Supportanfrage einem Kundendienstmitarbeiter zugewiesen werden, der außerhalb Ihrer Geschäftszeiten erfolgen. Möglich ist auch, dass Sie das Interesse mit Customer Care an den Werktagen in einer bestimmten Zeitzone. In in solchen Fällen sollten Sie den Kundendienst bitten, Ihre an die Zeitzone Ihres Supportfalls senden. 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ächsten für die Kundenbetreuung in einer Region, da die Sonne während die anderen Anfragen dem aktuellen Verantwortlichen überlassen würden, den Fall am nächsten Tag.

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 wirklich Bitte nehmen Sie sich ein paar Minuten Zeit, um sie auszufüllen. was wir gut gemacht haben und welche Herausforderungen wir hatten, 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. Ein Wert von 3 oder niedriger würde vom Wir werden uns dann bei Ihnen melden. Auf der anderen bedeutet ein Wert von 4 oder mehr, dass die Interaktion für den und als positive Erfahrung betrachtet wird.

Weitere Informationen finden Sie unter Feedback zu Google Cloud-Diensten einreichen mit CES-Video.

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.

Wenn Sie die Vorlage verwenden möchten, öffnen Sie den vorherigen Link und erstellen Sie eine Kopie. Einschließen Links zu allen relevanten Fällen und internen Tracking-Fehlern Dieses Dokument freigeben für Ihres Account-Management-Teams an und bitten Sie es, Customer Care-Experten.

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 an Nutzer weiterleitet, oder ähnliche geschäftskritische Auswirkungen hat, könnte es sich um einen Produktionsausfall handeln. 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. Ihr Unternehmen einen definierten Vorfallmanagement-Prozess haben. 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.

Beginnen Sie mit der Identifizierung der betroffenen Netzwerkendpunkte anhand der Internet-IP-Adresse oder RFC 1918 private Adresse plus eine Kennung für das Netzwerk. Beispiel: 2.3.4.5 oder 10.2.3.4 auf der Standardnetzwerk des Compute Engine-Projekts.

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

Wer sie kontrolliert
Ob sie einem DNS-Hostnamen zugeordnet sind
Zwischenkapselung oder Umleitung oder beides, z. B. VPN-Tunneling, Proxys und NAT-Gateways.
Jede Zwischenfilterung, wie Firewalls oder CDN oder WAF

Viele Probleme, die sich als hohe Latenz oder zeitweise Paketverluste äußern, eine Pfadanalyse, eine Paketerfassung oder beides zur Diagnose erfordern.

Die Pfadanalyse ist eine Liste aller Hops, die Pakete durchlaufen, und ist als "Traceroute" bekannt. Wir verwenden oft MTR oder tcptraceroute oder beides, da sie eine bessere diagnostische Leistungsfähigkeit haben. Wir empfehlen Ihnen, sich mit diesen Tools vertraut zu machen.
Paketerfassung (auch als „pcap“ bezeichnet, nach dem Namen der Bibliothek) „libpcap“) ist eine Beobachtung des realen Netzwerkverkehrs. Es ist wichtig, für beide Endpunkte gleichzeitig zu erfassen, was schwierig sein kann. Es empfiehlt sich, mit den notwendigen Tools (z. B. tcpdump oder Wireshark) bevor Sie sie benötigen.