Service Level Indicators: was wir messen und wie

Auf dieser Seite erfahren Sie, welche Service Level Indicators (SLI) wir für Kundenprojekte einsetzen, wie wir sie messen und wo die Grenzen dieser Messungen liegen. Wir veröffentlichen diese Informationen, damit Sie als Kunde nicht nur die Zielwerte, sondern auch die Methodik, die Einschränkungen und die Interpretation der Metriken nachvollziehen können.

Uptime ≥ 99,5 % (Ziel: 99,8 %)

P95-Latenz · API < 300 ms

Fehlerquote < 0,1 %

UptimeRobot · Grafana · Prometheus

Lighthouse CI in der Pipeline

Methodik: RED + USE

live · production monitoring ● UP

99.93% ▲ within SLO

uptime · last 30 days · target ≥ 99.8%

P95 latency 214 ms

Error rate 0.04%

Throughput 1.42k/s

SLI-Grundlagen

Das Wichtigste in Kürze

SLI ist das, was gemessen wird. SLO ist der Zielwert, an dem wir uns in der Arbeit orientieren. SLA ist die vertragliche Verpflichtung. Auf dieser Seite finden Sie die tatsächlichen Metriken und Tools; konkrete Schwellenwerte werden nach einem Audit im SOW festgelegt.

≥ 99,5 %

Basis-SLO für Uptime (Ziel: 99,8 %)

< 300 ms

P95-Latenz der API-Endpunkte

< 0,1 %

Fehlerquote (HTTP 5xx)

≤ 20 Min.

Erste Reaktion bei S1 während der Geschäftszeiten

Ansatz

RED + USE

RED für Anfragen (Rate, Errors, Duration), USE für Ressourcen (Utilization, Saturation, Errors).

Tool-Stack

UptimeRobot · Grafana · Prometheus · Nightwatch · Lighthouse CI

Alternative: New Relic APM. Die Toolwahl richtet sich nach der Projektarchitektur.

Perzentile

P50 · P95 · P99

Durchschnittswerte verschleiern den Worst Case. Perzentile zeigen, was Ihre langsamsten Nutzer tatsächlich erleben.

CWV

LCP ≤ 2,5 s · INP ≤ 200 ms · CLS ≤ 0,1

Lighthouse CI in der Pipeline blockiert das Deployment bei kritischer Verschlechterung der Werte.

Monitoring

24/7, nicht nur zu Geschäftszeiten

Metriken werden rund um die Uhr erfasst. Die Rufbereitschaft richtet sich nach dem gewählten Support-Plan.

Verbindlich geregelt in

SOW · SLA

Konkrete SLO und Verpflichtungen werden im Vertrag festgehalten. Diese Seite dient der Information.

Vorab

So lesen Sie diese Seite

Diese Seite dient der Information. Die aufgeführten SLI- und SLO-Werte sind typische Richtwerte für betreute Projekte und ersetzen nicht die individuellen Vereinbarungen aus Vertrag, SOW und SLA.

SLI sind messbare Kennzahlen — keine Marketingversprechen. Hinter jeder Zahl steht ein konkretes Messwerkzeug.

SLO auf dieser Seite sind Richtwerte für typische Szenarien. Die endgültigen Zielwerte werden nach dem Onboarding und einer Architekturanalyse festgelegt.

Datenquellen hängen von der Projektkonfiguration ab: externe synthetische Checks, Infrastrukturmetriken, APM und CI-Audits.

Aus den Berechnungen ausgenommen werden können: geplante Wartungsfenster, höhere Gewalt und Ausfälle externer Dienste, gemäß Vertragsbedingungen.

Die tatsächliche Berichterstattung und der Zugang zu Dashboards richten sich nach dem gewählten Support-Plan.

Nutzen für Ihr Unternehmen

Warum SLI für Ihr Unternehmen wichtig sind

Wenn ein Kunde sein Projekt in die Betreuung gibt, lautet die Erwartung meist ganz einfach: Die Website oder Anwendung soll stabil, schnell und vorhersehbar laufen. Aber die Formulierung „läuft alles normal“ ist für ein professionelles Qualitätsmanagement zu vage. SLI übersetzen sie in messbare Kennzahlen, die man prüfen, vergleichen und datenbasiert besprechen kann.

Was passiert gerade?

Echtzeit-Monitoring erfasst jede Abweichung sofort.

Wie stabil war der Service im Zeitverlauf?

Historische Daten zeigen Trends und saisonale Muster.

Wann müssen wir eingreifen?

Schwellenwerte lösen Alarme aus, bevor der Nutzer ein Problem bemerkt.

