Verfügbarkeit und SLAs

„Die Anwendung muss immer erreichbar sein“ – diesen Satz hört man in fast jedem Projekt. Doch hundert Prozent Verfügbarkeit gibt es nicht. Server fallen aus, Rechenzentren verlieren Strom, Updates gehen schief, externe Dienste haben Störungen. Die entscheidende Frage lautet deshalb nicht, ob ein System ausfällt, sondern wie oft, wie lange und mit welchen Folgen. Diese Lektion zeigt, wie man Verfügbarkeit misst, sinnvolle Ziele setzt und daraus Entscheidungen für den Entwurf ableitet.

1. Verfügbarkeit in Zahlen

Prozentzahlen wirken abstrakt, bis man sie in Zeit übersetzt. Probieren Sie es aus:

Jede zusätzliche Neun verringert die erlaubte Ausfallzeit auf ein Zehntel – und erhöht den Aufwand meist deutlich. Zwischen 99 und 99,9 Prozent liegen oft nur ein zweiter Server und ordentliche Überwachung. Zwischen 99,9 und 99,99 Prozent liegen automatische Umschaltung, mehrere Rechenzentren, gründlich getestete Deployments und ein Bereitschaftsdienst rund um die Uhr. Deshalb sollte das Ziel zum Geschäft passen: Ein Blog verträgt einen Ausfall von einer Stunde, ein Zahlungsdienst nicht.

2. SLI, SLO und SLA

Drei Begriffe tauchen immer wieder auf und werden oft verwechselt. Klicken Sie sich durch:

Gute Messgrößen beschreiben die Erfahrung der Nutzer, nicht den Zustand eines Servers. „Der Server läuft“ sagt wenig, wenn die Datenbank hängt und alle Anfragen scheitern. „99,9 Prozent der Buchungsanfragen sind erfolgreich und schneller als eine Sekunde“ beschreibt dagegen genau, was zählt. Das SLO liegt strenger als das SLA, damit das Team reagieren kann, bevor vertragliche Folgen entstehen.

3. Ketten und Parallelität

Ein System besteht aus vielen Teilen. Hängt eine Anfrage von mehreren Komponenten nacheinander ab, multiplizieren sich ihre Verfügbarkeiten. Drei Komponenten mit je 99,9 Prozent ergeben zusammen nur 99,7 Prozent. Sind Komponenten dagegen parallel ausgelegt, sodass eine die andere ersetzen kann, steigt die Verfügbarkeit stark. Spielen Sie mit dem Rechner:

Daraus folgen zwei Lehren für den Entwurf. Erstens: Jede zusätzliche Abhängigkeit im kritischen Pfad kostet Verfügbarkeit. Wenn eine Buchung ohne Empfehlungsdienst funktionieren kann, sollte sie das auch. Zweitens: Externe Dienste, deren Verfügbarkeit man nicht beeinflussen kann, setzen oft die Obergrenze. Wer ihnen mit Zeitlimits, Fallbacks und Warteschlangen begegnet, entkoppelt die eigene Verfügbarkeit teilweise davon.

4. Fehlerbudgets

Ein SLO von 99,9 Prozent bedeutet umgekehrt: 0,1 Prozent darf schiefgehen. Das ist das Fehlerbudget, bei 30 Tagen etwa 43 Minuten. Dieses Budget ist ein nützliches Steuerungsinstrument. Solange es nicht aufgebraucht ist, darf das Team zügig neue Funktionen ausrollen und Risiken eingehen. Ist es aufgebraucht, hat Stabilität Vorrang: weniger Deployments, mehr Tests, Ursachen beheben. So wird der ewige Streit zwischen „schneller liefern“ und „stabiler betreiben“ zu einer messbaren, gemeinsamen Entscheidung.

5. Geplante und ungeplante Ausfälle

Nicht jeder Ausfall ist ein Unfall. Wartungsfenster, Datenbank-Upgrades und Umzüge sind geplante Unterbrechungen. Moderne Systeme versuchen, auch diese zu vermeiden: durch Rolling Updates, Replikate, die während der Wartung übernehmen, und Datenbankänderungen, die ohne Sperren auskommen. Wo das nicht möglich ist, werden Wartungsfenster angekündigt, in ruhige Zeiten gelegt und im SLA gesondert geregelt. Ungeplante Ausfälle wiederum werden nach Dauer und Wirkung eingeordnet: Betrifft ein Fehler alle Nutzer oder nur eine Funktion, dauert er Minuten oder Stunden?

