Service Level Objectives: messbare Qualitätsziele für Ihren Dienst

Bei der Übernahme eines Projekts in die laufende Betreuung definiert das Team von Webdelo zunächst Service Level Objectives (SLOs) — messbare Qualitätsziele, zu deren Einhaltung wir uns verpflichten. Konkrete SLO-Werte werden stets projektindividuell nach einem Audit festgelegt und im Statement of Work (SOW) dokumentiert. Das Standardpaket umfasst mehrschichtiges Monitoring, ein Alerting-System, ein S1–S4-Incident-Response-Modell, ein Error Budget sowie regelmäßige Berichte. Wir geben keine pauschalen Verfügbarkeitszusagen wie „99,99 % für alle“. Stattdessen vereinbaren wir realistische, nachvollziehbare Zielwerte und übernehmen Verantwortung für deren Einhaltung.

Zielwerte nach dem Audit, im SOW

SLI: Verfügbarkeit · Latenz · Fehler

S1–S4-Incident-Modell

Monatliches Service Review

Grafana · Prometheus · VictoriaMetrics

Error-Budget-Policy

Auf einen Blick

Das Wichtigste in Kürze

SLOs sind operative Zielvorgaben, keine vertraglichen Zusagen. Konkrete Werte werden stets nach einem Audit bestimmt und im SOW festgeschrieben. Pauschale Uptime-Werte veröffentlichen wir nicht: Zielwerte sind immer an das Projekt, seine Architektur, den Service-Tier und das Betreuungsbudget gebunden.

SLI-Kategorien im Standardpaket

S1–S4

Severity-Modell für Incidents

15 Min.

Bestätigungszeit bei S1 (Richtwert)

monatlich

Standardrhythmus für Service Reviews

Ansatz

Zielwerte erst nach dem Audit

Ohne Audit werden keine SLOs festgelegt. Realistische Zielwerte entstehen erst nach der Analyse von Architektur, Last und Service-Tiers.

Wo es festgeschrieben wird

SOW

Konkrete SLO-Werte, Error Budgets, Reaktionszeiten und Berichtsrhythmus sind Anlage zum Vertrag.

Stack

Grafana · Prometheus · VictoriaMetrics

Primärer Stack. Alternativen (Datadog, New Relic u. a.) nach Abstimmung mit dem Auftraggeber.

SLI vs SLO vs SLA

Drei verschiedene Dinge

SLI ist die Metrik. SLO ist der Zielwert für diese Metrik. SLA ist der Vertrag. SLOs stehen im SOW; das SLA ist ein separates Dokument.

Error Budget

Es steuert die Prioritäten

Ist das Budget erschöpft, wird die Featureentwicklung gestoppt und das Team konzentriert sich auf Stabilität.

Was wir nicht zusagen

Null Incidents · 24/7 als Standard

Wir minimieren die Auswirkungen von Incidents; Rund-um-die-Uhr-Abdeckung hängt vom Paket und Service-Tier ab.

Gemeinsame Sprache

Begriffsbestimmungen: SLI · SLO · SLA · SOW · Error Budget

Das Grundvokabular, das wir in Gesprächen und Dokumenten verwenden. SLI ist das, was gemessen wird. SLO ist der Zielwert dieser Metrik. SLA ist das rechtliche Dokument. SOW ist das Pflichtenheft, in dem die konkreten Werte festgeschrieben werden.

Begriff

Definition

SLI Service Level Indicator

Eine konkrete, messbare Qualitätsmetrik des Dienstes: Verfügbarkeit, Latenz, Fehlerrate.

SLO Service Level Objective

Ein Zielwert oder -bereich für einen SLI, den Webdelo vertraglich zu halten verspricht.

SLA Service Level Agreement

Die vertragliche Vereinbarung zwischen Webdelo und dem Auftraggeber, die SLOs und Konsequenzen bei Nichteinhaltung regelt.

SOW Statement of Work

Das Pflichtenheft, in dem konkrete SLO-Werte nach dem Projektaudit festgeschrieben werden.

Error Budget

Das zulässige Maß an Dienstgradminderung innerhalb eines Abrechnungszeitraums ist begrenzt. Ist das Budget erschöpft, hat Stabilitätsarbeit Vorrang vor der Featureentwicklung.

