On-Call-KPIs designen, die systemische Fixes fördern

On-Call-KPIs designen, die systemische Fixes fördern, ist eine der wirksamsten Stellschrauben, um Incident-Last nachhaltig zu senken. Viele Organisationen messen On-Call vor allem über Aktivität: Anzahl der Alerts, Anzahl der Tickets, Reaktionszeiten. Das wirkt objektiv, führt aber häufig zu falschen Anreizen. Wenn Teams für „schnelles Schließen“ belohnt werden, entstehen Workarounds statt Ursachenbehebung. Wenn „weniger Alerts“ als Ziel gilt, werden Warnungen stummgeschaltet, statt Systeme stabiler zu machen. Und wenn On-Call ausschließlich als individuelles Leistungsproblem betrachtet wird, fehlt der Blick auf technische Schulden, fehlende Automatisierung, fragiles Dependency-Design oder unzureichende SLOs. Gute On-Call-KPIs lenken nicht auf Heldentum, sondern auf systemische Verbesserungen: weniger Wiederholincidents, weniger Paging außerhalb von SLO-relevanten Ereignissen, kürzere Zeit bis zur nachhaltigen Behebung, bessere Detection-Qualität und klarere Ownership. Dieser Artikel zeigt, wie Sie On-Call-KPIs so konzipieren, dass sie Stabilität messbar machen, Verhaltensanreize korrekt setzen und einen kontinuierlichen Fix-Loop unterstützen – inklusive konkreter KPI-Vorschläge, Formeln, Anti-Patterns und Governance, damit die Kennzahlen nicht zur Bürokratie werden, sondern zur Hebelwirkung.

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

On-Call ist ein sozio-technisches System: Es verbindet technische Zuverlässigkeit mit Teamstrukturen, Entscheidungswegen und Priorisierung. KPIs, die nur „Output“ messen (z. B. Anzahl gelöster Tickets), erfassen selten die wahren Kosten: Unterbrechungen, Kontextwechsel, Risiken durch Müdigkeit, Qualitätseinbußen durch Quick Fixes und die schleichende Normalisierung von Instabilität. Besonders gefährlich sind Metriken, die unbeabsichtigt „Alert-Optimierung“ statt „System-Optimierung“ fördern.

• „Alert Count“ als Ziel: Führt zu Silencing statt Ursachenbehebung.
• „MTTR um jeden Preis“: Belohnt schnelle Workarounds und verschiebt technische Schulden.
• „Sev1/Sev2 vermeiden“: Kann zu Downscoping oder Umklassifizieren von Incidents führen.
• Individuelle Rankings: Erzeugen Angstkultur und reduzieren Transparenz.

Ein belastbarer Rahmen, um Betrieb über SLOs und Error Budgets zu steuern, ist im Google SRE Book (Service Level Objectives) beschrieben. Daraus lässt sich ableiten: On-Call-KPIs sollten an Nutzerimpact und Systemverhalten gekoppelt sein, nicht an „Busy-ness“.

Designprinzipien für On-Call-KPIs mit Fix-Fokus

Bevor Sie konkrete Kennzahlen definieren, hilft ein Satz an Prinzipien. Diese Prinzipien sorgen dafür, dass KPIs die richtigen Diskussionen auslösen und nicht zur Kennzahlenkosmetik führen.

• Impact-first: Messen Sie, was Nutzer und Business betrifft (SLO-Burn, Journey-Failures), nicht nur interne Aktivität.
• Systemisch statt individuell: KPIs auf Team-/Service-Ebene, nicht als Personenvergleich.
• Fix-Loop messbar machen: Von Incident → Root Cause → Follow-up → wirksame Prävention.
• Qualität der Signale: Gute Alerting-KPIs sind „weniger, aber besser“, ohne Blindheit zu erzeugen.
• Segmentierbar: Nach Service, Fehlerklasse, Dependency, Region, Change-Typ.
• Resistent gegen Gaming: Definitionen so wählen, dass Umklassifizierung und Silencing nicht „hilft“.

Die KPI-Landschaft strukturieren: Vier Kategorien statt Kennzahlenchaos

Eine häufige Ursache für KPI-Frust ist unstrukturierte Vielfalt. Praktikabel ist eine Einteilung in vier Kategorien, die zusammen den Fix-Fokus abdecken.

• Stabilität & Nutzerimpact: Wie viel SLO-relevanter Schaden entsteht?
• On-Call-Load & Unterbrechung: Wie belastend ist das Paging und wie stark stört es Fokusarbeit?
• Signalqualität & Observability: Wie präzise sind Alerts, und wie gut ist die Diagnosefähigkeit?
• Systemische Verbesserungen: Wie schnell und wie zuverlässig werden Ursachen nachhaltig behoben?

