Dies ist Teil 2 des Beitrags Überblick über das Ereignismanagement bei Zendesk. Dieser Leitfaden enthält die folgenden Teile:
- Teil 1: Wie Service-Probleme von Zendesk zu Service-Vorfällen werden
- Teil 2: Management von Servicevorfällen in Zendesk (dieser Beitrag)
- Teil 3: Überwachen eines öffentlichen Zendesk-Servicevorfalls
- Teil 4: Analyse und Reporting von Vorfällen nach der Behebung
In diesem Beitrag, Teil 2, erfahren Sie mehr zu hwie die Zendesk-Teams auf Servicevorfälle in unseren Produkten reagieren, basierend auf Schweregraden. Zendesk verfolgt einen umfassenden Ansatz, um einen Vorfall zu verstehen – von der Ursache bis hin zu den Gesamtauswirkungen auf die betroffenen Kunden – und informiert die Agenten entsprechend.
Dieser Beitrag enthält die folgenden Abschnitte:
- Schweregrad des Vorfalls
- Struktur des Incident-Response-Teams
- Kommunikationszeitpläne für Vorfälle
- Prozess für Vorfälle mit niedrigem Schweregrad
Schweregrad des Vorfalls
Eine der wichtigsten Entscheidungen beim Erstellen eines Dienstvorfalls ist die Zuweisung des Schweregrads. Der Schweregrad eines Vorfalls bestimmt, wie und welche Zendesk-Teams das Problem in Angriff nehmen und wie die betroffenen Kunden informiert werden.
Zendesk verwendet ein System, das Servicevorfälle anhand der Merkmale des Vorfalls in 5 Prioritätsstufen gruppiert:
Zendesk-Schwerpunktbewertungssystem
Je nach Schweregrad werden unterschiedliche Eskalationspfade und Teams herangezogen, um die Vorfälle zu untersuchen, zu kommunizieren und zu beheben. So wird sichergestellt, dass jedem Vorfall die richtige Strenge zugewiesen wird. Das folgende Diagramm beschreibt die wichtigsten Aktivitäten, die während und nach der Behebung eines Vorfalls ausgeführt werden, basierend auf seinem Schweregrad:
Bearbeiten nach Schweregrad
Während Vorfälle mit hoher Priorität eingehende Analysen und Behebungsmaßnahmen durchlaufen, durchläuft jeder Vorfall – unabhängig von seinem Schweregrad – einen Echtzeit-Reaktions- und Untersuchungsprozess. Das Ergebnis:
- Aktualisierung der Zendesk-Statusseite, wenn der Vorfall öffentlich ist
- Ursachenanalyse und Behebung von Vorfällen
- Zendesk-Vorfallbericht (intern).
Beispiel für einen Zendesk-Dienstverfügbarkeitsvorfall
Dieses Beispiel zeigt, wie der Schweregrad des Vorfalls von Zendesk festgelegt wird und wie Zendesk-Teams intern darauf reagieren:
Beispiel für Vorfallerkennung und -antwort
Im Beispiel sehen Sie den folgenden Workflow:
- Das Zendesk Network Operations Center (ZNOC) hat ein Problem festgestellt wenn Systemalarme angezeigt haben, dass die Serviceknoten in Pod 17 von Anfragen nicht erreicht werden konnten. Das Zendesk Network Engineering-Team erkannte, dass die Zugriffsprobleme sich 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-Dienstvorfall wurde erstellt.
- Bei seiner Erstellung war bekannt, dass dieser Vorfall zwei Kunden betrifft, aber aufgrund der Art des Ausfalls traten mehr Kunden auf und begannen, sich an den Zendesk-Kundensupport zu wenden. Das Engineering-Team wies dem Vorfall den Schweregrad 1 zu – ein Vorfall mit hoher Priorität, der sofortiges Eingreifen erfordert.
- Das Incident-Response-Team wurde sofort benachrichtigt. Minuten nach Erstellung des Vorfalls sammelte ein Incident Manager Informationen und stellte zusätzliche Engineering-Ressourcen zusammen, um den Fehler zu beheben.
Struktur des Incident-Response-Teams
Zendesk verfügt über ein dediziertes globales Incident-Response-Team, das dafür sorgt, dass jeder Vorfall durch den Incident-Management-Prozess des Service geleitet und bei Bedarf an die geeignete Managementebene von Zendesk eskaliert wird.
Rollen und Verantwortlichkeiten im Incidentmanagement
Diese Teamstruktur ermöglicht es Zendesk, eine gründliche Analyse des Vorfalls mit technischen Ressourcen durchzuführen und in Echtzeit über den Zendesk-Kundensupport mit dem Kunden zu kommunizieren.
Kommunikationszeitpläne für Vorfälle
Zendesk investiert, um sicherzustellen, dass Vorfälle ordnungsgemäß kommuniziert und in dem für den Kunden angemessenen Zeitrahmen gelöst werden. Wir haben interne Zeitpläne für die Verteilung von Vorfalldetails festgelegt. Der Zeitrahmen richtet sich nach dem Schweregrad des Vorfalls und den Phasen des Service Incident Management.
|
Phase |
Antwortzeitpläne |
|
Öffentliche Ankündigung |
Innerhalb von 15 Minuten nach dem Vorfall |
|
Vorfallaktualisierungen |
Alle 30 Minuten, bis der Service wiederhergestellt ist bzw. sobald neue Informationen verfügbar werden |
|
Ereignisanalyse (für Vorfälle mit Schweregrad 0 und 1) |
Innerhalb von 48 Stunden nach Behebung des Vorfalls |
|
Ursachenanalyse |
Innerhalb von 72 Stunden nach Behebung des Vorfalls |
|
Öffentliche Vorfall-Retrospektive |
Innerhalb von mehr als 96 Stunden nach Lösung des Vorfalls |
Vorfälle mit einem Schweregrad von 0 bis 2 gelten als hoch Schweregrad Vorfälle. Bei einem Vorfall mit hohem Schweregrad ist das globale Incident Response Team rund um die Uhr verfügbar, um auf diese Vorfälle zu reagieren. Das Team besteht aus den folgenden Rollen:
Rollen von Incident-Response-Teams
Globale Standorte der Incident Response Teams
Da das Bereitschaftsteam benachrichtigt wird, beginnt die Vorfalldiagnose innerhalb von Minuten nach Bekanntgabe 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 erfasst, werden die verfügbaren Engineering-Teams benachrichtigt, je nachdem, welche Produkte und Services betroffen sind.
Ein öffentlicher Post auf der Zendesk-Statusseite wird innerhalb von 15 Minuten nach Erstellung des Vorfalls erstellt, um Kunden über den bekannten Vorfall auf dem Laufenden zu halten. Danach werden alle 30 Minuten Aktualisierungen veröffentlicht, bis der Fehler behoben ist, sobald neue Informationen verfügbar sind. Je nach dem Problem und der Anzahl neuer Informationen, die identifiziert werden, kann diese Intervalle je nach Bedarf kürzer oder verlängert werden. Kunden können aktive Servicevorfälle auf der Zendesk-Statusseite überwachen. Dieser Prozess ist unter beschrieben Teil 3 dieses Leitfadens.
Neben unseren globalen Incident-Response-Teams, die jederzeit verfügbar sind, hat Zendesk Prozesse zur Benachrichtigung und Eskalation von Vorgesetzten eingeführt. Wenn ein Vorfall mit hoher Dringlichkeit bestimmte Kriterien erfüllt, schalten wir die nächste Stufe der Reaktion ein, d. h. das Krisenmanagement.
Das Beispiel für einen Zendesk-Serviceverfügbarkeitsvorfall wurde fortgesetzt
Am Beispiel des Vorfalls zur Verfügbarkeit des Service durchläuft die Antwort auf den Vorfall jetzt den Incident-Management-Prozess bei Zendesk:
Zeitleiste für die Reaktion auf Serviceverfügbarkeitsvorfälle
Wie Sie im Beispiel sehen können, wurde nach dem Erstellen des Vorfalls im Zendesk-Vorfall-Portal eine Reihe von automatisierten Aktionen durchgeführt:
- Das On-Call-Team für Incident Response wurde benachrichtigt, um auf den Vorfall zu reagieren
- Es wurde automatisch ein Incident-Slack-Channel erstellt und das Bereitschaftsteam für Incident Response zum dedizierten Slack-Channel hinzugefügt
- Ein Zoom-Anruf wurde automatisch gestartet und im Slack-Channel gepostet, damit alle Antwortenden mitmachen konnten
- Es wurde automatisch eine Ereigniszusammenfassung erstellt, um den Vorfall zu dokumentieren und den Fortschritt intern in Zendesk zu teilen
Beim Zoom-Anruf validierte der Vorfallmanager den anfänglichen Schweregrad sowie den Umfang und die Auswirkungen des Problems.
Es stellte sich schnell heraus, dass mehrere Container-Knoten in Pod 17 nicht erreichbar waren und von abhängigen Diensten wie Support, Guide und Talk nicht genutzt werden konnten. Bei einem bestimmten Knotentyp waren keine Repliken in anderen Pods verfügbar. Dies würde letztendlich dazu führen, dass diese Produkte für mehrere Kunden nicht mehr verwendet werden.
Das ZNOC wies das entsprechende Network-Engineering-Team an den Zoom-Aufruf an, um mit der Untersuchung des unmittelbaren Problems der Wiederherstellung des Service- und API-Zugriffs für Kunden zu beginnen. Fachexperten, die im Edge-Engineering-Sektor aktiv sind, wurden ebenfalls angerufen. Innerhalb von 5 Minuten wurde eine Lösung gefunden und bereitgestellt, sodass die betroffenen Knoten wieder für API-Aufrufe und -Dienste erreichbar waren.
Der Zendesk-Kundensupport hat ein Problemticket erstellt, um die Kundenberichte zu verfolgen. Dieses Ticket wurde dem Slack-Channel für Vorfälle hinzugefügt, damit neue Berichte schnell hinzugefügt werden können.
Während die Untersuchung noch weiter lief, erstellte der Incident Escalation Manager 12 Minuten nach Erstellung des Vorfalls die erste öffentliche Aktualisierung auf der Zendesk-Statusseite.
First Service Availability Incident Post auf Zendesk System Status Page
Während das Team den Vorfall untersuchte, wurden Kundenberichte, die mit dem Hauptproblemticket verknüpft waren, mit dem Vorfall verknüpft. Dadurch konnte das Incident Response-Team bei öffentlichen Benachrichtigungen Aktualisierungen an alle betroffenen Kunden senden.
Das Network Engineering Team stellte fest, dass eine Änderung an der Art und Weise, wie Zertifikate generiert und verwendet wurden, für den Vorfall verantwortlich war, und ergriff die folgenden Maßnahmen, um den Service für die betroffenen Kunden wiederherzustellen:
- Unerreichbare Knoten deaktiviert
- Neue Dienstknoten mit ordnungsgemäß referenzierten Zertifikaten erstellt
- Verifiziert, dass neue Dienstknoten für Dienste und über API-Aufrufe erreichbar sind
- Der eingehende Datenverkehr wurde überwacht, um sicherzustellen, dass eingehende Anfragen jetzt korrekt gehandhabt wurden
Im weiteren Verlauf wurden zwei weitere öffentliche Aktualisierungen vorgenommen: eine 14 Minuten nach der Erstellung des Vorfalls und eine weitere 63 Minuten nach der Erstellung des Vorfalls. Der öffentliche Kommunikationsverlauf sowie rückblickende Informationen zu veröffentlichten Vorfällen sind auf der Seite „Service Notifications“ zu findendes Vorfalls antworten.
Wie das Beispiel zeigt, durchlaufen Vorfälle mit hohem Schweregrad einen rigorosen Prozess, in dem die Ursache ermittelt und behoben wird, damit das Produktentwicklungsteam das zugrundeliegende Problem beheben kann. Diese Analyse erfolgt während unserer Vorfall-Retrospektive und wird im detaillierter besprochen Abschnitt „Vorfallanalyse nach Lösung“.
Prozess für Vorfälle mit niedrigem Schweregrad
Servicevorfälle mit niedrigerem Schweregrad (Stufe 3-4) sind weniger kritisch, da sie eine kleinere Anzahl von Kunden betreffen und diese Kunden nicht an der Nutzung geschäftskritischer Funktionen der Zendesk-Produkte hindern. Diese Vorfälle werden gemäß den oben genannten Richtlinien behandelt, aber nicht in öffentlichen Channels gepostet.
Vorfälle mit Schweregrad 3 werden ähnlich gehandhabt wie Vorfälle mit Schweregrad 0-2. Aufgrund der geringeren Auswirkung auf das Geschäft verlängern sich die erwarteten Antwortzeiten. Auch wenn das Bereitschaftsteam nicht in Funktion ist, werden diese Vorfälle über spezielle Zendesk-Slack-Channels gehandhabt, die mit dem bzw. den unterstützenden Product-Engineering-Teams verbunden sind. Die Teams reagieren in der Regel so schnell wie Vorfälle mit höherem Schweregrad. Die meisten Vorfälle des Schweregrads 3 verwenden keine öffentlichen Kommunikationskanäle. Stattdessen wendet sich das Zendesk-Kundensupportteam an Kunden mit proaktiven Benachrichtigungen, wenn von einer Untergruppe von Kunden eine bestimmte Aktion erforderlich ist.
Vorfälle mit Schweregrad 4 wirken sich nicht direkt auf die Nutzung der Zendesk-Services durch Kunden aus, können aber negativ reagieren, wenn sie nicht behoben werden. Diese Vorfälle werden als proaktive Reaktion auf potenzielle Probleme erstellt. Produktentwicklungsteams interagieren genauso wie beim Schweregrad-3-Prozess.
Weitere Infos
Damit ist Teil 2, Wie Zendesk Servicevorfälle managt, im Überblick über das Ereignismanagement bei Zendeskabgeschlossen.
Wenn Sie mehr erfahren möchten, gehen Sie zum nächsten Teil dieses Leitfadens: 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.