Verantwortungsgrenzen

Geltungsbereich: was abgedeckt ist und was nicht

SLOs gelten für die Systeme und Ebenen, die wir beobachten und kontrollieren. Externe Dienste, geplante Wartungsfenster und Ereignisse höherer Gewalt liegen standardmäßig außerhalb unserer Zielwerte.

Im Leistungsumfang

Webanwendungen und APIs mit definierten Service-Tiers

Microservice-Architekturen und verteilte Systeme

Hochlast-Analyseplattformen und Datenverarbeitungspipelines

Finanz- und Trading-Systeme, interne Fintech- und Banking-Werkzeuge

Marketing-Automatisierungs- und ERP-Module

Infrastrukturebene: Server, Container, Datenbanken, Netzwerkdienste

Nicht im Leistungsumfang

Drittanbieter-Dienste und APIs, die weder vom Auftraggeber noch von Webdelo kontrolliert werden (Zahlungsdienstleister, externe Provider)

Vorab vereinbarte Wartungsfenster

Degradierungen, die durch Änderungen seitens des Auftraggebers außerhalb des vereinbarten Change-Management-Prozesses verursacht werden

Ereignisse höherer Gewalt, die außerhalb eines vertretbaren technischen Einflussbereichs liegen

Einflussfaktoren

Einflussfaktoren auf SLO-Parameter

Webdelo hat über die Jahre einen Ansatz entwickelt, bei dem Zielwerte durch drei Faktoren bestimmt werden. Ihre Kombination legt fest, wie tief das Monitoring reicht, wie streng die Schwellenwerte sind und wer wie reagiert.

01 Architektur

Architekturkomplexität

Ein monolithisches System mit einer Datenbank und ein verteiltes System mit zwanzig Microservices erfordern grundlegend unterschiedliche Monitoring-Ansätze. Je komplexer die Architektur, desto mehr Beobachtungspunkte werden benötigt und desto breiter muss das Bereitschaftsteam aufgestellt sein.

02 Tier

Service-Tier

Nicht alle Systemkomponenten haben die gleiche geschäftliche Bedeutung. Wir klassifizieren Dienste nach Tiers — Einflussebenen auf die Verfügbarkeit des Kernprodukts des Auftraggebers. Ein Zahlungsgateway und ein interner Berichtsgenerator erfordern fundamental unterschiedliche Reaktionsanforderungen. Der Tier bestimmt die Monitoring-Priorität, die Reaktionszeiten und die Zusammensetzung des Bereitschaftsteams.

03 Budget

Betreuungsbudget

Das Budget legt fest, wie viele Spezialisten bereitgestellt werden, in welchem Betriebsmodus sie arbeiten (Geschäftszeiten, erweiterter Betrieb oder 24/7-Abdeckung) und wie tief das Monitoring von Geschäftskennzahlen geht.

Einstiegspunkte

Zeitpunkt der SLO-Festlegung

SLOs werden in einer von zwei Phasen definiert. Das Idealszenario: Monitoring ist von Beginn an in die Architektur integriert. Bei bestehenden Projekten wird die Observability nach einem Audit schrittweise aufgebaut.

Szenario A · Greenfield

Bei der Entwicklung eines neuen Dienstes

Monitoring und Metriken werden von Beginn an in die Architektur integriert. Zum Zeitpunkt des Produktivstarts ist die vollständige Observability-Abdeckung bereits vorhanden — das ist das Idealszenario.

Szenario B · Brownfield

Beim Onboarding eines bestehenden Projekts

Webdelo führt ein Infrastructure-Audit durch, bestimmt Service-Tiers, identifiziert Monitoring-Lücken und baut das Beobachtungssystem schrittweise auf. Konkrete Zielwerte werden im SOW nach Abschluss des Audits festgeschrieben.

In beiden Fällen werden für die Schlüsselindikatoren Error Budgets definiert, die als Steuerungsinstrument bei der Priorisierungsentscheidung zwischen Featureentwicklung und Stabilitätsarbeit dienen.

Dienstmetriken

SLIs: Was wir messen