Der praktische Nutzen von SLI für Ihr Unternehmen: weniger Unsicherheit, früheres Erkennen von Leistungseinbußen und die Möglichkeit, Entscheidungen zur Weiterentwicklung Ihres Projekts auf Basis von Fakten statt Bauchgefühl zu treffen.

Qualitätsebenen

SLI, SLO und SLA: wie sie zusammenhängen

Die drei Ebenen der Servicequalität bauen aufeinander auf: Messung → Zielwerte → Zusagen.

Trust & Legal

DSGVO-Konformität

Einhaltung der Datenschutzvorgaben

Wir verarbeiten personenbezogene Daten nach den Grundsätzen der Datenschutz-Grundverordnung (DSGVO): Wir erheben nur die nötigen Daten, legen Zwecke und Speicherfristen fest, wahren die Rechte der Betroffenen und berücksichtigen die Anforderungen an Logs, Analytics und Backups.

Trust & Legal

ISO 27001 und SOC 2

auf dem Weg zur Zertifizierung

Unsere Informationssicherheit orientiert sich an ISO 27001 und SOC 2: Zugriffe nach dem Least-Privilege-Prinzip, dokumentierte Richtlinien, Secure SDLC, DevSecOps und interne Audits.

Trust & Legal

NDA und Vertraulichkeit

Schutz von Geschäftsinformationen

Für alle Webdelo-Projekte gilt standardmäßig ein NDA. Zugriffe auf Daten und Repositories vergeben wir rollenbasiert und nutzen sichere Kanäle sowie Secret Manager. Kundenmaterialien geben wir ohne gesonderte Zustimmung weder an externe Dienste noch an öffentliche KI-Modelle weiter.

Das Grundprinzip: SLIs speisen SLOs, SLOs bilden die Grundlage für SLAs. Ohne verlässliche Indikatoren sind Garantien nur leere Worte. Deshalb beginnen wir mit der Messung.

Metriken

Was wir messen

Wir erfassen Metriken, die sich auf das Nutzererlebnis, die Servicestabilität und die Steuerbarkeit des Supports auswirken. Der Umfang kann je nach Projekt variieren, aber die grundlegenden Indikatoren und Berechnungsprinzipien bleiben einheitlich.

Kernindikatoren

Indikator

Was er zeigt

Wie wir messen

Richtwert (SLO)

Uptime (Verfügbarkeit)

Anteil der Zeit, in der der Service erreichbar ist und korrekt antwortet

Anteil erfolgreicher HTTP-Antworten (2xx/3xx) an der Gesamtzahl synthetischer Checks

≥ 99,5 % (Standard), ≥ 99,8 % (Ziel)

Latency (Antwortzeit)

Geschwindigkeit der Serverantwort auf eine Nutzeranfrage

Perzentile P50, P95, P99 über alle Anfragen im Zeitraum

P95 < 300 ms (API), P95 < 2 s (Seite)

Error Rate (Fehlerquote)

Anteil der Anfragen, die mit einem Serverfehler enden

Prozentsatz der 5xx-Antworten an der Gesamtzahl der Anfragen

< 0,1 %

First Response Time

Wie schnell das Team auf ein eingehendes Ticket reagiert

Zeit von der Ticketerstellung bis zur ersten inhaltlichen Antwort

≤ 20 Min. (S1, Geschäftszeiten)

Core Web Vitals

Google nutzt Core Web Vitals als Rankingfaktor. Wir tracken sie separat, weil sie sich direkt auf SEO und Conversion auswirken.

Metrik

Was sie misst

Schwelle „gut“

Unser Tool

LCP Largest Contentful Paint

Ladegeschwindigkeit des Hauptinhalts der Seite

≤ 2,5 s

Lighthouse CI

INP Interaction to Next Paint

Reaktionsfähigkeit der Seite auf Nutzerinteraktionen

≤ 200 ms

Lighthouse CI

CLS Cumulative Layout Shift

Visuelle Stabilität — keine „springenden“ Elemente

≤ 0,1

Lighthouse CI

Lighthouse CI läuft automatisch in der Deployment-Pipeline. Wenn sich Core Web Vitals nach einem Update verschlechtern, erfahren wir das, bevor es sich auf die Suchpositionen auswirkt.

Ergänzende Indikatoren

Indikator

Was er zeigt

Richtwert (SLO)

TTMR Time to Mitigation/Restore

Zeit vom Beginn eines Vorfalls bis zur Wiederherstellung

≤ 4 Std. (S1), ≤ 8 Std. (S2)

Deployment Success Rate

