SLA & Verfügbarkeit

Verfügbarkeitskennzahlen

Die Service-Detailseite und die Verfügbarkeitstabelle zeigen mehrere Kennzahlen. Jede Spaltenüberschrift hat einen Info-Button, der die Definition in einem Popover zeigt, auf der öffentlichen Seite in der eingestellten Sprache (AVAILABILITY_METRIC_GLOSSARY in lib/domain/availability.ts).

Kennzahl	Definition
Overall Availability	Anteil der Zeit, in der der Service voll funktionsfähig war. Jede Störung zählt, auch geplante Wartung.
Excl. Maintenance	Wie oben, aber Wartungsfenster sind aus der Berechnung ausgenommen
Service Availability	Anteil der Zeit ohne Major- oder Partial-Outage (majorPartial). Dieser Wert steht auf der Service-Detailseite unter dem 90-Tage-Balken.
SLA Availability	Wie Service Availability, aber nur Ausfälle innerhalb des zugeordneten SLA-Zeitplans zählen. Wartung wird nicht abgezogen, außer der Plan hat die Option „Ignore Outages during maintenances“. Ohne Plan entspricht der Wert der Service Availability.
SLA Target	Das für den Zeitraum (Monat, Quartal oder Jahr) hinterlegte Ziel. Der Vergleich (✓ / ✗) nutzt die SLA Availability. Ohne Ziel oder ohne SLA-Zeit im Zeitraum steht „—“.

Die Tabelle zeigt acht Zeiträume: diese Woche, dieser Monat, letzter Monat, dieses Quartal, letztes Quartal, die letzten 90 Tage, seit Jahresbeginn und ein Jahr (die letzten 365 Tage).

SLA-Pläne und Zeitpläne

Ein SLA-Plan (sla_plans) legt fest, wann der Service verfügbar sein muss. Er enthält je Wochentag ein Zeitfenster (sla_plan_entries) mit Start und Ende in Minuten. from == to bedeutet an diesem Tag geschlossen. Mindestens ein Wochentag muss offen sein.

• Jede Komponente ist höchstens einem Plan zugeordnet (components.sla_plan_id).
• Kein Plan = 7×24. Jede Stunde jedes Tages zählt.
• Ein Ausfall zählt für die SLA Availability nur, wenn er sich mit dem Zeitplan überschneidet. Ein nächtlicher Ausfall reduziert zum Beispiel nicht die SLA Availability eines Plans, der nur von 08:00 bis 18:00 gilt.
• Mit der Option Ignore Outages during maintenances (sla_plans.ignore_outages_during_maintenance, Standard: aus) zählen Ausfälle innerhalb von Wartungsfenstern nicht für die SLA Availability. Das gilt für Tabelle und Balken. Die Service-Detailseite weist darauf hin.

Zeitzonen richten sich nach settings.timezone. Finale Report-Exporte nutzen die Zeitzone, die im Snapshot gespeichert ist (siehe unten).

Feiertage

Eine Feiertagsliste (holiday_lists) enthält Datumsangaben mit Monat und Tag. Ein Datum ohne Jahr wiederholt sich jährlich (Eingabeformat D.M., zum Beispiel 1.1.). Ein Datum mit Jahr gilt nur einmal (Eingabeformat D.M.YYYY). Doppelte Daten in einer Liste sind per Unique-Constraint ausgeschlossen.

Ein Plan kann eine Feiertagsliste referenzieren. An einem Feiertag gilt dann das Feiertagsfenster statt des Wochentagsfensters. Ist das Feiertagsfenster geschlossen (Standard, 0/0), gibt es an diesem Tag keine SLA-Zeit. Nur exakt 0/0 gilt als geschlossen. Ein anderes Fenster mit Start ≥ Ende wird mit „Holiday window: from must be before to.“ abgelehnt. Ohne Liste zählt jeder Tag als sein Wochentag. Dieselben Regeln gelten für die Service-Detailseite, die Balken, die SLA-Reports und die Incident-Metriken.

Eine Liste, die ein Plan verwendet, kann nicht gelöscht werden.

SLA-Relevanz

Jede Komponente hat das Attribut SLA relevant (components.sla_relevant, Standard: ja). Als nicht relevant markierte Services werden aus SLA-Reports ausgeschlossen. Sie bleiben in der SLA-Verwaltung sichtbar und können weiterhin Plänen und Zielen zugeordnet werden. Wird ein Service auf „nicht relevant“ gesetzt, werden seine offenen Bestätigungszeilen in laufenden Reports entfernt. Bereits eingefrorene Snapshots bleiben unverändert. Wird er wieder relevant, gilt das für Bestätigungen erst ab dem nächsten Report-Start.

Ziele und Balken

Jede Komponente kann optionale Ziele für Monat, Quartal und Jahr (in Prozent) haben. Die öffentlichen Balken nutzen sie:

• Monatsbalken auf der Service-Detailseite: ein Tick je Kalendermonat, beginnend im Januar des Vorjahres. Grün bei 100 %, rot unterhalb des Monatsziels, dazwischen ein linearer Übergang.
• Quartalsbalken: vom 1. Quartal des Vorjahres bis zum laufenden Quartal, gefärbt gegen das Quartalsziel. Das laufende Quartal ist an Monaten ausgerichtet und 1 bis 3 Monate breit.
• 90-Tage-Balken: Die Prozent-Beschriftung wird gegen das Quartalsziel gefärbt, wenn eines gesetzt ist. Ohne Ziel bleibt sie neutral.

Ohne Ziel färben Monats- und Quartalsbalken trotzdem, mit 0 % als Untergrenze: rot bei 0 %, grün bei 100 %. Ohne zugeordneten Plan wird mit 7×24 gerechnet. Grau bleibt ein Abschnitt nur, wenn der zugeordnete Plan in diesem Zeitraum keine SLA-Zeit hat.

