Gesunde On-Call-KPIs: Noise reduzieren und systemische Fixes fördern

Gesunde On-Call-KPIs sind ein wirksames Steuerungsinstrument für SRE-, Plattform- und Betriebsteams, wenn sie nicht als „Performance-Messung von Menschen“, sondern als Gesundheitsindikatoren für Systeme und Prozesse verstanden werden. In vielen Organisationen ist On-Call jedoch ein Dauerstress: Pager-Duty-Noise, wiederkehrende Alarme ohne klare Aktion, zu viele Eskalationen und ein permanentes Gefühl, „hinterherzulaufen“. Das Problem ist selten fehlender Einsatz, sondern fehlende Signallogik: Alerts sind nicht auf Nutzerwirkung und SLOs ausgerichtet, Ursachen werden nicht nachhaltig behoben, und die Erfolgskennzahlen belohnen kurzfristiges Feuerlöschen statt systemischer Fixes. Genau hier setzen gesunde On-Call-KPIs an: Sie machen Alarmqualität messbar, reduzieren kognitiven Overhead, fördern Automatisierung und zwingen Teams, strukturelle Ursachen anzugehen. Dieser Artikel zeigt praxistaugliche Kennzahlen, Zielwerte, Anti-Patterns und konkrete Mechanismen, um Noise zu senken und langfristige Verbesserungen zu incentivieren – ohne die falschen Anreize zu setzen.

Warum klassische On-Call-Metriken oft die falschen Anreize setzen

Viele Teams messen On-Call mit naheliegenden Zahlen: „Wie schnell wurde reagiert?“, „Wie viele Tickets wurden geschlossen?“, „Wie viele Incidents gab es?“ Diese Metriken sind nicht per se falsch, werden aber schnell toxisch, wenn sie als individuelle Leistungsbewertung genutzt werden oder wenn sie Ursachen nicht von Symptomen trennen. Dann optimiert man auf „schnell ruhigstellen“ statt auf nachhaltige Stabilität. Noise kann sogar steigen, weil jede Kleinigkeit alarmiert wird, um „nichts zu verpassen“. Ein gesundes KPI-Set muss daher zwei Dinge leisten: Es muss Belastung (Pager Load) und Signalqualität sichtbar machen – und es muss messbar belohnen, wenn Teams systemische Fixes umsetzen.

• Anti-Pattern: „MTTA/MTTR um jeden Preis“ → Teams löschen Symptome, verlagern Risiken.
• Anti-Pattern: „Viele Incidents = schlechtes Team“ → Incidents werden umklassifiziert oder versteckt.
• Anti-Pattern: „Ticket-Throughput“ → kurzfristige Arbeit gewinnt gegen Reliability Engineering.
• Gesundes Ziel: weniger Unterbrechungen, höhere Signalqualität, stabile SLOs, nachhaltige Fixes.

Grundlage: On-Call-KPIs müssen SLOs und Nutzerwirkung widerspiegeln

On-Call existiert, um Nutzerwirkung schnell zu begrenzen und Systeme stabil zu halten. Deshalb sollten die wichtigsten On-Call-KPIs eng mit SLOs, Error Budgets und „Actionability“ verknüpft sein. Ein Alert, der keine Handlung auslöst, ist kein Alert, sondern ein Logeintrag mit Sirene. Ein Incident ohne Nutzerwirkung kann trotzdem relevant sein (z. B. drohende Sättigung), aber dann muss die Eskalationslogik sauber sein: Warnung vs. Page.

• Page: erfordert sofortige menschliche Aktion, klare Runbook-Schritte, hohe Wahrscheinlichkeit für Nutzerimpact.
• Ticket: wichtig, aber nicht zeitkritisch; wird in Arbeitszeit bearbeitet.
• Observation: nur für Trend/Debug; darf nicht dauerhaft „an“ bleiben, ohne Ziel.

Für SLO-basierte Betriebsführung und Alerting-Prinzipien ist das Google SRE Book ein solider Referenzpunkt, insbesondere die Kapitel zu Monitoring und Incident Response.

Kategorie 1: Noise-KPIs (Belastung sichtbar machen)

Noise-KPIs messen die Unterbrechungslast und helfen, Überforderung objektiv zu erkennen. Wichtig ist, dass diese Kennzahlen nicht dazu dienen, „wer am meisten abbekommt“ zu bewerten, sondern um Alarmregeln, Ownership und Systemdesign zu verbessern. Idealerweise sind die KPIs segmentiert nach Service, Alarmtyp, Uhrzeit (Business Hours vs. Off-Hours) und Ursache (Alert Family).

