Vorfallsmetriken

1) Warum Vorfälle messen

Incident-Metriken verwandeln chaotische Ereignisse in einen überschaubaren Prozess: Sie helfen, Reaktions- und Wiederherstellungszeiten zu reduzieren, die Wiederholbarkeit von Ursachen zu verringern, die Erfüllung von SLOs/Verträgen zu beweisen und Automatisierungspunkte zu finden. Ein guter Satz von Metriken deckt den gesamten Zyklus ab: Erkennung → Klassifizierung → Eskalation → mitigierende Aktionen → Wiederherstellung → Analyse von CAPA- →.

2) Grundlegende Definitionen und Formeln

Ereignisintervalle

MTTD (Mean Time To Detect) = mittlere Zeit von T0 (tatsächlicher Beginn des Einflusses) bis zum ersten Signal/Detektion.
MTTA (Mean Time To Acknowledge) = mittlere Zeit vom ersten Signal bis zum ack on-call.
MTTM (Mean Time To Mitigate) = mittlere Zeit bis zum Absinken des Einflusses unterhalb der SLO-Schwelle (oft = Zeit bis zur Bypass-Lösung/UX-Degradation).
MTTR (Mean Time To Recover) = durchschnittliche Zeit bis zur vollständigen Wiederherstellung der Ziel-SLIs.
MTBF (Mean Time Between Failures) = durchschnittliches Intervall zwischen relevanten Vorfällen.

Betriebszeiten

Time to Declare - von T0 bis zur offiziellen Ankündigung des SEV-Levels/Vorfalls.
Time to Comms - von der Ankündigung bis zum ersten öffentlichen/internen Update auf SLA.
Zeit im Zustand - Dauer in jeder Phase (triage/diag/fix/verify).

Frequenz und Anteil

Incident Count - Anzahl der Vorfälle pro Zeitraum.
Incident Rate - bei 1k/10k/100k erfolgreichen Transaktionen oder Anfragen (Normalisierung).
SEV Mix - Verteilung nach Schweregrad (SEV-0... SEV-3).
SLA Breach Count/Rate - Anzahl/Anteil der Verstöße gegen externe SLAs.
Change Failure Rate -% der Vorfälle, die durch Änderungen (Releases/Configs/Migrationen) verursacht werden.

Signal- und Prozessqualität

% Actionable Pages - Anteil der Pages, die zu sinnvollen Playbook-Aktionen führten.
False Positive Rate (Pages) - Anteil der falsch positiven Ergebnisse.
Detection Coverage - Anteil der Vorfälle, die von der Automatisierung (und nicht von Clients/Support) erkannt werden.
Reopen Rate - Anteil der wiederholten Vorfälle mit der gleichen Wurzelursache ≤90 Tage.
CAPA-Abschluss -% der Korrektur-/Vorbeugungsmaßnahmen, die rechtzeitig abgeschlossen wurden.
Comms SLA Adherence ist der Anteil der Updates, die über die erforderliche Frequenz veröffentlicht werden.

3) Metrikkarte nach Vorfallsstadien

4) Normalisierung und Segmentierung

Normalisieren Sie die Zähler nach Volumen (Datenverkehr, erfolgreiche Operationen, aktive Benutzer).
Segmentieren nach: Region/Tenant, Anbieter (PSP/KYC/CDN), Änderungstyp (Code/config/infra), Tageszeit (Tag/Nacht), Nachweisquelle (synthetisch/RUM/infra/support).
Für Unternehmen sind Business-SLIs wichtig (Erfolg von Zahlungen, Registrierungen, Auffüllungen) - Metriken von Vorfällen sind an ihre Verschlechterung gebunden.

5) Schwellenziele (Benchmarks, an die Domäne anpassen)

MTTD: ≤ 5 min für Tier-0, ≤ 10-15 min für Tier-1.
MTTA: ≤ 5 min (24/7), ≤ 10 min (follow-the-sun).
MTTM: ≤ 15 min (Tier-0), ≤ 30-60 min (Tier-1).
MTTR: ≤ 60 min (Tier-0), ≤ 4 h (Tier-1).
Detection Coverage: ≥ 85% Automatisierung.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPA Completion (rechtzeitig): ≥ 85%.

6) Zuordnung von Ursachen und Auswirkungen von Veränderungen

Weisen Sie jedem Vorfall einen primären Grund (Code/Config/Infra/Provider/Security/Data/Capacity) und einen Auslöser (Release ID, config change, Migration, external factor) zu.
Führen Sie Change-linked MTTR/Count - soweit Releases und Configs dazu beitragen (Basis für Gate/Kanarienpolitik).
Berücksichtigen Sie separat Provider-bedingte Vorfälle (PSP/KYC/CDN/Cloud), um Routen und Verträge zu verwalten.

7) Kommunikation und Kundenimpakt

Time to First Public Update und Update Cadence (z.B. alle 15/30 min).
Complaint Rate - Tickets/Beschwerden für 1 Vorfall, Trend.
Status Accuracy - Anteil der öffentlichen Aktualisierungen ohne Rückzüge.
Post-Incident NPS (für Schlüsselkunden) - ein kurzer Impuls nach dem SEV-1/0.

