Was ist eine Eskalationsrichtlinie?

Wichtige Erkenntnisse: Eine Eskalationsrichtlinie definiert, wer benachrichtigt wird, wenn eine Warnmeldung für einen Vorfall ausgelöst wird, an wen der Vorfall übergeben wird, wenn die zuerst reagierende Person nicht verfügbar ist oder ihn nicht lösen kann, und wie diese Übergaben erfolgen – in der Regel abhängig von Schweregrad, Dauer und Umfang.

• Was es ist: Ein dokumentierter Pfad, der oft in einer Eskalationsmatrix erfasst wird und drei Arten der Eskalation verwendet: hierarchisch (nach Seniorität), funktional (nach Fachwissen) und automatisch (nach Regel, wenn eine Warnmeldung nicht rechtzeitig bestätigt wird).

• Warum es wichtig ist: Ohne einen solchen Plan geraten Vorfälle ins Stocken, während die Beteiligten herausfinden, wen sie anrufen müssen. Mit einem solchen Plan wird in wenigen Minuten die richtige Person für die Reaktion eingebunden, und niemand wird wegen der falschen Sache kontaktiert.

• So hilft Jira Service Management: Mit der Planung der Bereitschaft und den Warnmeldungen können Teams pro Service und Schweregrad Eskalationsregeln festlegen, nicht bestätigte Warnmeldungen automatisch eskalieren und innerhalb des Vorfallsdatensatzes eskalieren, damit jede Übergabe nachverfolgt wird.

Eine Eskalationsrichtlinie ist der dokumentierte Plan dafür, was passiert, wenn die erste Person, die über einen Vorfall benachrichtigt wird, ihn nicht allein bearbeiten kann: wer zuerst benachrichtigt wird, wer übernimmt, wenn die Person nicht verfügbar ist oder ihn nicht lösen kann, wie schnell die Übergabe erfolgt und über welchen Kanal. Es ist das Gegenstück zu einem Bereitschaftsplan – der Plan zeigt, wer verfügbar ist, die Richtlinie legt fest, wie der Vorfall zwischen ihnen weitergeleitet wird.

Im besten Fall behebt der Bereitschaftstechniker einen Vorfall selbst. Wenn für die Lösung ein größeres Team, spezialisiertes Wissen oder mehr Erfahrung erforderlich ist, brauchen Organisationen mit mehr als nur ein paar technischen Mitarbeitern einen Eskalationsplan. Dieser Leitfaden behandelt die Arten von Eskalation, die Eskalationsmatrix und Best Practices zum Verfassen einer effektiven Richtlinie.

Was sind Vorfalleskalationen?

Zu einer Vorfalleskalation kommt es, wenn ein Mitarbeiter einen Vorfall nicht selbst lösen kann und die Aufgabe an einen erfahreneren oder spezialisierteren Kollegen übergeben muss.

Was ist eine Eskalationsrichtlinie?

Die Fragen wirken einfach, aber je größer deine Organisation und je komplexer dein Technologie-Ökosystem ist, desto detaillierter müssen die Antworten ausfallen. Wenn du zum Beispiel festlegst, wer benachrichtigt werden soll, wenn eine Warnmeldung zu einem Vorfall eingeht, kann die Antwort nicht nur davon abhängen, wer Bereitschaft hat oder verfügbar ist, sondern auch von den Schweregraden, der Dauer des Vorfalls usw. 

In einigen Unternehmen kann ein einziger Bereitschaftsmitarbeiter die erste Person sein, die benachrichtigt wird, unabhängig vom Schweregrad des Vorfalls. In anderen Unternehmen ist es womöglich sinnvoller, einen weniger erfahrenen Entwickler bei Vorfällen mit Schweregrad 3 und einen erfahreneren Mitarbeiter oder ein spezialisiertes Team bei Vorfällen mit Schweregrad 1 zu informieren.

Ebenso bauen vielleicht einige Unternehmen darauf, dass der Erstbearbeiter Vorfälle bei Bedarf eskaliert. In anderen Unternehmen wird womöglich eine automatische Eskalation an einen erfahreneren Entwickler oder ein spezialisiertes Team ausgelöst, wenn ein Vorfall einen bestimmten Zeitraum überschreitet oder allmählich mehr Systeme oder Benutzer beeinträchtigt.