Incident-SLA-Metriken

Zusätzlich zur Verfügbarkeit misst SLAtus je Service, wie schnell auf Incidents reagiert und wie schnell sie gelöst werden. Konfiguriert wird das je Komponente in der SLA-Verwaltung:

• Incident SLA level (incident_sla_level): welche Impacts zählen, zum Beispiel nur critical oder critical + major.
• Maximale Reaktionszeit und maximale Lösungszeit in Stunden.
• Erlaubte Verfehlungen je Monat, Quartal und Jahr, getrennt für Reaktion und Lösung.

Die Zeiten werden ab dem nächsten Beginn der SLA-Zeit gemessen (nextScheduleStart), ein Incident außerhalb des Zeitplans startet die Uhr also erst mit dem nächsten Fenster. Die Ergebnisse stehen in den SLA-Reports (computeIncidentSlaMetrics).

SLA-Reports

Reports (sla_reports, Seite /admin/sla-reports) gibt es für Monate, Quartale und Jahre.

open → in_progress → confirmed → completed

• Monatsreports brauchen eine Bestätigung. Beim Start erscheint jedes Fenster mit degraded_performance, partial_outage oder major_outage eines SLA-relevanten Services, das im Monat beginnt oder endet, als Zeile in sla_report_outages. Jede Zeile muss von einem Nutzer mit passender Berechtigung bestätigt werden. Sind alle Zeilen bestätigt, wird der Report auf confirmed gesetzt. Zu diesem Zeitpunkt werden alle Reportdaten in confirmed_snapshot eingefroren.
• Beim Start wird sla_report_started an die Service Manager und an die Owner der Services mit zu bestätigenden Ausfällen gesendet.
• Über Generate wird ein bestätigter Report zu completed. Das geht erst, wenn alle Incidents des Zeitraums geprüft (reviewed oder closed) sind.
• Quartals- und Jahresreports haben keinen Bestätigungsschritt. Ein Quartalsreport ist erst möglich, wenn alle drei Monatsreports completed sind, ein Jahresreport erst, wenn alle vier Quartalsreports completed sind.

Info

Eine Änderung an Plan, Ziel oder Feiertagsliste nach der Bestätigung ändert die Zahlen eines bestätigten oder abgeschlossenen Reports nicht. Das ist gewollt, damit veröffentlichte SLA-Werte stabil bleiben.

Export (PDF und Excel)

PDF und Excel werden bei jedem Abruf neu erzeugt. Auf der Platte wird nichts gespeichert. Die Exportsprache folgt settings.language, Dezimaltrennzeichen, Nachkommastellen und Datumsformat werden beim Rendern angewendet.

Report-Status	Quelle	Kennzeichnung
completed, confirmed mit Snapshot	eingefrorener Snapshot (confirmed_snapshot, sonst report_data)	final
open, in_progress, confirmed ohne Snapshot	live berechnet	Entwurf, Wasserzeichen „ENTWURF“ bzw. „DRAFT“
Ad-hoc-Export	live berechnet, nicht gespeichert	vorläufig, Wasserzeichen „VORLÄUFIG“ bzw. „PRELIMINARY“

• PDF (lib/pdf/sla-report.ts): Titelseite, Inhaltsverzeichnis, Übersicht, Service-Details und ein Anhang mit Glossar und Berechnungsgrundlagen. Lange Inhalte brechen auf Folgeseiten um. Gekürzt wird nur sichtbar mit „...“: Tabellenzellen über 40 Zeilen sowie Einträge im Inhaltsverzeichnis und Kopf- und Fußzeilen auf ihre Breite. Zeichen außerhalb des WinAnsi-Zeichensatzes werden als „?“ ausgegeben.
• Excel (lib/export/sla-report-xlsx.ts): Blätter Deckblatt, Übersicht, Ausfälle, Incidents, Wartungen und Glossar. Zellen über 32 000 Zeichen werden mit „...“ gekürzt.
• Je Service: /admin/sla-reports/[id]/pdf und /admin/sla-reports/[id]/xlsx nehmen optional ?service=<id> und schneiden den Report auf einen Service zu.
• Ad hoc: /admin/sla-reports/adhoc exportiert einen SLA-relevanten Service für einen Monat, ein Quartal oder ein Jahr, ohne einen Report anzulegen. Ein laufender Zeitraum wird bis jetzt gemessen, ein noch nicht begonnener wird abgelehnt.
• Zeitzone: Finale Exporte rechnen in der Zeitzone, die beim Einfrieren im Snapshot gespeichert wurde (GeneratedReport.timeZone). Ältere Snapshots ohne dieses Feld nutzen die aktuelle settings.timezone.
• Fehler: Eine Report-ID, die keine UUID ist oder nicht existiert, ergibt 404. Abgelehnte Ad-hoc-Anfragen zeigen eine einfache Fehlerseite mit Link zurück zur Report-Liste.
• Zugriff haben alle Rollen mit ROLES_CAN_VIEW_SLA_REPORTS: Admin, Service Manager, SLA Manager und Service Owner.

Woher die Zahlen kommen

Die Berechnung liegt in reinen Funktionen: measureSlaWindow und windowForDay in lib/domain/sla.ts, nextScheduleStart für Incident-Metriken und buildSlaReportDataForPeriod für Reports. Ihre Eingaben sind die Statusfenster aus dem Statusmodell und die Konfiguration der Zeitpläne. Gespeicherte Snapshots liest überall parseGeneratedReportJson (lib/domain/sla-report.ts), das fehlende Felder älterer Snapshots mit neutralen Werten auffüllt.