Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

So wählst du KPIs und Metriken für das Vorfallmanagement aus

Nachverfolgung und Verbesserung des Vorfallmanagements im Laufe der Zeit

In der heutigen, von ständiger Verfügbarkeit geprägten Welt, sind technische Vorfälle mit erheblichen Auswirkungen verbunden.

Systemausfallzeiten kosten Unternehmen durchschnittlich 300.000 US-Dollar pro Stunde an Umsatzverlusten, Mitarbeiterproduktivität und Wartungsgebühren. Bei umfangreicheren Ausfällen können diese Kosten noch viel höher sein (Delta Airlines kostete ein IT-Ausfall im Jahr 2017 etwa 150 Millionen US-Dollar). Und Kunden, die ihre Rechnungen nicht bezahlen, sich nicht per Videokonferenz in ein wichtiges Meeting einschalten oder ein Flugticket nicht kaufen können, wandern schnell zu einem Mitbewerber ab.

Nachdem so viel auf dem Spiel steht, ist es für die Teams wichtiger denn je, die KPIs für das Vorfallmanagement zu verfolgen und die Ergebnisse zu nutzen, um Vorfälle zu erkennen, zu diagnostizieren, zu beheben und – letztendlich – zu verhindern.

Die gute Nachricht ist, dass Teams bei Web- und Softwarevorfällen (anders als bei Vorfällen in mechanischen und nicht vernetzten Systemen) i. d. R. viel mehr Daten erfassen können, um Ursachen zu verstehen und Prozesse zu verbessern.

Und die schlechte Nachricht? Manchmal können zu viele Daten Probleme verschleiern, anstatt sie zu beleuchten.

Der Nutzen von KPIs, Metriken und Analysen von Vorfällen

KPIs (Key Performance Indicators) sind Metriken, die Unternehmen dabei helfen, zu erkennen, ob sie bestimmte Ziele erreichen. Beim Vorfallmanagement können diese Metriken etwa die Anzahl der Vorfälle, die durchschnittliche Zeit für die Behebung oder die durchschnittliche Zeit zwischen Vorfällen sein.

Die Verfolgung von KPIs für das Vorfallmanagement kann helfen, Probleme mit Prozessen und Systemen zu identifizieren und zu diagnostizieren, Benchmarks und realistische Ziele für das Team festzulegen, auf die es hinarbeiten kann, sowie einen Ausgangspunkt für umfassendere Fragestellungen bieten.

Nehmen wir z. B. an, das Ziel des Unternehmens ist es, alle Vorfälle innerhalb von 30 Minuten zu lösen. Dein Team benötigt derzeit jedoch durchschnittlich 45 Minuten. Ohne konkrete Metriken kann man nur schwer feststellen, was schiefläuft. Arbeitet dein Warnmeldungssystem zu langsam? Stimmt etwas mit deinem Prozess nicht? Muss dein Diagnosetool aktualisiert werden? Handelt es sich um ein Teamproblem oder ein technisches Problem?

Mit Metriken wird die Sache um einiges leichter: Wenn du genau weißt, wie lange das Warnmeldungssystem braucht, kannst du es als Problem identifizieren oder ausschließen. Wenn du weißt, dass die Diagnose mehr als 50 % der Zeit in Anspruch nimmt, kannst du hier mit der Fehlerbehebung ansetzen. Wenn du feststellst, dass Team B 25 % länger braucht als die Teams A, C und D, weist dies auf ein Teamproblem hin.

Vier Teams, welche die mittlere Reaktionszeit (MTTR) unterschiedlich messen

KPIs werden deine Probleme nicht automatisch lösen, sie helfen dir aber zu verstehen, wo das Problem liegt. Dann kannst du deine Energie darauf richten, in bestimmten Bereichen gezielter nachzuforschen.

Beliebte KPIs und Metriken für Vorfälle

Erstellte Warnmeldungen

Wenn du ein Benachrichtigungstool verwendest, ist es hilfreich zu wissen, wie viele Warnungen in einem bestimmten Zeitraum generiert werden. Mit einem Tool wie Opsgenie kannst du sowohl Warnmeldungen senden als auch Berichte und Dashboards erstellen, um sie zu verfolgen.

Halte Ausschau nach Zeiträumen mit signifikanten, untypischen Steigerungen oder Rückgängen oder mit Aufwärtsentwicklungen. Gehe dann den Ursachen für diese Veränderungen auf den Grund und kläre ab, wie deine Teams darauf reagieren.

Zahl der Vorfälle im Laufe der Zeit

Wenn du Vorfälle über längere Zeit verfolgst, kannst du die durchschnittliche Anzahl von Vorfällen in einem bestimmten Zeitraum erkennen. Das kann wöchentlich, monatlich, vierteljährlich, jährlich oder sogar täglich sein.