In einer Eskalationsrichtlinie solltest du nicht nur darauf eingehen, wie und an wen Vorfälle in deinem Unternehmen eskaliert werden, sondern auch darauf, ob es Unterschiede je nach Vorfalltyp, Schweregrad, Dauer und Umfang des Vorfalls gibt.

Prozesse für die Vorfalleskalation

In Unternehmen, die sich an ITSM-Best-Practices halten, steht in der Regel der Servicedesk im Mittelpunkt der Vorfalleskalation. Wenn der Erstbearbeiter einen Vorfall nicht lösen kann, wird er zurück zum Servicedesk geleitet, der das Problem dann an die entsprechende nächste Stelle eskaliert. Mit Jira Service Management können Bearbeiter Vorfälle innerhalb des Vorfalltickets eskalieren. Die Bearbeiter haben Zugriff auf Workflows, um den Lösungsprozess zu steuern, und können Aktionen automatisieren oder nach Bedarf anpassen. Durch die Angabe eines Schweregrads wird Bearbeitern ein entsprechender Arbeitsablauf zugewiesen.

Andere Unternehmen, wie beispielsweise Google, betrauen einen SRE-Mitarbeiter mit Vorfällen und diese Person ist für die nötigen Eskalationen verantwortlich (genau wie für das Stoppen von Releases, falls das Team wegen eines Vorfalls den laut SLA/SLO zulässigen Ausfallschwellenwert überschreitet).

In wieder anderen Unternehmen ist der Erstbearbeiter womöglich ein Entwickler oder ein Vorfallmanager oder es gibt mehrere Erstanlaufstellen (insbesondere bei Eingang einer Warnmeldung wegen eines Vorfalls mit hohem Schweregrad) und die Eskalation erfolgt anhand vordefinierter Prozesse direkt in und zwischen den Teams.

Unabhängig davon, ob der Prozess den Servicedesk durchläuft, durch einen SRE-Mitarbeiter verwaltet wird oder automatisch in deinen Vorfallverfolgungssystemen stattfindet: Es gibt drei Methoden, auf die Eskalationsrichtlinien in der Regel ausgerichtet sind.

Hierarchische Eskalation

Bei der hierarchischen Eskalation ist die Erfahrung oder die Dauer der Unternehmenszugehörigkeit ausschlaggebend dafür, an welches Team oder welche Person ein Vorfall weitergeleitet wird.

Der Erstbearbeiter im Bereitschaftsdienst könnte beispielsweise ein weniger erfahrener Entwickler sein, der neu im Team ist. Wenn dieser das Problem nicht lösen kann und hierarchisch vorgegangen wird, gibt er das Problem an einen erfahreneren Entwickler weiter. Wenn der erfahrenere Entwickler das Problem auch nicht lösen kann, gibt er das Problem an einen Entwickler mit noch mehr Erfahrung weiter. Dieser Prozess wird solange wiederholt, bis das Problem gelöst wurde.

Funktionelle Eskalation

Bei der funktionellen Eskalation werden Vorfälle an das Team oder die Person weitergeleitet, das bzw. die mit Blick auf Kompetenzen oder Systemkenntnisse am besten gerüstet ist, um das Problem zu lösen. Die Dauer der Unternehmenszugehörigkeit spielt dabei keine Rolle.

Der Erstbearbeiter im Bereitschaftsdienst kann beispielsweise ein weniger erfahrener Entwickler aus einem Team sein, das sich auf das Back-End von Produkt X konzentriert. Wenn dieser feststellt, dass das Kernproblem anscheinend auf eine Integration mit Produkt Y zurückzuführen ist, eskaliert er den Vorfall an einen anderen weniger erfahrenen Entwickler im für Produkt Y zuständigen Team.

Automatische Eskalation

Für Teams, die mit einer Plattform wie Opsgenie arbeiten, kannst du auch Regeln festlegen, damit das System einen Vorfall automatisch eskaliert, wenn der primäre Bereitschaftsmitarbeiter eine Warnmeldung nicht bestätigt oder schließt.

Manche Teams ziehen möglicherweise eine bestimmte Eskalationsmethode vor. Die Methoden schließen sich aber nicht gegenseitig aus und viele Teams nutzen eine Kombination aus hierarchischer, funktioneller und automatischer Eskalation.

Die Eskalationsmatrix

