Service-Status & Ausfälle

Die Seite Service Status (Operations → Service Status) erlaubt, den Status jedes Services direkt zu setzen, und führt zur Ausfallhistorie. Admins und Servicemanager sehen alle aktiven Services, Serviceowner nur ihre eigenen. Ist ein Serviceowner für keinen Service verantwortlich, erscheint „You are not responsible for any services yet.“.

Status setzen

1. Öffnen Sie Operations → Service Status.
2. Wählen Sie beim Service einen neuen Status.
3. Optional: Bei einer Störung und offenen Incidents erscheint die Auswahl Attach to open incident. Wählen Sie einen Incident, wird der Status zum Auftrittszeitpunkt des Incidents gebucht. „— don't attach —“ lässt den Status ohne Verknüpfung.
4. Klicken Sie Set. Die Änderung erscheint sofort auf der öffentlichen Seite. Benachrichtigungen werden gemäß Templates und Stummschaltung gesendet.

Status:

Status	Wann verwenden
Operational	Alles funktioniert. Beendet alle laufenden Ausfälle des Services.
Degraded Performance	Funktioniert, aber langsamer oder mit eingeschränkten Funktionen
Partial Outage	Einige Funktionen oder Nutzer sind betroffen
Major Outage	Der Service ist nicht verfügbar
Under Maintenance	Ungeplante Wartung ohne Wartungsfenster

Für geplante Arbeiten nutzen Sie besser ein Wartungsfenster. Es setzt under_maintenance automatisch für den geplanten Zeitraum und benachrichtigt die Abonnenten.

Je Zeile gibt es außerdem den Link Create incident, der das Incident-Formular mit diesem Service öffnet. Das Formular öffnet sich nur für Admins und Servicemanager, Serviceowner landen auf dem Dashboard. Ein farbiges Symbol zeigt das Ergebnis des letzten Uptime-Checks.

Nur Services im Modus Active (Public) oder Active (Internal) erscheinen in der Liste.

Ausfallhistorie

Klicken Sie auf einen Service, um seine Outage history zu sehen. Jeder Eintrag ist ein Ausfallfenster mit Status, Beginn und Ende, bei Bedarf mit Link auf den zugehörigen Incident. Einsehen dürfen alle Rollen. Ändern dürfen Admins, Servicemanager und SLA Manager für alle Services, Serviceowner für ihre eigenen. Ohne Recht erscheint „You can view these outages, but only users with access for this service can edit or delete them.“.

Jede Zeile ist ein Formular mit Beginn, Ende, Status und Save:

• Zeiten korrigieren: Beginn und Ende werden in der Zeitzone der Einstellungen eingegeben. Ein leeres Ende bedeutet, dass der Ausfall noch läuft. Überschneidet sich das Fenster mit einem Nachbarn, wird es angepasst: Der Beginn liegt nie vor dem Ende des vorherigen Ausfalls, das Ende nie nach dem Beginn des nächsten.
• Schweregrad ändern: Status wählen und speichern. Der Status Operational entfernt den Eintrag aus der Historie, zum Beispiel bei einem Fehlalarm.
• Ausfall löschen: Entfernt das Fenster nach einer Rückfrage („Are you sure? Deleting this outage also removes the link to its incident, if any.“). Das Löschen macht einen bereits gesetzten Status des Services nicht rückgängig. Prüfen Sie danach den aktuellen Status.

Warning

Korrekturen wirken sofort auf Uptime- und SLA-Werte. Ein Ausfall, der in einem SLA-Report bestätigt ist, ist gesperrt: Das Formular ist deaktiviert, und es gibt keinen Löschen-Button. Serverseitig lehnen Bearbeiten und Löschen mit „This outage is confirmed in an SLA report and cannot be edited.“ bzw. „… cannot be deleted.“ ab. Läuft gerade ein Report, in dem der Ausfall noch zu bestätigen ist, erscheint in der Zeile der Button Confirm. Siehe SLA-Verwaltung.

Automatischer Status durch Uptime-Checks

Hat ein Service einen Uptime-Check, kann sein Status nach einer Serie fehlgeschlagener Checks automatisch gesetzt werden. Der Checker vermerkt dann, dass er den Status gesetzt hat. Eine manuelle Änderung überschreibt den automatischen Status, und der Checker stellt keinen Status wieder her, den er nicht selbst gesetzt hat. Siehe Uptime-Checks.

Status über die API

Monitoring-Werkzeuge können Ausfälle mit einem Token über die API setzen und beenden. So angelegte Einträge erscheinen in der Historie wie manuelle. Siehe Öffentliche API.