Dies ist Teil 4 des Überblicks ü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: Wie Zendesk Dienstvorfälle verwaltet
- Teil 3: Überwachen eines öffentlichen Zendesk-Servicevorfalls
- Teil 4: Analyse von Vorfällen nach Lösung und Erstellen von Berichten (dieser Beitrag)
In diesem Beitrag, Teil 4, erfahren Sie,wie das Incident-Response-Team eine Rückschau durchführt, die die Ursachenanalyse und Behebung von Servicevorfällen umfasst, und anschließend die Behebungsarbeiten an die zuständigen Engineering-Teams zuweist.
Dank dieser Aktivitäten kann der Zendesk-Kundensupport den betroffenen Kunden Details zum Vorfall und die nächsten Schritte mitteilen.
Dieser Beitrag enthält die folgenden Abschnitte:
Überblick über einen Servicevorfall
Zendesk führt eine reflektierte Übung mit allen am Vorfall beteiligten Teammitgliedern durch, um die Ursachen, die Auswirkungen des Vorfalls auf die Kunden und die Maßnahmen zur Eindämmung oder Behebung zu untersuchen und zu dokumentieren. Das Team überprüft die ermittelte(n) Ursache(n) und ergreift Folgemaßnahmen, um zu verhindern, dass der Vorfall erneut auftritt. Dies wird als interner Rückblick auf den Servicevorfall bezeichnet. Rückblicke auf Vorfälle werden nur bei Vorfällen mit hohem Schweregrad öffentlich geteilt.
Um Transparenz und Eingliederung für alle Zendesk-Teams zu gewährleisten, steht ein interner Zendesk-Retrospektivkalender zur Verfügung, damit sie an internen rückblickenden Besprechungen teilnehmen und mehr Informationen über Servicevorfälle und deren Ursachen erhalten können. Die Ergebnisse werden allen Engineering-Teams zur Verfügung gestellt. Bedeutende Vorfälle werden im wöchentlichen Zendesk-Engineering-Meeting hervorgehoben und besprochen.
In der Rückschau eines Servicevorfalls werden vier Hauptaktivitäten durchgeführt:
- Überprüfen Sie die im Vorfalldokument enthaltenen Details zum Vorfall, um die Teilnehmer besser zu verstehen
- Die Ergebnisse der Ursachenanalyse im Vorfalldokument überprüfen und validieren
- Identifizieren und kategorisieren Sie alle Behebungsarbeiten, die erforderlich sind, damit die Zendesk-Engineeringteams die Hauptursachen, die zum Dienstvorfall geführt haben, vollständig beheben können. Alle Korrekturpunkte werden von den rückblickenden Teilnehmern einvernehmlich akzeptiert
- Weisen Sie die Behebungsarbeiten den entsprechenden Engineering-Teams mit klaren und geeigneten SLAs zu.
Analyse von Vorfällen mit hohem Schweregrad
Sobald ein Vorfall mit hohem Schweregrad behoben ist, plant der Vorfallmanager ein rückblickendes Meeting, das folgende Themen enthält:
- Alle Teammitglieder, die an der Reaktion auf den Vorfall beteiligt waren
- Techniker von Teams, deren Produkte oder Services von dem Vorfall betroffen waren
- Teams mit eigenen Inhabern oder Beteiligungen, wie z. B.:
- Zendesk-Kundensupport
- Produktteams
- Führungskräfte, die für die betroffenen Produkte, Services und Supportbereiche zuständig sind
Es wird alles daran gesetzt, das rückwirkende Meeting innerhalb von 72 Stunden nach Behebung des Vorfalls abzuhalten, wobei der zeitliche Ablauf von der Komplexität der Ursache und der Verfügbarkeit von Teammitgliedern in den geografischen Regionen abhängt.
Nach dem Festlegen des Zeitplans für die Vorfall-Retrospektive dokumentiert der technische Verantwortliche die Ursachenanalyse und erstellt das Vorfalldokument anhand der folgenden Kategorien:
- Vorfallübersicht
- Kundenauswirkungen
- Technische Beschreibung
- Ursache und Serviceinformationen
- Details und Zeitangaben für Vorfälle
- Korrekturen
Das Vorfalldokument leitet die Rückschau des Vorfalls und erfasst alle Arbeiten, die durchgeführt wurden, um die zugrunde liegenden Probleme, die zum Vorfall geführt haben, vollständig zu beheben.
Für Vorfälle mit Schweregrad 0-3 wird eine zusätzliche Analysephase durchgeführt, die als Ursachenanalyse bezeichnet wird. Diese Analyse ermöglicht es dem Engineering-Team, den Vorfall zu verstehen und zu dokumentieren sowie die zur vollständigen Behebung der Probleme erforderlichen Arbeiten festzulegen. Diese Informationen werden im Vorfalldokument erfasst.
Zendesk-Prozess zur Analyse der Ursache für Vorfälle
Analyse von Vorfällen mit niedrigem Schweregrad
Vorfälle mit niedrigem Schweregrad durchlaufen eine effizientere Ursachen- und Berichtsphase als Vorfälle mit hohem Schweregrad. Bei Vorfällen mit geringem Schweregrad wird nur dann ein formelles Rückblicksmeeting durchgeführt (es sei denn, der Verantwortliche für Product Engineering hat dies angefordert), aber der Verantwortliche für Product Engineering erstellt ein Vorfalldokument.
Die Ursache wird identifiziert, klassifiziert und an die Engineering-Teams weitergeleitet; Behebungsmaßnahmen werden anhand von SLAs in das Product Engineering-Team aufgenommen. Wie bei Vorfällen mit höherem Schweregrad versucht Zendesk, unsere Engineering-Prozesse durch gründliche Untersuchung von Vorfällen mit niedrigerem Schweregrad zu verbessern.
Da Vorfälle des Schweregrads 3 geringfügige Auswirkungen auf Kunden haben, werden der Problemstatus und die identifizierten Behebungen mit den betroffenen Kunden geteilt, die sich über den Zendesk-Kundensupport in einem Zendesk-Ticket an den Vorfall gewendet haben.
Vorfälle mit Schweregrad 4 haben per Definition keine direkten Auswirkungen auf Kunden. Kunden erhalten keine nachträgliche Vorfallanalyse, doch die Hauptursachen werden identifiziert und ihre Behebung dann intern anhand der oben beschriebenen Prozesse und Verfahren eingeleitet.
Zuweisen von Korrekturelementen
Um sicherzustellen, dass die Korrekturen abgeschlossen sind, überprüft das Product Engineering-Team die validierten Korrekturen im Nachhinein und führt die folgenden Aktionen durch:
- Korrekturen als „Präventiv“ oder „Allgemein“ klassifizieren:
- Präventivmaßnahmen sind solche, die aktiv verhindern, dass der Vorfall erneut auftritt
- Allgemeine Punkte sind nicht nur präventiv, sondern würden auch einen wesentlichen Teil der Umstände des Vorfalls beheben
- Priorisieren Sie die Abhilfemaßnahmen, um Antwort-SLAs festzulegen. Diese Übung umfasst die folgenden Aktivitäten:
- Bestimmen Sie die für die Korrektur verantwortlichen Engineering-Teams
- Verknüpfen Sie den Behebungspunkt mit der identifizierten Ursache, die er behebt
- Nehmen Sie die Behebungsmaßnahmen in den Rückstand des zuständigen Engineering-Teams auf
- Sie müssen das Wartungselement dem Engineering-SLA-Bericht hinzufügen, um die SLA-Erfüllung zu verfolgen
Nachfolgend ein Diagramm, mit dem Product-Engineering-Teams bestimmen, wann eine Behebung erforderlich und geplant ist.
Zendesk-SLA für „Korrektur-Elementepriorität“.
Das Zendesk-Kundensupportteam, das an der Rückschau teilnimmt, erstellt die für die Kunden sichtbaren Beschreibungen der Vorfälle, Ursachen und Behebungen. Dies wird unter gepostet Help-Center-Beitrag , der mit dem Vorfall verknüpft ist.
Beispiel für einen Serviceverfügbarkeitsvorfall
Hier sehen Sie, wie eine Vorfall-Retrospektive für diesen Vorfall durchgeführt wurde.
4 Arbeitstage nach dem Auftreten des Vorfalls setzten sich das Incident Response-Team und die Ingenieure zusammen, um den Vorfall zu prüfen, gemeinsam an der Ursache zu arbeiten und Behebungsmaßnahmen zu erstellen oder zu aktualisieren. Alle Verbesserungspunkte werden von den Teilnehmern einvernehmlich angenommen.
Jede am Vorfall beteiligte Person spielt bei der Rückblickung auf den Vorfall eine bestimmte Rolle:
Im Meeting wurden unter anderem folgende Details besprochen und besprochen:
|
Bereich |
Beispiel |
|
Zeitleiste |
|
|
Ursachen |
|
|
Einflussfaktoren |
|
|
Korrekturen |
|
Um eine gründliche Analyse mit konkreten Maßnahmen für das Engineering-Team zu ermöglichen, haben alle Teammitglieder mit Eingaben den Vorfall gemeldet und Behebungsmaßnahmen entwickelt. Nachdem alle Fragen oder Probleme durch das Incident Response-Team beantwortet waren, wurde die Vorfall-Retrospektive als abgeschlossen betrachtet.
Die für die öffentliche Vorfall-Retrospektive verantwortliche Person im Zendesk-Kundensupport wurde am Ende des internen Rückblicks gefragt, ob sie Fragen hat oder zusätzliche Informationen vom Team benötigt, um die öffentliche Dokumentation zu erstellen. Sie hatte keine weiteren Fragen und fügte die rückwirkenden Informationen unten zum öffentlichen Servicevorfallbeitrag im Abschnitt „Servicebenachrichtigungen“ hinzu unserem Help Center.
Öffentliche rückwirkende Informationen zum Vorfall der Dienstverfügbarkeits-VPN
Drei wichtige Ergebnisse dieser Rückschau, die zu einer Verbesserung der Zendesk-Produkte und -Services führten, waren:
- Die Hauptursachen des Vorfalls wurden identifiziert und werden von allen Zendesk-Produktteams bei der zukünftigen Entwicklung berücksichtigt
- Die Korrekturen wurden identifiziert und mit SLAs Engineering-Teams zugewiesen
- Die öffentliche Rückschau wurde vom Zendesk-Kundensupport im Help Center veröffentlicht und an die betroffenen Kunden gesendet, die Tickets eingereicht hatten
Schließen eines Servicevorfalls
Als Best Practice empfiehlt es sich, in Zendesk alle offenen Tickets mit dem Kunden zu schließen, um sicherzustellen, dass der Vorfall ordnungsgemäß dokumentiert und kommuniziert wird.
Alle abgeschlossenen Servicevorfälle werden in einem wöchentlichen Service Incident Digest Report zusammengefasst, der dann an das gesamte Zendesk-Team weitergegeben wird. Dieser Bericht enthält Beschreibungen der Vorfälle, Auswirkungen auf die Kunden und wichtige Abhilfemaßnahmen. Sie fließen auch in einen zweiwöchentlichen Operations Review ein, der dem Executive Team von Zendesk zur Verfügung gestellt wird.
Mit der Veröffentlichung der rückblickenden Informationen im Help Center und der Aktualisierung der offenen Tickets mit den Ergebnissen der Rückschau 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.