Treten Vorfälle im Laufe der Zeit mehr oder weniger häufig auf? Ist die Anzahl der Vorfälle akzeptabel oder dürfte sie niedriger sein? Sobald du ein Problem mit der Anzahl der Vorfälle identifiziert hast, kannst du Fragen dazu stellen, warum diese Zahl nach oben tendiert oder hoch bleibt und was das Team tun kann, um einen Vorfall zu beheben.

MTBF

MTBF (mittlere Betriebsdauer zwischen Ausfällen) ist die durchschnittliche Betriebszeit zwischen behebbaren Ausfällen eines Technologieprodukts. Du kannst damit die Verfügbarkeit und Zuverlässigkeit eines Produkts nachverfolgen.

Wie andere Metriken auch ist sie ein guter Ausgangspunkt, um wichtigere Fragen zu klären. Wenn deine MTBF niedriger ist, als es dir lieb ist, solltest du dich fragen, warum die Systeme so oft ausfallen und wie du zukünftige Ausfälle reduzieren oder verhindern kannst.

MTTA

MTTA (mittlere Zeit bis zur Bestätigung) ist die durchschnittliche Zeitdauer zwischen einer Systemwarnmeldung und der Bestätigung des Vorfalls und dem Beginn von Vorfallbehebungsmaßnahmen durch ein Teammitglied. Der Wert veranschaulicht, wie schnell dein Team auf Probleme reagiert.

Sobald du weißt, dass es ein Problem bei der Reaktion gibt, kannst du genauer nachforschen. Warum ist eine MTTA hoch? Sind Teams überlastet oder abgelenkt? Ist unklar, wer für die Warnmeldung zuständig ist? Die MTTA kann dir helfen, ein Problem zu identifizieren, und mithilfe dieser Fragen kannst du ihm auf den Grund gehen.

MTTD

MTTD (mittlere Erkennungszeit) ist die durchschnittliche Zeit, die dein Team benötigt, um ein Problem zu erkennen. Dieser Begriff wird häufig im Bereich Cybersicherheit verwendet, wo sich Teams mit der Erkennung von Angriffen und Sicherheitsverletzungen befassen.

Wenn sich diese Metrik drastisch ändert oder nicht ganz ins Schwarze trifft, solltest du die Gründe dafür ermitteln.

MTTR

MTTR kann für mittlere Reparaturzeit, mittlere Problemlösungszeit, mittlere Reaktionszeit oder mittlere Wiederherstellungszeit stehen. Die wohl nützlichste dieser Metriken ist die mittlere Problemlösungszeit, die nicht nur die Zeit für die Diagnose und Behebung eines unmittelbaren Problems verfolgt, sondern auch die Zeit, die aufgewendet wird, um ein erneutes Auftreten des Problems zu verhindern. Die Wiederherstellungszeit ist eine wichtige DevOps-Metrik, die laut DevOps Research and Assessment (DORA) entscheidend für die Stabilität des DevOps-Teams ist.

Diese Metrik eignet sich am besten für Diagnosen. Sind deine Problemlösungszeiten so schnell und effizient, wie du es dir wünschst? Wenn nicht, solltest du dir detailliertere Fragen darüber stellen, inwiefern und warum diese Problemlösungszeit ungenügend ist.

Die Wiederherstellungszeit ist eine wichtige DevOps-Metrik, die laut DevOps Research and Assessment (DORA) die Stabilität eines DevOps-Teams misst. Es handelt sich dabei um die für die Erfassung, Eindämmung und Behebung eines Problems insgesamt benötigte Zeit.

Bereitschaftszeit

Falls du mehrere Bereitschaftsdienstmitarbeiter hast, die in Schichten arbeiten, könntest du nachverfolgen, wie viel Zeit Mitarbeiter und Auftragnehmer im Bereitschaftsdienst verbringen.Diese Metrik kann dir dabei helfen sicherzustellen, dass kein Mitarbeiter oder Team überlastet wird.

In einem Tool wie Opsgenie kannst du umfassende Berichte generieren, um diese Zahlen auf einen Blick darzustellen.

Service Level Agreement (SLA)

Ein SLA (Service Level Agreement) ist eine Vereinbarung zwischen Anbieter und Kunden über messbare Metriken wie Verfügbarkeit, Reaktionsfähigkeit und Verantwortlichkeiten.

Die in SLAs festgehaltenen Versprechen (bezüglich Verfügbarkeit, mittlerer Wiederherstellungszeit usw.) sind einer der Gründe, warum Vorfallmanagementteams diese Metriken nachverfolgen müssen. Wenn sich Dinge wie die durchschnittliche Reaktionszeit oder die mittlere Betriebsdauer zwischen Ausfällen ändern, müssen Verträge aktualisiert und/oder Korrekturen vorgenommen werden, und zwar schnell.

Service Level Objective (SLO)

