Vorfallmanagement für High-Velocity-Teams
Eskalationsrichtlinien für effektives Vorfallmanagement
Im Idealfall kann dein Techniker oder SRE-Mitarbeiter im Bereitschaftsdienst einen aufgetretenen Vorfall schnell und alleine lösen.
In der Praxis ist das aber natürlich nicht immer der Fall. Manchmal sind zum Lösen eines Problems ein größeres Team, Fachwissen oder erweiterte Kompetenzen erforderlich. Aus diesem Grund benötigt jedes Unternehmen mit mehr als zwei Technikexperten einen Plan und eine Richtlinie für die Eskalation von Vorfällen.
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?
Eine Eskalationsrichtlinie regelt, wie in deinem Unternehmen diese Übergaben gehandhabt werden. In ihr wird beschrieben, wer beim Eingang einer Vorfallalarmierung zu benachrichtigen ist, an wen ein Vorfall eskaliert werden sollte, wenn der Erstbearbeiter nicht verfügbar ist, wer den Fall übernehmen sollte, falls der Bearbeiter das Problem nicht selbst lösen kann, und wie diese Übergaben erfolgen sollten (Über den Servicedesk? Von einem Techniker direkt an einen anderen? Über ein Vorfallmanagementtool?)
Auf den ersten Blick scheinen diese Fragen einfach zu sein, doch je größer dein Unternehmen und je komplexer die technische Umgebung ist, desto mehr Details müssen beachtet werden. Wer bei Eingang einer Vorfallalarmierung zu benachrichtigen ist, kann beispielsweise in Abhängigkeit davon variieren, wer Bereitschaftsdienst hat oder verfügbar ist, aber auch basierend auf 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. 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.
Einrichten eines Bereitschaftsplans mit Opsgenie
In diesem Tutorial erfährst du, wie du einen Bereitschaftsplan einrichtest, Regeln für Außerkraftsetzungen anwendest, Bereitschaftsbenachrichtigungen konfigurierst und vieles mehr – und das alles in Opsgenie.
Dieses Tutorial ansehenEin besseres Konzept für die Bereitschaftsplanung
Ein effektiver Bereitschaftsplan ist für eine nachhaltige, gesunde Bereitschaftskultur entscheidend. Wir zeigen dir häufige Fehler, Arten von Rotationsplänen und wie du es richtig machst.
Diesen Artikel lesen