Im On-Call-Betrieb ist das Bauchgefühl ein schlechter Ratgeber. Wer verbessern möchte, wie sein Team auf Vorfälle reagiert, braucht Daten. Aber nicht jede Kennzahl ist nützlich – und manche wird schädlich, wenn sie falsch eingesetzt wird. Dieser Artikel beschreibt, welche On-Call-Metriken wirklich Steuerungsrelevanz haben, was sie konkret messen und wie Teams sie produktiv nutzen, ohne daraus ein Instrument zur Leistungskontrolle einzelner Personen zu machen.
Warum Metriken im On-Call-Betrieb unverzichtbar sind
On-Call-Dienst ist teuer – in Zeit, Energie und manchmal in der Lebensqualität der beteiligten Ingenieure. Ohne Metriken lässt sich kaum beurteilen, ob sich der Bereitschaftsdienst verbessert oder verschlechtert, ob neue Alerts sinnvoll waren oder ob bestimmte Systeme unverhältnismäßig viel Aufmerksamkeit beanspruchen.
Metriken schaffen Transparenz: Sie zeigen, wo der größte Handlungsbedarf liegt, und machen Verbesserungen sichtbar. Sie helfen dabei, das Gespräch mit dem Management auf sachlicher Grundlage zu führen – etwa wenn ein Team mehr Kapazität oder weniger technische Schulden benötigt.
Mean Time to Acknowledge (MTTA)
Die Mean Time to Acknowledge misst die durchschnittliche Zeit zwischen dem Auslösen eines Alarms und der Bestätigung, dass eine zuständige Person den Alarm wahrgenommen hat und sich darum kümmert.
Eine hohe MTTA kann verschiedene Ursachen haben:
- Die Eskalationskette ist unklar oder nicht aktuell konfiguriert.
- Alarme erreichen die diensthabende Person nicht zuverlässig (falscher Kanal, kein Weckalarm nachts).
- Alert Fatigue hat dazu geführt, dass Ingenieure Alarme ignorieren, bis sie als wirklich dringend eingestuft werden.
- Es gibt keine klare Definition, wer für welches System verantwortlich ist.
MTTA ist kein Maß für die Leistung einzelner Personen. Eine Ingenieurin, die nachts um 3 Uhr einen Alarm erhält, wird natürlich länger brauchen als jemand, der tagsüber am Rechner sitzt. Sinnvoll ist es, MTTA nach Tageszeit und Schicht zu segmentieren und Ausreißer zu analysieren statt Durchschnittswerte blind zu optimieren.
Mean Time to Resolve (MTTR)
Die Mean Time to Resolve beschreibt die durchschnittliche Zeit zwischen dem ersten Alarm und der vollständigen Behebung des Problems – also dem Zeitpunkt, zu dem der betroffene Service wieder stabil läuft.
MTTR ist die meistgenannte On-Call-Metrik und gleichzeitig die am häufigsten falsch interpretierte. Eine hohe MTTR bedeutet nicht zwangsläufig, dass Ingenieure langsam arbeiten. Sie kann bedeuten:
- Das Problem war besonders komplex und schwer zu diagnostizieren.
- Wichtige Runbooks fehlen oder sind veraltet.
- Abhängigkeiten zu anderen Teams oder externen Diensten haben die Lösung verzögert.
- Die Observability des betroffenen Systems war unzureichend – fehlende Logs oder Traces machen die Diagnose schwierig.
Sinnvoller als ein einziger Gesamtdurchschnitt ist die Segmentierung der MTTR nach Systembereich, Severity-Level und Ursachenkategorie. So lässt sich gezielt dort ansetzen, wo die größten Verbesserungspotenziale liegen.
Alarmvolumen und Alarmqualität
Das absolute Alarmvolumen – also wie viele Alarme ein Team pro Schicht oder pro Woche erhält – ist eine der wichtigsten, aber oft vernachlässigten Metriken im On-Call-Betrieb.
Ein hohes Alarmvolumen korreliert direkt mit Alert Fatigue: Je mehr Alarme eingehen, desto größer die Gefahr, dass kritische Ereignisse in der Masse untergehen oder dass Ingenieure beginnen, Alarme reflexartig zu schließen ohne sie wirklich zu analysieren.
Mindestens so wichtig wie das Volumen ist die Alarmqualität:
- Actionable Rate: Welcher Anteil der Alarme erfordert tatsächlich eine manuelle Reaktion? Alarme, die automatisch behoben werden oder die keine Konsequenz haben, sollten eliminiert oder als informational umklassifiziert werden.
- False Positive Rate: Wie viele Alarme stellen sich im Nachhinein als falsch heraus? Eine hohe False-Positive-Rate ist ein sicheres Zeichen für zu niedrig gesetzte Schwellenwerte oder schlecht kalibrierte Bedingungen.
- Doppelalarme: Wie viele Alarme betreffen denselben Incident? Gut konfiguriertes Alert Grouping verhindert, dass ein einzelner Vorfall Dutzende von Benachrichtigungen erzeugt.
Weitere sinnvolle Kennzahlen
Neben den Kerndaten gibt es weitere Metriken, die On-Call-Teams wichtige Erkenntnisse liefern:
- Incidents per Shift: Wie viele Vorfälle muss eine diensthabende Person im Durchschnitt bearbeiten? Dieser Wert ist direkt mit der Belastung der Ingenieure verbunden.
- Pages outside business hours: Wie viele Alarme treffen außerhalb regulärer Arbeitszeiten ein? Ein hoher Anteil nächtlicher Alarme ist ein klares Signal für Handlungsbedarf – entweder bei der Alarmkonfiguration oder beim Systemdesign.
- Recurring Incidents: Wie viele Incidents sind Wiederholungen desselben Problems? Wiederkehrende Vorfälle zeigen, dass Root Causes nicht nachhaltig behoben wurden – ein häufiges Symptom von zu wenig Zeit für tiefe Problemlösung.
- Time to Escalate: Wie schnell eskaliert ein Incident an die nächste Stufe, wenn der erste Ansprechpartner nicht verfügbar ist oder nicht weiterkommt?
Typische Fehler beim Umgang mit On-Call-Metriken
Metriken können schaden, wenn sie falsch eingesetzt werden. Der häufigste Fehler ist die Nutzung von MTTA oder MTTR als persönliche Leistungskennzahl. Das führt dazu, dass Ingenieure Alarme schnell bestätigen, ohne sie zu bearbeiten, oder Incidents voreilig schließen, um die MTTR zu senken.
Metriken sollten immer auf Systemebene aggregiert werden – nicht auf Personenebene. Sie zeigen Muster, keine Schuldigen. Eine hohe MTTR in einem bestimmten Systembereich ist Anlass für ein Gespräch über Runbooks, Observability und technische Schulden – nicht für Kritik an einzelnen Personen.
KI-gestützte Metrik-Analyse
Aktuelle KI-Werkzeuge können die Auswertung von On-Call-Metriken deutlich beschleunigen. Sprachmodelle lassen sich nutzen, um Incident-Logs automatisch zu kategorisieren und wiederkehrende Muster zu identifizieren. Einige Plattformen bieten KI-gestützte Anomalieerkennung für Alerting-Metriken: Wenn das Alarmvolumen in einem bestimmten System plötzlich steigt, wird das als Signal erkannt – noch bevor manuell ausgewertet wird.
Darüber hinaus können KI-Systeme Korrelationen zwischen Metriken aufdecken, die Menschen leicht übersehen – etwa dass eine bestimmte Deployment-Frequenz mit einem Anstieg nächtlicher Alarme zusammenfällt. Diese Erkenntnisse liefern Grundlagen für datengetriebene Entscheidungen über Deployment-Prozesse oder Änderungen an der Systemarchitektur.
On-Call-Metriken sind ein Spiegel der Systemqualität – nicht ein Maßstab für die Qualität einzelner Ingenieure.
Bild: Serverracks in einem Rechenzentrum, Wikimedia Commons (CC BY 2.0, Serverracks im Datacenter)
Quellen
- Google SRE Book: Kapitel zu Alerting und On-Call-Philosophie (sre.google/sre-book)
- PagerDuty Incident Response Documentation (response.pagerduty.com)
- Charity Majors: Blogbeitraege zu On-Call und Observability (charity.wtf)
