Dies ist Teil 2 des Überblicks über das Vorfallmanagement bei Zendesk. Dieser Leitfaden enthält die folgenden Teile:
- Teil 1: Wie Zendesk-Serviceanfragen zu Servicevorfällen werden
- Teil 2: Wie Zendesk Servicevorfälle handhabt (dieser Beitrag)
- Teil 3: Überwachen eines öffentlichen Zendesk-Servicevorfalls
- Teil 4: Analyse und Berichterstellung nach der Lösung von Vorfällen
In diesem Beitrag erfahren Sie, wie die Zendesk-Teams je nach Schweregrad auf Servicevorfälle in unseren Produkten reagieren. Zendesk verfolgt einen umfassenden Ansatz, um einen Vorfall zu verstehen – von der Ursache bis hin zur vollständigen Auswirkung auf die betroffenen Kunden – und kommuniziert den entsprechenden Detailgrad.
Dieser Beitrag enthält die folgenden Abschnitte:
- Vorfallschwere
- Teamstruktur der Vorfallreaktion
- Kommunikationszeiträume für Vorfälle
- Vorfallprozess mit niedrigem Schweregrad
Vorfallschwere
Eine der wichtigsten Entscheidungen, die beim Erstellen eines Servicevorfalls getroffen werden, ist die Zuweisung des Schweregrads des Vorfalls. Der Schweregrad eines Vorfalls bestimmt, wie und welche Zendesk-Teams das Problem angehen und wie es den betroffenen Kunden mitgeteilt wird.
Zendesk verwendet ein System, das Servicevorfälle basierend auf den Merkmalen des Vorfalls in fünf Schweregrade unterteilt:
Schweregradbewertungssystem von Zendesk
Je nach Schweregrad werden verschiedene Eskalationspfade und Teams eingesetzt, um den Vorfall zu untersuchen, zu kommunizieren und zu beheben. Dadurch wird sichergestellt, dass jeder Vorfall mit der richtigen Sorgfalt behandelt wird. Das folgende Diagramm beschreibt die wichtigsten Aktivitäten während und nach der Behebung eines Vorfalls anhand seines Schweregrads:
Prozess nach Schweregrad
Während Vorfälle mit hohem Schweregrad rigoros analysiert und behoben werden, durchläuft jeder Vorfall – unabhängig vom Schweregrad – einen Echtzeitreaktions- und Untersuchungsprozess. Das Ergebnis:
- Aktualisierung der Zendesk-Statusseite, wenn der Vorfall öffentlich ist
- Ursachenanalyse und Vorfallbehebung
- Zendesk (interner) Vorfallbericht
Beispiel für Zendesk-Dienstverfügbarkeitsvorfälle
Nachfolgend ein Beispiel, wie der Vorfallsschweregrad von Zendesk festgelegt wird und wie Zendesk-Teams intern reagieren:
Beispiel für Vorfallerkennung und -reaktion
In diesem Beispiel sehen Sie den folgenden Workflow:
- Das Zendesk Network Operations Center (ZNOC) erkannte ein Problem, bei dem Systemwarnungen zeigten, dass Serviceknoten in Pod 17 von Anfragen nicht erreicht werden konnten. Das Zendesk Network Engineering-Team stellte sicher, dass sich die Zugriffsprobleme direkt auf den Kundenservice auswirkten, und erkannte schnell, dass die Support, Guide- und Talk-Services für mehrere Kunden nicht wie erwartet funktionierten. Ein neuer Zendesk-Servicevorfall wurde erstellt.
- Dieser Vorfall war zu Beginn bereits für zwei Kunden bekannt, aber aufgrund der Art des Ausfalls trat das Problem bei mehr Kunden auf und begann, ihre Probleme mit dem Zendesk-Kundensupport anzusprechen. Der Vorfall wurde vom Engineering-Team mit der Schweregradbewertung 1 bewertet – ein Vorfall mit hoher Priorität, der sofortige Aufmerksamkeit erfordert.
- Das Bereitschaftsteam wurde sofort angepiept. Innerhalb weniger Minuten nach Erstellung des Vorfalls sammelte ein Vorfallmanager Informationen und stellte zusätzliche Engineering-Ressourcen zusammen, um den Servicevorfall zu beheben.
Teamstruktur der Vorfallreaktion
Zendesk verfügt über ein dediziertes globales Incident Response Team, das dafür sorgt, dass jeder Vorfall im Rahmen des Service-Incident-Management-Prozesses gemanagt und bei Bedarf an die richtige Zendesk-Führungsebene eskaliert wird.
Rollen und Verantwortlichkeiten im Vorfallmanagement
Diese Teamstruktur ermöglicht es Zendesk, den Vorfall mit technischen Ressourcen gründlich zu analysieren und über den Zendesk-Kundensupport in Echtzeit mit Kunden zu kommunizieren.
Kommunikationszeitpläne für Vorfälle
Zendesk setzt alles daran, Vorfälle in angemessenen Zeiträumen für den Kunden zu kommunizieren und zu lösen. Wir haben interne Zeitpläne für die Verteilung von Vorfalldetails festgelegt. Die Zeitleiste basiert auf dem Schweregrad des Vorfalls und den Phasen des Servicevorfallsmanagements.
| Phase | Antwortzeiträume |
| Öffentliche Bekanntmachung | Innerhalb von 15 Minuten nach dem Vorfall |
| Vorfallaktualisierungen | Alle 30 Minuten, bis der Service wiederhergestellt ist oder neue Informationen verfügbar werden |
|
Ereignisanalyse (bei Vorfällen mit Schweregrad 0 und 1) |
Innerhalb von 48 Stunden nach Lösung des Vorfalls |
| Ursachenanalyse | Innerhalb von 72 Stunden nach Lösung des Vorfalls |
| Rückblick auf öffentliche Vorfälle | Innerhalb von 96 Stunden nach Lösung des Vorfalls |
Vorfälle mit einer Schweregradbewertung von 0 - 2 gelten als Vorfälle mit hohem Schweregrad. Wenn ein Vorfall mit hohem Schweregrad auftritt, ist das globale Bereitschaftsteam rund um die Uhr verfügbar, um auf diese Vorfälle zu reagieren. Das Team besteht aus den folgenden Rollen:
Teamrollen für Vorfallreaktionen
Standorte des globalen Incident Response Teams
Wenn das Bereitschaftsteam eine Seite aufruft, beginnt die Vorfalldiagnose innerhalb von Minuten nach Meldung des Vorfalls. Ein Slack Channel und ein Zoom-Anruf werden erstellt, damit das Antwortteam in Echtzeit kommunizieren kann. Während das Incident-Response-Team den Vorfall triagiert und ausdehnt, werden die Engineering-Teams in Bereitschaft nach den betroffenen Produkten und Dienstleistungen aufgeschlüsselt.
Ein öffentlicher Post auf der Zendesk-Statusseite wird innerhalb von 15 Minuten nach Erstellung des Vorfalls veröffentlicht, damit Kunden über den bekannten Vorfall auf dem Laufenden sind. Aktualisierungen werden danach alle 30 Minuten gepostet, bis die Lösung verfügbar ist. Je nach Problem und Anzahl neuer Informationen kann diese Kadenz je nach Bedarf reduziert oder verlängert werden. Kunden können aktive Servicevorfälle auf der Zendesk-Statusseite überwachen. Dieser Prozess wird in Teil 3 dieses Leitfadens beschrieben.
Zusätzlich zu unseren globalen Bereitschaftsteams hat Zendesk Prozesse zur Benachrichtigung und Eskalation von Führungskräften eingerichtet. Wenn ein Vorfall mit hohem Schweregrad bestimmten Kriterien entspricht, aktivieren wir die nächste Reaktionsebene: Krisenmanagement.
Beispiel für Zendesk-Dienstverfügbarkeitsvorfälle fortgesetzt
In Fortführung des Serviceverfügbarkeitsvorfalls geht die Vorfallreaktion bei Zendesk wie folgt durch den Vorfallmanagementprozess:
Zeitleiste für die Antwort auf Serviceverfügbarkeitsvorfälle
Wie Sie im Beispiel sehen, wurden nach Erstellung des Vorfalls im Zendesk-Vorfallportal eine Reihe automatisierter Aktionen durchgeführt:
- Das Bereitschaftsteam für Vorfallreaktionen wurde seitenweise auf den Vorfall reagiert.
- Ein Slack-Channel für Vorfälle wurde automatisch erstellt und das Bereitschaftsteam für Vorfälle wurde zum dedizierten Slack-Channel hinzugefügt.
- Ein Zoom-Anruf wurde automatisch gestartet und an den Slack Channel gesendet, damit alle Responder beitreten können.
- Es wurde automatisch ein Dokument mit einer Ereigniszusammenfassung erstellt, das den Vorfall dokumentiert und den Fortschritt intern mit Zendesk teilt.
Im Zoom-Anruf bestätigte der Vorfallmanager den anfänglichen Schweregrad und bestätigte den Umfang und die Auswirkungen des Problems.
Es stellte sich schnell heraus, dass mehrere Containerknoten in Pod 17 nicht erreichbar waren und von abhängigen Diensten wie Support, Guide und Talk nicht verwendet werden konnten. Insbesondere ein Knotentyp hatte in anderen Pods keine verfügbaren Replikate. Dies würde letztendlich dazu führen, dass diese Produkte für mehrere Kunden nicht mehr reagierten.
Das ZNOC hat das entsprechende Network Engineering-Team zum Zoom-Aufruf weitergeleitet, um zu untersuchen, wie das unmittelbare Problem der Wiederherstellung des Service- und API-Zugriffs für Kunden gelöst werden kann. Edge Engineering-KMUs wurden ebenfalls angepiept und schlossen sich dem Aufruf an. Innerhalb von 5 Minuten wurde eine Korrektur gefunden und bereitgestellt, sodass die betroffenen Knoten wieder für API-Aufrufe und -Services zugänglich waren.
Der Zendesk-Kundensupport erstellte ein Problemticket zur Verfolgung der Kundenberichte. Dieses Ticket wurde zum Channel „Slack Incident“ hinzugefügt, damit neue Berichte schnell hinzugefügt werden können.
Während die Untersuchung fortgesetzt wurde, erstellte der Vorfalleskalationsmanager 12 Minuten nach Erstellung des Vorfalls die erste öffentliche Aktualisierung auf der Zendesk-Statusseite und veröffentlichte sie.
Erster Beitrag zu Service Availability Incident auf der Zendesk-Systemstatusseite
Während die Teams den Vorfall untersuchten, wurden eingehende Kundenberichte mit dem Hauptproblemticket verknüpft, das mit dem Vorfall verknüpft war. Auf diese Weise konnte das Incident-Response-Team allen betroffenen Kunden Updates senden, wenn sie öffentliche Benachrichtigungen versendeten.
Das Network Engineering-Team hat eine Änderung der Art und Weise festgestellt, wie Zertifikate generiert und verwendet wurden, und die folgenden Maßnahmen ergriffen, um den Service für betroffene Kunden wiederherzustellen:
- Nicht erreichbare Knoten deaktiviert
- Neue Serviceknoten mit korrekt referenzierten Zertifikaten erstellt
- Verifiziert, dass neue Serviceknoten für Dienste und über API-Aufrufe erreichbar waren
- Überwachte den eingehenden Datenverkehr, um sicherzustellen, dass eingehende Anfragen jetzt ordnungsgemäß bearbeitet wurden.
Im Laufe des Vorfalls wurden zwei weitere öffentliche Aktualisierungen vorgenommen: Eine 14 Minuten nach der Vorfallerstellung und eine weitere 63 Minuten nach der Vorfallerstellung. Der Verlauf der öffentlichen Kommunikation mit den veröffentlichten Informationen zur rückwirkenden Veröffentlichung des Vorfalls finden Sie auf der Seite „Servicebenachrichtigungen“.
Wie im Beispiel gezeigt, durchlaufen Vorfälle mit hohem Schweregrad einen rigorosen Prozess, bei dem die Hauptursachen ermittelt und Korrekturelemente für Produktentwicklungsteams erstellt werden, um das zugrundeliegende Problem zu beheben. Diese Analyse findet während unserer Vorfallrückschau statt und wird im Abschnitt „Nachlösungsvorfallanalyse“ ausführlicher behandelt.
Vorfallprozess mit niedrigem Schweregrad
Servicevorfälle niedrigeren Schweregrads (Stufe 3-4) sind weniger kritisch, da sie eine geringere Anzahl von Kunden betreffen und diese nicht daran hindern, geschäftskritische Funktionen von Zendesk-Produkten zu nutzen. Diese Vorfälle werden gemäß den oben genannten Richtlinien behandelt, aber nicht in öffentlichen Kanälen gepostet.
Vorfälle mit Schweregrad 3 werden ähnlich gehandhabt wie Vorfälle mit Schweregrad 0-2. Aufgrund der geringeren Geschäftsauswirkungen verlängern sich die erwarteten Antwortzeiten. Obwohl das Bereitschaftsteam nicht angepiept ist, werden diese Vorfälle über spezifische Zendesk Incident Slack Kanäle bearbeitet, die mit dem unterstützenden Produktentwicklungsteam verknüpft sind, und die Teams reagieren in der Regel so schnell wie Vorfälle mit höherem Schweregrad. Die meisten Vorfälle des Schweregrads 3 nutzen keine öffentlichen Kommunikationskanäle. Stattdessen Reachen Zendesk Customer Support Teams Kunden proaktiv, wenn bestimmte Maßnahmen von einer Teilmenge von Kunden erforderlich sind.
Vorfälle des Schweregrads 4 wirken sich nicht direkt auf die Nutzung der Zendesk-Services durch Kunden aus, können dies aber tun, wenn sie nicht behoben werden. Diese Vorfälle werden als proaktive Reaktion auf potenzielle Probleme erstellt. Produktentwicklungsteams arbeiten auf die gleiche Weise wie beim Schweregrad-3-Prozess.
Weitere Infos
Damit ist Teil 2, Wie Zendesk Servicevorfälle handhabt, des Überblicks über das Vorfallmanagement bei Zendesk abgeschlossen.
Wenn Sie mehr erfahren möchten, fahren Sie mit dem nächsten Teil dieses Leitfadens fort: Teil 3: Überwachen eines öffentlichen Zendesk-Servicevorfalls.
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.