Warum Incident-Kennzahlen mehr sind als Reporting
MTTA und MTTR tauchen in fast jeder Diskussion über On-Call-Prozesse auf. Trotzdem werden sie in vielen IT-Teams entweder gar nicht gemessen, falsch erhoben oder ausschließlich für Berichte verwendet, ohne dass aus ihnen operative Konsequenzen folgen. Dabei sind diese Kennzahlen – richtig eingesetzt – ein präzises Diagnosewerkzeug für die Gesundheit des eigenen Incident-Response-Prozesses.
Dieser Artikel beschreibt, was MTTA und MTTR wirklich messen, welche Messfehler häufig vorkommen, wie IT-Teams belastbare Daten erheben und wie KI-gestützte Auswertungen dabei helfen, Muster sichtbar zu machen, die in manuellen Reports unsichtbar bleiben.
Die Kennzahlen im Überblick
MTTD – Mean Time to Detect
MTTD misst die Zeit zwischen dem tatsächlichen Entstehen eines Problems und dem Zeitpunkt, zu dem das Monitoring-System es erkennt. Ein hoher MTTD-Wert deutet auf Lücken in der Monitoring-Abdeckung hin – Bereiche, die nicht überwacht werden, oder Schwellenwerte, die zu spät reagieren.
MTTA – Mean Time to Acknowledge
MTTA misst die Zeit zwischen dem Auslösen eines Alarms und dem Zeitpunkt, zu dem eine Person diesen Alarm bestätigt und die Verantwortung übernimmt. Es ist die Zeitspanne zwischen „der Alarm hat jemanden geweckt" und „jemand hat aktiv geantwortet". Hohe MTTA-Werte signalisieren Probleme bei der Erreichbarkeit, bei der Alarmzustellung oder bei der Motivation zur schnellen Reaktion.
MTTR – Mean Time to Resolve
MTTR misst die Zeit zwischen dem Erkennen eines Incidents (oder dem Alarmanerkenntnis) und seiner vollständigen Behebung. Es ist die Kennzahl, die direkt widerspiegelt, wie effizient ein Team einen Incident bearbeiten kann. Hohe MTTR-Werte können auf fehlende Runbooks, unklare Verantwortlichkeiten, schwierige Fehlerdiagnose oder fehlende Rollback-Mechanismen hindeuten.
MTTF und MTBF
MTTF (Mean Time to Failure) und MTBF (Mean Time Between Failures) ergänzen das Bild: Sie messen, wie lange ein System durchschnittlich läuft, bevor es ausfällt. Diese Kennzahlen sind besonders relevant für Hardware-Infrastruktur und Systeme mit bekannten Ausfallmustern.
Häufige Messfehler
Falscher Startpunkt für MTTR
Ein klassischer Messfehler: MTTR wird ab dem Zeitpunkt der Alarmanerkenntnis gemessen, nicht ab dem tatsächlichen Entstehen des Problems. Das verzerrt die Kennzahl, weil sie die Detektionszeit (MTTD) ausblendet. Für eine vollständige Sicht auf den Incident-Lebenszyklus sollte MTTR ab dem Zeitpunkt gemessen werden, zu dem das Problem tatsächlich aufgetreten ist – das erfordert manchmal manuelle Schätzungen oder Log-Analyse, ist aber für die Systemzuverlässigkeit relevanter.
Outlier ziehen den Durchschnitt
Ein einzelner, besonders komplexer Incident mit 8 Stunden MTTR kann den Monatsdurchschnitt deutlich verzerren, auch wenn alle anderen Incidents in unter 15 Minuten behoben wurden. Neben dem Mittelwert sollten Teams immer den Median und Perzentile betrachten (z.B. P90, P95) – diese sind robuster gegenüber Ausreißern und zeigen das typische Erlebnis präziser.
Incidents zu unterschiedlich definiert
Wenn jedes Team eigene Kriterien dafür hat, wann ein Alarm ein „Incident" ist und wann er nur ein „kurzer Ausrutscher" war, sind Vergleiche wertlos. Konsistente Definitionen – was wird als Incident erfasst, ab welchem Schweregrad – sind Voraussetzung für belastbare Kennzahlen.
Business-Hours-Bias
Teams, die ausschließlich während der Geschäftszeiten MTTA messen, unterschätzen ihre reale nächtliche Reaktionszeit. Wer ehrliche Zahlen will, muss nach Tageszeit, Wochentag und On-Call-Person segmentieren.
Belastbare Daten erheben
Die Grundlage guter Kennzahlen ist ein sauberer Daten-Workflow:
- Automatische Zeitstempel: Monitoring-Systeme, Alerting-Plattformen und Incident-Management-Tools müssen exakte Zeitstempel für Alarm-Auslösung, Anerkenntnis und Schließung automatisch erfassen – manuelle Eingaben sind fehleranfällig.
- Einheitliche Incident-Quelle: Alle Incidents sollten in einem zentralen System erfasst werden, nicht über mehrere Chat-Kanäle, E-Mails und Ticketsysteme verteilt.
- Schweregrad-Klassifikation: MTTA und MTTR sollten immer getrennt nach Schweregrad ausgewertet werden. Ein P1-Incident und ein P3-Incident in einen Topf zu werfen, produziert bedeutungslose Durchschnittswerte.
- Eindeutige Schließkriterien: Was bedeutet „resolved"? Ist der Dienst nur wieder erreichbar, oder ist auch die Ursache behoben und das Risiko eines Rückfalls beseitigt? Diese Definition beeinflusst die MTTR direkt.
KI-gestützte Auswertung: Was Algorithmen sehen, was Menschen übersehen
Manuelles Reporting zeigt Durchschnittswerte und Trends. KI-gestützte Analyse geht weiter:
Mustererkennung über Incidents hinweg
Machine-Learning-Modelle können Incidents gruppieren, die ähnliche Root Causes haben – auch wenn die Oberflächensymptome verschieden waren. Ein Algorithmus erkennt, dass 12 verschiedene Incidents über drei Monate alle auf denselben Datenbankknoten zurückzuführen waren, während das manuell nur durch aufwändige Postmortem-Analyse sichtbar geworden wäre.
Zeitliche Anomalieerkennung
KI-Systeme können identifizieren, zu welchen Tageszeiten, Wochentagen oder nach welchen Deployments Incidents überdurchschnittlich häufig oder mit höherer MTTR auftreten. Diese Korrelationen sind in tabellarischen Reports schwer zu entdecken.
Vorhersagemodelle für Incident-Wahrscheinlichkeit
Mit ausreichend historischen Daten lassen sich Vorhersagemodelle trainieren, die die Wahrscheinlichkeit eines Incidents in bestimmten Zeitfenstern schätzen – zum Beispiel nach bestimmten Deployments, bei bestimmten Lastprofilen oder an Wochenenden mit geringerer Monitoring-Abdeckung. Diese Vorhersagen ermöglichen proaktive Maßnahmen statt reaktiver Brandbekämpfung.
On-Call-Fairness analysieren
KI-Dashboards können erkennen, wenn bestimmte Personen systematisch mehr Incidents, komplexere Incidents oder Incidents zu ungünstigeren Zeiten bearbeiten. Das ist nicht nur eine Fairness-Frage, sondern auch ein Burnout-Risikosignal.
Von Kennzahlen zu konkreten Maßnahmen
Kennzahlen sind nur dann wertvoll, wenn sie Entscheidungen informieren. Typische Ableitungen:
- Hohe MTTA: Alarm-Zustellprobleme prüfen, Eskalationszeiten kürzen, On-Call-Training verbessern
- Hohe MTTR bei bestimmten Systemklassen: Runbooks fehlen oder sind veraltet, Tooling für Diagnose verbessern, mehr Expertenabdeckung im On-Call
- Steigende MTTD: Monitoring-Abdeckung prüfen, Schwellenwerte überarbeiten, synthetisches Monitoring ergänzen
- Hohe Incident-Häufigkeit nach Deployments: Deployment-Prozesse und Pre-Production-Testing überprüfen
Visualisierung und Kommunikation
Die Art, wie Kennzahlen präsentiert werden, bestimmt, ob sie wirken. Empfehlungen für die Praxis:
- Trendlinien statt Einzelwerte: Wie entwickelt sich MTTR über die letzten sechs Monate?
- Segmentierung nach Schweregrad und System: Wo ist die Situation schlimmer als anderswo?
- Vergleich vor und nach Verbesserungsmaßnahmen: Hat das neue Runbook geholfen?
- Regelmäßige Retrospektiven: Kennzahlen als Gesprächsgrundlage, nicht als Kontrollmittel
Fazit
MTTA und MTTR sind keine abstrakten KPIs für Quartalsberichte. Sie sind diagnostische Instrumente, die zeigen, wo im Incident-Response-Prozess Zeit verloren geht – und damit, wo Investitionen am meisten bewirken. KI-gestützte Auswertung macht Muster sichtbar, die manuelles Reporting übersieht, und ermöglicht proaktives Handeln statt reaktiver Schadensbegrenzung.
Teams, die ihre Incident-Kennzahlen ernst nehmen, lernen nicht nur aus jedem einzelnen Incident, sondern aus dem Muster aller Incidents gemeinsam – und das ist der Unterschied zwischen einer Organisation, die Probleme behebt, und einer, die sie systematisch verhindert.
Bildquelle: Pexels / Lukas (pexels.com/photo/590022) – Symbolbild: Analytik und Datenvisualisierung
