Incident Management dort, wo Ihre Telemetrie schon liegt

Was ist Incident Management?

Incident Management umfasst das Erkennen, Reagieren, Beheben und Auswerten ungeplanter Unterbrechungen oder Beeinträchtigungen eines Dienstes. In der Praxis gehören mehrere Tätigkeiten dazu: die richtigen Personen alarmieren, die Reaktion koordinieren, Stakeholder informieren, den Dienst wiederherstellen und anschließend verstehen, warum es passiert ist – und wie man eine Wiederholung verhindert.

In vielen Teams sind diese Tätigkeiten auf getrennte Werkzeuge verteilt: Das Monitoring erkennt das Problem, ein Paging-Tool weckt jemanden, ein Chat-Channel hält die Diskussion, eine Statusseite informiert Kunden und ein Wiki speichert das Post-Mortem. Jeder Übergang zwischen diesen Tools kostet Minuten und Kontext. Responder kopieren Links, fügen Graphen in den Chat ein und rekonstruieren die Timeline später aus dem Gedächtnis.

Warum integriertes Incident Management wichtig ist

Die schnellste Incident Response beginnt mit Kontext. Enthält der Incident bereits die betroffenen Services, den Abhängigkeitsgraphen, die letzten Deployments und eine wahrscheinliche Ursache, verbringt das Team die ersten fünfzehn Minuten mit der Behebung statt mit der Suche. Das ist der wichtigste Hebel, um die Mean Time to Resolve zu senken.

Integration verbessert auch die Genauigkeit. Routing auf Basis von Service-Ownership bedeutet, dass das Payments-Team für Payments alarmiert wird – nicht eine zentrale Betriebsrota, die den Anruf weiterleiten muss. Eine automatisch aufgezeichnete Timeline sorgt dafür, dass das Post-Mortem abbildet, was wirklich passiert ist: welche Alerts gefeuert haben, welche Aktionen erfolgten und wann sich der Dienst erholt hat.

Kennzahlen im Incident Management

Incident Management sollte gemessen und nicht nur ausgeführt werden. Sinnvolle Kennzahlen sind:

Kennzahl	Aussage
Mean Time to Detect (MTTD)	Wie schnell Probleme nach ihrem Beginn bemerkt werden.
Mean Time to Acknowledge (MTTA)	Wie schnell die Rufbereitschaft auf einen Alarm reagiert.
Mean Time to Resolve (MTTR)	Wie lange Kunden im Schnitt betroffen sind.
Incidents pro Service	Wo Zuverlässigkeitsarbeit die größte Wirkung hat.
Abschlussquote der Maßnahmen	Ob Post-Mortems tatsächlich zu Veränderungen führen.

Obseria berechnet diese Kennzahlen aus den Incident-Daten und zeigt sie pro Team und Service. Reliability-Reviews beruhen damit auf Zahlen statt auf Eindrücken.

Betrachten Sie diese Werte als Trends über Quartale und nicht als Zielvorgabe für einzelne Incidents. Ein einzelner langer Ausfall kann einen Durchschnitt verzerren. Eine stetige Verbesserung bei der Reaktionszeit oder bei der Abschlussquote der Maßnahmen zeigt dagegen, dass der Prozess selbst besser wird.

So funktioniert Incident Management mit Obseria

Ein Incident in Obseria entsteht aus einem von Obseria Intelligence erkannten Problem, aus einer beliebigen Alert-Regel oder manuell. Er übernimmt alle Belege: betroffene Entitäten aus TopoGraph, zugehörige Anomalien, aktuelle Deployments und – falls eine Untersuchung lief – die Ursache samt Beweiskette. Der Schweregrad bestimmt, wer alarmiert wird und in welchem Takt Updates erwartet werden.

On-Call-Pläne und Eskalationsrichtlinien liegen direkt neben dem Service-Katalog. Jeder Service hat ein verantwortliches Team, jedes Team eine Rotation und einen Eskalationspfad. Alarme gehen per Mobile Push, SMS, Anruf, Chat oder E-Mail raus. Bestätigt niemand innerhalb des konfigurierten Timeouts, wird die nächste Stufe benachrichtigt.

Während des Incidents zeichnet die Timeline alles automatisch auf: Alerts, Statuswechsel, Deployments, Workflow-Läufe und Nachrichten aus dem verknüpften Chat-Channel. Responder starten Obseria-Automation-Workflows wie einen Rollback oder einen Diagnose-Snapshot direkt aus dem Incident. Updates veröffentlichen sie aus derselben Ansicht auf der Statusseite. Nach der Behebung erstellt Obseria aus der Timeline einen Entwurf für ein Blameless Post-Mortem, den das Team überarbeitet, abstimmt und mit nachverfolgten Maßnahmen abschließt.

Best Practices im Incident Management

1. Schweregrade klar definieren. Legen Sie fest, was SEV1 bis SEV4 an Kundenauswirkung bedeuten und was jeweils zu tun ist.
2. Auf Symptome alarmieren, nicht auf Ursachen. Alarmieren Sie bei Nutzerauswirkung und SLO-Burn; Ursachen sind Kontext im Incident.
3. Einen Incident Commander benennen. Eine Person koordiniert, die übrigen konzentrieren sich auf die technische Arbeit.
4. Ownership aktuell halten. Das Routing ist nur so gut wie der Service-Katalog dahinter.
5. Blameless Post-Mortems schreiben. Betrachten Sie Systeme und Entscheidungen statt Personen und setzen Sie Maßnahmen konsequent um.