Erhalte 30 % Rabatt, wenn du dich für Jira Service Management anmeldest
Vorfallmanagement für High-Velocity-Teams
Ein Leitfaden für Manager zur Verbesserung des Bereitschaftsdienstes
In der Notaufnahme werden Bereitschaftspläne für Ärzte benötigt, damit sie sich um gesundheitliche Notfälle kümmern. DevOps-Teams benötigen ebensolche Pläne für die Reaktion auf Software- und Systemprobleme, die sich auf die Leistung, das Deployment und die Verfügbarkeit auswirken.
Das Einführen und Verwalten des Bereitschaftsdienstes ist jedoch keine leichte Aufgabe. Bereitschaftsarbeit kann für Mitarbeiter eine abschreckende und leidige Erfahrung sein. Das richtige Gleichgewicht zwischen Abdeckung, Skalierbarkeit und Lebensqualität für das Team zu finden, ist eine ständige Herausforderung.
Während sich Best Practices verändern und Unternehmen wachsen, implementieren die agilsten High-Velocity-Teams neue Ansätze und sind damit erfolgreich.
You built it, you maintain it
Noch vor zehn Jahren war das Reagieren auf IT-Vorfälle in erster Linie die Aufgabe von Operations-Teams. Unternehmen hatten in der Regel eine gestaffelte Teamstruktur (d. h. Level 1, Level 2, Level 3 … mit höheren Qualifikationsniveaus und Gehältern auf den höheren Stufen).
Mit dieser Struktur sollten die Betriebskosten reduziert werden. Level 1 umfasste in der Regel Berufsanfänger. Wenn Level 1 ein Problem nicht lösen konnte, wurde an die erfahreneren (und demnach auch teureren) Mitarbeiter von Level 2 eskaliert. Dieser Prozess wurde solange wiederholt, bis das Problem gelöst war.
Doch mit der Zunahme der durchgehenden Services nahmen auch die Verflechtung von Systemen und die Kundenerwartungen in puncto Verfügbarkeit zu. Heute kann eine langsame Reaktion ein Unternehmen mit Blick auf seinen Ruf, die Kundenzufriedenheit und Umsatzeinbußen mehr kosten als das frühzeitige Einbeziehen erfahrenerer Entwickler bei einem Vorfall.
Die sich verändernde Technologielandschaft hat dazu geführt, dass auch die Struktur der Reaktionsteams sich verändern musste. Hier kommt die DevOps-Bewegung mit dem Konzept "you built it, you maintain it" ins Spiel, bei dem der Entwickler eines Produkts auch für die nachfolgende Wartung zuständig ist.
Der Grundgedanke ist einfach: Der Entwickler, der sich am besten mit dem Code auskennt, kann damit verbundene Probleme am schnellsten lösen. Dank DevOps und dieser Logik ist es mittlerweile üblich, dass Entwickler Bereitschaftsdienst haben, um sicherzustellen, dass der Code reibungslos funktioniert, und die durchschnittliche Zeit bis zur Bestätigung (Mean Time To Acknowledge, MTTA) und durchschnittliche Zeit bis zur Lösung (Mean Time To Resolve, MTTR) bei Vorfällen zu verkürzen.
Ein zusätzlicher Vorteil dieses Ansatzes ist, dass vor dem Deployment sorgfältiger getestet wird. Da der für den Code zuständige Entwickler außerhalb der regulären Arbeitszeiten alarmiert werden kann, gibt es ein größeres Verantwortungsbewusstsein und einen höheren Anreiz, den Code zwei- oder sogar dreimal zu prüfen. Dadurch verzeichnen immer mehr Unternehmen zuverlässigere und stabilere Systeme.
Aufbau eines Bereitschaftsdienstes, mit dem sich die Teams anfreunden können
Der Bereitschaftsdienst gerät zuweilen in Verruf – und manchmal aus gutem Grund. Unausgewogene Bereitschaftsprogramme können sich negativ auf die Work-Life-Balance, die Gesundheit und den Schlaf auswirken. Mitarbeiter, die schlechte oder noch gar keine Erfahrungen mit dem Bereitschaftsdienst gemacht haben, befürchten möglicherweise, dass er das Ende ihres Privatlebens und der Work-Life-Balance bedeutet.
Tatsächlich muss der Bereitschaftsdienst aber nicht zwangsläufig mit einer geringeren Lebensqualität verbunden sein. Durch eine ausgewogene Verteilung der Aufgaben, die Berücksichtigung von Teampräferenzen und die Implementierung robuster Systeme zum bestmöglichen Vermeiden und Reduzieren der Warnmeldungen während des Bereitschaftsdienstes kannst du die Belastung minimieren und auf deine Teams aufteilen.
Damit das Management dies erfolgreich umsetzen kann, bedarf es zum einen grundsätzlicher Transparenz gegenüber Teams. Zum anderen ist viel Training erforderlich und es müssen faire Erwartungen für Bereitschafts- und Entwicklungsaufgaben vermittelt werden. Außerdem werden zuverlässige Prozesse benötigt und es sollte kontinuierliche Rücksprache mit den Teams gehalten werden, um mit deren Input und Unterstützung Verbesserungen herbeizuführen.
Transparenz gegenüber deinen Teams
Transparenz ist der Schlüssel für eine erfolgreiche Kommunikation. Das Klären der Erwartungen rund um die Verfügbarkeit ist ein absolutes Muss, wenn ein Bereitschaftssystem eingeführt oder ein bestehendes Bereitschaftssystem verändert wird. Mach dir Gedanken über gängige Mitarbeiterfragen wie die folgenden und achte darauf, sie klar zu beantworten:
- Haben Techniker über Nacht Bereitschaftsdienst?
- Ist es bei Bereitschaftsdienst über Nacht möglich, am nächsten Tag im Homeoffice zu bleiben? Kann ein Bereitschaftsmitarbeiter am nächsten Tag später mit der Arbeit anfangen, wenn er Schlaf nachholen muss?
- Müssen Entwickler während des Bereitschaftsdienstes Entwicklungsarbeit leisten?
- Wie viele Male wird ein Entwickler im Monat für den Bereitschaftsdienst eingeteilt? Wie oft kann eine Person maximal Bereitschaftsdienst haben?
- Wie sieht die Vergütung für Bereitschaftsmitarbeiter aus?
Angemessenes Training
Zu den Best Practices für die Schulung von Teams im Bereitschaftsdienst zählen folgende:
- Erstellung eines Schulungsprogramms, in dem sowohl prozessbezogene als auch allgemeine Probleme berücksichtigt werden
- Bereitstellung aktueller Runbooks
- Anlernen neuer Mitarbeiter durch Beobachtung erfahrener Techniker im Bereitschaftsdienst
- Ermöglichen des Zugriffs auf Berichte zu früheren Vorfällen, damit Mitarbeiter nachsehen können, wie ähnliche Vorfälle erfolgreich behoben wurden
Außerdem ist es gut, mehrere Eskalationskanäle zu haben. Die typische Best Practice besteht darin, noch unerfahrene Techniker der primären Bereitschaftsrotation zuzuordnen und erfahrene Techniker als Unterstützung oder sekundäre Rotation einzuplanen. So können weniger erfahrene Techniker sich die erforderlichen Kompetenzen für den Bereitschaftsdienst aneignen, ohne in Panik zu verfallen, falls ein Problem über ihr Know-how hinausgeht.
Trennung von Bereitschafts- und Entwicklungsaufgaben
Das Bearbeiten von Entwicklungsaufgaben im Bereitschaftsdienst ist in der Regel mit vielen Kontextwechseln und Unterbrechungen verbunden, insbesondere in Unternehmen mit häufigen Vorfällen und hohen Bereitschaftsanforderungen.
All das führt meistens zu einer geringeren Entwicklungseffizienz und mehr Stress für die Entwickler im Bereitschaftsdienst, was Burn-outs, Alarm-Fatigue und Unzufriedenheit im Job nach sich ziehen kann. Auch negative Auswirkungen auf Entwicklungs-Sprints sind möglich, da sich schwer abschätzen lässt, wie viel ein Bereitschaftsmitarbeiter zu einem bestimmten Sprint beitragen kann und wird.
Aus diesem Grund empfehlen wir die Trennung von Bereitschafts- und Entwicklungsaufgaben. Wenn Mitarbeiter im Bereitschaftsdienst Zeit haben, können sie an der Verbesserung der bereitschaftsbezogenen Dokumentation und Automatisierung arbeiten, um die Zukunftsfähigkeit von Systemen und Services zu verbessern.
Optimierung des Bereitschaftsprozesses
Ein intaktes Bereitschaftssystem ist nur möglich, wenn es durch eine Optimierung der Prozesse und Systeme beständig verbessert wird. Passe Bereitschaftspläne, Weiterleitungsregeln und Eskalationsrichtlinien mit einer Vorfallmanagementlösung wie Jira Service Management an, um Warnungen effizient zu verarbeiten. Dafür empfehlen wir Folgendes:
- Evaluierung der Priorität und Dringlichkeit von Warnmeldungen und Einrichtung entsprechender Systeme. Warnmeldungen mit geringer Dringlichkeit können bis zum Morgen warten, sodass Bereitschaftsmitarbeiter ihr Schlafdefizit ausgleichen können.
- Reduzierung von Fehlmeldungen durch Klassifizierung von Warnmeldungen anhand von Faktoren wie Ursache, Ursprungssystem, Meldung, Schwellenwerten usw. So lassen sich handlungsorientierte Warnmeldungen vom Rest trennen.
- Deduplizierung zusammengehöriger Warnmeldungen zur Vermeidung von Alarm-Fatigue.
- Design umfangreicher Warnmeldungen, in denen ein Problem genau beschrieben wird und die den Bereitschaftsmitarbeitern eine effektive Entscheidungsfindung sowie die Nutzung der Informationen aus Runbooks ermöglichen.
- Bereitstellung von Warnmeldungsberichten und Metriken für die Teams im Bereitschaftsdienst, damit Schwachstellen in Systemen identifiziert und verbessert werden können. (Anders ausgedrückt: Es sollte vermieden werden, dass die Bereitschaftsteams immer wieder mit den gleichen Problemen zu kämpfen haben.)
Prüfung der Berichte zum Bereitschaftsdienst und Anpassungen nach Bedarf
Der Fairness halber und zur Vermeidung des Burn-outs bei Mitarbeitern sollten Manager anhand der bereitschaftsbezogenen Berichte Folgendes überprüfen:
- Wie oft wurden die einzelnen Teammitglieder über den Pager kontaktiert oder aufgeweckt?
- Wie lange hatten die einzelnen Teammitglieder Bereitschaftsdienst?
- Wie wurden die Bereitschaftsaufgaben stündlich und täglich unter den Mitarbeitern verteilt?
- Die Pläne sollten nach Bedarf angepasst werden, um eine faire Arbeitsverteilung zu gewährleisten.
Den Mitarbeitern zuhören
Das Management sollte regelmäßige Mitarbeiterversammlungen mit den für den Bereitschaftsdienst eingeteilten Technikern veranstalten, um Probleme, Beschwerden und Schwachstellen zu besprechen und dann die nötigen Maßnahmen zu ergreifen.
Die Systeme, Tools, Prozesse, Mitarbeiter, Dokumentation und das Training im Bereitschaftsdienst sind keine statischen Dinge, um die du dich einmal kümmerst und dann nicht mehr beachten musst. Im Zuge des Unternehmenswachstums, der Wissenserweiterung und Veränderung von Teams sowie des Wandels der Vorfälle im Laufe der Zeit sollte das Management seine Bereitschaftsprogramme immer wieder neu bewerten und verbessern.
Die Techniker im Bereitschaftsdienst können dir am ehesten sagen, was funktioniert und was nicht. Nimm dir ihr Feedback zu Herzen. Implementiere die nötigen Änderungen. Und achte vor allem darauf, dass das Management im Hinblick auf die Organisation und Protokolle des Bereitschaftsdienstes keine Entscheidungen im Alleingang trifft. Je mehr du es Teams ermöglichst, ihre Prozesse und Praktiken zu verbessern, umso besser werden sie den Bereitschaftsdienst annehmen.
Entwicklung einer mitarbeiterfreundlichen Bereitschaftskultur
Die Techniker im Bereitschaftsdienst tragen große Verantwortung im Hinblick auf den Erfolg des Unternehmens. Es ist also nicht überraschend, dass Stress und Anspannung gängige Probleme sind, insbesondere bei gravierenden Fehlern mit unbekannter Ursache.
Die von erfahrenen Bereitschaftsmitarbeitern und Managementteams geschaffene Bereitschaftskultur definiert, wie mit diesem Stress und dieser Anspannung umgegangen wird und was Mitarbeiter vom Bereitschaftsdienst halten.
Um der Bereitschaftsmitarbeiter und der Bereitschaftskultur des Unternehmens willen sollten Managementteams darauf achten, eine mitarbeiterfreundliche Bereitschaftskultur zu entwickeln, und verdeutlichen, dass das Ziel immer das Aufdecken von Problemen, Risiken und Schwächen in Systemen mit anschließender Behebung sein sollte.
Bei Atlassian achten wir nicht nur auf die kontinuierliche Verbesserung unserer Bereitschaftssysteme. Wir führen auch Post-Mortem-Analysen ohne Schuldzuweisungen aus, bei denen der Fokus auf der Verbesserung und nicht auf dem Finden eines Schuldigen liegt.
Entdecke Jira Service Management – eine Lösung, die eine positive Bereitschaftskultur unterstützt. Damit verbesserst du die Incident Response durch ein System mit verbesserten Kommunikationsfunktionen, zentralisierter Warnmeldung, flexibler Automatisierung und erweiterter Berichterstellung.
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