Anteil der Deployments ohne Servicebeeinträchtigung

≥ 99 %

Saturation (Auslastung)

Nutzung der Serverressourcen: CPU, RAM, Festplatte

CPU idle > 10 %, RAM < 85 %, Festplatte > 10 % frei

SSL/Domain Expiry

Überwachung der Laufzeiten von Zertifikaten und Domains

Warnung ≥ 30 Tage vor Ablauf

Die Werte in den obigen Tabellen dienen als Basisrichtwerte. Für ein konkretes Projekt werden sie nach dem Onboarding, der Architekturanalyse, dem Lastprofil und der Kritikalität der Geschäftsprozesse angepasst.

Stack und Methodik

Wie wir messen: Tools und Methodik

Die Aussagekraft von Metriken hängt nicht nur vom Tool ab, sondern auch von der Art der Anwendung: Prüffrequenz, Alarmkonfiguration, Monitoring-Standorte, Aufbewahrungsdauer der Daten und korrekte Interpretation. Deshalb setzen wir auf eine Kombination aus externem synthetischem Monitoring und Analysen auf Infrastruktur- und Anwendungsebene.

Grafana — overview dashboard grafana.webdelo.io

Uptime · 30d 99.93% target ≥ 99.8%

P95 latency 214 ms SLO < 300 ms

Error rate · 5xx 0.04% SLO < 0.1%

Throughput 1.42k req/s

Request rate / 6h

P95 latency / 6h (ms)

CPU idle 71%

RAM used 62%

Disk free 38%

Grafana-Übersichtsdashboard mit den wichtigsten Projektmetriken.

Externes Verfügbarkeitsmonitoring

UptimeRobot

Synthetische Checks von mehreren geografischen Standorten alle 1–5 Minuten

HTTP/HTTPS, Ping, Port-Checks, DNS- und SSL-Monitoring

Sofortige Benachrichtigungen bei Ausfall via E-Mail, Slack, Telegram

Historische Uptime-Daten für die Berichterstattung

Öffentliche Statusseiten für Transparenz gegenüber Nutzern

Visualisierung und Analyse

Grafana + Prometheus

Prometheus sammelt Metriken von Servern und Anwendungen, Grafana visualisiert sie auf konfigurierbaren Dashboards

Latency (P50, P95, P99), Error Rate, Throughput — in Echtzeit

Monitoring der Serverressourcen: CPU, RAM, Festplatte, Netzwerk

Konfigurierbare Alarme bei Überschreitung von Schwellenwerten

Historische Trends zur Erkennung von Verschlechterungen, bevor sie zum Vorfall werden

Grafana — health & uptime

api.example.com UP200 OK last check 23s ago

app.example.com UP200 OK last check 14s ago

cdn.example.com UP200 OK last check 18s ago

Uptime history · 30d

30d agouptime 99.91% · 2 incidentsnow

Grafana — Verfügbarkeits- und Health-Status-Historie des Projekts.

Grafana — latency & error rate

P50 / P95 / P99 — last 1h

P50 92 msP95 214 msP99 518 ms

Error rate · 5xx

peak 0.42% · current 0.04%

Dashboard Latency und Error Rate.

Grafana — aggregated logs

10:42:18INFOUser login successful · uid=8341

10:42:21INFOPOST /api/orders · 201 · 87 ms

10:42:33WARNSlow query · orders.find · 412 ms

10:42:47INFOCache hit ratio · 94.2%

10:42:51ERRExternal API timeout · delivery.svc · 5000 ms

10:42:58INFOGET /api/profile · 200 · 41 ms

10:43:02WARNQueue lag · default · 124 jobs

10:43:11INFODeployment v2.18.4 · success

Aggregierte Anwendungslogs.

Monitoring auf Anwendungsebene

Laravel Nightwatch

Tiefgreifende Instrumentierung von Laravel-Anwendungen — direkt von den Framework-Entwicklern

Tracing jeder Anfrage vom Eingang bis zur Antwort

Erkennung langsamer SQL-Abfragen und Engpässe in Warteschlangen

Echtzeit-Monitoring von Exceptions und Fehlern

Überwachung von Hintergrundaufgaben und Cron-Zeitplänen

Hinweis: Bei einzelnen Projekten wird als Alternative zu Nightwatch New Relic APM eingesetzt — eine umfassende Plattform für Performance-Monitoring. Die Toolwahl richtet sich nach der Projektarchitektur und den Kundenanforderungen.

Nightwatch — request trace

GET/api/orders/8341 214 ms · 200 OK

Controller@showApp\Http\Controllers 214 ms

