Best Practices für die Arbeit mit dem Cloud Support

Wenn Sie einen detaillierten Supportfall erstellen, ist es für das Google-Supportteam leichter, Ihnen schnell und effizient zu antworten. Wenn in Ihrem Supportfall wichtige Details fehlen, müssen wir nach weiteren Informationen fragen, was zusätzliche Zeit in Anspruch nimmt. In diesem Leitfaden erfahren Sie, welche Informationen wir zur Bearbeitung Ihres technischen Supportfalls benötigen, damit wir die Probleme schneller lösen können.

Problem beschreiben

Die besten Problemberichte sind sowohl detailliert als auch spezifisch. Aus ihnen geht hervor, was passiert ist und was Sie erwartet haben. Ein guter Problembericht enthält die folgenden Details:

  • Zeit: Der spezifische Zeitstempel, als das Problem begann.
  • Produkt: Die Produkte und Funktionen, die mit dem Problem verbunden sind.
  • Zone: 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.
  • 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 beendet: 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 Supporttechniker, der das Problem bearbeitet, befindet sich höchstwahrscheinlich nicht in Ihrer Zeitzone. 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 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, gcloud-Tool, Cloud Console oder möglicherweise ein Tool wie 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..." (Wir müssen darüber informiert werden, welche Methode Sie zum Erstellen von Instanzen verwenden.)
  • "Der Befehl gcloud compute create instances ergibt einen Fehler..." (Die Befehlssyntax ist falsch, 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.)

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 mit einer Compute-Instanz, einem Lastenausgleichsmodul, 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)..."
  • "Die Verbindung zur externen GCP-IP-Adresse 218.239.8.9 von unserem privaten Gateway 56.56.56.56 aus..."

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 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 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. Beachten Sie, dass das Transmission Control Protocol (TCP) auf Fehler wie kleine Paketverluste und Latenzspitzen ausgelegt ist und diese Probleme effektiv verarbeiten kann, 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 zur Reproduktion des Problems mit, damit unsere Supporttechniker die Umgebung replizieren und das Problem beheben können.

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

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 nur eingeschränkt in der Produktion verfügbar und weist eine störende 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. Das Problem verursacht lediglich Unannehmlichkeiten oder es sind nur unwesentliche Geschäftsprozesse betroffen.
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 uns im Detail, warum Sie P1 gewählt haben. Fügen Sie eine kurze Beschreibung der Auswirkungen dieses Problems auf Ihr Unternehmen ein. Beispielsweise können Sie ein Problem mit einer Entwicklungsversion als P1 betrachten, wenn ein kritisches Sicherheitsupdate blockiert wird, auch wenn keine direkten Auswirkungen auf Endnutzer bestehen.

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 kurze erste Antwort (innerhalb von 15 Minuten für Unternehmenskunden und bis zu einer Stunde für die Produktionsrolle des rollenbasierten Supportexperten). Danach erhalten Sie regelmäßige Updates.

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 Google Cloud Platform-Richtlinien für technische Supportdienste definiert sind. Wenn Sie eine Antwort bis zu einem bestimmten Zeitpunkt benötigen, teilen Sie uns dies in Ihrer Berichtsbeschreibung mit. Wenn ein P1-Problem rund um die Uhr behandelt werden muss, können Sie den Dienst "Follow the Sun" anfordern. Diese Fälle werden mehrmals täglich einem aktiven Supporttechniker zugewiesen.

Eskalieren

Wenn sich die Umstände ändern, müssen Sie möglicherweise das Problem eskalieren, damit es schneller behandelt wird. Gute Gründe für die Eskalation sind:

  • Steigerung der geschäftlichen Auswirkungen
  • Problem muss schneller gelöst werden
  • Problem ist nach dem Austausch mehrerer Nachrichten ohne Fortschritt "stecken geblieben"

