SLA Hosting wirkt oft klar, doch ein SLA Bruch passiert schneller, als es die Uptime Garantie verspricht. Ich zeige, was Verfügbarkeit Webhosting wirklich bedeutet, wie du Reaktionszeit SLA und Lösungszeit bewertest, wie Incident Management greift und welche Bonus-Malus-Regeln dich praktisch absichern.
Zentrale Punkte
Die folgenden Punkte setze ich im Artikel um und zeige sie mit Beispielen und Taktiken.
- Definition eines Hosting-SLA: Inhalt, Messpunkte, Ausnahmen
- Ursachen für SLA-Verstöße: Technik, Menschen, Dritte
- Belege durch Monitoring und saubere Messmethoden
- Vertrag mit Bonus-Malus, Haftung und Eskalation
- Resilienz durch Architektur, Automation und Playbooks
Was ein SLA im Hosting wirklich regelt
Ein SLA legt fest, welche Leistungen ein Provider liefert, wie Ausfälle gemessen werden und welche Kompensation greift. Ich achte auf klare Definitionen zu Uptime, Reaktionszeit, Lösungszeit, Wartungsfenstern und Security-Standards. Messpunkte spielen eine zentrale Rolle: Erfolgt die Messung auf Server-, Netzwerk- oder App-Ebene, und in welcher Zeitzone? Ohne eindeutige Formulierungen fehlt dir später der Nachweis, dass ein Verstoß vorliegt. Ich fordere deshalb Reporting-, Audit- und Dashboard-Zugriff, damit ich Kennzahlen jederzeit prüfen kann.
Häufige Ursachen für SLA-Brüche
Ich sehe vier Haupttreiber für Verstöße: Technik, Menschen, Angriffe und Kapazität. Hardwaredefekte, Firmware-Bugs oder Routing-Probleme führen schnell zu Downtime oder starker Degradation. Fehlkonfigurationen, unsaubere Deployments oder mangelhafte Changes sorgen genauso zuverlässig für Ärger. Externe DDoS- oder Malware-Vorfälle können Services blockieren, häufig mit Haftungsausschlüssen im Vertrag. Unerwartete Lastspitzen durch Kampagnen oder Peaks überfordern Ressourcen, wenn Skalierung und Limits nicht sauber eingestellt sind.
SLA, SLO und OLA: Begriffe sauber trennen
Ich unterscheide sauber zwischen SLA (vertragliche Zusicherung gegenüber Kundinnen und Kunden), SLO (internes Serviceziel, meist strenger als das SLA) und OLA (Vereinbarung zwischen internen Teams oder mit Subdienstleistern). In der Praxis formuliere ich SLOs als belastbare Zielwerte, aus denen ein Fehlerbudget abgeleitet wird. Wird das Fehlerbudget eines Zeitraums aufgebraucht, greife ich zu Gegenmaßnahmen: Release-Freeze, Fokus auf Stabilisierung und gezielte Risiko-Reduktion. OLAs sorgen dafür, dass Netzwerk, Datenbank, CDN oder DNS ihre Beiträge liefern, damit das End-to-End-SLA überhaupt erreichbar ist. Diese Trennung verhindert, dass ich im Ernstfall Schuldfragen kläre, statt das Problem zu lösen.
Live-Beispiele aus Projekten
Ein großer Shop hatte eine 99,99%-Uptime-Garantie, doch ein Carrier-Routingfehler kappte den Zugang in mehreren Regionen. Der Vertrag wertete nur vollständige Ausfälle als Verstoß, regionale Degradation zählte nicht – wirtschaftlich schmerzhaft, formal kein Bruch. Eine Webagentur vereinbarte 30 Minuten Reaktionszeit und vier Stunden Lösungszeit für P1. Wegen falsch konfigurierter Alarme sah der Provider den Incident erst nach Stunden und zahlte eine kleine Gutschrift, während Umsatz und Image bei der Agentur blieben. Ein KMU nutzte ein zweites Rechenzentrum; beim Ausfall lief die Notfallumgebung, aber deutlich langsamer und die geplante Wartung wurde vom Uptime-Budget ausgenommen – rechtlich sauber, für Kundinnen und Kunden trotzdem frustrierend.
Wartungsfenster und Change-Policy ohne Hintertüren
Ich halte Wartungsfenster schlank und klar: geplante Zeiträume, Vorlauf zur Ankündigung, Kommunikationskanäle und messbare Auswirkungen. Für „Emergency Maintenance“ definiere ich enge Kriterien und ein transparentes Freigaboverfahren. Blackout-Perioden (z. B. Sale-Phasen) nehme ich explizit von Änderungen aus. Ich verlange, dass Wartungen auf ein Minimum an Downtime und Degradation optimiert werden (z. B. Rolling Changes, Blue-Green), und dass sie in meiner Geschäftszeitzone kommuniziert werden – nicht nur in der Zone des Rechenzentrums.
- Vorlaufzeiten: mind. 7 Tage für reguläre, 24 Stunden für dringliche Changes
- Maximale Dauer pro Wartung und pro Monat begrenzen
- Impact-Klassen: No-Impact, Degradation, Downtime – jeweils dokumentiert
- Rollback-Plan und „No-Go“-Zeiträume vertraglich fixieren
Was ein SLA-Bruch kostet und welche Rechte du hast
Eine Gutschrift deckt selten den echten Schaden. Oft liegen Service-Credits bei 5–25 % der Monatsgebühr, während Umsatzverluste und Reputationsschäden weit darüber liegen. Ich vereinbare Sonderkündigungsrechte bei wiederholten oder groben Verstößen. Vertragsstrafen können sinnvoll sein, müssen aber zur Höhe der Geschäftsrisiken passen. Zusätzlich nutze ich QBRs mit Fehleranalysen und Maßnahmenkatalogen, damit sich Probleme nicht wiederholen.
Transparenz: Statusseite, Kommunikationspflichten, RCA-Fristen
Ich definiere, wie und wann informiert wird: initiale Störungsmeldung, Aktualisierungsfrequenz und Abschlussbericht. Eine Statusseite oder dedizierte Incident-Kommunikation erspart mir die Suche über Support-Tickets. Ich verpflichte den Provider zu einer Root-Cause-Analyse (RCA) mit konkreten Maßnahmen und Terminen.
- Erstmeldung binnen 15–30 Minuten nach Erkennung, Updates alle 30–60 Minuten
- Klare Timeline: Erkennung, Eskalation, Mitigation, Recovery, Close
- RCA binnen fünf Werktagen, inklusive Ursachenbaum und Präventionsplan
- Benennung eines Owners pro Maßnahme mit Fälligkeitsdatum
Messbarkeit und Nachweis: So belege ich Verstöße
Ich vertraue nicht allein auf Provider-Metriken, sondern setze eigenes Monitoring auf. Synthetische Checks aus mehreren Regionen und Real-User-Monitoring liefern mir Belege, falls einzelne Routen oder Regionen ausfallen. Ich dokumentiere Zeitzonen, Zeitquellen und Messpunkte und gleiche sie mit Vertragsdefinitionen ab. Jede Abweichung halte ich mit Screenshots, Logs und Incident-Timelines fest. Für die Tool-Auswahl hilft mir dieser Überblick: Uptime-Monitoring-Tools.
Messmethoden präzisieren: Brownouts statt Schwarz/Weiß
Ich bewerte nicht nur „an/aus“, sondern auch Brownouts – spürbare Degradationen ohne vollständigen Ausfall. Dazu nutze ich Latenzschwellen (z. B. P95 < 300 ms) und Apdex-ähnliche Werte, die Nutzerzufriedenheit erfassen. Ich trenne Netz-, Server- und Applikationsebene, um Fehlzuordnungen zu vermeiden. Synthetische Checks kalibriere ich mit Timeouts, Retries und einem Mindestanteil fehlerfreier Proben, damit einzelne Paketverluste nicht als Ausfall zählen. RUM-Daten gleiche ich mit den synthetischen Messungen ab, um regionale Effekte und CDN-Edge-Probleme zu erkennen. Wichtig: Zeitquellen synchronisieren (NTP), Zeitzonen festlegen und Messpunkte im Vertrag benennen.
Kennzahlen im Vergleich: Uptime, Reaktionszeit, Lösungszeit
Ich vereinbare Kennzahlen, die zu Risiko und Geschäft passen. Dazu gehören Uptime, Reaktions- und Lösungszeit je Priorität sowie Performance-Ziele wie P95-Latenz. Außerdem fordere ich Time-to-Detect und Time-to-Recover, damit die Entstörung messbar bleibt. Werte ohne Messmethode nützen wenig, deshalb definiere ich Messpunkte und Toleranzen. Die folgende Tabelle zeigt typische Zielwerte und ihre praktische Bedeutung.
| Kennzahl | Typischer Zielwert | Praktischer Effekt | Orientierung Downtime/Monat |
|---|---|---|---|
| Uptime-Garantie | 99,90–99,99 % | Schützt Umsatz und Reputation | 99,9 % ≈ 43,8 Min; 99,99 % ≈ 4,4 Min |
| Reaktionszeit P0/P1 | 15–30 Min | Schneller Start der Entstörung | Verkürzt Mean Time to Acknowledge |
| Lösungszeit P0 | 1–4 Std | Begrenzt geschäftskritische Ausfälle | Minimiert MTTR |
| Performance P95 | < 300 ms | Bessere UX, höhere Conversion | Erfasst Latenz statt nur Uptime |
| Sicherheit | 2FA, TLS, Backups, Restore-Tests | Reduziert Angriffsfolgen | Schnellere Recovery |
Fehlerbudgets und Priorisierung im Alltag
Ich übersetze Zielwerte in ein monatliches Fehlerbudget. Beispiel: Bei 99,95 % Uptime stehen mir rund 21,9 Minuten Ausfall pro Monat zu. Ist die Hälfte des Budgets verbraucht, priorisiere ich Stabilisierung über Feature-Entwicklung. Ich verankere diese Logik vertraglich als Governance: Wenn Fehlerbudgets gerissen werden, greift ein abgestimmter Maßnahmenplan mit zusätzlichen Reviews, verstärkter On-Call-Besetzung und gegebenenfalls einem Change-Freeze. So werden SLOs nicht zu Deko-Kennzahlen, sondern steuern Entwicklung und Betrieb.
Architektur-Resilienz gegen SLA-Risiken
Ich plane Infrastruktur so, dass ein Fehler nicht gleich das Geschäft stoppt. Multi-AZ- oder Multi-Region-Setups, aktive/aktive Designs und Autoscaling puffern Ausfälle und Lastspitzen. Caching, CDN und Circuit Breaker halten Anfragen fließend, wenn Subsysteme wackeln. Readiness- und Liveness-Probes, Blue-Green- und Canary-Deployments senken Deploy-Risiken deutlich. Notfall-Runbooks plus regelmäßige Recovery-Tests zeigen, ob das Konzept im Ernstfall trägt.
Testkultur: Game Days, Chaos-Engineering und Restore-Drills
Ich übe Störungen unter kontrollierten Bedingungen: Game Days simulieren realistische Ausfälle, von Datenbank-Locks über DNS-Fehler bis zu Netzwerkjitter. Chaos-Experimente decken versteckte Abhängigkeiten auf, bevor sie im Betrieb zuschlagen. Restore-Drills mit harten Zielen (RTO, RPO) zeigen, ob Backups wirklich taugen. Ich messe, wie lange Detection, Eskalation und Recovery dauern – und passe Runbooks, Alarme und Limits danach an. Diese Tests machen SLA-Ziele nicht nur erreichbar, sondern auch überprüfbar.
Klare Haftungsabgrenzung und Bonus-Malus fair verhandeln
Ich trenne Verantwortung sauber: Was liegt beim Provider, was bei mir, was bei Dritten wie CDN oder DNS? Fälle höherer Gewalt definiere ich eng und zeitlich begrenzt. Für Übererfüllung verhandle ich Credits oder Upgrades, für Unterschreitungen spürbare Sanktionen mit automatischer Gutschrift. Dabei halte ich Fristen schlank, damit ich nicht erst nach Antrag Geld sehe. Für die Vertragsarbeit nutze ich Best Practices wie in der SLA-Optimierung im Hosting.
Beispielklauseln, die sich bewährt haben
- Automatische Gutschrift bei Verstoß, ohne Antrag, innerhalb von 30 Tagen
- Degradationen über Schwelle X (z. B. P95 > 800 ms) zählen anteilig als Ausfall
- RCA-Pflicht mit Maßnahmen und Deadlines; Nichterfüllung erhöht den Credit
- Credits kumulieren für mehrere Verstöße im Monat; keine „einmalig pro Monat“-Kappe
- Keine Anrechnung geplanter Wartung außerhalb genehmigter Fenster
- Sonderkündigungsrecht bei wiederholten P0-Verstößen oder bei Nichteinhaltung der Lösungszeit
- „Credit ≠ Haftungsfreistellung“: Gutschriften schließen weitere Ansprüche nicht aus
Incident Management im Alltag: Playbooks und Eskalation
Ich definiere klare Prioritäten P0–P3 und zugehörige Reaktions- und Lösungszeiten. Ein On-Call-Plan, Kommunikationskanäle und Eskalationsstufen sorgen dafür, dass niemand improvisieren muss. Runbooks führen Schritt für Schritt durch Diagnose, Rollback und Recovery. Nach jedem Vorfall halte ich eine Postmortem-Analyse fest und setze Maßnahmen mit Termin und Owner. QBRs helfen, Trends zu erkennen und Fehlerbudgets sinnvoll einzusetzen.
Eskalationsmatrix und RACI
Ich lege fest, wer informiert, wer entscheidet und wer handelt. Eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) verhindert Leerlauf und Doppelarbeit. Die Eskalation folgt festen Zeiten: z. B. P0 sofort an On-Call, nach 15 Minuten an Teamlead, nach 30 Minuten an Management. Ich benenne Ersatzkanäle (Telefon, Messenger), falls E-Mail-Systeme selbst betroffen sind. So bleibt die Reaktionszeit nicht am Kalender, sondern an der tatsächlichen Erreichbarkeit messbar.
DDoS & externe Störungen: Absicherung ohne Grauzonen
Ich nehme Dritte explizit in den Vertrag auf: CDN, DNS, Payment und E-Mail-Gateways. Für DDoS-Angriffe vereinbare ich Schutzmaßnahmen, Schwellenwerte und Reaktionszeiten, statt pauschaler Ausschlüsse. Falls ein Fremdanbieter ausfällt, kläre ich, wie der Hauptprovider koordiniert und berichtet. Außerdem teste ich Failover-Routen und Rate Limits, um Angriffslast zu dämpfen. Eine hilfreiche Übersicht liefert mir der DDoS-Schutz fürs Webhosting.
Drittanbieter-Management und Kaskadenfehler
Ich verlange, dass der Hauptprovider die Koordination bei Kettenvorfällen übernimmt: ein Verantwortlicher, ein Ticket, ein gemeinsamer Status. Ich kläre, wie externe SLAs in mein End-to-End-Ziel einfließen, und welche Redundanzen sinnvoll sind (z. B. Multi-DNS, sekundärer Payment-Provider). Ich halte Failover-Tests schriftlich fest: Auslösekriterien, Rückkehr in den Normalbetrieb und maximale Dauer im Degradationsmodus. So werden Kaskadenfehler schneller entkoppelt.
Vertrags-Checklist vor Unterschrift
Ich prüfe die Messmethode für Uptime und Performance und sichere mir Prüfrechte zu. Ausnahmen wie Wartungen, höhere Gewalt und Fremdanbieter grenze ich klar ein und dokumentiere sie. Credits sollen automatisch fließen und nicht an enge Antragsfristen gebunden sein. Reaktions- und Lösungszeiten differenziere ich nach Priorität und Uhrzeit, inklusive On-Call-Fenster. Backups, RTO, RPO und Wiederherstellungstests verhandle ich genauso verbindlich wie die Uptime.
Kurz zusammengefasst
Ich verlasse mich nicht blind auf eine Uptime-Zahl im Vertrag. Klare Definitionen, eigene Messung, faire Bonus-Malus-Regeln und eine belastbare Architektur senken das Risiko spürbar. Reaktionszeit, Lösungszeit und Performance-KPIs wie P95-Latenz mache ich messbar und nachweisbar. Mit Incident-Playbooks, Eskalation und regelmäßigen Reviews halte ich den Betrieb agil, aber kontrolliert. So belege ich SLA-Verstöße, sichere Kompensation und reduziere die Ausfallzeit nachhaltig.