Middleware: auth2 ms 2 ms

DB: orders.findSELECT 38 ms

DB: order_items.whereSELECT 26 ms

External: delivery.svcPOST 90 ms

Cache: redis.get2 hits 7 ms

View: orders.showrender 39 ms

Request-Tracing.

Nightwatch — request list

TIMEMETHODURLDURATIONSTATUS

10:42:18 GET /api/orders/8341 214 ms 200

10:42:14 POST /api/checkout 892 ms 201

10:42:09 GET /api/profile 41 ms 200

10:42:01 GET /api/products?cat=12 318 ms 200

10:41:55 DELETE /api/cart/items/22 68 ms 204

10:41:48 POST /webhooks/payment 156 ms 200

10:41:42 GET /api/orders 1240 ms 500

Request-Liste.

Nightwatch — exception

Illuminate\Database\QueryException SQLSTATE[HY000]: General error: 2006 MySQL server has gone away at vendor/laravel/framework/src/Illuminate/Database/Connection.php:759
at App\Http\Controllers\OrderController->show:34
at App\Http\Middleware\Authenticate->handle:18
GET /api/orders/8341 · trace_id=a3f8b91c

first seen 2h agooccurrences 14affected users 9

Exception mit Stack Trace.

Core Web Vitals

Lighthouse CI

Automatisches Performance-Audit bei jedem Deployment

Ausführung in der CI/CD-Pipeline von Bitbucket Pipelines

Vergleich der Metriken mit dem vorherigen Release — Regressionen fallen sofort auf

LCP, INP, CLS sowie Accessibility- und SEO-Audit

Blockierung des Deployments bei kritischer Verschlechterung der Werte

98 Performance scoreCI passing

LCP2.1 s✓ good

INP180 ms✓ good

CLS0.05✓ good

Bitbucket Pipelines · last run 8 min ago · deploy blocked below 90

Methodik

Für Webanwendungen verwenden wir den Ansatz RED (Rate, Errors, Duration) — drei Schlüsselsignale, die als Erste auf eine Verschlechterung des Nutzererlebnisses reagieren. Für Infrastrukturmetriken nutzen wir den ergänzenden Ansatz USE (Utilization, Saturation, Errors).

Perspektive

Aus Nutzersicht

Nicht interne Serverwerte, sondern das reale Erlebnis: Seitenladezeiten, Erfolg von Aktionen, Wartezeiten.

Statistik

Perzentile statt Durchschnitte

P95 und P99 zeigen das schlechteste Erlebnis realer Nutzer, nicht den „Durchschnitt über alle Patienten“.

Abdeckung

Kontinuierlich, rund um die Uhr

Metriken werden 24/7 erfasst, nicht nur während der Geschäftszeiten.

Die Schwellenwerte werden vierteljährlich überprüft, außerdem nach jedem bedeutsamen Vorfall und bei Änderungen im Lastprofil.

Risikomanagement

Error Budget — das Budget für zulässige Fehler

Kein Service läuft komplett störungsfrei. Das Error Budget ist ein Engineering-Ansatz, der diese Realität in eine steuerbare Größe übersetzt: das zulässige Maß an Ausfallzeit oder Fehlern innerhalb eines Zeitraums, bei dem der Service im Rahmen des SLO bleibt.

99,5 %

zulässige Ausfallzeit pro Monat ~3 Std. 39 Min.

pro Jahr ~43 Std. 48 Min.

~43 Std. 48 Min. pro Jahr

99,8 %

zulässige Ausfallzeit pro Monat ~1 Std. 27 Min.

pro Jahr ~17 Std. 31 Min.

~17 Std. 31 Min. pro Jahr

99,9 %

zulässige Ausfallzeit pro Monat ~43 Min.

pro Jahr ~8 Std. 46 Min.

~8 Std. 46 Min. pro Jahr

99,95 %

zulässige Ausfallzeit pro Monat ~22 Min.

pro Jahr ~4 Std. 23 Min.

~4 Std. 23 Min. pro Jahr

Budget nicht ausgeschöpft

Freie Fahrt

Updates, neue Features und Experimente sind möglich.

Budget wird knapp

Fokus auf Stabilität

Nur kritische Fixes, verstärktes Testing.

Budget aufgebraucht

Änderungsstopp

Bis der Puffer wiederhergestellt ist, hat die Beseitigung der Ursachen Priorität.

Warum das für Sie wichtig ist: Das Error Budget hilft uns, Entscheidungen nicht aus dem Bauch heraus zu treffen („lieber nichts anfassen“), sondern auf Basis von Daten. Das bedeutet: Ihr Projekt entwickelt sich so schnell wie möglich — bei dem von Ihnen gewünschten Zuverlässigkeitsniveau.