Pages pro On-Call-Schicht und pro Woche

Eine einfache Kennzahl ist die Anzahl von Pages, die wirklich einen Pager auslösen. Sie sollte nicht isoliert betrachtet werden, aber sie ist ein guter Startpunkt, um Trends zu erkennen.

• Segmentierung: Off-Hours Pages separat auswerten.
• Drill-down: Top 10 Alerts nach Häufigkeit und nach „Wiederholrate“.
• Interpretation: Hohe Page-Zahl ist ein Symptom; die Ursache liegt oft in fehlendem Tuning.

Noise Rate: Anteil nicht-actionabler Pages

„Nicht-actionable“ bedeutet: keine klare Aktion, false positive, bereits bekannt/dupliziert, oder nur Informationswert. Dieser Anteil sollte konsequent sinken, sonst verbrennt das Team Aufmerksamkeit.

$\mathrm{NoiseRate}=\frac{\mathrm{Pages}{\mathrm{nonActionable}}_{}}{\mathrm{Pages}{\mathrm{total}}_{}}$

• Praxis: Jede Page erhält im Nachgang ein Label: actionable / non-actionable + Grundcode.
• Ziel: nicht „0%“, sondern so niedrig, dass On-Call Vertrauen in den Pager hat.

Duplication Factor: Wie oft alarmiert dasselbe Problem?

Ein häufiger Stressor sind Alarmstürme, bei denen ein einzelner Ausfall Dutzende Pages erzeugt. Der Duplication Factor macht das sichtbar: Wie viele Pages entstehen pro Incident oder pro Root Cause?

$\mathrm{DuplicationFactor}=\frac{\mathrm{Pages}{\mathrm{total}}_{}}{\mathrm{Incidents}{\mathrm{unique}}_{}}$

• Hebel: Alert-Deduplizierung, Gruppierung, „fan-in“ statt „fan-out“.
• Hebel: Multi-Window/Burn-Rate Alerts statt einzelner Schwellenalarme pro Pod.

Off-Hours Interruption Minutes

Nicht jede Page ist gleich belastend. Eine einzelne Page mit 90 Minuten Debugging kann schlimmer sein als fünf kurze, gut dokumentierte Aktionen. Interruption Minutes messen die tatsächliche Unterbrechung, z. B. von Page bis „stabil“ oder bis Übergabe an den nächsten Kanal.

• Messung: Startzeit Page → Endzeit Mitigation (nicht unbedingt vollständiger Fix).
• Nutzen: zeigt, ob Runbooks und Automatisierung wirken.

Kategorie 2: Signalqualität-KPIs (Alerts als Produkt behandeln)

Ein reifes SRE-Team behandelt Alerts wie ein Produkt: mit Qualitätskriterien, Versionierung und kontinuierlichem Tuning. Signalqualität bedeutet: der richtige Alarm, zur richtigen Zeit, mit der richtigen Dringlichkeit, mit ausreichend Kontext, damit die erste Person handeln kann.

Actionability Score (konsequent und einfach)

Ein praktischer Ansatz ist ein Score pro Alert, der mehrere Qualitätsmerkmale zusammenführt. Wichtig ist weniger die perfekte Formel, sondern die konsequente Bewertung im Betrieb.

• Runbook vorhanden (ja/nein)
• Owner klar (Team/Service eindeutig)
• Kontext (Dashboard/Logs/Trace-Link enthalten)
• Dringlichkeit korrekt (Page vs. Ticket)
• Wiederholrate (tritt der Alert häufig ohne Impact auf?)

Alert-to-User-Impact Ratio

Wenn sehr viele Pages ohne korrelierbaren Nutzerimpact auftreten, ist das ein starkes Indiz für falsche Schwellen, fehlende Deduplizierung oder nicht SLO-basiertes Alerting.

$\mathrm{AlertImpactRatio}=\frac{\mathrm{Pages}{\mathrm{total}}_{}}{\mathrm{Incidents}{\mathrm{withUserImpact}}_{}}$

• Ziel: niedriger Ratio-Wert, ohne „Impact zu verstecken“.
• Hebel: Pages an SLO-Burn koppeln, symptomorientierte Alerts priorisieren.

Time-to-First-Useful-Action

Diese Kennzahl misst nicht, wie schnell jemand „reagiert“, sondern wie schnell eine sinnvolle Aktion stattfindet: Mitigation, Traffic-Shift, Rollback, Feature-Flag, Rate-Limit. Damit belohnen Sie gute Runbooks, gute Alarmtexte und gute Automatisierung.