Sieben Messkategorien, die das Standardpaket abdeckt. Die Schwellenwerte werden projektindividuell festgelegt, Kategorien und Vorgehen bleiben gleich.

SLI-Kategorie

Was gemessen wird

Beispiel-Metriken

Verfügbarkeit

Dienstbereitschaft in Echtzeit

Healthcheck-Status, Uptime je Dienst

Fehler

Fehlerhäufigkeit und -entwicklung je Dienst

HTTP-5xx-Rate, Fehleraufschlüsselung nach Typ und Kritikalität

Latenz

Antwortzeiten auf Anfragen

p50, p95, p99 Latenz an Schlüssel-Endpunkten

Ressourcen

Auslastung der Serverinfrastruktur

CPU, RAM, Disk-I/O, Netzwerkdurchsatz

Datenbanken

Zustand und Performance der Datenbanken

Query-Latenz, Slow-Query-Log, CPU-/RAM-Auslastung

Netzwerk-Endpunkte

Erreichbarkeit externer und interner Abhängigkeiten

Verfügbarkeit von Drittanbieter-APIs und internen Microservices

Geschäftskennzahlen

Ausführungszeit von Geschäftsprozessen und deren Ketten

Bestellstatusübergangszeiten, produktspezifische SLA-Metriken

Praxisbeispiel: Monitoring von Geschäftskennzahlen

In einem Projekt richtete Webdelo ein Monitoring für die Statusübergangszeiten von Bestellungen ein. Die Metriken zeigten, dass ein Teil der Bestellungen an bestimmten Bearbeitungsschritten dauerhaft hängen blieb. Die Ursachenanalyse deckte ein kombiniertes Problem auf: fehlerhafte Bestätigungsprozesse im Kundendienst + erhöhte Latenzen bei externen Lieferdiensten = Akkumulation blockierter Bestellungen = Datenbanküberlastung = systemweite Degradierung. Jede Komponente schien für sich funktionsfähig; der Kaskadenausfall war ausschließlich über Geschäftskennzahlen sichtbar.

Leistungsumfang

Standardkomponenten des SLO-Pakets

Jedes Betreuungsmandat von Webdelo umfasst fünf Pflichtkomponenten. Konkrete Werkzeuge und Schwellenwerte sind konfigurierbar.

Monitoring-Infrastruktur. Primärer Stack: Grafana + Prometheus (oder mit dem Auftraggeber abgestimmte Äquivalente). Die Abdeckung umfasst alle sieben SLI-Kategorien: Verfügbarkeit, Fehler, Latenz, Ressourcen, Datenbanken, Netzwerkabhängigkeiten und Geschäftsprozesse.

Alerting-System. Das Alerting basiert auf VictoriaMetrics (oder einem Äquivalent). Jeder Alert ist an einen definierten Metrikschwellenwert und einen Kritikalitätslevel gebunden. Benachrichtigungen werden über den vereinbarten Kanal zugestellt (Slack, Telegram oder ein anderes System). Bereitschaftsingenieure erhalten ausschließlich handlungsrelevante Signale — niedrigpriorisierte Ereignisse werden herausgefiltert.

Runbooks und Eskalationspfade. Für jeden Dienst erstellen wir eine Verantwortlichkeitskarte: wer bei welchem Incident benachrichtigt wird, die Eskalationsreihenfolge sowie initiale Maßnahmen vor der Einbindung eines Fachspezialisten. Dies eliminiert die im Krisenfall kostspielige Frage: „Wer ist eigentlich zuständig?“

Incident-Management-Team. Das Incident-Team arbeitet auf drei Ebenen: Incident-Management — Spezialisten mit vollständigem Architekturwissen, die Incidents eröffnen, Tickets im Projektverwaltungssystem anlegen (Jira, ClickUp oder ein vom Auftraggeber präferiertes System) und die Verantwortung zuweisen; Bereitschafts-DevOps/SysOps — Infrastrukturingenieure für die Diagnose von Problemen auf Server-, Container-, Netzwerk- und Orchestrierungsebene; Bereitschaftsentwickler — dienstspezifische Fachleute, die hinzugezogen werden, wenn ein Problem auf der Ebene des Anwendungscodes oder der Geschäftslogik lokalisiert ist.