8) Alerting-Qualitätsmetriken um Vorfälle

Page Storm Index - Anzahl der Pages/Stunde pro On-Call während eines Vorfalls (Median/p95).
Dedup Efficiency - Anteil der unterdrückten Duplikate.
Quorum Confirmation Rate - der Anteil der Vorfälle, bei denen das Quorum der Sonden (≥2 unabhängiger Quellen) ausgelöst wurde.
Shadow→Canary→Prod Umsetzung der neuen Regeln (Alert-as-Code).

9) Dashboards (Mindestsatz)

1. Executive (28 Tage): Anzahl der Vorfälle, SEV-Verteilung, MTTR/MTTM, SLA-Breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.
3. Change Impact: Anteil der Incidents im Zusammenhang mit Releases/Config, MTTR für Change Incidents, Wartungsfenster vs Incidents.
4. Anbieter: Vorfälle nach Anbieter, Degradationszeiten, Routenwechsel, vertragliche SLAs.
5. Heatmap nach Diensten/Regionen: Vorfälle und MTTR bei 1k Transaktionen.

Kombinieren Sie SLI/SLO-Grafiken mit Release-Anmerkungen und SEV-Markierungen.

10) Datenschema des Vorfalls (empfohlen)

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11) Berechnungsbeispiele (SQL-Idee)

sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');

sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12) Verknüpfung mit SLOs und Fehlerbudgets

Fixieren Sie SLO burn minutes auf den Vorfall - das ist das Haupt- „Gewicht“ des Ereignisses.
Priorisieren Sie die CAPA nach Gesamtburn und SEV-Gewicht, nicht nach der Anzahl der Vorfälle.
Vernetzen Sie Burn mit einem finanziellen Impact (Beispiel: $/Minute Ausfallzeit oder $/verlorene Transaktion).

13) Prozessreifemetriken (Programmebene)

Postmortem Lead Time: Median vom Abschluss des Vorfalls bis zur Veröffentlichung des Berichts.
Evidence Completeness: Anteil der Berichte mit Timeline, SLI-Charts, Logs, Links zu PR/Comms.
Alert Hygiene Score: zusammengesetzter Index nach actionable/FP/dedup/quorum.
Handover Defects: Anteil der Schichten, bei denen der Kontext aktiver Vorfälle verloren geht.
Training Coverage:% on-call, die die Simulationen für das Quartal bestanden haben.

14) Checkliste zur Einführung von Metriken

• Einheitliche Zeitstempel (UTC) und Ereignisvertrag des Vorfalls sind definiert.
• SEV-Wörterbuch, Ursachen (root cause taxonomy) und Erkennungsquellen wurden übernommen.
• Metriken werden nach Volumen normiert (Verkehr/erfolgreiche Operationen).
• 3 Dashboards stehen bereit: Executive, Operations, Change Impact.
• Alert-as-Code: Jede Seitenregel hat ein Playbook und einen Besitzer.
• SLA-Post-Mortem (z. B. Entwurf ≤72ch, Finale ≤5 Sklave. Tage).
• CAPAs werden mit Effekt-KPIs und D + 14/D + 30-Daten verfolgt.
• Wöchentliche Incident Review: Trends, Top-Gründe, CAPA-Status.

15) Anti-Muster

Zählen Sie nur MTTR ohne MTTD/MTTA/MTTM → Verlust der Beherrschbarkeit der frühen Phasen.
Nicht normalisieren auf das Volumen → große Dienste „scheinen“ schlimmer.
Unsystematisches SEV → Inkonsistenz von Vorfällen.
Das Fehlen von Evidence → Kontroversen statt Verbesserungen.
Fokus auf Anzahl der Vorfälle statt Burn/SLO-Einfluss.
Ignorieren Reopen und CAPA → ewige Rückfälle.
„Metriken in Excel“ ohne automatisches Hochladen aus Telemetrie/ITSM.

16) Mini-Vorlagen

Karte des Vorfalls (Sokr.)

INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

Executive Report (28 Tage, Schlüsselzeilen)

Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17) Roadmap (4-6 Wochen)

1. Ned. 1: Zeitstempel-/Feldstandard, SEV-Wörterbuch/Ursachen; das grundlegende Schaufenster der Vorfälle.
2. Ned. 2: MTTD/MTTA/MTTM/MTTR-Berechnungen, Normalisierung und SEV-Dashboards.
3. Ned. 3: Verknüpfung mit Releases/Config, Detection Coverage und Alert Hygiene.
4. Ned. 4: Executive Report, Post Mortems SLA, CAPA Tracker.
5. Ned. 5-6: Anbieterberichte, burn→$ Finmodel, Quartalsziele und vierteljährlicher Incident Review.

18) Ergebnis

Incident-Metriken sind nicht nur Zahlen, sondern ein Storyboard der Betriebssicherheit. Wenn Sie den gesamten Fluss messen (von der Erkennung bis zur CAPA), die Leistung normalisieren, sie mit SLOs und Änderungen verknüpfen und regelmäßig Überprüfungen durchführen, reduziert die Organisation vorhersehbar die Reaktionszeit, die Kosten und die Wiederholbarkeit von Vorfällen - und die Benutzer sehen einen stabilen Service.