Kategorie 1: Stabilität & Nutzerimpact messen (SLO-gekoppelt)

Wenn On-Call-KPIs systemische Fixes fördern sollen, müssen sie den „Schaden“ sichtbar machen, der durch Instabilität entsteht. Am saubersten gelingt das über SLOs und Error Budgets. On-Call sollte nicht „Incidents minimieren“, sondern „SLO-Verletzungen minimieren“ – denn nicht jede Störung ist gleich relevant.

• Error-Budget-Verbrauch pro Service: Anteil des Budgets, der durch Incidents/Degradation verbrannt wird.
• SLO-Burn Rate Peaks: Wie oft und wie stark steigt die Burn Rate über definierte Schwellen?
• Impact-Minuten: Nutzeranteil × Dauer × Schwere (z. B. Journey-Failures).
• Wiederholte SLO-Breaches: Anzahl SLO-Verletzungen mit gleicher Fehlerklasse/Root-Cause-Familie.

Formelbeispiel: Error-Budget-Verbrauch

Wenn Ihr SLO eine zulässige Fehlerquote eslo pro Zeitraum definiert und die gemessene Fehlerquote eobs ist, kann der Budgetverbrauch als Anteil des zulässigen Fehlers modelliert werden:

$\mathrm{BudgetUsed}=\frac{e_{\mathrm{obs}}}{e_{\mathrm{slo}}}$

So sehen Sie sofort, ob ein Incident „nur sichtbar“ war oder tatsächlich die Zuverlässigkeitsziele gefährdet.

Kategorie 2: On-Call-Load messen, ohne Heldentum zu fördern

On-Call-Load ist real: Er beeinflusst Fokus, Gesundheit und letztlich auch die Qualität von Fixes. Gute KPIs messen Belastung, ohne daraus individuelle Leistungsbewertungen zu machen. Ziel ist, strukturelle Überlast sichtbar zu machen und zu reduzieren.

• Pages pro Schicht (pro Service): Anzahl Pager-Events, getrennt nach „actionable“ und „noise“.
• After-Hours-Paging-Rate: Anteil der Pages außerhalb definierter Kernzeiten.
• Page-Storm-Indikator: Burst von Alerts in kurzer Zeit (z. B. > N Pages in 10 Minuten).
• Time-to-Acknowledge (TTA) als Diagnose, nicht als Ziel: Nur als Gesundheitsindikator für Überlast, nicht als KPI für „gutes On-Call“.

Formelbeispiel: After-Hours-Paging-Rate

Diese Kennzahl macht sichtbar, wie stark On-Call private Zeit regelmäßig stört, ohne einzelne Personen zu bewerten:

$\mathrm{AfterHoursRate}=\frac{P_{\mathrm{after}}}{P_{\mathrm{total}}}$

Wenn diese Rate hoch ist, ist das meist ein Signal für fehlende Stabilität, unpassende Alert-Schwellen oder fehlende automatische Mitigations.

Kategorie 3: Signalqualität – KPIs, die „weniger, aber besser“ liefern

Systemische Fixes entstehen schneller, wenn Alerts präzise sind und Diagnose schnell gelingt. Deshalb lohnt es sich, die Qualität des Alertings selbst zu messen. Zentral ist dabei die Frage: Hat ein Alert eine klare Handlung ausgelöst oder war er Noise?

• Actionability Rate: Anteil der Pages, die eine konkrete Aktion erfordern (Mitigation, Rollback, Degradation).
• False-Positive-Rate: Anteil der Alerts ohne reales Problem oder ohne Relevanz für Nutzerimpact.
• Duplicate-Rate: Alerts, die denselben Zustand mehrfach paged (fehlende Deduplication/Grouping).
• Mean Time to Diagnose (MTTDx): Zeit bis zur plausiblen Ursache/Hypothese, nicht bis zur Lösung.
• Runbook Coverage: Anteil der Alerts mit verlinktem Runbook und klaren First Steps.

Für Observability-Standards und konsistente Telemetrie ist OpenTelemetry eine hilfreiche Referenz, weil es die Vereinheitlichung von Logs, Metriken und Traces unterstützt – ein Kernbaustein für bessere Diagnosezeiten.

Actionability Rate operational definieren

Damit die Kennzahl nicht beliebig wird, definieren Sie „actionable“ streng: Ein Pager ist actionable, wenn innerhalb eines definierten Fensters eine Maßnahme erfolgt (z. B. Feature Flag toggeln, Rollback, Traffic-Shift, Rate Limit anpassen) oder ein Incident formal eröffnet wird. Alternativ ist er „noise“, wenn er ohne Maßnahme und ohne bestätigten Impact geschlossen wird.