Kanal für gemeldete Störungen. Wir etablieren einen Kanal für Mitarbeitende des Auftraggebers, über den beobachtete Anomalien gemeldet werden können. Endnutzer bemerken Probleme häufig vor dem Auslösen automatisierter Alerts. Alle Meldungen werden konsolidiert, priorisiert und in den regulären Incident-Workflow eingespeist.

Incident-Prioritäten

Incident-Severity-Modell S1–S4

Ein vierstufiges Kritikalitätsmodell. Die angegebenen Zeiten sind Richtwerte; die endgültigen Parameter hängen vom Service-Tier, dem Bereitschaftsmodus und dem Budget ab und werden im SOW festgeschrieben.

Stufe

Kritikalität

Beschreibung

Bestätigungszeit

Angestrebte Lösungszeit

Kritisch

Vollständiger Ausfall eines Schlüsseldienstes oder -produkts; direkte finanzielle Auswirkungen

15 Minuten

4 Stunden

Hoch

Teilweise Degradierung eines Schlüsseldienstes; erhebliche Beeinträchtigung der Nutzererfahrung

30 Minuten

8 Stunden

Mittel

Degradierung eines nicht kritischen Dienstes; Kernprodukt bleibt betriebsfähig

4 Stunden

24 Stunden

Niedrig

Geringfügige Probleme ohne Betriebsauswirkungen; Maßnahmen zur Monitoring-Verbesserung

Nächster Werktag

Nach Vereinbarung

Die konkreten Reaktionszeiten hängen vom Service-Tier, dem Bereitschaftsmodus und dem Betreuungsbudget ab. Die endgültigen Parameter werden im SOW festgeschrieben.

Zuverlässigkeitsmanagement

Error-Budget-Policy

Das Error Budget ist das zulässige Maß an Dienstgradminderung innerhalb eines Abrechnungszeitraums (in der Regel monatlich oder quartalsweise). Der Zustand des Budgets bestimmt direkt, worauf das Team seine Zeit verwendet: auf Features oder auf Stabilität.

Normalbereich

Error Budget im Normalbereich

Restbudget oberhalb der Warnschwelle. Das Team arbeitet im regulären Entwicklungstakt — Featureentwicklung und Infrastrukturänderungen laufen planmäßig.

Nähert sich der Erschöpfung

Error Budget nähert sich der Erschöpfung

Restbudget unterhalb der Warnschwelle. Prioritäten verschieben sich in Richtung Stabilisierung. Neue Features werden pausiert, bis das Budget sich erholt oder der SLO gemeinsam mit dem Auftraggeber neu verhandelt wird.

Erschöpft

Error Budget erschöpft

Featureentwicklung wird vollständig eingestellt. Das Team konzentriert sich ausschließlich auf die Wiederherstellung der Systemzuverlässigkeit. Es findet ein gemeinsames Review mit dem Auftraggeber zur Ursachenanalyse und Plankorrektur statt.

Transparenz

Berichterstattung und Service Reviews

Regelmäßige Berichte geben dem Auftraggeber Transparenz über SLIs, den Zustand des Error Budgets und die Zuverlässigkeitsentwicklung. Standardrhythmus: monatlich. Wöchentliche oder quartalsweise Formate sind nach Vereinbarung möglich.

Inhalt der periodischen Berichte

Abschnitt

Inhalt

SLO-Status

Tatsächliche SLI-Werte des Zeitraums im Vergleich zu den SLO-Zielen

Error Budget

Restbudget je Dienst, Verbrauchsverlauf

Incidents

Incident-Übersicht nach S1–S4-Stufen, MTTR, Ursachen

Trends

Entwicklung von Performance und Zuverlässigkeit im Vergleich zur Vorperiode

Empfehlungen

Vorschläge zur Verbesserung von Monitoring, Architektur oder Prozessen

Vorgehen nach Incident-Behebung

Jeder Incident wird in einem Ticket dokumentiert: Ursachen, betroffene Systeme und ergriffene Maßnahmen. Korrigierende Tickets für identifizierte Fehler und logische Schwachstellen werden verknüpft. Die resultierende Ticket-Struktur bildet die Grundlage für Postmortem-Analysen und die kontinuierliche Bewertung der Teameffektivität.