Support-Pläne

Monitoring-Umfang nach Support-Plan

Die Monitoring-Tiefe und der Umfang der erfassten SLI richten sich nach dem gewählten Support-Plan.

Leistung

Basic

Extended

Enterprise empfohlen

Synthetische Verfügbarkeitschecks (Uptime)

Überwachung von SSL-Zertifikaten und Domains

Benachrichtigungen bei Ausfall

Lighthouse CI (Core Web Vitals)

Latency-Monitoring (P50, P95, P99)

—

Error-Rate-Monitoring

—

Ressourcen-Monitoring (CPU, RAM, Festplatte)

—

Teilweise

APM auf Anwendungsebene (Nightwatch / New Relic)

—

Teilweise

Individuelle Grafana-Dashboards

—

Proaktive Benachrichtigungen bei Verschlechterungen

—

Error-Budget-Tracking

—

SLI-Berichterstattung

Auf Anfrage

Monatlich

Wöchentlich + QBR

Ziel-Uptime (SLO)

99,5 %

99,5–99,8 %

bis 99,9 %^*

* Die Zielwerte des Enterprise-Plans werden individuell nach dem Onboarding und einer Architekturanalyse festgelegt.

Vorfälle

Modell zur Einstufung von Vorfällen

Alle Vorfälle werden nach ihrer geschäftlichen Auswirkung klassifiziert. Jedem Schweregrad sind eigene Reaktionsziele zugeordnet.

Sev

Schweregrad

Beschreibung

Erste Reaktion (SLO)

Wiederherstellung (SLO)

Kritisch

Vollständiger oder teilweiser Ausfall, ein zentraler Geschäftsprozess ist blockiert, Sicherheitsvorfall

≤ 20 Min. (Geschäftszeiten)

≤ 4 Stunden

Hohe Auswirkung

Erhebliche Beeinträchtigung mit Workarounds, Einfluss auf SEO oder Conversion

≤ 1 Stunde

≤ 8 Stunden

Mittlere Auswirkung

Defekte mit begrenztem geschäftlichem Einfluss

≤ 4 Stunden

Im laufenden Sprint

Geringe Auswirkung

Kosmetische Probleme, UX-Verbesserungen

≤ 1 Werktag

Nach Priorität im Backlog

S1 · Kritisch: Reaktion in Minuten

S2 · Hohe Auswirkung: Reaktion in Stunden

S3 · Mittlere Auswirkung: im laufenden Sprint

S4 · Geringe Auswirkung: im Backlog

Transparenz

Transparenz und Berichterstattung

SLI haben nur dann einen Wert, wenn sie für den Kunden zugänglich und verständlich sind. Wir verstecken keine Metriken — wir machen sie zur Grundlage gemeinsamer Entscheidungen.

Was ein SLI-Bericht enthält

Abschnitt

Inhalt

Uptime im Zeitraum

Tatsächlicher Verfügbarkeitsprozentsatz im Vergleich zum Ziel-SLO

Latency-Trends

Entwicklung der Antwortzeiten (P50, P95) mit Hervorhebung von Anomalien

Error Rate

Fehlerquote mit Aufschlüsselung nach Typ und Quelle

Core Web Vitals

Entwicklung von LCP, INP, CLS und Auswirkungen auf SEO-Rankings

Vorfälle im Zeitraum

Anzahl, Schweregrad, Reaktionszeit und Wiederherstellungsdauer

Error Budget

Wie viel Budget verbraucht wurde und wie viel noch übrig ist

Empfehlungen

Konkrete Maßnahmen zur Verbesserung der Kennzahlen

Berichtsfrequenz

Plan

SLI-Bericht

Format

Basic

Auf Anfrage

Zusammenfassung im Ticketsystem

Extended

Monatlich

PDF + Kommentare

Enterprise

Wöchentlich + vierteljährlicher QBR

Dashboard + PDF + Call

Zuverlässigkeitskultur

Unser Ansatz für Zuverlässigkeit

SLI sind nicht einfach Zahlen in einem Bericht. Sie bilden die Grundlage einer Engineering-Kultur, die unsere täglichen Entscheidungen bestimmt.

Restore-first

Bei einem Vorfall hat die Wiederherstellung des Betriebs Vorrang — nicht die Ursachenanalyse. Die Untersuchung beginnt erst, wenn der Service wieder läuft.

Keine Geheimnisse

Wenn etwas schiefläuft, erfährt der Kunde das von uns — nicht aus seinem eigenen Monitoring. Proaktive Benachrichtigungen gehören zu unserem Standard.