$\mathrm{Actionability}=\frac{P_{\mathrm{actionable}}}{P_{\mathrm{total}}}$

Kategorie 4: Systemische Verbesserungen messbar machen

Der Kern des Themas liegt hier: KPIs müssen den Weg von Incident zu nachhaltigem Fix sichtbar machen. Das gelingt, wenn Sie Follow-ups nicht als „nice to have“ behandeln, sondern als Teil des Betriebsprozesses. Gute KPIs messen nicht die Menge an Tickets, sondern die Wirksamkeit der Fixes.

• Recurrence Rate: Wie oft tritt dieselbe Fehlerklasse/Root-Cause-Familie erneut auf?
• Time to Permanent Fix (TTPF): Zeit vom ersten Auftreten bis zur nachhaltigen Behebung (nicht nur Mitigation).
• Fix Throughput für Top-Issues: Wie viele der Top-N On-Call-Treiber wurden pro Quartal eliminiert?
• Automation Coverage: Anteil der häufigsten Mitigations, die automatisiert oder „one-click“ sind.
• Change Risk Reduction: Anteil der Incidents, die durch Changes ausgelöst wurden, sinkt über Zeit.

Formelbeispiel: Recurrence Rate über Root-Cause-Familien

Damit Teams nicht durch Umbenennung oder Ticket-Splitting „besser aussehen“, aggregieren Sie Wiederholungen über Root-Cause-Familien:

$\mathrm{RecurrenceRate}=\frac{I_{\mathrm{repeat}}}{I_{\mathrm{total}}}$

Hier ist Irepeat die Anzahl Incidents, die einer bestehenden Root-Cause-Familie zugeordnet werden, und Itotal die Gesamtanzahl. Entscheidend ist eine klare Taxonomie für Fehlerklassen.

Die Taxonomie: Ohne saubere Klassifikation werden KPIs wertlos

Systemische KPIs brauchen stabile Kategorien, sonst sind Trends nicht interpretierbar. Eine minimal brauchbare Taxonomie ist klein, aber konsequent. Sie sollte sowohl technische als auch prozessuale Ursachen abdecken.

• Change-induced: Deployment, Konfigurationsänderung, Feature Flag, Infrastrukturänderung.
• Capacity/Saturation: CPU/Memory, Queueing, Connection Pools, Rate Limits, Quotas.
• Dependency/Third Party: Datenbank, Cache, Message Queue, externe APIs, Cloud-Provider-Services.
• Network/Ingress/Hidden Layers: DNS/TLS/Ingress, Routing, egress, Load Balancer.
• Data issues: Schema, Backfills, Hot Keys, Partitioning, Consistency, corrupt data.
• Observability gap: Missing dashboards, fehlende Alerts, unzureichende Traces/Logs.

Wenn Sie Ursachen sauber erfassen, können On-Call-KPIs direkt auf Engineering-Arbeit übersetzen: „Top 3 Root-Cause-Familien eliminieren“ ist ein klares, systemisches Ziel.

KPIs gegen Gaming absichern: Definitionen, Guardrails, Reviews

Wo gemessen wird, wird optimiert. Das ist gut – solange die Optimierung dem System dient. Deshalb brauchen On-Call-KPIs Guardrails: klare Definitionen, unabhängige Checks und regelmäßige Reviews.

• Noise-Reduktion nur mit Coverage-Check: Alert Count darf sinken, aber SLO-Burn und Synthetic Failures dürfen nicht steigen.
• MTTR nicht allein: Immer zusammen mit Recurrence Rate und TTPF betrachten.
• Severity-Definitionen fixieren: Einheitliche Kriterien, damit Umklassifizierung keinen KPI-Vorteil bringt.
• Audit von Silences: Jede dauerhafte Stummschaltung braucht Owner, Begründung und Ablaufdatum.
• Stichprobenreview: Monatlich 5–10 Incidents prüfen: Klassifikation, Root Cause, Follow-ups, Wirksamkeit.

Wie KPIs den Fix-Backlog steuern: Vom Incident zur Roadmap

Damit KPIs systemische Fixes fördern, müssen sie in Planung und Priorisierung wirken. Ein effektives Muster ist ein „Reliability Backlog“, der aus On-Call-Daten gespeist wird. Die KPIs liefern dabei die Priorisierungslogik:

• Top Driver List: Die Top-N Root-Cause-Familien nach Impact-Minuten oder Error-Budget-Burn.
• Fix ROI: Erwartete Reduktion von Pages und SLO-Burn durch einen Fix.
• Automatisierungs-Pipeline: Wiederkehrende Mitigations werden als Automations-Tasks umgesetzt.
• Change Quality Loop: Change-induced Incidents führen zu Guardrails (Canary, bessere Rollbacks, Readiness Reviews).