Eine Eskalationsmatrix ist ein Dokument oder System, mit dem definiert wird, wann eine Eskalation stattfinden und wer Vorfälle auf jeder Eskalationsebene bearbeiten sollte.

Der Begriff wird in zahlreichen Branchen verwendet. Im Personalwesen gibt es vielleicht eine Eskalationsmatrix für interne Probleme. Callcenter können eine Eskalationsmatrix für Kundenserviceprobleme haben. IT- und DevOps-Team haben in der Regel mindestens eine Matrix, die den Technikern hilft, zu bestimmen, wie und wann ein Vorfall eskaliert werden muss.

Der Detailgrad einer Matrix ist von Unternehmen zu Unternehmen sehr unterschiedlich. Manche Unternehmen haben möglicherweise ein einfaches hierarchisches Diagramm und jeder Entwickler eskaliert bei Bedarf an einen anderen Entwickler mit höherem Qualifikationsniveau. Andere Unternehmen verfügen vielleicht über situationsspezifische Matrizen, denen Entwickler entnehmen können, welche Teams sie je nach Vorfalltyp oder Schweregrad kontaktieren sollen. Wie es im Vorfallmanagement meistens der Fall ist, gibt es auch zum Erstellen der Matrix für dein Unternehmen keine Universallösung.

Empfehlungen für die Erarbeitung einer Eskalationsrichtlinie

Eskalationsrichtlinie als Leitfaden und nicht als verbindliches Regelwerk

Technologie ist nichts Statisches – und deine Teams auch nicht. Google empfiehlt, SRE-Mitarbeitern das flexible Entscheiden nach eigenem Ermessen zu ermöglichen, wenn sie der Meinung sind, dass in einem bestimmten Fall eine andere Eskalationsstrategie angebracht ist. Es geht hier nicht darum, unflexible Regeln festzulegen, sondern einen Leitfaden für die meisten Situationen zu erstellen.

Regelmäßige Prüfung des Bereitschaftsplans

Gibt es Lücken im Plan? Stehen die richtigen Mitarbeiter auf Abruf bereit? Sind die richtigen Mitarbeiter in der zweiten und dritten Bereitschaftsstufe eingeteilt? Deine Bereitschaftspläne und Eskalationsrichtlinie sollten ineinandergreifen, um ein schnelleres Vorfallmanagement zu ermöglichen.

Intelligente Schwellenwerte für Eskalationen

Vorfälle sind nicht alle gleich und demnach sollten sie auch nicht alle der gleichen Eskalationsrichtlinie folgen. 

Bei unwesentlichen Vorfällen muss der Techniker im Bereitschaftsdienst vielleicht nicht vor den Geschäftszeiten alarmiert werden. Bei schwerwiegenden Vorfällen brauchst du wahrscheinlich diesen Techniker, egal zu welcher Zeit des Tages. Falls mehrere Vorfälle auftreten, muss der Techniker wissen, um was er sich zuerst kümmern soll und/oder ob er einen Vorfall sofort an einen zweiten Techniker eskalieren soll.   

Hier ist ein echter Balanceakt erforderlich: Einerseits musst du sicherstellen, dass Systeme maximale Verfügbarkeit bieten und SLA-Versprechen eingehalten sowie SLO-Ziele erreicht werden. Andererseits gilt es, Techniker vor Burn-out, Überarbeitung, Schlafentzug und Alarm-Fatigue zu bewahren.

Klare Prozesse für Eskalationen

Soll der Entwickler, der die Eskalation veranlasst, sich direkt an das entsprechende Team bzw. die entsprechende Person wenden, oder muss er den Weg über den Helpdesk gehen? Gibt es ein System, das der Entwickler nutzen sollte? Wie verfolgst du Eskalationen? Was sind die Aufgaben des Erstbearbeiters, um sicherzustellen, dass der Vorfall von der nächsten Person übernommen wird?

Diese Fragen sollten in deiner Richtlinie klar beantwortet werden. Außerdem ist es wichtig, alle Entwickler im Bereitschaftsdienst diesbezüglich unmissverständlich zu informieren, damit Eskalationen reibungslos vonstattengehen und Vorfälle schneller gelöst werden.

Erfahre mehr darüber, wie Jira Service Management dein Vorfallmanagement vereinfacht und die Problemlösung beschleunigt, indem es die gemeinsame Bearbeitung und Eskalation von Vorfällen ermöglicht.