Alerts
Kurzzusammenfassung
- Alerting operationalisiert Monitoring- und Drift-Signale in verbindliche Reaktionsklassen.
- Severity, Routing und Triage-Zeiten sind standardisiert und teamübergreifend abgestimmt.
- Einheitliche Abschlusskriterien verhindern „Alert geschlossen ohne Nachweis“.
- Alerts bilden die operative Brücke zwischen Erkennung, Incident-Handling und Governance.
Ziel
Business-Nutzen: Ein klarer Alert-Standard senkt Mean Time To Detect/Resolve (MTTD/MTTR), reduziert Fehlroutings und stellt belastbare Abschlussnachweise sicher.
Severity-Klassen und Triage-SLAs
| Severity | Typisches Signal | Routing | Triage-Zeit (max.) |
|---|---|---|---|
| SEV-1 Kritisch | Produktionsausfall, massiver Qualitätsverlust, Guardrail-Verstoss | Sofort an On-Call, Incident Commander, ML Lead, Risk On-Call | 15 Minuten |
| SEV-2 Hoch | Persistente KPI-Degradation, kritische Drift-Warnung | On-Call + zuständiger Service-/Model-Owner | 60 Minuten |
| SEV-3 Mittel | Einzelne Grenzwertverletzung ohne akuten Business-Impact | zuständiges Produkt-/Plattform-Team | 4 Stunden |
| SEV-4 Niedrig | Trendhinweis, geringe Abweichung, Kapazitätsfrühwarnung | Backlog-Queue + Team-Channel | 1 Arbeitstag |
Routing-Regeln (verbindlich)
| Alert-Typ | Primary Route | Secondary Route | Eskalation |
|---|---|---|---|
| Datenqualität/Freshness | Data Engineering On-Call | Data Owner | Incident Commander bei SEV-1/2 |
| Modellqualität/Drift | MLOps On-Call | Model Owner + ML Lead | Governance Board bei wiederholtem SEV-2 |
| Plattform/SLO | Platform Ops On-Call | Service Owner | Incident Commander |
| Compliance/Auditierbarkeit | Risk Ops | Compliance Lead | Governance Board |
Ablauf
| Schritt | Mechanik | Ergebnis |
|---|---|---|
| Klassifizieren | Alert-Regel mappt Signal auf Severity + Alert-Typ | Einheitliches Prioritätsniveau |
| Routen | Automatisches Paging und Ticketing nach Routing-Matrix | Zuständigkeit innerhalb SLA geklärt |
| Triagieren | Owner bewertet Impact, Ursache, Scope | Incident-/Mitigation-Plan gestartet |
| Abschliessen | Nachweis gegen Abschlusskriterien prüfen | Auditierbar geschlossener Alert |
Abschlusskriterien (Pflicht)
Ein Alert darf nur geschlossen werden, wenn alle Punkte erfüllt sind:
- Root Cause dokumentiert (oder begründete „unknown cause“ mit Folgeaktion).
- Gegenmassnahme umgesetzt und Verantwortliche benannt.
- Rückkehr in Kontrollband über mindestens ein definiertes Beobachtungsfenster bestätigt.
- Verlinkte Evidenz (Dashboard, Ticket, ggf. Decision Record) vorhanden.
- Post-Incident-Learnings bei SEV-1/2 erfasst und terminiert.
Kontrollen
Governance- und Risiko-Aspekte
- Severity-Zuordnung und Triage-SLAs sind für alle Alert-Typen verbindlich.
- Jede SEV-1/SEV-2-Meldung wird im Incident-Management und Governance-Reporting geführt.
- Wiederkehrende Alerts triggern Trendanalyse und Regel-Nachschärfung.
Operative Checks
| Check | Monitoring | Verantwortlich | Eskalation |
|---|---|---|---|
| SLA-Einhaltung Triage | kontinuierlich, wöchentlicher SLA-Report | Incident Manager | Head of Operations |
| Routing-Korrektheit | monatlicher Sample-Review | Platform Ops + MLOps | Governance Board |
| Abschlusskriterien erfüllt | Pflichtprüfung vor Close | Alert Owner | Risk Ops bei Audit-Lücken |
Entscheidung
- Severity und Routing wurden regelkonform gesetzt.
- Triage erfolgte innerhalb der SLA.
- Abschlusskriterien sind vollständig nachweisbar erfüllt.
BPMN-Kontext
- IDs:
ServiceTask_Monitor, Gateway_Retrain - Input-Bezug: Grenzwertverletzungen aus Monitoring und Drift-Analyse.
- Entscheidungsbezug: Alerts steuern Priorität und Eskalation bis zur Massnahmeentscheidung.
- Output-Bezug: Incident-Tickets, Mitigation-Aktionen und ggf. Retrain-Vorlage.