Blameless Postmortem

Nach jedem bedeutsamen Vorfall — Analyse ohne Schuldzuweisungen. Ziel sind systemische Verbesserungen, keine Sanktionen. Das Ergebnis: konkrete Maßnahmen, um eine Wiederholung zu verhindern.

Automatisiertes Monitoring

Alles, was sich automatisieren lässt, wird automatisiert. Unsere Ingenieure treffen Entscheidungen — statt manuell Grafiken zu prüfen.

Klare Verantwortlichkeiten

Wir übernehmen die Verantwortung für Code, Deployment-Prozesse und Monitoring. Hosting-Infrastruktur, Zugänge und Verträge mit Drittanbietern liegen im Verantwortungsbereich des Kunden. Diese klare Abgrenzung ermöglicht realistische SLO.

Vierteljährliche Überprüfung

Schwellenwerte und SLO werden vierteljährlich und nach jedem bedeutsamen Vorfall überprüft.

Grenzen und Ausnahmen

Verantwortungsbereiche und Ausnahmen

Eine klare Abgrenzung der Verantwortungsbereiche macht SLI aussagekräftig und interpretierbar. Ohne sie können Metriken und Zielwerte leicht in die Irre führen.

Unser Verantwortungsbereich

Anwendungscode, Deployment und CI/CD-Pipelines

Einrichtung, Pflege und Weiterentwicklung des Monitoring-Systems

Reaktion auf Vorfälle, Root-Cause-Analyse und Korrekturmaßnahmen

Kontrolle der Core Web Vitals und Optimierungsempfehlungen

Verwaltung des Error Budgets und SLI-Berichterstattung

Verantwortungsbereich des Kunden

Hosting-Infrastruktur und DNS, sofern nicht an uns übergeben

Drittanbieter-Services und APIs: Zahlungssysteme, CRM, E-Mail-Provider und andere externe Abhängigkeiten

Verwaltung von Zugängen, Benutzerkonten und internen Sicherheitsrichtlinien

Content, Einstellungen und Nutzeraktionen im Admin-Bereich

Rechtzeitige Bereitstellung von Daten und Zugängen für die Diagnose

Was SLI in der Regel nicht abdecken

Höhere Gewalt

Größere Providerausfälle, Rechenzentrumsausfälle, Naturereignisse.

Geplante Wartung

Im Voraus vereinbarte Wartungsfenster.

Nicht abgestimmte Änderungen

Änderungen durch den Kunden oder Dritte ohne Beteiligung unseres Teams.

Externe Abhängigkeiten außerhalb unserer Kontrolle

Externe APIs, CDN, E-Mail- und Zahlungsdienste.

Die konkreten Verantwortungsbereiche und Ausnahmen werden im Vertrag festgelegt und können je nach Projektarchitektur und gewähltem Support-Plan variieren.

Häufig gestellte Fragen

Was ist der Unterschied zwischen SLI und SLA?

SLA beschreibt Prozesse und formelle Verpflichtungen gegenüber dem Kunden. SLI sind konkrete messbare Kennzahlen: Verfügbarkeit, Geschwindigkeit, Fehler, Stabilität. SLI bilden die technische Grundlage für das SLA.

Kann ich die Metriken meines Projekts in Echtzeit sehen?

Ja. Die Art des Zugangs richtet sich nach dem Support-Plan und der Projektkonfiguration. Für einen Teil der Projekte stehen regelmäßige Berichte zur Verfügung, bei Enterprise-Support separate Dashboards und erweiterte Metrikvisualisierung.

Was passiert, wenn ein SLO verletzt wird?

Wir dokumentieren die Verletzung, informieren den Kunden, führen eine Vorfallanalyse durch und legen Korrekturmaßnahmen fest. Wenn für das Projekt ein SLA mit Service-Credits oder anderen Verpflichtungen gilt, richten sich die weiteren Schritte nach den Bedingungen dieser Vereinbarung.

Wie werden die SLO-Zielwerte für mein Projekt festgelegt?

Nach dem Onboarding bewerten wir Architektur, Infrastruktur, Vorfallhistorie, Lastprofil und die Kritikalität der Geschäftsprozesse. Die Werte auf dieser Seite zeigen unseren typischen Ansatz und stellen keine automatische Garantie für jedes Projekt dar.

Garantieren Sie eine Verfügbarkeit von 100 %?

Nein. Null Ausfallzeit ist in realen Systemen nicht erreichbar. Statt unrealistischer Versprechen arbeiten wir mit messbaren Zielen, tracken das Error Budget und managen Risiken datenbasiert.