• Praxis: Incident-Timeline enthält „erste wirksame Aktion“ als Marker.
• Interpretation: Wenn diese Zeit hoch ist, fehlen oft Kontextlinks oder klare Schritte.

Kategorie 3: Systemische-Fix-KPIs (Langfristige Verbesserungen fördern)

Wenn Sie Noise reduzieren wollen, müssen Sie nicht nur Alerts tunen, sondern Ursachen eliminieren. Deshalb brauchen Sie KPIs, die systemische Fixes sichtbar machen und priorisieren. Wichtig ist dabei die Unterscheidung zwischen „Work abgeschlossen“ und „Risiko reduziert“.

Recurrence Rate: Wiederkehrende Incidents und wiederkehrende Alerts

Wiederkehr ist der Feind gesunder On-Call-Rotation. Wenn derselbe Incident-Typ wiederkommt, war die Maßnahme vermutlich nur symptomatisch oder unvollständig.

• Incident Recurrence: gleicher Root Cause innerhalb von X Tagen/Wochen.
• Alert Recurrence: gleicher Alert-Fingerprint mit gleicher Mitigation.
• Hebel: Problem Management, dauerhafte Fixes, bessere Tests und Guardrails.

Percent of Toil vs. Engineering Time

„Toil“ beschreibt repetitive, manuelle, nicht skalierende Arbeit. Ein gesundes KPI-Set macht sichtbar, wie viel Zeit in Toil fließt und wie sich das über Monate verändert. Ziel ist, Toil zu reduzieren und Zeit für Reliability Engineering zu schaffen.

• Toil-Beispiele: manuelle Restarts, wiederholte Datenkorrekturen, ständiges Alert-Acknowledge ohne Aktion.
• Engineering-Beispiele: Automatisierung, Guardrails, Architekturfixes, Testhärtung.

Eine konzeptionelle Einordnung von Toil und SRE-Arbeit findet sich im Google SRE Book (Stichwort: Toil reduzieren, Engineering statt Feuerwehr).

Closure Quality: RCA- und Action-Item-Qualität statt „Ticket geschlossen“

Wenn Action Items nur „Dokumentation verbessern“ sind, ohne technische Guardrails, bleibt das Risiko. Ein gutes KPI ist daher nicht die Anzahl, sondern die Qualität: Sind Action Items spezifisch, messbar und auf Risiko-Reduktion ausgerichtet?

• Gute Action Items: Retry-Budget enforced, Circuit Breaker eingeführt, Rate-Limits getestet, bessere Deduplizierung.
• Schwache Action Items: „Mehr aufpassen“, „Dashboard anschauen“, „Dokumentation irgendwann“.
• Praxis: Action Items bekommen Typen: Guardrail / Automation / Observability / Capacity / Process.

Alert Hygiene: Die wichtigsten Hebel, um Noise messbar zu reduzieren

Noise sinkt nicht durch „härtere Menschen“, sondern durch bessere Alarme. Alert Hygiene ist ein kontinuierlicher Prozess: Regeln werden angepasst, neue Signale werden eingeführt, alte werden entfernt. Entscheidend ist, dass das Tuning als reguläre Engineering-Arbeit geplant wird.

• SLO-Burn-Rate Alerting: statt Schwellen auf Einzelmetriken, die häufig flappen.
• Deduplizierung und Gruppierung: ein Incident → ein Page, nicht fünfzig.
• Severity-Policy: klare Regeln, wann Page, wann Ticket, wann nur Beobachtung.
• Kontext erzwingen: Alarmtext muss Links zu Dashboard, Logs, Traces und Runbook enthalten.
• Auto-Remediation: bekannte, sichere Schritte automatisieren (mit Guardrails und Limits).

Balanced Scorecard: Ein gesundes KPI-Set, das nicht „gamable“ ist

Ein einzelner KPI ist leicht zu „optimieren“, ohne dass es besser wird. Daher ist eine Balanced Scorecard sinnvoll: wenige Kennzahlen, die sich gegenseitig ausbalancieren. Wenn jemand versucht, Noise zu senken, indem er Alarme einfach abschaltet, steigt die Nutzerwirkung oder das Error-Budget-Burn, und die Scorecard zeigt das sofort.

• Noise: Pages pro Woche (Off-Hours), NoiseRate, DuplicationFactor
• Impact: SLO-Burn (schnell/langsam), Incidents mit Nutzerimpact
• Qualität: Time-to-First-Useful-Action, Runbook Coverage
• Systemisch: Recurrence Rate, Toil-Anteil, Guardrail-Actions umgesetzt

