23. 05. 2022
Cloud, Service Management
02. 07. 2014
MarinovMihail
Uncategorized
Incident Management und funktionelles Eskalieren mit EriZone powered by OTRS
Unternehmen welche nach ITIL Standards arbeiten, also über einen gut organisierten Service Desk mit 1st, 2nd und 3rd-Level-Support verfügen, benötigen die Möglichkeit Tickets an Spezialisten eines jeweils höheren Service-Levels weiterzuleiten (zu eskalieren). Siehe dazu Img 1
Eine solche Struktur kann mithilfe von drei “queues”, welche die drei Service-Levels darstellen, veranschaulicht werden. Innerhalb dieser queues können Tickets erstellt, verschoben und abgeschlossen werden.
Für eine funktionelle Eskalation an ein höheres Service-Level stehen generell zwei Möglichkeiten zur Verfügung:
- Ein Ticket kann von einer Bearbeitungsgruppe in eine andere Bearbeitungsgruppe (welche ein höheres Service-Level repräsentiert) verschoben werden
- Ein Ticket kann gesplittet werden. Das somit entstehende, neue „Unterticket“ wird als „child“ bezeichnet und kann an das höhere Service-Level weitergeleitet werden.
Um die richtige Variante zu wählen, ist es wichtig folgende Unterschiede zu berücksichtigen:
- Besitz und Kommunikation:
Wenn das Ticket in eine andere Support-Level-Gruppe verschoben wird, kann der Besitzer direkt mit dem Kunden kommunizieren, während der SD Agent für das Ticket verantwortlich bleibt.
Wenn das Ticket gesplittet wird und das „child“ einem anderen Besitzer zugeteilt wird, erzeugt dies einen neuen, separaten Kommunikationszweig (es kann also passieren, dass für ein und dieselbe Problemstellung, zwei „Unterhaltungen“ mit dem Kunden gestartet werden). - Performancemessung der einzelnen Support-Levels:
In EriZone powered by OTRS ist es nur möglich eine SLA (Service-Level-Agreement; Dienstleistungsvereinbarung) pro Ticket zu messen. Die SLA’s der einzelnen Support-Levels können also nur gemessen werden, wenn jedem Service Level ein separates Ticket zugeordnet wird. Sollte ein Ticket also von einer Bearbeitungsgruppe in die nächste verschoben werden, kann nur die SLA der gesamten Ticketbearbeitung gemessen werden, nicht jene der einzelnen Support-Levels.
Lassen Sie mich, zum besseren Verständnis, einige Beispiele einer solchen funktionellen Eskalation aufzeigen:
Funktionelle Eskalation an den 3rd-Level-Support (Hersteller)
Situation 1.1: Der Hersteller hat einen Zugang zu EriZone: Splitten Sie das ursprüngliche Ticket und setzten Sie den Agenten als Kunden (requestor) des „child“-Tickets. Das „child“-Ticket kann nun der Hersteller-Queue (3rd Level) zugeteilt werden und eine SLA des „child“ (in Übereinstimmung mit den Abmachungen mit dem Hersteller) kann definiert werden.
Situation 1.2: Der Hersteller hat keinen Zugang zu EriZone: Splitten Sie das ursprüngliche Ticket, verschieben Sie das Anfangsticket in die 3rd-Level-Gruppe und leiten Sie das „child“-Ticket per E-Mail an den Hersteller weiter.
Funktionelle Eskalation an den 2nd-Level-Support
Situation 2.1: Nur SD Agenten können mit dem Kunden kommunizieren: Splitten Sie das ursprüngliche Ticket und setzten Sie den Agenten als Kunden (requestor) des „child“-Tickets. Schieben Sie das „child“-Ticket in die 2nd-Level-Gruppe und definieren Sie eine entsprechende SLA. In diesem Fall sollten Kundeninformationen ausschließlich vom SD Agent gesammelt und im Anfangsticket festgehalten werden. Zum Weiterleiten der Informationen an das 2nd Level, soll das „child“-Ticket verwendet werde.
Situation 2.2: Der SD Agent ist verantwortlich für die Kommunikation mit dem Kunden, aber der 2nd-Level-Agent soll auch direkt mit dem Kunden kommunizieren können: Um zu vermeiden, dass zwei „Unterhaltungen“ entstehen, welche eigentlich das selbe Ticket betreffen, ist die Option des Splittens des Tickets sicher nicht gerade die beste Lösung. Die SD Agenten könnten das Ticket direkt zum 2nd Level verschieben, doch dann hätten wir wieder das Problem der Performancemessung der einzelnen Service Levels.
Eine Idee zur Lösung dieses Problems:
Sobald das Ticket in die 2nd-Level-Gruppe verschoben wird, soll automatisch ein separates Ticket erstellt werden, für welches eine eigene SLA definiert werden kann. Dieses neue, mit dem Anfangsticket verbundene Ticket dient lediglich der Performancemessung des 2nd-Level-Supports und wird automatisch abgeschlossen, sobald das ursprüngliche Ticket an den SD zurückgeschickt wird. So kann die SLA des 2nd-Level-Supports gemessen werden, aber auch der benötigte Zeitaufwand für das gesamte Ticket wird ersichtlich.
MarinovMihail
Developer at Würth Phoenix
“Hi guys! I’m Mihail and since the university years I has been fascinated by distributed systems and measurements on them. Now when I join the Neteye project I get the possibility to continue with this passion and this is great. My free time is completely dedicated to my wife and my daughters, I simply love them.”
Author
Latest posts by MarinovMihail
18. 06. 2019
NetEye, Unified Monitoring
Go pprof – How to Understand Where There is Memory Retention