Service Level Objectives: Der Ansatz von Webdelo für Projektbetreuung

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 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.

Begriffsbestimmungen Geltungsbereich SLIs: Was wir messen Paketkomponenten Severity-Modell Error Budget Glossar

Begriffsbestimmungen

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.

Geltungsbereich (Scope)

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 auf SLO-Parameter

Webdelo hat über die Jahre einen Ansatz entwickelt, bei dem Zielwerte durch drei Faktoren bestimmt werden.

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.

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.

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.

Zeitpunkt der SLO-Festlegung

SLOs werden in einer von zwei Phasen definiert.

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.

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.

SLIs: Was wir messen

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

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.

Standardkomponenten des SLO-Pakets

Jedes Betreuungsmandat von Webdelo umfasst fünf Pflichtkomponenten.

1. Monitoring-Infrastruktur

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

2. 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.

3. 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?"

4. 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.

5. 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-Severity-Modell

Stufe	Kritikalität	Beschreibung	Bestätigungszeit	Angestrebte Lösungszeit
S1	Kritisch	Vollständiger Ausfall eines Schlüsseldienstes oder -produkts; direkte finanzielle Auswirkungen	15 Minuten	4 Stunden
S2	Hoch	Teilweise Degradierung eines Schlüsseldienstes; erhebliche Beeinträchtigung der Nutzererfahrung	30 Minuten	8 Stunden
S3	Mittel	Degradierung eines nicht kritischen Dienstes; Kernprodukt bleibt betriebsfähig	4 Stunden	24 Stunden
S4	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.

Error-Budget-Policy

Das Error Budget ist das zulässige Maß an Dienstgradminderung innerhalb eines Abrechnungszeitraums (in der Regel monatlich oder quartalsweise).

Error Budget im Normalbereich

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

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.

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.

Berichterstattung und Service Reviews

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 zum Vorjahreszeitraum
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

Standardrhythmus für Berichte und Service Reviews: monatlich. Wöchentliche oder quartalsweise Formate sind nach Vereinbarung möglich.

Was wir nicht zusagen

Klare Grenzen unserer Leistungsfähigkeit sind Bestandteil unseres Vertrauensansatzes.

Keine universellen SLO-Werte

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

Drittanbieter-Abhängigkeiten liegen außerhalb unserer Kontrolle

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

SLO ist nicht SLA

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

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.

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.

Monitoring von Geschäftsprozessen erfordert gesonderte Vereinbarung

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

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.

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.