Eskalationsrichtlinien für effektives Vorfallmanagement

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.

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. Schwerwiegendere Vorfälle erfordern aber wahrscheinlich das Eingreifen des Technikers unabhängig von der Uhrzeit. 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.