Was die „Neunen“ wirklich bedeuten
Verfügbarkeit (Availability, Uptime) ist der Zeitanteil, in dem ein Dienst funktioniert. Die zulässige Ausfallzeit lässt sich einfach berechnen: zulässige Ausfallzeit = (100 % − Verfügbarkeit) × Länge des Zeitraums. Auf dem Papier trennt 99,9 % und 99,99 % nur eine Neun, in der Praxis ist es ein Zehntel der zulässigen Ausfallzeit.
| Verfügbarkeit | Pro Tag | Pro Monat (30 Tage) | Pro Jahr (365 Tage) |
|---|---|---|---|
| 99 % | 14 min 24 s | 7 h 12 min | 3 d 15 h 36 min |
| 99,5 % | 7 min 12 s | 3 h 36 min | 1 d 19 h 48 min |
| 99,9 % | 1 min 26 s | 43 min 12 s | 8 h 45 min 36 s |
| 99,95 % | 43 s | 21 min 36 s | 4 h 22 min 48 s |
| 99,99 % | 8,6 s | 4 min 19 s | 52 min 34 s |
| 99,999 % | 0,86 s | 26 s | 5 min 15 s |
Die meisten SLAs messen die Verfügbarkeit je Kalendermonat, daher ist die zulässige Ausfallzeit im Februar kürzer als im Januar. Der Jahreswert eignet sich zum Vergleich, vertraglich zählt der Monatswert. Exakte Werte für jeden Prozentsatz und Zeitraum berechnen Sie mit dem SLA-Rechner auf dieser Seite.
SLA, SLO und SLI: drei Abkürzungen, drei verschiedene Dinge
Die Begriffe werden oft vermischt, beschreiben aber unterschiedliche Ebenen. Das Google-Buch „Site Reliability Engineering“ unterscheidet sie so:
- SLI (Service Level Indicator) ist ein Messwert, etwa der Anteil erfolgreicher Anfragen, der Anteil der Minuten, in denen der Dienst antwortet, oder die Antwortzeit.
- SLO (Service Level Objective) ist der Zielwert für diesen Indikator, zum Beispiel 99,95 % erfolgreiche Anfragen im Kalendermonat. Das ist ein internes Ziel des Teams.
- SLA (Service Level Agreement) ist der Vertrag mit dem Kunden, der das zugesagte Niveau und die Folgen bei Nichterreichen enthält, meist eine Gutschrift (Service Credit).
Ein internes SLO ist deshalb in der Regel strenger als der SLA gegenüber Kunden. Die Differenz zwischen Ziel und Ist-Zustand nennt SRE Fehlerbudget (Error Budget): Solange genug davon übrig ist, darf das Team Änderungen ausrollen, ist es aufgebraucht, hat Stabilität Vorrang.
Was ein SLA üblicherweise nicht mitzählt
Der Prozentwert im Vertrag ist nur die halbe Information. Die andere Hälfte sind die Definition der Ausfallzeit und die Liste der Ausschlüsse. Prüfen Sie beim Lesen eines SLA vor allem:
- Geplante Wartung. Viele Anbieter nehmen angekündigte Wartungsfenster von der Berechnung aus. Für Nutzer ist der Dienst trotzdem nicht erreichbar, prüfen Sie also Dauer, Häufigkeit und Lage der Fenster außerhalb Ihrer Geschäftszeiten.
- Die Definition der Ausfallzeit. Zählt nur ein Totalausfall oder auch ein Teilausfall? Bei der regionalen EC2-Verfügbarkeit zählt AWS einen Ausfall zum Beispiel erst, wenn alle Ihre laufenden Instanzen in zwei oder mehr Availability Zones gleichzeitig keine externe Konnektivität haben.
- Den Messzeitraum. Monatlich, quartalsweise oder jährlich. Bei einem Jahreszeitraum lässt sich ein einzelner langer Ausfall über das ganze Jahr „verdünnen“.
- Wer misst. Ob das Monitoring des Anbieters oder Ihr eigenes zählt und wie schnell Sie einen Ausfall melden müssen.
- Ausschlüsse. Höhere Gewalt, Fehler auf Kundenseite, Netzprobleme außerhalb des Anbieterbereichs und Vorschau-Dienste sind fast immer ausgenommen.
Service Credits sind keine Versicherung
Verfehlt der Anbieter das zugesagte Niveau, steht Ihnen meist eine Gutschrift zu, also eine Teilerstattung der Monatsgebühr für den betroffenen Dienst. Bei Amazon EC2 sind es zum Beispiel 10 %, wenn die monatliche Verfügbarkeit unter das zugesagte Niveau fällt, 30 % unter 99 % und 100 % unter 95 %, und der Antrag muss bis zum Ende des zweiten Abrechnungszeitraums nach dem Vorfall eingehen.
Ein Beispiel: Der Dienst kostet 2.000 EUR pro Monat, ein Ausfall dauert 4 Stunden in einem 30-Tage-Monat. Die Verfügbarkeit sinkt auf 99,44 %, und Sie erhalten 10 % Gutschrift, also 200 EUR. Kostet Sie eine Ausfallstunde 1.500 EUR, beträgt der Schaden 6.000 EUR. Die Gutschrift ist ein Anreiz für den Anbieter, keine Entschädigung für Sie. Bei der Anbieterwahl zählt daher eine Architektur, die Ausfälle verhindert, mehr als die Höhe der Gutschrift.
Verfügbarkeit des Gesamtsystems: Ketten und Redundanz
Ein Onlineshop braucht Internetanbindung, Applikationsserver und Datenbank. Fällt ein Glied aus, steht der Shop. Für Komponenten in Serie multiplizieren sich die Verfügbarkeiten: A = A₁ × A₂ × … × Aₖ. Drei Komponenten mit 99,9 %, 99,9 % und 99,95 % ergeben zusammen 99,75 %, also knapp 22 Stunden Ausfall pro Jahr statt 8 Stunden 46 Minuten. Jede zusätzliche Komponente senkt die Verfügbarkeit.
Redundanz wirkt umgekehrt. Für eine Gruppe aus n gleichen Instanzen, von denen eine genügt, gilt A = 1 − (1 − a)ⁿ. Zwei Server mit je 99 % erreichen zusammen 99,99 %, zwei mit je 99,9 % sogar 99,9999 %. Voraussetzung ist, dass sie unabhängig voneinander ausfallen. Gemeinsame Stromversorgung, derselbe Switch, dieselbe fehlerhafte Softwareversion oder ein fehlgeschlagenes automatisches Failover heben diese Annahme auf, deshalb liegt die reale Verfügbarkeit redundanter Systeme unter der berechneten.
Ein praktischer Tipp: Suchen Sie zuerst das schwächste Glied, denn seine Verbesserung bringt dem System am meisten. Oft ist das kein Server, sondern eine einzelne Internetleitung, eine einzelne Firewall oder eine Datenbank ohne Replikat.
SLA, RPO und RTO
Der SLA legt fest, wie viel Ausfallzeit in einem Zeitraum zulässig ist. Die RTO (Recovery Time Objective) bestimmt, wie schnell ein System nach einem einzelnen Vorfall wieder laufen muss, die RPO (Recovery Point Objective), wie viele Daten verloren gehen dürfen. Die Werte müssen zusammenpassen: Liegt die RTO für ein kritisches System bei 4 Stunden, verbraucht ein größerer Vorfall mehr, als ein monatlicher SLA von 99,9 % erlaubt (43 Minuten). Ein hoher SLA erfordert daher Replikation und schnelles Failover, nicht nur gute Backups.
Wie Sie RPO und RTO je Systemgruppe festlegen und prüfen, ob Ihre Wiederherstellung sie erreicht, erklärt der Ratgeber Backup, RPO und RTO.
Checkliste für den SLA-Vertrag
- Klären Sie mit der Geschäftsführung, was eine Ausfallstunde kostet und wie viel Ausfall pro Monat noch tragbar ist.
- Erfassen Sie die Abhängigkeiten des Dienstes und berechnen Sie die Verfügbarkeit der ganzen Kette, nicht nur einzelner Komponenten.
- Prüfen Sie die Definition der Ausfallzeit, den Messzeitraum und die Messmethode.
- Prüfen Sie Dauer, Häufigkeit und Zeitpunkt geplanter Wartungsfenster.
- Lesen Sie die Ausschlüsse sowie Verfahren und Frist für die Geltendmachung von Gutschriften.
- Verlangen Sie neben der Verfügbarkeit auch Reaktions- und Lösungszeiten des Supports nach Priorität.
- Stimmen Sie den SLA mit RPO, RTO und Ihrem Notfallwiederherstellungsplan ab.
- Richten Sie ein eigenes, unabhängiges Verfügbarkeits-Monitoring und ein monatliches Reporting ein.
Humanfrog betreibt Infrastruktur in TIER-III-Rechenzentren in Slowenien und plant redundante Architekturen und Monitoring. Wenn Sie die Ergebnisse des Rechners mit einem Experten prüfen oder einen bestehenden SLA durchsehen lassen möchten, schreiben Sie uns.