Für etablierte Zuverlässigkeitspraktiken, insbesondere die Kopplung an Error Budgets, ist die Sammlung an SRE-Ressourcen unter sre.google eine nützliche Orientierung.

Konkretes KPI-Set als Startpunkt für Teams

Viele Teams scheitern, weil sie zu viel auf einmal messen. Ein pragmatisches Start-Set umfasst 8–10 KPIs, die zusammen Signalqualität, Belastung, Impact und Fix-Loop abdecken.

• Error-Budget-Verbrauch pro Service (monatlich): mit Trend.
• SLO-Burn-Rate Peaks (wöchentlich): Anzahl Peaks über definierter Schwelle.
• Actionability Rate (monatlich): Anteil actionable Pages.
• Duplicate-Rate (monatlich): Anteil deduplizierbarer Pages.
• Pages pro On-Call-Schicht (wöchentlich): getrennt nach Kernzeit/After-Hours.
• After-Hours-Paging-Rate (monatlich): als Belastungsindikator.
• MTTDx (monatlich): Zeit bis Diagnosehypothese, nicht bis Fix.
• Recurrence Rate (quartalsweise): Wiederholincidents pro Root-Cause-Familie.
• Time to Permanent Fix (quartalsweise): Median und p90.
• Top-Driver Elimination (quartalsweise): Wie viele der Top-N Ursachen wurden nachhaltig reduziert?

Wie Sie KPIs kommunizieren, ohne Druckkultur zu erzeugen

On-Call-KPIs funktionieren nur in einer Kultur, die Lernen über Schuld stellt. Kommunizieren Sie Kennzahlen daher als Systemdiagnose: „Wo verlieren wir Zeit? Wo ist Signalqualität schlecht? Wo wiederholen sich Ursachen?“ Vermeiden Sie Formulierungen, die Personen verantwortlich machen. Entscheidend ist auch, dass KPIs zu Ressourcen führen: Wenn die Organisation weniger Pages will, muss sie Zeit für Reliability Work freigeben.

• Team-Level Reports: Trends pro Service oder Plattformbereich, keine Personenlisten.
• Fix-Fokus im Review: Jede KPI-Session endet mit 1–3 systemischen Aktionen, nicht mit Diskussion über Reaktionszeit.
• Kapazitätszusagen: Ein fester Anteil Engineering-Zeit für Reliability (z. B. 20%) bei hohem Budget-Burn.
• Transparenz über Trade-offs: Wenn Features priorisiert werden, steigt On-Call-Load – das wird explizit gemacht.

Anti-Patterns: KPIs, die Sie besser vermeiden oder nur als Kontext nutzen

• „Tickets geschlossen pro Person“: Fördert Speed statt Qualität und erzeugt Vergleichsdruck.
• „MTTA als Zielmetrik“: Reaktionszeit ist oft durch Alerting und Schichtmodell bestimmt, nicht durch Kompetenz.
• „0 Alerts“ als Erfolg: Führt zu Blindheit; wichtiger ist Actionability und Coverage.
• „MTTR ohne Recurrence“: Belohnt Workarounds; kombinieren Sie immer mit TTPF und Wiederholrate.
• „Sev1 Count“ isoliert: Ohne Impact-Minuten und SLO-Burn ist die Zahl leicht manipulierbar.

Checkliste: On-Call-KPIs designen, die systemische Fixes fördern

• On-Call an SLOs koppeln: Nutzerimpact und Error-Budget-Burn als Primärsignal.
• Belastung messen, nicht bewerten: Pages/After-Hours als Systemindikator, nicht als Personenmetrik.
• Signalqualität quantifizieren: Actionability, Duplicate-Rate, Runbook Coverage.
• Fix-Loop messen: Recurrence Rate und Time to Permanent Fix als Kern-KPIs.
• Taxonomie klein halten: Fehlerklassen konsequent taggen, Root-Cause-Familien bilden.
• Gaming verhindern: Guardrails gegen Silencing, Severity-Drift und Ticket-Splitting.
• KPIs in Priorisierung übersetzen: Top Driver List → Reliability Backlog → Quartalsziele.
• Regelmäßig reviewen: Monatliche KPI-Runde mit 1–3 verpflichtenden systemischen Actions.
• Tooling vereinheitlichen: Traces/Metriken/Logs konsistent instrumentieren, z. B. mit OpenTelemetry.
• Kultur schützen: KPIs als Lerninstrument, keine individuelle Leistungskennzahl.

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.