Dies ist Teil 4 der Übersicht ü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
- Teil 3: Überwachen eines öffentlichen Zendesk-Servicevorfalls
- Teil 4: Analyse und Berichterstellung nach Lösungsvorfällen (dieser Beitrag)
In diesem Beitrag, Teil 4, erfahren Sie, wie das Incident Response Team eine Retrospektive durchführt, die die Ursachenanalyse und die Behebung von Servicevorfällen umfasst, und dann die Behebungselemente dem bzw. den zuständigen Engineering-Teams zuweist.
Durch diese Aktivitäten kann der Zendesk-Kundensupport Vorfalldetails und die nächsten Schritte mit den betroffenen Kunden teilen.
Dieser Beitrag enthält die folgenden Abschnitte:
Rückblick auf Servicevorfälle
Zendesk führt eine Reflexionsübung mit allen am Vorfall beteiligten Teammitgliedern durch, um die Ursachen des Vorfalls, die Auswirkungen des Vorfalls auf Kunden und die zu seiner Eindämmung oder Lösung ergriffenen Maßnahmen zu untersuchen und zu dokumentieren. Das Team überprüft die identifizierten Ursachen und Folgeaktionen, die verhindern, dass sich der Vorfall wiederholt. Dies wird als interne Rückschau auf Servicevorfälle bezeichnet. Vorfallrückblicke werden nur bei Vorfällen mit hohem Schweregrad öffentlich geteilt.
Um Transparenz und Inklusion für alle Zendesk-Teams zu gewährleisten, steht ein interner Retrospektivkalender zur Verfügung, damit sie an dem internen Retrospektivtreffen teilnehmen und mehr Informationen zu Servicevorfällen und Ursachen erhalten können. Die Ergebnisse von Vorfällen werden mit allen Engineering-Teams geteilt und wichtige Vorfallergebnisse werden in der wöchentlichen Engineering-Sitzung von Zendesk hervorgehoben und überprüft.
Eine Servicevorfallrückschau umfasst vier Hauptaktivitäten:
- Überprüfen Sie die im Vorfalldokument enthaltenen Vorfalldetails, um die Teilnehmer an dem Vorfall zu orientieren.
- Überprüfen und Validieren der Ergebnisse der Ursachenanalyse im Vorfalldokument
- Identifizieren und kategorisieren Sie alle für die Zendesk-Engineeringteams erforderlichen Korrekturarbeiten, um die Ursachen für den Servicevorfall vollständig zu beheben. Alle Korrekturelemente werden von den retrospektiven Teilnehmern im Konsens angenommen
- Verteilen Sie Sanierungsarbeiten an die entsprechenden Engineering-Teams mit klar definierten und angemessenen SLAs.
Analyse von Vorfällen mit hohem Schweregrad
Sobald ein Vorfall mit hohem Schweregrad behoben ist, plant der Vorfallmanager ein retrospektives Meeting, das Folgendes umfasst:
- Alle Teammitglieder, die an der Vorfallreaktion teilgenommen haben
- Ingenieure von Teams, deren Produkte oder Dienstleistungen von dem Vorfall betroffen waren
-
Teams, die Inhaber sind oder Interesse investiert haben, wie z. B.:
- Zendesk-Kundensupport
- Produktteams
- Führungskräfte, die Eigentümer der betroffenen Produkte, Dienstleistungen und Supportbereiche sind
Es wird alles getan, um das rückwirkende Meeting innerhalb von 72 Stunden nach Lösung des Vorfalls abzuhalten. Dabei ist klar, dass der Zeitpunkt des Meetings von der Komplexität der Ursache und der Verfügbarkeit von Teammitgliedern in den einzelnen Regionen abhängt.
Nach der Planung der Vorfallrückschau dokumentiert der Engineering-Inhaber die Ursachenanalyse und erstellt das Vorfalldokument anhand der folgenden Kategorien:
- Vorfallübersicht
- Kundenwirkungen
- Technische Beschreibung
- Ursache und Serviceinformationen
- Vorfalldetails und Zeitpunkte
- Korrekturen
Das Vorfalldokument führt den Vorfall rückblickend durch und erfasst eventuelle Korrekturarbeiten, die zur vollständigen Lösung der zugrundeliegenden Probleme identifiziert wurden.
Für Vorfälle mit dem Schweregrad 0-3 wird eine zusätzliche Analysephase durchgeführt, die als Ursachenanalyse bezeichnet wird. Diese Analyse gibt dem Engineering-Team die Möglichkeit, den Vorfall zu verstehen und zu dokumentieren und die Arbeit zu definieren, die erforderlich ist, um die Probleme vollständig zu beheben. Diese Informationen werden im Vorfalldokument erfasst.
Zendesk-Prozess zur Analyse der Ursache von Vorfällen
Analyse von Vorfällen mit geringem Schweregrad
Vorfälle mit geringem Schweregrad durchlaufen eine schlankere Ursache und Berichtphase als Vorfälle mit hohem Schweregrad. Bei Vorfällen mit niedrigem Schweregrad wird zwar (es sei denn, der Product Engineering-Inhaber hat dies angefordert) kein formelles Rückblickgespräch abgeschlossen, aber der Product Engineering-Inhaber erstellt ein Vorfalldokument.
Ursachen werden identifiziert, klassifiziert und mit Engineering-Teams geteilt, und mit SLAs werden Behebungselemente zum Rückstand des Produktentwicklungsteams hinzugefügt. Wie bei Vorfällen mit höherem Schweregrad möchte Zendesk unsere Engineering-Prozesse durch gründliche Untersuchung von Vorfällen mit niedrigem Schweregrad verbessern.
Da Vorfälle des Schweregrads 3 nur geringfügige Auswirkungen auf Kunden haben, werden der Status des Problems und die identifizierten Behebungen mit den betroffenen Kunden geteilt, die sich über das Zendesk-Ticket über den Zendesk-Kundensupport mit dem Vorfall in Verbindung gesetzt haben.
Per Definition haben Vorfälle des Schweregrads 4 keine direkten Auswirkungen auf Kunden. Die Analyse von Post-Incidents wird Kunden nicht mitgeteilt, aber die Ursachen werden identifiziert und Behebungen intern anhand der oben beschriebenen Prozesse und Verfahren behoben.
Zuweisen von Korrekturelementen
Um sicherzustellen, dass die Korrekturelemente abgeschlossen sind, überprüft das Produktentwicklungsteam die validierten Korrekturelemente in der Retrospektive und führt die folgenden Aktionen durch:
-
Klassifizieren Sie Sanierungen als präventiv oder allgemein:
- Vorbeugende Maßnahmen verhindern das erneute Auftreten des Vorfalls
- Allgemeine Punkte sind nicht nur präventiv, sondern würden einen wesentlichen Teil der Umstände des Vorfalls beheben.
- Priorisieren Sie die Korrekturen, um die Antwort-SLAs festzulegen. Diese Übung durchläuft die folgenden Aktivitäten:
- Identifizieren Sie die Engineering-Teams, die für die Bearbeitung des Sanierungsgegenstands zuständig sind.
- Verknüpfen Sie das Sanierungselement mit der identifizierten Ursache, die es angeht
- Das Sanierungselement zum Arbeitsrückstand des zuständigen Engineering-Teams hinzufügen
- Abhilfeelement zum Engineering SLA Report hinzufügen, um die Erfüllung von SLA zu verfolgen
Nachfolgend sehen Sie ein Diagramm, anhand dessen Produktentwicklungsteams bestimmen, wann eine Sanierung priorisiert und für ihre Arbeit geplant wird.
Prioritäts-SLA für Zendesk-Remediation Items
Das Zendesk Customer Support Team, das an der Retrospektive teilnahm, erstellt für Kunden sichtbare Beschreibungen von Vorfällen, Ursachen und eventuellen festgestellten Abhilfemaßnahmen. Diese wird im Abschnitt „Servicebenachrichtigungen“ unseres Help Centers gepostet.
Beispiel für Service Availability Incident fortgesetzt
So wurde eine Vorfallrückschau für diesen Vorfall durchgeführt.
4 Werktage nach dem Vorfall trafen sich das Incident-Response-Team und die Ingenieure, um den Vorfall zu überprüfen, gemeinsam an den Ursachen zu arbeiten und die Behebungselemente zu erstellen oder zu aktualisieren. Alle Punkte, die behoben werden, werden im Konsens der Sitzungsteilnehmer angenommen.
Jede am Vorfall beteiligte Person spielte bei der Vorfallrückschau eine Rolle:
In der Besprechung wurden folgende Details besprochen:
| Bereich | Beispiel |
| Zeitleiste |
|
| Ursachen |
|
| Einflussfaktoren |
|
| Korrekturen |
|
Für eine gründliche Analyse, um konkrete Aktionen für das Engineering-Team zu generieren, gaben alle Teammitglieder Input, um den Vorfall nachzuzählen und Behebungsaufgaben zu entwickeln. Sobald das Incident Response Team alle Fragen oder Probleme beantwortet hatte, galt die Vorfallrückschau als abgeschlossen.
Die für die Retrospektive öffentlicher Vorfälle zuständige Zendesk Customer Support Lead wurde am Ende der internen Retrospektive gefragt, ob sie Fragen hatte oder zusätzliche Informationen vom Team benötigte, um die öffentliche Dokumentation zu erstellen. Sie hatte keine weiteren Fragen und fügte die folgenden retrospektiven Informationen zum Bereich „Servicebenachrichtigungen“ in unserem Help Center hinzu.
Öffentliche retrospektive Informationen zum Service Availability VM-Vorfall
Diese Vorfallrückschau hat drei wichtige Ergebnisse zur Verbesserung der Zendesk-Produkte und -Services gebracht:
- Die Ursachen des Vorfalls wurden identifiziert und werden von allen Zendesk-Produktteams in Zukunft berücksichtigt.
- Die Behebungen wurden identifiziert und den Engineering-Teams mit SLAs zugewiesen.
- Die öffentliche Retrospektive wurde vom Zendesk-Kundensupport im Help Center veröffentlicht und an betroffene Kunden gesendet, die Tickets eingereicht hatten.
Beenden eines Servicevorfalls
Als Best Practice empfiehlt es sich, alle offenen Tickets mit Kunden zu schließen, um sicherzustellen, dass alles ordnungsgemäß dokumentiert und für den Vorfall kommuniziert wird.
Alle abgeschlossenen Servicevorfälle werden in einem wöchentlichen Bericht zusammengefasst, der in Zendesk allgemein geteilt wird. Dieser Bericht enthält Vorfallbeschreibungen, Kundenauswirkungen und wichtige Korrekturen sowie einen alle zwei Wochen veröffentlichten Operations Review-Bericht, der dem Zendesk-Exekutivteam zur Verfügung gestellt wird.
Nachdem retrospektive Informationen im Help Center veröffentlicht und offene Tickets mit den Ergebnissen aus der Retrospektive aktualisiert wurden, gilt die Analyse- und Berichtphase für den Servicevorfall als abgeschlossen. Der Zendesk-Kundensupport verknüpft diese Tickets mit dem Servicevorfall und markiert sie als geschlossen.
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.