Berichtsrhythmus

Standard

Monatlich

regelmäßiges Service Review

Optional

Wöchentlich

für Systeme mit hohem Service-Tier

Optional

Quartalsweise

QBR-Format

Ehrliche Grenzen

Was wir nicht zusagen

Klare Grenzen unserer Leistungsfähigkeit sind Bestandteil unseres Vertrauensansatzes. Lieber benennen wir offen, wo unsere Garantien enden, als Zahlen zu unterschreiben, die wir nicht halten können.

Universelle SLOs

Keine universellen SLO-Werte

Wir veröffentlichen keine pauschalen Zusagen wie „99,99 % für alle“ vor einem Audit. Zielwerte sind immer projektspezifisch.

Drittanbieter

Drittanbieter-Abhängigkeiten liegen außerhalb unserer Kontrolle

Wir überwachen externe APIs und Dienste, können deren Verfügbarkeit jedoch nicht garantieren.

SLO ≠ SLA

SLO ist nicht SLA

SLOs sind operative Zielvorgaben, keine rechtsverbindlichen Zusagen. Rechtliche Konsequenzen bei Nichteinhaltung werden in einem separaten SLA geregelt.

Abdeckung

24/7-Bereitschaft ist nicht standardmäßig enthalten

Rund-um-die-Uhr-Abdeckung hängt vom Budget und Service-Tier ab. Standardpakete können auf erweiterte Geschäftszeiten beschränkt sein.

Das Ideal

Keine Garantie für null Incidents

Wir arbeiten darauf hin, Incidents zu vermeiden und deren Auswirkungen zu minimieren. Ihr vollständiges Ausbleiben kann nicht zugesagt werden.

Geschäftskennzahlen

Monitoring von Geschäftsprozessen erfordert gesonderte Vereinbarung

Die Überwachung von Geschäftsabläufen setzt eine separate Abstimmung über Metriken und Datenzugang voraus.

Fazit

Der SLO-Ansatz von Webdelo ist eine ingenieurtechnische Praxis — keine Marketingversprechen. Wir definieren, was gemessen wird, konfigurieren die Werkzeuge, besetzen das Team und vereinbaren realistische Zielwerte. Konkrete SLO-Werte werden stets im SOW nach einem Projektaudit festgelegt. Das ermöglicht uns, klare Verantwortung für Ergebnisse zu übernehmen — und dem Auftraggeber, genau zu verstehen, was ihm zugesichert wird.

Für eine Beratung zur Betreuung Ihres Projekts nehmen Sie bitte Kontakt mit uns auf.

Terminologie

Glossar

Alert / Alerting — automatische Benachrichtigung, die ausgelöst wird, wenn eine Metrik einen definierten Schwellenwert über- oder unterschreitet. Das Alerting-System stellt sicher, dass das Bereitschaftsteam ausschließlich handlungsrelevante Signale erhält.

API (Application Programming Interface) — eine Schnittstelle, über die Softwaresysteme miteinander kommunizieren. Beispielsweise erfolgt die Anbindung eines Zahlungsdienstleisters an eine Webanwendung über eine API.

Bereitschaftsdienst (On-Call) — ein Rotationsmodell, bei dem ein Ingenieur als primärer Ansprechpartner für einen definierten Zeitraum eingeteilt ist und Incidents innerhalb der vereinbarten Reaktionszeit bestätigen und bearbeiten muss.

Change Management — ein strukturierter Prozess zur Steuerung von Änderungen an Systemen und Infrastruktur. Änderungen außerhalb dieses Prozesses können Degradierungen verursachen, die nicht unter die SLO-Verantwortung fallen.

CPU (Central Processing Unit) — die zentrale Recheneinheit eines Servers. Eine hohe CPU-Auslastung ist eines der wichtigsten Signale für eine Leistungsdegradierung.

DevOps (Development + Operations) — eine Praxis und Kultur, die Softwareentwicklung und IT-Betrieb vereint. Ein DevOps-Ingenieur verantwortet CI/CD-Pipelines, Infrastrukturbereitstellung, Containerisierung und Deployment-Automatisierung.