Bei Eskalation eines GCP-Supportfalls wird sofort ein Supportmanager benachrichtigt und Sie werden innerhalb einer Stunde informiert. Der Escalation Manager ist für die Eskalation bis zu deren Schließung zuständig. Der Manager wird die Eskalationsursache ermitteln und beheben sowie vorbeugende Maßnahmen ergreifen, um ähnliche Eskalationen in Zukunft zu vermeiden.

Wenn Sie einen Fall eskalieren möchten, können Sie eine Eskalation in den Kommentaren im aktuellen Fall anfordern oder auf die Schaltfläche Eskalieren klicken, die 60 Minuten nach dem Erstellen des Falls angezeigt wird.

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 obigen Link und erstellen 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 sie, es mit bestimmten Supporttechnikern zu teilen.

Dieses Dokument enthält:

  • 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 Datenverkehr mehr an Nutzer weiterleiten konnte, oder ähnliche geschäftskritische Auswirkungen hat, kann 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 die GCP-Infrastruktur betreffen
  • Überprüfung der Art des Problems
  • Einrichtung von Kommunikationskanälen

Sie können eine Antwort mit einer kurzen Nachricht erwarten, die Folgendes enthalten wird:

  • 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 (z. B. Telefon, Hangout oder Fall)

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. Ihre Organisation hat möglicherweise einen definierten Vorfallmanagement-Prozess 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.

Beginnen Sie mit der Identifizierung der betroffenen Netzwerkendpunkte anhand der Internet-IP-Adresse oder der privaten RFC 1918-Adresse und einer Kennzeichnung 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 diagnostische Leistungsfähigkeit haben. Bitte machen Sie sich also mit diesen Tools vertraut.
  • Die Paketerfassung (auch bekannt als "pcap", abgeleitet aus dem Namen der Bibliothek "libpcap") ist eine Beobachtung des realen Netzwerkdatenverkehrs. Es ist wichtig, eine Paketerfassung für beide Endpunkte gleichzeitig vorzunehmen, was schwierig sein kann. Installieren Sie daher frühzeitig die notwendigen Tools (beispielsweise tcpdump oder Wireshark) und machen Sie sich mit ihnen vertraut.

Beispielfälle

Beispiel 1

Jobname:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Quelle:

S3_avl-transfer

Ziel:

CloudStorage: avl-transfer

Startzeit (ISO 8601-Format): 2017-04-20 20:14:43 PDT

Endzeit (ISO 8601-Format): 2017-04-21 um 10:03:44 PDT

Ich habe am 2017-04-20 um 20:14:43 Uhr PDT eine Dateiübertragung mit der Transfer API gestartet. Dieser Job dauert in der Regel 10 Minuten. In diesem Fall lief der Job jedoch noch, als ich ihn am nächsten Tag stornierte (2017-04-21 um 10:03:44 PDT). Dies ist kein isoliertes Ereignis. Mehrere andere Jobs, bei denen die Transfer API verwendet wurde, hatten zeitweise erhebliche Verzögerungen.

Bitte untersuchen Sie die Ursache der Verzögerungen und geben Sie Hinweise zu Best Practices, die wir implementieren können, um diese Probleme in Zukunft zu vermeiden.

Beispiel 2

Startzeit (ISO 8601-Format): 2017-05-12 11:03:43

Endzeit (ISO 8601-Format): Das Problem tritt zum Zeitpunkt dieses Berichts noch immer auf.

Problemzusammenfassung:

Der Cronjob /cron/payments-service/sync-v2-batch, der die App Engine Task Queue API verwendet, wird seit dem 2017-05-12 um 11:03:43 nicht mehr ausgeführt. Wir sind auf diesen Job angewiesen, um Zahlungen korrekt abzuwickeln.

Wir haben Datenspeicher- und Warteschlangenfehler gesehen und dann wurde der Cronjob nicht mehr ausgeführt. Wir haben versucht, das Problem durch erneutes Hochladen von cron.xml zu beheben, leider ohne Erfolg. Hier ist der Fehler-Trace:

[error trace]

Teilen Sie uns mit, ob es sich um ein Problem mit der API oder unserer Implementierung handelt, und informieren Sie uns über die nächsten Schritte.