Welche Monitoring-Tools setzen Sie ein?

Der Basis-Stack hängt vom Projekt ab, umfasst aber in der Regel UptimeRobot für externe Verfügbarkeitschecks, Grafana und Prometheus für Metriken und Visualisierung, Laravel Nightwatch oder New Relic für APM sowie Lighthouse CI für Performance-Kontrolle und Core Web Vitals.

Was ist ein Error Budget und wozu braucht man es?

Das Error Budget zeigt, wie viel Ausfallzeit oder Fehler im Rahmen des gewählten SLO zulässig sind. Es hilft, Zuverlässigkeit und Entwicklungsgeschwindigkeit in Balance zu halten: Solange das Budget nicht aufgebraucht ist, kann das Produkt zügig weiterentwickelt werden; ist es erschöpft, verschiebt sich der Fokus auf Stabilisierung.

Terminologie

Glossar

APM (Application Performance Monitoring) — eine Kategorie von Tools, die Anwendungscode instrumentieren, um Anfragen zu verfolgen, langsame Abfragen zu erkennen, Exceptions anzuzeigen und die Ressourcennutzung innerhalb der Anwendung zu analysieren. Beispiele: Laravel Nightwatch, New Relic.

Blameless Postmortem — eine strukturierte, schuldfreie Analyse nach einem bedeutsamen Vorfall. Fokussiert auf Zeitablauf, Ursache, beitragende Faktoren und konkrete Maßnahmen zur Vermeidung von Wiederholungen.

CDN (Content Delivery Network) — ein verteiltes Netzwerk von Servern, das statische Ressourcen vom geografisch nächstgelegenen Knoten an Nutzer ausliefert und so die Latenz reduziert.

CI/CD (Continuous Integration / Continuous Delivery) — eine automatisierte Pipeline, die Code bei jedem Commit erstellt, testet und deployt. CI erkennt Regressionen frühzeitig; CD überträgt validierte Änderungen zuverlässig und reproduzierbar in die Produktion.

CLS (Cumulative Layout Shift) — eine Core Web Vitals-Metrik, die unerwartete visuelle Bewegungen von Seitenelementen während des Ladens quantifiziert. Schwelle „gut": ≤ 0,1.

Core Web Vitals — eine von Google definierte Gruppe nutzerzentrierter Metriken — LCP, INP und CLS — die als Suchranking-Signal und Indikator für die wahrgenommene Seitenqualität dienen.

CPU (Central Processing Unit) — die primäre Recheneinheit eines Servers. Hohe CPU-Last ist eines der wichtigsten Signale für Performance-Verschlechterungen.

Deployment Success Rate — der Prozentsatz der Deployments, die ohne Servicebeeinträchtigung oder Ausfall abgeschlossen werden. Richtwert: ≥ 99 %.

DNS (Domain Name System) — das System, das lesbare Domainnamen in Server-IP-Adressen auflöst. DNS-Ausfälle machen eine Website unerreichbar, auch wenn der Server selbst ordnungsgemäß funktioniert.

Error Budget — das zulässige Maß an Servicebeeinträchtigungen innerhalb eines Messzeitraums (typischerweise monatlich oder quartalsweise). Wenn das Budget aufgebraucht ist, werden neue Features eingefroren und der Fokus auf die Wiederherstellung der Zuverlässigkeit gelegt.

Error Rate (Fehlerquote) — der Prozentsatz der Anfragen, die mit einem serverseitigen Fehler enden (typischerweise HTTP-5xx-Antworten). Richtwert: < 0,1 %.

First Response Time — die Zeit von der Ticketerstellung bis zur ersten inhaltlichen Antwort des Support-Teams. Richtwert für S1: ≤ 20 Minuten während der Geschäftszeiten.

INP (Interaction to Next Paint) — eine Core Web Vitals-Metrik zur Messung der Seitenreaktionsfähigkeit: die Verzögerung zwischen einer Nutzerinteraktion und der nächsten visuellen Aktualisierung. Schwelle „gut": ≤ 200 ms.

Latency (Latenz) — die Zeit zwischen dem Absenden einer Anfrage durch den Client und dem Empfang des ersten Antwort-Bytes. Wird typischerweise als Perzentile (P50, P95, P99) statt als Durchschnittswert angegeben.

LCP (Largest Contentful Paint) — eine Core Web Vitals-Metrik, die angibt, wann das größte sichtbare Inhaltselement vollständig gerendert ist. Schwelle „gut": ≤ 2,5 s.

