Zum Inhalt

Incidents & Wartungen

Incidents

Ein Incident ist eine kommunizierte Störung. Er hat einen Titel, einen Impact (none, minor, major, critical), die betroffenen Komponenten mit ihrem Status und eine Timeline öffentlicher Updates.

Lebenszyklus

investigating → identified → monitoring → resolved → reviewed → closed
  • Die ersten vier Status sind live und können über Timeline-Updates gesetzt werden. Übergänge sind in beide Richtungen möglich, zum Beispiel von monitoring zurück zu identified.
  • resolved setzt resolved_at. Ein Incident lässt sich durch ein neues Update wieder öffnen, dabei wird resolved_at zurückgesetzt.
  • reviewed und closed sind eingefroren. Sie nehmen keine Timeline-Updates mehr an. Gesetzt werden sie durch die Review- und Close-Aktion. Die exakten Ausfallzeiten bleiben auch dann korrigierbar.
  • Jeder Incident beginnt mit einem automatischen Timeline-Eintrag mit Status occurred. Er trägt den Zeitpunkt, an dem die Störung tatsächlich begann.

Timeline und interne Notizen

  • Timeline-Updates (incident_updates) sind öffentlich. Jedes Update hat einen eigenen occurred_at, der statt der Erstellungszeit angezeigt wird. Die Timeline ist danach sortiert.
  • Interne Notizen (incident_notes) sind private Team-Notizen. Sie sind append-only, nie öffentlich sichtbar und getrennt von der Timeline und vom Review-Text.
  • Der Review-Text (review_notes) dokumentiert Ursache und Maßnahmen nach der Auflösung.

Verknüpfung mit laufenden Ausfällen

Beim Anlegen eines Incidents können offene, noch nicht verknüpfte Ausfälle gewählt werden. Der Incident wird diesen Ausfallfenstern zugeordnet (component_status_events.source_incident_id). Die bestehenden Fenster bleiben unverändert. Das occurred_at des Incidents ist der früheste Wert aus Formularzeit und frühestem Ausfallbeginn (computeIncidentOccurredAt). Komponenten der gewählten Ausfälle werden automatisch ergänzt.

Impact und Anzeige

Die Incident-Liste im Admin gruppiert: aktive Incidents oben, darunter gelöste und geprüfte. Geschlossene Incidents erscheinen erst nach einem Klick auf Show all incidents (Query-Parameter all=1). Die öffentliche Seite zeigt Incidents und Ausfälle gemeinsam, sortiert nach Schweregrad (lib/domain/severity.ts). Ist show_resolved_minutes größer als 0, bleibt ein gelöster Incident so viele Minuten sichtbar und wird grün als gelöst markiert. Der Standard ist 0.

Erlaubte Startstatus

Beim Anlegen über API und Formular sind nur investigating, identified, monitoring und resolved als Startstatus erlaubt. So kann ein Incident nicht direkt als reviewed oder closed entstehen.

Wartungsfenster

Ein Wartungsfenster hat Titel, Beschreibung, geplanten Beginn und Ende sowie die betroffenen Komponenten. Die Datenbank erzwingt scheduled_end > scheduled_start.

Phase Erreicht durch
scheduled Anlage in der Admin-Oberfläche oder über die API
in_progress Wird nicht gespeichert, sondern beim Lesen aus dem Zeitfenster abgeleitet, sobald der Beginn erreicht ist
completed Manuell über „Mark complete“ oder automatisch zur geplanten Endzeit (Prüfung jede Minute)
  • Während ein Fenster läuft, zeigen die betroffenen Komponenten under_maintenance.
  • Wartung ist kein Ausfall. Sie erhöht nicht den Ausfallzähler der öffentlichen Seite, sondern erscheint im Zähler „Aktive Wartungen“ und im Wartungsbereich.
  • Beim Anlegen wird maintenance_scheduled gesendet.
  • Die Benachrichtigung maintenance_started wird einmalig zum Beginn gesendet (maintenances.notified_started_at macht den Vorgang idempotent). Das automatische Ende ist still. Nur ein manueller Abschluss sendet maintenance_completed.
  • Lief der Worker zum Beginn nicht, wird die Startbenachrichtigung nachgeholt, solange das Fenster noch läuft. Schlägt der Versand fehl oder gibt es keine Empfänger oder kein aktives Template, wird der Merker zurückgesetzt und im nächsten Lauf erneut versucht. Verloren ist die Benachrichtigung nur, wenn das Fenster bereits vorbei ist. Der automatische Abschluss zur geplanten Endzeit wird immer nachgeholt.
  • Wartungen anlegen, bearbeiten und abschließen können in der Admin-Oberfläche Admins und Service Manager (siehe Rollen & Anmeldung). Eine abgeschlossene Wartung lässt sich nicht mehr bearbeiten.