Disk I/O (Disk Input/Output) — Lese- und Schreiboperationen auf einem Speichermedium. Hoher Disk-I/O kann Ursache für Datenbankverlangsamerungen oder systemweite Degradierungen sein.

Endpunkt (Endpoint) — eine spezifische URL oder Netzwerkadresse, unter der ein Dienst oder eine API Anfragen entgegennimmt. Das Monitoring von Endpunkten ermöglicht die Überwachung der Verfügbarkeit jeder einzelnen Schnittstelle.

ERP (Enterprise Resource Planning) — integrierte Unternehmenssoftware, die Finanzen, Lager, Produktion, HR und weitere Geschäftsprozesse in einer Plattform zusammenführt.

Error Budget — das zulässige Maß an Dienstgradminderung innerhalb eines Abrechnungszeitraums (typischerweise monatlich oder quartalsweise). Bei Erschöpfung des Budgets wird die Featureentwicklung gestoppt und der Fokus auf Stabilitätswiederherstellung gelegt.

Fintech (Financial Technology) — Technologiesektor, der Softwarelösungen für Finanzdienstleistungen einsetzt: Zahlungsverkehr, Kreditvergabe, Handel und Versicherungen.

Grafana — eine Open-Source-Plattform zur Visualisierung von Metriken und zur Erstellung von Monitoring-Dashboards. Wird typischerweise zusammen mit Prometheus oder VictoriaMetrics eingesetzt, um den Systemzustand in Echtzeit darzustellen.

Healthcheck — eine periodische automatisierte Prüfung, die feststellt, ob ein Dienst erreichbar und funktionsfähig ist. Das grundlegende Instrument zur Erkennung von Dienstausfällen.

HTTP-5xx — Klasse von HTTP-Antwortcodes (500–599), die serverseitige Fehler anzeigen: interner Serverfehler (500), Bad Gateway (502), Service Unavailable (503) u.a. Ein Anstieg der 5xx-Rate ist ein direktes Signal für Dienstdegradierung.

Incident — ein ungeplantes Ereignis, das die Verfügbarkeit oder Qualität eines Dienstes beeinträchtigt oder zu beeinträchtigen droht. Incidents werden nach dem S1–S4-Modell klassifiziert und strukturiert bearbeitet.

Jira / ClickUp — Projektmanagement- und Issue-Tracking-Systeme, die zur Erstellung von Incident-Tickets, Zuweisung von Verantwortlichkeiten und Nachverfolgung von Behebungsmaßnahmen eingesetzt werden.

Latenz — die Antwortzeit; der Zeitraum zwischen dem Absenden einer Anfrage durch den Client und dem Empfang der Antwort vom Server. Gemessen in Millisekunden. Hohe Latenz verschlechtert die Nutzererfahrung selbst dann, wenn ein Dienst technisch erreichbar ist.

MTTR (Mean Time To Resolve) — die durchschnittliche Zeit zur Behebung eines Incidents vom Zeitpunkt der Erkennung bis zur vollständigen Wiederherstellung des Dienstes. Einer der wichtigsten Leistungsindikatoren für ein Betreuungsteam.

Observability — die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Ausgaben (Metriken, Logs, Traces) zu verstehen. Vollständige Observability-Abdeckung ist die Grundvoraussetzung für effektives SLO-Management.

p50 / p95 / p99 (Latenz-Perzentile) — statistische Kennzahlen der Antwortzeitenverteilung. p95 bedeutet, dass 95 % der Anfragen schneller als der angegebene Wert bearbeitet werden; p99 deckt 99 % der Anfragen ab. Perzentile bilden die tatsächliche Nutzererfahrung genauer ab als Durchschnittswerte.

Postmortem — eine strukturierte Analyse nach Behebung eines Incidents: Ursachenforschung, Ereignis-Chronologie, Liste betroffener Systeme und konkrete Maßnahmen zur Vermeidung einer Wiederholung. Die Grundlage für systematische Zuverlässigkeitsverbesserung.

Prometheus — ein System zur Erfassung und Speicherung von Metriken mit Unterstützung für flexible PromQL-Abfragen und einem integrierten Alerting-Mechanismus. De-facto-Standard für das Monitoring cloud-nativer und Microservice-Anwendungen.