P50 / P95 / P99 (Perzentile) — statistische Maßzahlen für die Latenzverteilung. P95 bedeutet: 95 % der Anfragen wurden innerhalb dieser Zeit abgeschlossen. Perzentile zeigen die Tail-Latenz, die Durchschnittswerte verbergen, und spiegeln die Erfahrung der langsamsten echten Nutzer wider.

QBR (Quarterly Business Review) — ein formelles vierteljährliches Meeting zwischen Dienstleister und Kunde zur Überprüfung von Performance-Daten, SLI/SLO-Ergebnissen, Vorfällen und Plänen für das kommende Quartal.

RAM (Random Access Memory) — der Arbeitsspeicher eines Servers. Hoher RAM-Verbrauch (über 85 %) kann zu Anwendungsverlangsamungen oder Crash-Loops führen.

RCA (Root Cause Analysis) — eine systematische Untersuchung zur Ermittlung der eigentlichen Ursache eines Vorfalls, nicht nur seiner Symptome.

RED (Rate, Errors, Duration) — eine Monitoring-Methodik, die sich auf drei anfragebezogene Signale konzentriert, die am empfindlichsten auf nutzerseitige Verschlechterungen reagieren. Rate = Anfragedurchsatz, Errors = fehlgeschlagene Anfragen, Duration = Latenz.

Restore-first — ein Prinzip der Vorfallbehandlung: Zuerst wird die Dienstverfügbarkeit wiederhergestellt, erst danach die Ursache untersucht.

Saturation (Auslastung) — der Grad, in dem eine Ressource (CPU, RAM, Festplatte, Netzwerk) an ihre Kapazitätsgrenze gelangt. Hohe Auslastung prognostiziert künftige Latenzzunahmen und Ausfälle, bevor explizite Fehler auftreten.

SEO (Search Engine Optimization) — Maßnahmen zur Verbesserung der Sichtbarkeit einer Website in Suchmaschinen-Ergebnissen. Core Web Vitals beeinflussen SEO-Rankings direkt.

SLA (Service Level Agreement) — eine formelle vertragliche Verpflichtung zwischen Dienstleister und Kunde, die Garantien, Verantwortungsmechanismen und Abhilfemaßnahmen bei Nichteinhaltung festlegt.

SLI (Service Level Indicator) — eine quantitative Kennzahl, die eine bestimmte Dimension der Servicequalität aus Nutzersicht erfasst (z. B. Uptime in %, P95-Latenz, Fehlerquote). Die Messungsebene des Qualitätsmanagements.

SLO (Service Level Objective) — ein internes Ziel für einen SLI (z. B. „P95-API-Latenz < 300 ms"). SLOs definieren die Qualitätslatte, an der das Team gemessen wird, und bilden die Grundlage für SLA-Verpflichtungen.

SOW (Statement of Work) — ein Vertragsdokument, das die konkreten Liefergegenstände, Zeitpläne und den Umfang der Arbeit für ein Projekt oder einen Support-Einsatz festlegt, einschließlich konkreter SLO-Zielwerte.

SQL (Structured Query Language) — die Standardsprache für Abfragen und Manipulation relationaler Datenbanken. Langsame SQL-Abfragen sind eine häufige Ursache für Performance-Verschlechterungen in Anwendungen.

SSL (Secure Sockets Layer) — das Vorgängerprotokoll zu TLS, weitgehend als Synonym für HTTPS-zertifikatbasierte Verschlüsselung verwendet. Die Überwachung des SSL-Ablaufdatums verhindert zertifikatbedingte Ausfälle (Warnschwelle: ≥ 30 Tage vor Ablauf).

Throughput (Durchsatz) — die Anzahl der Anfragen, die ein Service pro Zeiteinheit verarbeitet (z. B. Anfragen pro Sekunde). Eines der drei RED-Signale.

TTMR (Time to Mitigation / Restore) — die Zeit vom Erkennen des Vorfalls bis zur vollständigen Wiederherstellung des Dienstes. Richtwert: ≤ 4 Std. für S1, ≤ 8 Std. für S2.

Uptime (Verfügbarkeit) — der Anteil der Zeit, in der ein Service erreichbar ist und korrekt antwortet, ausgedrückt in Prozent. Berechnet als erfolgreiche synthetische Checks geteilt durch Gesamtchecks. Richtwert: ≥ 99,5 %.

USE (Utilization, Saturation, Errors) — eine Monitoring-Methodik für Infrastrukturressourcen. Ergänzt RED, indem sie identifiziert, ob Hardware-Engpässe — nicht die Anwendungslogik — der Flaschenhals sind.