Kurz gefasst: Genehmigen Sie keine AIOps-Investition auf Basis einer einzelnen Aussage wie „MTTR um X % reduziert“. Zerlegen Sie jeden Incident in Zeit bis zur Erkennung, Diagnose, Mitigation oder Reparatur und—falls abweichend—bis zur vollständigen Wiederherstellung. Jedes Intervall hat andere Datenquellen, Verantwortliche und Automatisierungshebel. Vergleichen Sie danach vergleichbare Incident-Kohorten anhand von Verteilungen, nicht nur Mittelwerten. Sonst verbessert schnelleres Alerting die Gesamtzahl, während Diagnose und Reparatur nahezu unverändert bleiben.
MTTR beschreibt Wiederherstellung, aber keine Attribution
Die DORA-orientierte Implementierung von Google Cloud führt Time to Restore Service als eine von vier Software-Delivery-Metriken. Das Beispiel startet bei einer SLO-Verletzung und endet mit der Rückkehr in den zulässigen Bereich. Das eignet sich für Customer-Impact-Reporting, zeigt aber nicht, welche Reaktionsphase besser wurde.
Google Clouds MTTR-Leitfaden definiert MTTR als gesamte Lösungszeit geteilt durch gelöste Incidents. Er nennt Erkennung, Diagnose und Reparatur als getrennte Einflussfaktoren und ordnet Monitoring, Untersuchung und Automatisierung unterschiedlichen Engpässen zu. Der Mittelwert entfernt genau diese Struktur.
Das Incident-Metrics-Handbuch von Google SRE zeigt das statistische Problem: Incident-Dauern sind rechtsschief, Fallzahlen oft klein und Varianz hoch. In Simulationen blieb eine reale Verbesserung von 10 % häufig im MTTR unsichtbar; scheinbare Verbesserungen traten auch ohne Änderung auf. Die Empfehlung lautet, die Metrik an die konkrete Frage anzupassen und die betroffene Aktivität im Incident-Lebenszyklus zu messen.
Definieren Sie eine gemeinsame Timeline
Praktische Ereignisse: t0 = erster verifizierter Nutzer- oder Service-Impact; t1 = Erkennung durch System oder Bereitschaft; t2 = ausreichend bestätigte Diagnose zur Auswahl einer Maßnahme; t3 = Mitigation/Reparatur beseitigt den wesentlichen Impact; t4 = vollständige Wiederherstellung einschließlich Replikate, Backlog und Cleanup.
Erkennung = t1−t0. Diagnose = t2−t1. Reparatur/Mitigation = t3−t2. Recovery Tail = t4−t3. Customer-Impact-Dauer = t3−t0, sofern die Mitigation das SLO wiederherstellt; vollständige Recovery = t4−t0. Legen Sie fest, welche Definition Sie MTTR nennen.
Datenfluss: Telemetrie/SLO-Ereignisse → unveränderlicher Incident-Eventstream → normalisierte Lifecycle-Events → Stufendauer-Berechnung → Kohortenspeicher → Perzentil-/Vergleichsanalyse → ROI-Ansicht. Speichern Sie Event-ID, Incident-ID, Service, Schweregrad, Fehlermodus, Change-ID, Event Time, Ingestion Time, Akteur, Automationsversion, Konfidenz und Override-Grund. Grundlage ist passive, zeitgenaue OT-Observability-Evidenz.
Pflichtvisual: Der Summenbalken verdeckt das Ergebnis
Illustratives Beispiel bei gleicher Kohorte und Severity-Verteilung: VOR AIOps, 60 min = ERKENNEN 10 + DIAGNOSE 35 + REPARATUR 15. NACH AIOps, 48 min = ERKENNEN 4 + DIAGNOSE 31 + REPARATUR 13. Die Überschrift lautet „20 % weniger MTTR“. Die Zerlegung zeigt: Erkennung −60 %, Diagnose rund −11 %, Reparatur rund −13 %; Diagnose belegt weiterhin 31 von 48 Minuten. Dies ist ein Rechenbeispiel, kein Benchmark.
| VORHER | Erkennen █████ 10 | Diagnose █████████████████ 35 | Reparatur ███████ 15 | 60 min |
|---|---|---|---|---|
| NACHHER | Erkennen ██ 4 | Diagnose ███████████████ 31 | Reparatur ██████ 13 | 48 min |
Beschaffung: Bezahlen Sie für den Detection-Effekt nur dann, wenn Detection der Geschäftsengpass war. Versprach der Business Case Root-Cause-Analyse oder Remediation, belegt das Beispiel diesen Nutzen nicht.
Entscheidungstabelle: Stufe, Hebel, Nachweis
Erkennen. Zeit: erster Impact → erste handlungsfähige Erkennung. Hebel: SLO-Alerting, Anomalieerkennung, Deduplizierung, Routing. Nachweis: niedrigeres p50/p90 bei kontrollierten Fehlalarmen und übersehenen Incidents. Fehler: Die Anbieteruhr startet erst mit dem eigenen Alert.
Diagnose. Zeit: akzeptierte Erkennung → dokumentierte Arbeitshypothese, die eine Maßnahme auswählt. Hebel: Korrelation, Topologiekontext, kausale Traversierung, Log-/Trace-Anreicherung. Nachweis: p50/p90, Genauigkeit der ersten Hypothese, Revisionsrate. Fehler: Ein KI-Vorschlag gilt bereits als Ursache. Architekturvergleich: kausale KI statt reiner Korrelation im AIOps.
Reparatur/Mitigation. Zeit: akzeptierte Diagnose → SLO wiederhergestellt. Hebel: Runbook, Rollback, Traffic Shift, Isolation, freigegebene Operator-Aktion. Nachweis: Ausführungsdauer, Erfolgs-, Rollback- und Wiederholungsrate. Fehler: schnelle falsche Aktion erzeugt Folgeincident. Kontrollmuster: freigabegesteuerte Incident-Automation.
Recovery Tail. Zeit: Mitigation → vollständiger Service und abgearbeiteter Backlog. Hebel: Kapazitätswiederherstellung, Datenabgleich, Cleanup. Nachweis: Tail-Dauer und verbleibender Impact. Fehler: MTTR endet bei Teilmitigation.
Lifecycle instrumentieren, ohne Scheingenauigkeit
Leiten Sie t0 möglichst aus SLI/SLO oder unabhängig bestätigtem Impact ab. Erfassen Sie Systemerkennung und menschliche Bestätigung getrennt. Markieren Sie Diagnose erst, wenn Komponente oder Mechanismus, Evidenz und gewählte Aktion dokumentiert sind. Protokollieren Sie Runbook-Start, Nebenwirkungen, Freigabe, Ergebnis und Rollback automatisch.
Bewahren Sie Roh-Timeline und Korrekturen auf. Überschreiben Sie die erste Hypothese nicht, sondern versionieren Sie Revisionen. Trennen Sie maschinellen Vorschlag und menschliche Akzeptanz. Bei unsicherer Grenze kennzeichnen oder exkludieren Sie den Fall aus kausalen ROI-Behauptungen.
Verbinden Sie Exposition auf Incident-Ebene: AIOps-Version, aktive Funktionen, Topologieabdeckung, Runbook-Verfügbarkeit und tatsächliche Nutzung der Empfehlung. „Nach Einführung“ ist nicht gleich „behandelt“. Ohne Expositionsdaten bleibt nur ein Kalendervergleich, beeinflusst durch Personal, Architektur und Incident-Mix.
Evaluationsdesign für den Business Case
1. Definitionen und Uhren vor dem Pilot einfrieren. 2. Nach Service, Severity und Fehlermodus stratifizieren. 3. Fallzahl, p50, p75 und p90 je Stufe berichten. 4. Gematchte oder randomisierte Behandlung nutzen, soweit betrieblich möglich. 5. Historische Incidents für deterministische Detection-/Diagnosetests replayen; Live-Workflow separat prüfen. 6. Customer Impact, Fehlalarme, unsichere Aktionen und Wiederholung als Guardrails führen.
Bootstrap-Konfidenzintervalle oder vorab definierte nichtparametrische Tests quantifizieren Unsicherheit, reparieren aber keine unvergleichbaren Kohorten. Ein seltener Langläufer kann den Mittelwert dominieren. Entfernen Sie ihn nicht zur Ergebnisverbesserung; zeigen Sie Perzentile und Sensitivitätsanalyse mit und ohne deklarierte Extremfälle.
Monetarisieren Sie erst danach: vermiedene Impact-Minuten × abgestimmter Kostenkorridor; gesparte Responder-Zeit × Vollkosten; belastbar vermiedene SLA-/Betriebsverluste. Ziehen Sie Lizenz, Integration, Telemetriespeicher, Modellaufrufe, Runbook-Pflege, Fehlalarmbearbeitung und Governance ab. Detection-Zeit nicht doppelt als Downtime und Arbeitszeit anrechnen.
Fehlermodi, die den ROI-Nachweis entwerten
Clock Substitution; leichterer Incident-Mix nach Einführung; Ausschluss ungelöster Incidents; Teilmitigation als Recovery; erzwungene lineare Phasen trotz Parallelität; als behandelt gezählte Incidents bei deaktiviertem Tool; schnellere Automatisierung bei höherer Rollback-/Wiederholungsrate; Pilot nur auf Services mit guter Topologie; Mean-only-Reporting; nicht berücksichtigte neue Rufbereitschaft oder Runbooks; frühes Ticket-Schließen durch Zielvorgaben. Jeder Fehler braucht vor dem Review eine Audit-Abfrage und einen Owner.
Trade-offs und Grenzen
Auch die Zerlegung ist nicht perfekt kausal. Phasen überlappen, Mitigation beginnt oft ohne Root Cause, verteilte Fehler haben mehrere Ursachen und „Diagnose akzeptiert“ enthält menschliches Urteil. Instrumentierung erzeugt Aufwand, wenn Events nicht automatisch aus Monitoring, ChatOps, Runbooks und Deployment-Systemen kommen.
Kleine Stichproben bleiben volatil. Lokale Optimierung ist möglich: empfindliches Alerting verkürzt Detection, erhöht aber Fehlalarme; schnelle Diagnose kann überkonfident sein; Auto-Repair erhöht Change-Risiko. Koppeln Sie jede Geschwindigkeitsmetrik mit Qualitäts- und Safety-Guardrails. Nutzerbezogene SLIs/SLOs beschreiben Zuverlässigkeit besser als Reaktionsgeschwindigkeit allein.
Implementierungscheckliste
— t0–t4 und Mitigation versus Recovery festlegen. — Event Time und Ingestion Time halten. — Ungelöste und zensierte Incidents erhalten. — Nach Service, Severity und Fehlermodus stratifizieren. — Tool-Exposition, Version, Topologieabdeckung und Nutzung erfassen. — p50/p90, Fallzahl und Konfidenzintervalle je Stufe zeigen. — Fehlalarm-, Diagnosegenauigkeits-, Unsafe-Action-, Rollback- und Recurrence-Guardrails ergänzen. — Stufensumme gegen Customer Impact abgleichen. — Grenzänderungen auditieren. — Anbieterprozente aus exportierbaren Einzelfalldaten reproduzieren.
Praktischer Einstieg
Rekonstruieren Sie für die letzten 20–30 relevanten Incidents t0–t4 aus unveränderlicher Evidenz. Das erste Ergebnis ist ein Coverage-Bericht: Welche Zeitpunkte existieren, welche sind belastbar und wo bleiben Diagnose oder Reparatur subjektiv? Erst danach definieren Sie Baseline und Pilotziel. Ich unterstütze Plattform- und Betriebsteams dabei, daraus eine auditierbare AIOps-Evaluierung und einen belastbaren Business Case zu bauen.
Primäre und autoritative Quellen
Google Cloud: DORA-orientierte DevOps-Messung — Time to Restore Service und SLO-Ereignisse.
Google SRE: Incident Metrics in SRE — Verteilungen, Monte-Carlo-Nachweis und Grenzen von MTTx.
Google Cloud: How to Reduce MTTR — Formel sowie getrennte Detection-, Diagnose- und Reparaturhebel.