RAM (Random Access Memory) — Arbeitsspeicher; schneller temporärer Speicher für laufende Prozesse und Anwendungen. Eine Erschöpfung des RAM führt zu Leistungsdegradierung oder einem harten Dienstabsturz.

Runbook — eine dokumentierte Schritt-für-Schritt-Anleitung, die ein Bereitschaftsingenieur bei einem bestimmten Alert befolgt. Runbooks gewährleisten eine konsistente und schnelle Reaktion unabhängig vom individuellen Wissensstand.

S1 / S2 / S3 / S4 (Severity 1–4) — Incident-Kritikalitätsstufen von kritisch (S1: Totalausfall, direkte finanzielle Auswirkungen) bis niedrig (S4: geringfügige Defekte ohne Betriebsauswirkung). Die Stufe bestimmt die Reaktionspriorität und den Eskalationspfad.

Service Review — ein regelmäßiges Treffen zwischen Betreuungsteam und Auftraggeber zur Analyse der Periodenmetriken, Incident-Auswertung und Vereinbarung eines Verbesserungsplans. Standardrhythmus: monatlich.

Service-Tier — Klassifizierungsstufe eines Dienstes nach seinem Einfluss auf die Verfügbarkeit des Kernprodukts. Der Tier bestimmt Monitoring-Priorität, Reaktionszeiten und Bereitschaftsteam-Zusammensetzung.

Severity — der Kritikalitätslevel eines Incidents; gibt an, wie schwerwiegend die Beeinträchtigung der Dienstverfügbarkeit ist und wie schnell das Team reagieren muss.

SLA (Service Level Agreement) — ein Vertragsdokument, das SLOs formalisiert und die rechtlichen Konsequenzen bei Nichteinhaltung regelt. Das SLA ist die bindende Vereinbarung; der SLO ist das operative Ziel.

SLI (Service Level Indicator) — eine konkrete, messbare Qualitätsmetrik eines Dienstes: Verfügbarkeit, Latenz, Fehlerrate. SLIs sind die Rohmessungen, anhand derer SLOs bewertet werden.

SLO (Service Level Objective) — ein Zielwert oder -bereich für einen SLI, den das Team zu halten verpflichtet ist. SLOs werden pro Dienst definiert und nach dem Projektaudit im SOW festgeschrieben.

Slow Query Log — ein Datenbankprotokoll, das automatisch Abfragen aufzeichnet, deren Ausführungszeit einen definierten Schwellenwert überschreitet. Ein wichtiges Diagnosewerkzeug zur Identifizierung von Datenbankleistungsproblemen.

SOW (Statement of Work) — das Pflichtenheft, das Umfang, Zeitplan und konkrete Bedingungen eines Mandats festlegt, einschließlich der nach dem Projektaudit vereinbarten SLO-Werte.

SysOps (Systems Operations) — ein Spezialist für den Betrieb von Serverinfrastruktur, Netzwerken, Speichersystemen und Container-Orchestrierung. Wird bei einem Incident hinzugezogen, wenn das Problem auf Infrastrukturebene lokalisiert ist.

Trading-System — eine Softwareplattform für die automatisierte Ausführung von Transaktionen auf Finanzmärkten. Gehört zur Klasse hochkritischer Systeme mit strengen Anforderungen an Latenz und Verfügbarkeit.

Uptime — die Betriebszeit; der Zeitraum, in dem ein Dienst oder System ohne Unterbrechung verfügbar ist. Wird üblicherweise als Prozentwert über einen Messzeitraum angegeben: 99,9 % Uptime bedeutet maximal ~8,7 Stunden Ausfall pro Jahr.

VictoriaMetrics — eine hochperformante Zeitreihendatenbank für die Langzeitspeicherung von Metriken und das Alerting. Kompatibel mit dem Prometheus-Format und ressourcenschonender bei hoher Last.

Wartungsfenster — ein vorab mit dem Auftraggeber vereinbarter Zeitraum für geplante Systemarbeiten. Ausfälle während Wartungsfenstern fallen nicht in den SLO-Geltungsbereich.