Incidents & Wartungen

Incidents und Wartungen anlegen und bearbeiten können in der Oberfläche Admins und Servicemanager. SLA Manager und Serviceowner sehen die Seiten nur lesend. Serviceowner können bei abgeschlossenen Incidents ihrer Services die exakten Ausfallzeiten pflegen. Siehe Rollen & Anmeldung.

Incident anlegen

Öffnen Sie Operations → Incidents → New incident.

1. Title: kurz und für Kunden verständlich, zum Beispiel „Checkout-Fehler in der EU-Region“. Mindestens 3 Zeichen.
2. Incident status: Investigating (Standard), Identified, Monitoring oder Resolved.
3. Occurred at (in Zeitzone): Wann das Problem tatsächlich begann. Der Zeitpunkt kann vor dem jetzigen liegen. Das Feld wird in der Zeitzone der Einstellungen erfasst.
4. Responded at (in Zeitzone): Wann das Team reagiert hat. Grundlage der Reaktionszeit in den SLA-Metriken.
5. Impact: No impact, Minor (Standard), Major oder Critical.
6. Set affected components to: ein gemeinsamer Status für alle gewählten Komponenten: Operational, Degraded Performance, Partial Outage (Standard) oder Major Outage.
7. Open outages (optional): Ist bereits ein Ausfall aktiv, wählen Sie ihn aus. Der Incident übernimmt dann dieses Fenster, ohne ein zweites anzulegen. Die Komponenten des Ausfalls werden automatisch ergänzt.
8. Affected components: Wählen Sie einen oder mehrere Services. Pflicht ist mindestens eine Komponente oder ein offener Ausfall („Select at least one affected component or open outage“).
9. First update message: das erste öffentliche Update, 3 bis 2000 Zeichen.

Klicken Sie Create incident. Beim Speichern wird incident_created an die Kanäle gesendet, die für die betroffenen Services aktiviert sind.

Mit einem Incident arbeiten

Die Liste Incidents zeigt die Abschnitte Active und Resolved and reviewed. Geschlossene Incidents erscheinen im Abschnitt Closed erst nach einem Klick auf Show all incidents, Hide closed blendet sie wieder aus. Offene Incidents öffnen Sie mit Manage, geschlossene mit View.

Die Detailseite enthält je nach Status folgende Karten:

Karte	Wann	Wirkung
Post update	immer, bei reviewed und closed nur lesend	Felder Occurred at, Responded at, Resolved at (nur bei Status Resolved), Incident status, Component status (Standard „Keep current status“), Affected services (die Auswahl ersetzt die bisherige) und Message. Update incident veröffentlicht den Timeline-Eintrag. Bei einem gelösten Incident öffnet ein anderer Status als Resolved ihn wieder.
Internal Notes	immer	Private Notizen für das Team, nie öffentlich. Lesen dürfen alle, schreiben nur Admins und Servicemanager. Add Note, höchstens 2000 Zeichen.
Outage times (exact)	bei resolved, reviewed und closed	Je betroffener Komponente Status during outage, Outage start und Outage end. Save outage times ersetzt die ursprünglichen Fenster in der Historie. Dürfen Admins, Servicemanager und Owner aller betroffenen Komponenten.
Review incident	bei resolved	Review notes (root cause, measures), 3 bis 5000 Zeichen, dazu korrigierbare Zeiten Occurred, Responded und Resolved at. Save review → reviewed setzt den Status reviewed und sendet incident_reviewed.
Close incident	bei reviewed	Close incident friert den Incident ein und sendet incident_closed.

Wichtige Regeln:

• Der Wechsel von resolved zurück zu einem offenen Status öffnet den Incident erneut. Der Zeitpunkt der Auflösung wird zurückgesetzt.
• Ein geprüfter oder geschlossener Incident nimmt keine Timeline-Updates mehr an („A reviewed or closed incident cannot receive timeline updates.“). Die exakten Ausfallzeiten bleiben änderbar.
• Jedes Update löst eine Benachrichtigung gemäß den Templates aus, zum Beispiel incident_updated oder incident_resolved.

Wartungsfenster

Öffnen Sie Operations → Maintenance → New maintenance.

1. Title und optional Description (optional) eingeben.
2. Start und End festlegen, beide in der Zeitzone der Einstellungen. Das Ende muss nach dem Beginn liegen („End must be after start“).
3. Unter Affected components die betroffenen Services auswählen.
4. Schedule maintenance klicken. Beim Anlegen wird maintenance_scheduled gesendet.

Die Liste Maintenance zeigt Title, Window, Components und Status. Solange eine Wartung nicht abgeschlossen ist, gibt es die Buttons Edit (Änderungen mit Save changes speichern) und Mark complete. Eine abgeschlossene Wartung lässt sich nicht mehr bearbeiten („Cannot edit a completed maintenance.“).

Das Fenster durchläuft drei Phasen:

Phase	Bedeutung
Scheduled	Geplant, noch nicht begonnen. Auf der öffentlichen Seite als bevorstehend angezeigt.
In progress	Beginnt automatisch zur Startzeit. Betroffene Komponenten zeigen „under maintenance“. Die Benachrichtigung maintenance_started wird einmal gesendet.
Completed	Setzen Sie die Wartung mit Mark complete ab, wenn die Arbeit erledigt ist. Dies sendet maintenance_completed. Ist die Wartung bis zur Endzeit nicht manuell abgeschlossen, setzt der Worker sie automatisch zur geplanten Endzeit auf Completed. Dieser automatische Abschluss sendet keine Benachrichtigung.

Eine Wartung ist kein Ausfall. Sie erhöht nicht den Ausfallzähler der öffentlichen Seite, sondern erscheint bei den aktiven Wartungen und im Wartungsbereich. Ob Ausfälle während einer Wartung in die SLA-Verfügbarkeit eingehen, legt der SLA-Zeitplan mit der Option Ignore Outages during maintenances fest, siehe SLA-Verwaltung.

Info

Läuft der Worker nicht, wenn ein Wartungsfenster beginnt, wird die Startbenachrichtigung nachgeholt, sobald er wieder läuft, solange das Fenster noch nicht vorbei ist. Der automatische Abschluss zur Endzeit wird immer nachgeholt. Achten Sie darauf, dass der Worker läuft, siehe Betrieb, Backup & Restore.

Tipps zur Kommunikation

• Veröffentlichen Sie bei einem großen Incident mindestens alle dreißig Minuten ein Update, auch nur um zu sagen, dass weiter gearbeitet wird.
• Verwenden Sie „monitoring“, sobald eine Lösung eingespielt ist, und „resolved“ erst, wenn der Service nachweislich läuft.
• Halten Sie interne Notizen sachlich. Sie helfen später beim Review.
• Füllen Sie das Review aus, solange die Details frisch sind. Die Review-Notizen erscheinen öffentlich in der Timeline, und erst geprüfte Incidents lassen einen SLA-Report generieren.