Ein SLO (Service Level Objective) ist eine Vereinbarung innerhalb eines SLAs zu einer bestimmten Metrik wie der Verfügbarkeit. Wie SLAs selbst sind SLOs wichtige Kennzahlen, um sicherzustellen, dass das Unternehmen eigene Versprechen bezüglich des Kundenservice einhält.

Zeitstempel (oder Zeitleiste)

Ein Zeitstempel ist eine codierte Information darüber, was zu bestimmten Zeiten während, vor oder nach dem Vorfall passiert ist. Diese Informationen werden in der Regel nicht als Metrik angesehen. Sie sind aber nützlich, wenn du den Zustand deines Vorfallmanagements beurteilen und Strategien für Verbesserungen entwickeln möchtest.

Zeitstempel helfen Teams dabei, Zeitleisten für den Vorfall sowie für die Maßnahmen davor oder danach zu erstellen. Eine klare, gemeinsam genutzte Zeitleiste ist eines der hilfreichsten Mittel für Post-Mortem-Analysen von Vorfällen.

Betriebszeiten

Verfügbarkeit ist die Zeitspanne (dargestellt als Prozentsatz), während der deine Systeme verfügbar und funktionsfähig sind.

Die zunehmende Konnektivität bei Online-Services und die sich erhöhende Komplexität der Systeme selbst bedeutet, dass es eigentlich keine garantierte Verfügbarkeit von 100 % gibt. Das Ziel für die meisten Produkte ist die Hochverfügbarkeit. Damit ist gemeint, dass ein System oder Produkt über einen längeren Zeitraum unterbrechungsfrei läuft. Laut Branchenstandard ist eine Verfügbarkeit von 99,9 % sehr gut und von 99,99 % hervorragend.

Wenn du deinen Erfolg anhand dieser Kennzahl misst, geht es darum, Kunden Versprechungen zu machen und diese einzuhalten. Wie alle anderen Metriken auch, ist sie nur ein Ausgangspunkt. Wenn deine Verfügbarkeit nicht bei 99,99 % liegt, wird die Frage nach dem "Warum" umfangreichere Nachforschungen, Gespräche mit deinem Team und die Untersuchung von Prozessen, Strukturen, Zugriffen oder Technologien erforderlich machen.

Vorsicht bei der Analyse von Vorfällen

Der Nachteil von KPIs besteht darin, dass man sich leicht zu sehr auf ungenügende Daten verlässt. Wenn du weißt, dass dein Team Vorfälle nicht schnell genug behebt, führt dich das noch lange nicht zu einer Lösung. Du musst nach wie vor herausfinden, wie und warum das Team Probleme behebt oder eben nicht. Außerdem musst du wissen, ob die Probleme, die du vergleichst, überhaupt vergleichbar sind.

KPIs können dir keinen Aufschluss darüber geben, wie deine Teams an schwierige Probleme herangehen. Sie können nicht erklären, warum die Zeit zwischen Vorfällen immer kürzer anstatt länger wird. Und sie liefern dir keine Antwort darauf, warum Vorfall A dreimal länger als Vorfall B dauerte.

Um all diese Fragen zu beantworten, benötigst du Einblicke. Daten können zwar als Ausgangspunkt dafür dienen, diese Einblicke zu erlangen, aber sie können auch ein Hindernis dafür sein. Sie können uns den Eindruck vermitteln, dass wir genug tun, selbst wenn sich unsere Kennzahlen nicht verbessern. Es kann passieren, dass Vorfälle, die in der Realität erhebliche Unterschiede aufweisen und eine unterschiedliche Herangehensweise erfordern, zusammengefasst werden. Die Erfahrung deiner Teams und die zugrunde liegenden Komplexitäten von Vorfällen können außer Acht gelassen werden.

"Vorfälle sind viel einzigartiger als die gängige Meinung einen glauben macht. Zwei Vorfälle derselben Dauer können bei der Ermittlung der Geschehnisse völlig unterschiedliche Grade an Überraschung und Unsicherheit bei Mitarbeitern hervorrufen. Sie können auch sehr unterschiedliche Risiken aufweisen, welche die Maßnahmen beeinflussen, die zur Milderung oder Verbesserung der Situation ergriffen werden. Vorfälle sind keine Widgets, die in Bereichen fabriziert werden, in denen eine geringe Abweichung der physischen Abmessungen als wichtiges Qualitätsmerkmal betrachtet werden."
- John Allspaw, Moving Past Shallow Incident Data

Damit ist nicht gemeint, dass KPIs schlecht sind und du diese komplett verwerfen solltest. Wir wollen nur deutlich machen, dass KPIs allein nicht ausreichen. Sie sind ein Ausgangspunkt, ein Diagnosewerkzeug. Sie sind der erste Schritt auf einem komplexeren Weg hin zu echten Verbesserungen.

Weiter geht's
Common metrics