6. Ein Beispiel

Ein Fahrradladen mit Werkstatt bietet Online-Terminbuchung an. Gemeinsam mit dem Inhaber wird festgelegt: 99,9 Prozent der Buchungsanfragen sollen innerhalb einer Sekunde erfolgreich sein, gemessen über 30 Tage. Das erlaubt rund 43 Minuten Störung im Monat. Die Analyse zeigt, dass der größte Risikofaktor der externe Kalenderdienst ist. Der Entwurf sieht deshalb vor, Buchungen zuerst in der eigenen Datenbank zu speichern und die Übertragung in den Kalender über eine Warteschlange nachzuholen. Fällt der Kalenderdienst aus, können Kunden weiter buchen. Zwei Anwendungsinstanzen und ein Datenbankreplikat mit automatischer Umschaltung sichern den Rest ab. Ein Dashboard zeigt den Verbrauch des Fehlerbudgets, sodass der Inhaber jederzeit sieht, wie stabil sein Buchungssystem läuft.

Das Beispiel zeigt, wie Verfügbarkeit im Entwurf wirkt: nicht als abstrakte Zahl, sondern als Leitlinie für konkrete Entscheidungen. Welche Abhängigkeiten liegen im kritischen Pfad? Wo braucht es Redundanz? Welche Teile dürfen ausfallen, ohne dass das Kerngeschäft leidet? Die folgenden Lektionen zeigen die Werkzeuge dafür: Redundanz, Überwachung, sichere Deployments und den Blick auf die Kosten.

7. Verfügbarkeit richtig messen

Wie misst man Verfügbarkeit in der Praxis? Der einfachste Weg ist ein externer Prüfdienst, der jede Minute die Startseite aufruft und festhält, ob sie antwortet. Das ist besser als nichts, zeigt aber nur einen kleinen Ausschnitt. Aussagekräftiger ist die Messung anhand echter Anfragen: Der Load Balancer oder die Anwendung zählt, wie viele Anfragen erfolgreich und schnell genug waren und wie viele nicht. Daraus ergibt sich die Verfügbarkeit aus Sicht der Nutzer. Eine Seite, die zwar erreichbar ist, aber bei jeder zweiten Buchung einen Fehler meldet, ist für Nutzer eben nicht verfügbar – ein einfacher Erreichbarkeitstest würde das übersehen.

Wichtig ist auch, was nicht in die Messung gehört. Fehler, die Nutzer selbst verursachen, etwa eine falsch eingegebene Adresse oder ein ungültiges Formular, zählen nicht als Ausfall des Systems. Anfragen von automatisierten Programmen, die das System absichtlich überlasten, sollten gesondert betrachtet werden. Und der Zeitraum sollte fest vereinbart sein, meist ein gleitendes Fenster von 28 oder 30 Tagen. So entsteht eine Zahl, der alle Beteiligten vertrauen und an der sich Entscheidungen über Prioritäten, Investitionen und Deployments ausrichten lassen.

Schließlich lohnt sich ein Blick auf zwei weitere Kennzahlen, die eng mit der Verfügbarkeit zusammenhängen: die mittlere Zeit zwischen Ausfällen und die mittlere Zeit bis zur Wiederherstellung. Die erste beschreibt, wie oft etwas schiefgeht, die zweite, wie schnell man es behebt. In der Praxis lässt sich die zweite meist leichter verbessern – durch gute Überwachung, klare Zuständigkeiten, vorbereitete Anleitungen und die Möglichkeit, eine fehlerhafte Version in Sekunden zurückzurollen. Ein Team, das Fehler in fünf Minuten behebt, erreicht mit denselben Ausfällen eine viel höhere Verfügbarkeit als eines, das dafür zwei Stunden braucht.

Kurz zusammengefasst: Verfügbarkeit ist eine bewusste Entscheidung über Aufwand und Nutzen. Wer sie aus Sicht der Nutzer misst, ein passendes Ziel festlegt und das Fehlerbudget ernst nimmt, investiert genau dort, wo Ausfälle wirklich schmerzen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.