Zielwerte: Was als „gesund“ gelten kann (pragmatische Orientierung)

Es gibt keine universellen Grenzwerte, aber es gibt pragmatische Orientierungen, die in vielen Teams funktionieren. Wichtig ist: Zielwerte müssen zum Reifegrad passen und über Zeit besser werden. Ein Team, das von „Pager chaos“ kommt, sollte zuerst eine Trendverbesserung anstreben, nicht sofort Idealwerte.

• NoiseRate: klar sinkender Trend; Priorität auf „keine Page ohne Aktion“
• DuplicationFactor: deutlich unter Alarmsturm-Niveau durch Gruppierung/Dedupe
• Runbook Coverage: Top-Alerts haben Runbooks und Kontextlinks
• Recurrence: wiederkehrende Root Causes werden als Problem-Cluster priorisiert
• Off-Hours: Ziel ist spürbar weniger Unterbrechungen, nicht „Heldentum“

Prozessmechaniken, die KPIs in echte Verbesserungen übersetzen

KPIs allein verändern nichts, wenn sie nicht in Routinen eingebettet sind. Bewährt haben sich kurze, regelmäßige Mechaniken: wöchentliches Alert-Review, monatlicher Reliability-Review und ein klarer Pfad von „Top Noise Alerts“ zu „Engineering-Arbeit“. Entscheidend ist, dass Teams Zeit bekommen, die Ursachen zu beheben.

• Weekly Alert Review: Top 10 Alerts, Top 3 Noise-Quellen, konkrete Tuning-PRs
• Incident Triage: wiederkehrende Muster clustern, Problem Tickets mit Owner und Deadline
• Error Budget Policy: bei hohem Burn werden Feature-Changes eingeschränkt, Reliability priorisiert
• Blameless Postmortems: Fokus auf System, nicht auf Schuld; Action Items messbar und wirksam

Für Postmortem-Prinzipien und nachhaltige Verbesserungen ist „Postmortem Culture“ im Google SRE Book eine sinnvolle Referenz.

Anti-Patterns bei On-Call-KPIs und wie man sie vermeidet

Gesunde On-Call-KPIs können kippen, wenn sie falsch kommuniziert oder falsch verwendet werden. Typische Anti-Patterns lassen sich verhindern, indem Sie klar definieren, wofür KPIs gedacht sind: Systemgesundheit, nicht Mitarbeiterbewertung.

• Ranking von Personen: führt zu Vermeidungsverhalten; messen Sie Teams/Systeme, nicht Individuen.
• „Zero Alerts“-Ziel: verleitet zum Abschalten; besser: „Pages nur bei Aktion“.
• Nur MTTR: belohnt schnelle Mitigation ohne Ursachenfix; ergänzen Sie Recurrence und Toil.
• Keine Segmentierung: globale Zahlen verschleiern Hotspots; segmentieren nach Service und Alert-Family.
• Keine Zeit für Fixes: KPI ohne Engineering-Kapazität erzeugt Frust; planen Sie Reliability-Sprints.

Copy-Paste: KPI-Definitionen für ein gesundes On-Call-Programm

• Pages Off-Hours: Anzahl Pages außerhalb Business Hours pro Woche
• NoiseRate: nicht-actionable Pages / total Pages
• DuplicationFactor: total Pages / unique Incidents
• Time-to-First-Useful-Action: Page → erste wirksame Mitigation (Median + P95)
• Runbook Coverage: Anteil der Top-Alerts mit Runbook + Kontextlinks
• Recurrence Rate: Anteil der Incidents mit gleichem Root Cause innerhalb von X Tagen
• Toil Share: Toil-Zeit / Gesamtzeit der Betriebsarbeit (trend über Monate)
• Guardrail Throughput: Anzahl umgesetzter systemischer Fixes pro Monat (z. B. Dedupe, Rate Limits, Auto-Remediation)

Outbound-Links für vertiefende Best Practices

• Google SRE Book für SLOs, Alerting-Prinzipien, Toil und Incident Response
• Google SRE Book: Monitoring Distributed Systems für Signaldesign und sinnvolles Alerting
• Google SRE Book: Incident Response für On-Call-Prozesse, Rollen und Incident-Steuerung
• Google SRE Book: Postmortem Culture für systemische Lernprozesse und wirksame Action Items
• SREcon (USENIX) für praxisnahe Vorträge und Case Studies zu On-Call, Alert Fatigue und Reliability Engineering

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.