Was bedeutet eine Verfügbarkeit von «99,9%» wirklich? Es klingt fast perfekt, aber es verbirgt eine überraschende Zahl: über 43 Minuten erlaubte Nichtverfügbarkeit jeden Monat. Und «99,99%»? Nur 4 Minuten. Dieser Rechner übersetzt ein Uptime-SLA-Ziel in das, was wirklich zählt: wie viel Ausfallzeit (Downtime) in einem gegebenen Zeitraum erlaubt ist, wie viel Sie bereits verbraucht haben (das Error Budget), die erreichte tatsächliche Verfügbarkeit und die wirtschaftlichen Kosten der Ausfallzeit. Geben Sie das SLA-Ziel (zum Beispiel 99,9%), den Zeitraum in Tagen, die beobachtete Ausfallzeit (mit etwaiger auszuschließender geplanter Wartung) und die Kosten pro Minute ein, und erhalten Sie das erlaubte Ausfallzeit-Budget, die tatsächliche Verfügbarkeit, den Prozentsatz des verbrauchten Error Budgets und die Kosten. Er ist parametrisch und währungsneutral: er funktioniert mit jedem Ziel, jedem Zeitraum und jeder Währung. Es ist ein Werkzeug für technische Teams, SRE, DevOps, Cloud-Service-Manager und jeden, der eine Verfügbarkeitszusage verstehen, verhandeln oder erfüllen muss — ein universelles Thema im modernen Systems Engineering.

Was ein Uptime-SLA ist

Ein SLA (Service Level Agreement) ist eine Vereinbarung über das Serviceniveau, und in der Welt der IT-Systeme ist der häufigste Parameter die Verfügbarkeit (Uptime, Availability): der Prozentsatz der Zeit, in der ein Dienst betriebsbereit und erreichbar ist, in einem gegebenen Zeitraum. Eine Verfügbarkeit von 99,9% bedeutet, dass der Dienst 99,9% der Zeit verfügbar ist; die restlichen 0,1% sind Ausfallzeit (Downtime), also Nichtverfügbarkeit. Uptime-SLAs werden fast immer in «Neunen» ausgedrückt: 99% («zwei Neunen»), 99,9% («drei Neunen»), 99,99% («vier Neunen»), 99,999% («fünf Neunen»). Mehr Neunen, höhere versprochene Verfügbarkeit — und schwieriger und teurer zu garantieren. Ein SLA kann intern sein (ein Ziel, das sich ein Team setzt) oder vertraglich (eine Zusage gegenüber Kunden, oft mit Vertragsstrafen bei Nichteinhaltung). Der entscheidende und oft unterschätzte Punkt ist, dass ein kleiner Unterschied im Prozentsatz einem riesigen Unterschied in der erlaubten Ausfallzeit entspricht. Diese Übersetzung zu verstehen — von Prozentsatz zu realen Minuten — ist der erste Schritt, um eine Verfügbarkeitszusage bewusst zu managen, zu verhandeln oder zu erfüllen.

Wie die erlaubte Ausfallzeit berechnet wird

Die Grundberechnung ist einfach. Die erlaubte Ausfallzeit (oder «Error Budget» in Minuten) ist der vom SLA erlaubte Anteil der Nichtverfügbarkeitszeit, angewendet auf die Dauer des Zeitraums. Zuerst wird der Zeitraum in Minuten umgerechnet: Tage × 24 × 60. Dann wird mit dem erlaubten Ausfallanteil multipliziert, also eins minus das Ziel geteilt durch 100. In Formel: D_max = (1 − s/100) × P, wobei D_max die erlaubte Ausfallzeit, s das SLA-Ziel in Prozent, P die Gesamtminuten des Zeitraums ist. Zum Beispiel, mit einem Ziel von 99,9% über 30 Tage: P = 43.200 Minuten, der erlaubte Anteil ist 0,1% = 0,001, also D_max = 43,2 Minuten. Der Rechner tut genau das und vergleicht dann die tatsächlich beobachtete Ausfallzeit mit diesem Budget, berechnet, wie viel Sie verbraucht haben (das verbrauchte Error Budget), die erreichte tatsächliche Verfügbarkeit und die wirtschaftlichen Kosten der Ausfallzeit. Sie können auch die geplante Wartung ausschließen, die viele SLAs nicht zählen. Es ist das Werkzeug, um vom abstrakten Ziel zu konkreten Zahlen überzugehen: wie viel Marge Sie haben, ob Sie die Zusage erfüllen, und was Sie die Nichtverfügbarkeit kostet.

Die Mathematik der «Neunen»

Das Herz der Verfügbarkeit ist eine gnadenlose Mathematik: jede zusätzliche «Neun»-Stelle reduziert die erlaubte Ausfallzeit um das Zehnfache. Die Tabelle zeigt, wie viel Ausfallzeit den häufigsten Zielen entspricht, auf monatlicher (30 Tage) und jährlicher Basis:

Die Progression ist beeindruckend. Der Wechsel von 99% auf 99,9% reduziert die jährliche Ausfallzeit von über 3 Tagen auf weniger als 9 Stunden; von 99,9% auf 99,99%, von fast 9 Stunden auf weniger als eine Stunde; von 99,99% auf 99,999%, auf etwas mehr als 5 Minuten pro Jahr. Aber es gibt eine Kehrseite: jede zusätzliche Neun kostet unverhältnismäßig. Der Wechsel von drei auf vier Neunen erfordert typischerweise Redundanz, Automatisierung, Failover-Systeme, fortgeschrittenes Monitoring, Bereitschaftsteams — Investitionen, die viel schneller wachsen als die Reduzierung der Ausfallzeit. Deshalb ist die Wahl des Ziels nicht «mehr Neunen ist immer besser»: es ist ein Gleichgewicht zwischen dem Wert höherer Verfügbarkeit und ihren steigenden Kosten. Der Rechner hilft Ihnen, diese Realität in konkreten Zahlen für Ihren spezifischen Zeitraum zu sehen.

Die Aufschlüsselung der Berechnung

Die Tabelle zeigt die Aufschlüsselung im Standardfall — SLA-Ziel 99,9%, Zeitraum 30 Tage, beobachtete Gesamtausfallzeit 25 Minuten, ausgeschlossene geplante Wartung 5 Minuten, Kosten 500 pro Minute:

Das Bild ist klar. Mit einem Ziel von 99,9% über 30 Tage haben Sie ein Budget von 43,2 Minuten Ausfallzeit. Von den 25 beobachteten Minuten waren 5 geplante Wartung (ausgeschlossen), also werden 20 gezählt: 46% des Budgets. Sie sind daher deutlich innerhalb des SLA, mit einer tatsächlichen Verfügbarkeit von 99,954% und mehr als der Hälfte des Budgets noch verfügbar. Die gezählte Ausfallzeit kostete etwa 10.000. Ändern Sie die Parameter mit Ihren Zahlen: Sie sehen sofort, ob Sie die Zusage erfüllen und wie viel Marge Ihnen bleibt.

Das Error Budget: eine andere Art, über Zuverlässigkeit nachzudenken

Eines der mächtigsten Konzepte, die von der Zuverlässigkeitstechnik (SRE, Site Reliability Engineering) eingeführt wurden, ist das Error Budget. Die Idee ist kontraintuitiv, aber genial: ist das Ziel 99,9%, dann sind die 0,1% Ausfallzeit kein um jeden Preis zu vermeidender Fehler, sondern ein «Budget» zum Ausgeben. Dieses Nichtverfügbarkeits-Budget kann produktiv «ausgegeben» werden: um neue Funktionen zu veröffentlichen (die Risiko bergen), Wartung durchzuführen, zu experimentieren oder einfach Unvorhergesehenes zu absorbieren. Solange Sie im Budget bleiben, ist alles gut. Das ändert die Perspektive radikal. Statt jede Minute Ausfallzeit als Katastrophe zu behandeln (was dazu führen würde, jede Änderung aus Angst zu blockieren), schafft das Error Budget ein Gleichgewicht zwischen Zuverlässigkeit und Innovation. Wird das Budget zu schnell verbraucht, ist das das Signal, Releases zu verlangsamen und sich auf Stabilität zu konzentrieren; wird es fast nie verbraucht, «überinvestiert» man vielleicht in Zuverlässigkeit auf Kosten der Entwicklungsgeschwindigkeit. Das Error Budget wird so zu einem Steuerungsinstrument, das zwischen denen, die entwickeln (schnell veröffentlichen wollen), und denen, die betreiben (Stabilität wollen), geteilt wird und die Anreize auf einer messbaren Zahl ausrichtet. Der Rechner zeigt genau, wie viel Error Budget Sie verbraucht haben: es ist die Schlüsselzahl für diese Entscheidungen.

Uptime vs Downtime: die Umrechnung

Uptime und Downtime sind zwei Seiten derselben Medaille, aber sie getrennt zu denken hilft, Fehler zu vermeiden. Die Uptime ist der Prozentsatz der Zeit, in der der Dienst funktioniert; die Downtime ist die Zeit (in Minuten, Stunden, Tagen), in der er nicht funktioniert. Die Beziehung ist: Downtime = (1 − Uptime%) × Zeitraum. Der häufigste Fehler ist, nur in Prozent zu denken, wo die Unterschiede klein erscheinen («99,9% und 99,99% sind fast gleich»), während sie in realer Zeit riesig sind (43 Minuten gegenüber 4 pro Monat, ein Faktor zehn). Ein weiterer wichtiger Punkt ist, dass sich die Uptime immer auf einen Zeitraum beziehen muss: 99,9% über einen Monat und 99,9% über ein Jahr erlauben sehr unterschiedliche Gesamtausfallzeiten im absoluten Wert. Und es gibt die Frage, was gemessen wird: die Uptime des Servers? Des vom Nutzer wahrgenommenen Dienstes? Einer einzelnen Komponente oder der ganzen Kette? Ein Dienst kann die Server «oben» haben, aber durch ein nachgelagertes Problem faktisch unbrauchbar sein. Der Rechner arbeitet mit dem allgemeinen Konzept der Dienstverfügbarkeit im von Ihnen angegebenen Zeitraum; die präzise Definition dessen, was «Downtime» ausmacht, ist in der Praxis einer der wichtigsten (und umstrittensten) Punkte jedes SLA.

Geplante Wartung und Ausschlüsse

Ein Detail, das einen großen Unterschied macht, ist, was das SLA von der Downtime-Zählung ausschließt. Das häufigste ist die geplante Wartung: im Voraus mitgeteilte Wartungsfenster, während derer der Dienst nicht verfügbar sein kann, ohne dass dies als Verletzung zählt. Viele SLAs sehen diese Fenster vor, typischerweise zu Zeiten geringer Nutzung. Andere häufige Ausschlüsse betreffen: höhere Gewalt (außergewöhnliche Ereignisse außerhalb der Kontrolle des Anbieters), dem Kunden zuzurechnende Probleme (zum Beispiel falsche Konfigurationen auf Nutzerseite), Drittanbieter-Ausfälle (externe Anbieter, Konnektivität) und Angriffe oder Sicherheitsereignisse unter bestimmten Bedingungen. Die praktische Folge ist, dass die «reale» wahrgenommene Downtime und die für SLA-Zwecke «gezählte» Downtime differieren können, auch stark. Im Rechner ermöglicht Ihnen das Feld «ausgeschlossene geplante Wartung», diesen Anteil von der Gesamtausfallzeit abzuziehen, um die tatsächlich gezählte Ausfallzeit zu berechnen. Es ist eine wichtige Erinnerung: bei der Bewertung oder Verhandlung eines SLA zählen die Definitionen und Ausschlüsse ebenso viel wie der Prozentsatz. Ein 99,99%-SLA mit vielen Ausschlüssen kann in der Praxis weniger bieten als ein 99,9%-SLA mit wenigen Ausschlüssen. Lesen Sie die Klauseln immer sorgfältig.

Die Kosten der Ausfallzeit: die geschäftliche Auswirkung

Hinter jeder Minute Ausfallzeit stehen Kosten, und sie zu quantifizieren ist wesentlich, um rationale Entscheidungen über Zuverlässigkeit zu treffen. Die Kosten der Ausfallzeit hängen von der Art des Dienstes ab, umfassen aber typischerweise: entgangene Erlöse (für einen E-Commerce oder einen kostenpflichtigen Dienst ist jede Minute Nichtverfügbarkeit entgangener Umsatz), verlorene Produktivität (wird der Dienst intern genutzt, können Mitarbeiter nicht arbeiten), Wiederherstellungs- und Reaktionskosten (das eingreifende Team, Überstunden, Post-Incident-Analyse), etwaige Vertragsstrafen gegenüber Kunden und — oft die heimtückischsten — den Reputationsschaden und den Vertrauensverlust. Manche Dienste haben enorme Ausfallkosten, wo jede Minute Tausende oder Zehntausende wert ist; andere sind toleranter. Die Kosten pro Minute zu kennen ist aus zwei Gründen entscheidend. Erstens: es erlaubt, Zuverlässigkeitsinvestitionen zu rechtfertigen (kostet eine Minute Ausfallzeit X, wie viel ist es wert, die erwartete Ausfallzeit zu reduzieren?). Zweitens: es hilft, das richtige Ziel zu wählen, indem man die Kosten höherer Verfügbarkeit mit den Kosten der vermiedenen Ausfallzeit abwägt. Indem Sie im Rechner die Kosten pro Minute eingeben, sehen Sie die wirtschaftliche Auswirkung der gezählten Ausfallzeit — eine konkrete Zahl, um mit dem Business zu sprechen, nicht nur mit den Technikern. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

SLAs gegenüber Kunden: Vertragsstrafen und Servicegutschriften

Wenn ein SLA vertraglich ist — also eine Zusage des Anbieters gegenüber Kunden — hat eine Verletzung direkte wirtschaftliche Folgen, typischerweise in Form von Vertragsstrafen oder, häufiger, Servicegutschriften (Service Credits). Der klassische Mechanismus funktioniert so: sinkt die Uptime unter die versprochene Schwelle, hat der Kunde Anspruch auf eine Erstattung gleich einem Prozentsatz der gezahlten Gebühr, steigend mit der Verschlimmerung der Verletzung. Zum Beispiel könnte ein SLA eine Gutschrift von 10% der Monatsgebühr vorsehen, wenn die Uptime unter 99,9% sinkt, 25% unter 99%, und so weiter. Es ist wichtig, einige praktische Aspekte zu verstehen. Servicegutschriften sind oft das einzige Rechtsmittel (der Kunde kann nicht mehr verlangen, außer in besonderen Fällen) und sind in der Regel auf einen Höchstprozentsatz der Gebühr begrenzt. Sie müssen zudem fast immer vom Kunden innerhalb bestimmter Fristen aktiv beantragt werden, nicht automatisch gutgeschrieben. Aus Sicht des Anbieters sind Gutschriften ein Anreiz, das SLA zu erfüllen, decken aber selten den realen Schaden des Kunden (der viel größer als die Gebühr sein kann). Aus Sicht des Kunden gibt ein SLA mit großzügigen Gutschriften eine Garantie, muss aber sorgfältig gelesen werden: der versprochene Prozentsatz, die Ausschlüsse, die Grenzen und die Verfahren machen den Unterschied zwischen einem realen und einem formalen Schutz. Der Rechner schätzt die Ausfallzeit und ihre technischen Kosten; der Wert der Gutschriften hängt von den spezifischen Vertragsklauseln ab.

SLAs in der Welt der Cloud-Dienste

Uptime-SLAs sind in der Welt der Cloud- und Digitaldienste allgegenwärtig. Die Tabelle fasst einige typische Niveaus zusammen (indikativ, jeder Anbieter hat seine eigenen Bedingungen):

In der realen Welt bieten Cloud-Anbieter (Infrastruktur, Plattformen, Software) nach Service-Tier differenzierte SLAs an: je mehr man zahlt, desto höher die garantierte Uptime. Es ist ein universelles und internationales Thema: dieselbe Logik gilt überall, weil die Mathematik der Verfügbarkeit nicht vom Land oder der Währung abhängt. Einige praktische Beobachtungen. Die höchsten SLAs (vier oder fünf Neunen) sind meist den Premium-Tiers vorbehalten und bringen strengere Bedingungen mit sich. Viele SLAs beziehen sich auf einzelne Komponenten (zum Beispiel Compute oder Storage), während die vom Nutzer wahrgenommene Ende-zu-Ende-Verfügbarkeit von der Kette aller Komponenten abhängt — und, wie wir sehen werden, multiplizieren sich Abhängigkeiten und senken die Gesamt-Uptime. Die Definitionen von «Downtime», die Ausschlüsse und die Gutschriften variieren stark zwischen Anbietern. Der Rechner ist gerade deshalb parametrisch, um sich an jedes SLA anzupassen: geben Sie das Ziel und den Zeitraum des Sie interessierenden Dienstes ein, und erhalten Sie eine konkrete Schätzung. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Wie viel Uptime man wirklich braucht: das Ziel wählen

Eine der wichtigsten und am häufigsten schlecht getroffenen Entscheidungen ist die Wahl des Uptime-Ziels. Der Instinkt ist, auf das Maximum zu zielen («wir wollen fünf Neunen!»), aber es ist fast immer der falsche Ansatz. Das richtige Ziel hängt von einem Gleichgewicht zwischen dem Wert höherer Verfügbarkeit und ihren Kosten ab. Einige Leitfragen. Was sind die realen Kosten der Ausfallzeit für diesen Dienst? Ein internes Reporting und eine Zahlungsplattform haben sehr unterschiedliche Bedürfnisse. Was ist die Toleranz der Nutzer? Manche Dienste können sich kurze Unterbrechungen ohne Folgen leisten; andere nicht. Was sind die Kosten, eine Neun hinzuzufügen? Wie gesehen, wachsen sie rasch. Und, entscheidend, ist das versprochene Ziel realistisch für die aktuelle Architektur? Eine Uptime zu versprechen, die man nicht halten kann, ist kontraproduktiv: es erzeugt Verletzungen, Strafen und Vertrauensverlust. Die goldene Regel des SRE ist, dass die Zuverlässigkeit für die Nutzer «hoch genug» sein sollte, nicht «maximal» im absoluten Sinn: über einen bestimmten Punkt hinaus nehmen die Nutzer die Verbesserung nicht einmal wahr, aber die Kosten wachsen weiter. Der Rechner hilft, diese Wahl konkret zu machen: probieren Sie verschiedene Ziele und Zeiträume aus, betrachten Sie die erlaubte Ausfallzeit und die Kosten, und finden Sie den richtigen Gleichgewichtspunkt für Ihren Fall. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Grenzen der Berechnung

Dieser Rechner liefert eine parametrische Schätzung der Beziehung zwischen Uptime-Ziel, erlaubter Ausfallzeit, Error Budget und Kosten, keine vertragliche Zusage und keine offizielle Messung der Verfügbarkeit. Die Berechnung nimmt eine «einfache» Definition von Downtime als Nichtverfügbarkeitszeit im Zeitraum an, während in der Praxis die Definition von Downtime für SLA-Zwecke oft komplex ist: was als «down» zählt (totale Nichtverfügbarkeit? Leistungsverschlechterung? Fehler bei einem Teil der Anfragen?), wie es gemessen wird (von wo, mit welcher Granularität) und was ausgeschlossen ist (Wartung, höhere Gewalt, Dritte). Das Modell berücksichtigt einen einzigen Ausschluss (geplante Wartung), während reale SLAs viele vorsehen. Es berechnet nicht die tatsächlichen Servicegutschriften (die von den Vertragsklauseln abhängen), modelliert nicht die kumulierte Uptime mehrerer Komponenten in Reihe oder parallel, berücksichtigt nicht die zeitliche Verteilung der Ausfallzeit (eine einzige lange Unterbrechung und viele kurze haben unterschiedliche Auswirkungen, auch bei gleichen Gesamtminuten), noch die realen Kosten der Ausfallzeit (die hier eine einfache Multiplikation sind, während sie in der Realität mit dem Zeitpunkt, der Dauer und der Art des Dienstes variieren). Nutzen Sie das Ergebnis, um die Logik der Verfügbarkeit zu verstehen — insbesondere die Mathematik der «Neunen» und das Konzept des Error Budgets — und für Größenordnungsschätzungen, aber für vertragliche Zusagen und präzise Messungen verlassen Sie sich auf dedizierte Monitoring-Werkzeuge und eine rigorose Definition des SLA. Dies ist keine Servicegarantie.

SLA, SLO und SLI: wer macht was

In der Welt der Service-Zuverlässigkeit werden drei Abkürzungen verwendet, die leicht verwechselt werden, aber unterschiedliche Rollen haben: SLA, SLO und SLI. Die Tabelle klärt sie:

Die Beziehung zwischen den dreien ist hierarchisch und logisch. Der SLI (Service Level Indicator) ist die Messung: eine konkrete Zahl, die das Verhalten des Dienstes beschreibt, zum Beispiel der Prozentsatz der korrekt oder innerhalb einer bestimmten Zeit bedienten Anfragen. Das SLO (Service Level Objective) ist das Ziel, das sich das Team auf diesem Indikator setzt: «wir wollen, dass der SLI über 99,95% bleibt». Es ist ein internes Ziel, die Referenz für das Error Budget. Das SLA (Service Level Agreement) ist die vertragliche Zusage gegenüber Kunden, mit Folgen (Strafen, Gutschriften) bei Verletzung. Eine gute Praxis ist, das SLO strenger als das SLA zu halten: verpflichten Sie sich vertraglich zu 99,9% (SLA), zielen aber intern auf 99,95% (SLO), haben Sie eine Sicherheitsmarge — wenn Sie das interne Ziel überschreiten, haben Sie noch Spielraum, bevor Sie die externe Zusage verletzen. Diese Konzepte zu verwechseln führt zu Fehlern: Kunden (SLA) dasselbe Niveau zu versprechen, das man intern zu erreichen hofft (SLO), ist riskant. Der Rechner arbeitet mit dem allgemeinen Konzept eines Verfügbarkeitsziels; Sie können ihn sowohl für ein internes SLO als auch für ein vertragliches SLA nutzen. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Kumulierte Uptime: warum Abhängigkeiten zählen

Ein kontraintuitiver und entscheidender Aspekt ist, dass die Uptime eines aus mehreren Komponenten in Reihe zusammengesetzten Dienstes (wo jede funktionieren muss, damit das Ganze funktioniert) niedriger ist als die der einzelnen Komponenten: die Verfügbarkeiten multiplizieren sich. Die Tabelle zeigt den Effekt, angenommen jede Abhängigkeit hat eine Uptime von 99,9%:

Die Mathematik ist gnadenlos: hängt Ihr Dienst von zehn Komponenten ab, jede mit ausgezeichneten 99,9%, sinkt die vom Nutzer wahrgenommene Ende-zu-Ende-Verfügbarkeit auf etwa 99,0% — mit über 7 Stunden Ausfallzeit pro Monat, eine Größenordnung schlechter als die einzelne Komponente. Das erklärt ein häufiges Phänomen: ein Dienst kann Cloud-Anbieter nutzen, die je eine sehr hohe Uptime versprechen, und dennoch seinen eigenen Nutzern eine deutlich niedrigere Verfügbarkeit bieten, weil die Kette der Abhängigkeiten die kleinen Ausfälle jeder einzelnen multipliziert. Die Gegenmaßnahmen sind das Gegenteil der Reihe: die parallele Redundanz (alternative Komponenten zu haben, die sich gegenseitig ersetzen) erhöht die Verfügbarkeit statt sie zu reduzieren, weil das System oben bleibt, solange mindestens eine funktioniert. Für Zuverlässigkeit zu entwerfen bedeutet daher, kritische Reihenabhängigkeiten zu minimieren und Redundanz dort hinzuzufügen, wo es zählt. Der Rechner schätzt die Uptime eines einzelnen Dienstes oder einer Komponente; für die kumulierte Uptime einer komplexen Architektur muss man die Abhängigkeitskette modellieren. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Wie man die Uptime verbessert: Redundanz und Resilienz

Die Uptime zu erhöhen — also «Neunen» hinzuzufügen — erfordert Investitionen in Redundanz und Resilienz, mit steigenden Kosten. Die Haupthebel. Die Redundanz: «Single Points of Failure» eliminieren, indem man duplizierte Komponenten hat (Server, Datenbanken, geografische Zonen), die im Ausfall übernehmen. Der automatische Failover: Mechanismen, die den Verkehr ohne manuellen Eingriff auf eine gesunde Komponente verschieben und die Wiederherstellungszeit drastisch reduzieren. Das Monitoring und die Alarmierung: Probleme schnell erkennen (idealerweise vor den Nutzern), um sofort einzugreifen. Die Reaktionsautomatisierung: automatische Verfahren, die gängige Szenarien ohne menschliches Warten bewältigen. Die Reduzierung des Blast Radius: das System so zu entwerfen, dass ein Ausfall in einem Teil nicht das Ganze abschaltet. Die Resilienztests (einschließlich «Chaos Engineering», das kontrollierte Ausfälle einführt, um die Robustheit zu prüfen). Und, nicht zuletzt, die Prozesse: Vorfallreaktionsverfahren, Bereitschaftsteams, schuldfreie Post-Incident-Analyse, um aus Fehlern zu lernen. Der Schlüsselpunkt ist, dass jede zusätzliche Neun mehr kostet als die vorherige: der Wechsel von 99,9% auf 99,99% erfordert typischerweise einen viel größeren Aufwand als von 99% auf 99,9%. Deshalb muss die Wahl des Ziels mit den Ausfallkosten in der Hand getroffen werden, wie der Rechner zeigt. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Die Rolle des Monitorings: die reale Uptime messen

Eine deklarierte Uptime ist wenig wert ohne ein seriöses Monitoring, das sie misst. Und hier tauchen subtile, aber entscheidende Fragen auf: von wo wird die Verfügbarkeit gemessen? Ein Dienst kann vom Rechenzentrum aus «oben» erscheinen, aber für einen Nutzer in einer anderen Region «unten» sein, wegen eines Netzwerkproblems. Was wird genau gemessen? Die einfache Erreichbarkeit des Servers, oder die Tatsache, dass der Dienst korrekt und in angemessener Zeit antwortet? Ein Server, der antwortet, aber mit Fehlern oder sehr langsam, ist technisch «oben», aber faktisch unbrauchbar. Mit welcher Frequenz wird abgetastet? Eine Prüfung alle fünf Minuten kann einen zweiminütigen Ausfall «verpassen». Deshalb kombiniert das moderne Monitoring mehrere Ansätze: externe Prüfungen von mehreren Standorten (um den Dienst so zu sehen, wie die Nutzer ihn sehen), internes Monitoring der Komponenten und zunehmend die auf der realen Nutzererfahrung basierende Messung (wie viele Anfragen erfolgreich sind, mit welcher Latenz). Die Messung der Uptime ist daher selbst eine Designentscheidung: den SLI (den Indikator) so zu definieren, dass er erfasst, was für die Nutzer zählt, ist die Hälfte der Arbeit. Eine schlecht gemessene «99,9%»-Uptime kann eine viel schlechtere Nutzererfahrung verbergen. Der Rechner arbeitet mit der von Ihnen eingegebenen Ausfallzeit; die Qualität dieser Zahl hängt von der Qualität Ihres Monitorings ab. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Fragen vor der Unterzeichnung eines SLA

Ob Sie der Anbieter sind, der ein SLA anbietet, oder der Kunde, der es bewertet, einige Fragen sind wesentlich. Was ist die genaue Definition von «Downtime»? Totale Nichtverfügbarkeit, Verschlechterung, Fehler bei einem Teil der Anfragen? Es ist der wichtigste und am häufigsten mehrdeutige Punkt. Von wo und wie wird die Verfügbarkeit gemessen, und mit welcher Frequenz? Was ist ausgeschlossen von der Zählung — geplante Wartung (mit wie viel Vorlauf?), höhere Gewalt, Drittanbieterprobleme, Kundenursachen? Über welchen Zeitraum ist das SLA definiert (monatlich, jährlich)? Bei gleichem Prozentsatz ist ein kürzerer Zeitraum strenger. Was sind die Rechtsmittel im Verletzungsfall — Servicegutschriften? Welchen Umfangs, mit welchen Grenzen und wie werden sie beantragt? Bezieht sich die Uptime auf die einzelne Komponente oder den Ende-zu-Ende-Dienst? Und, für den Kunden: deckt das SLA wirklich mein Risiko ab, oder sind die Gutschriften symbolisch im Vergleich zum Schaden, den ich erleiden würde? Für den Anbieter: ist das versprochene Ziel für meine Architektur realistisch, oder setze ich mich fortlaufenden Verletzungen aus? Diese Fragen zeigen, dass ein SLA viel mehr ist als nur der Uptime-Prozentsatz: die Definitionen, Ausschlüsse und Rechtsmittel machen den Unterschied zwischen einem realen und einem Fassaden-Schutz. Der Rechner hilft Ihnen, den Prozentsatz in konkrete Ausfallzeit zu übersetzen und über die Kosten nachzudenken; für die vollständige vertragliche Bewertung lesen Sie jede Klausel sorgfältig. Dies ist eine parametrische Schätzung, keine vertragliche Zusage.

Häufig gestellte Fragen

Wie viel Ausfallzeit erlaubt eine Uptime von 99,9%?

Etwa 43,2 Minuten pro Monat (über 30 Tage) oder etwa 8,77 Stunden pro Jahr. 99,9% («drei Neunen») bedeutet, dass 0,1% der Zeit Nichtverfügbarkeit sein kann. Es klingt wenig, aber in reale Minuten übersetzt ist es mehr, als viele erwarten. Der Rechner wandelt jedes SLA-Ziel in die erlaubte Ausfallzeit für den von Ihnen angegebenen Zeitraum um und zeigt die Mathematik der «Neunen».

Welche Daten brauche ich, um den Rechner zu nutzen?

Fünf Werte: das Uptime-SLA-Ziel (%), den Zeitraum in Tagen, die beobachtete Gesamtausfallzeit in Minuten, die etwaige auszuschließende geplante Wartung und die Kosten der Ausfallzeit pro Minute. Der Rechner liefert die erlaubte Ausfallzeit (Error Budget), die tatsächliche Verfügbarkeit, den Prozentsatz des verbrauchten Error Budgets und die Kosten der gezählten Ausfallzeit.

Wie wird die erlaubte Ausfallzeit berechnet?

Der Zeitraum wird in Minuten umgerechnet (Tage × 1440) und mit dem erlaubten Ausfallanteil multipliziert, also eins minus das Ziel geteilt durch 100. In Formel: D_max = (1 − s/100) × P, wobei s das SLA-Ziel und P die Minuten des Zeitraums ist. Zum Beispiel 99,9% über 30 Tage: 43.200 × 0,001 = 43,2 Minuten. Der Rechner tut das und vergleicht Ihre beobachtete Ausfallzeit mit dem Budget.

Was ist die Mathematik der «Neunen»?

Es ist die Tatsache, dass jede zusätzliche «Neun»-Stelle der Uptime die erlaubte Ausfallzeit um das Zehnfache reduziert. 99% erlaubt ~7,2 Stunden pro Monat, 99,9% ~43 Minuten, 99,99% ~4 Minuten, 99,999% ~26 Sekunden. Kleine Unterschiede im Prozentsatz entsprechen riesigen Unterschieden in realer Zeit — und jede zusätzliche Neun zu erreichen kostet unverhältnismäßig (Redundanz, Automatisierung, Failover).

Was ist das Error Budget?

Es ist ein SRE-Konzept (Site Reliability Engineering): ist das Ziel 99,9%, sind die 0,1% Ausfallzeit kein um jeden Preis zu vermeidender Fehler, sondern ein «Budget» zum Ausgeben. Sie können es «ausgeben», um neue Funktionen zu veröffentlichen, Wartung durchzuführen, Unvorhergesehenes zu absorbieren. Solange Sie im Budget bleiben, ist alles gut. Es ist ein Steuerungsinstrument, das Zuverlässigkeit und Innovation ausbalanciert: verbrauchen Sie es zu schnell, verlangsamen Sie die Releases.

Hängt die Berechnung von der Währung ab?

Nein. Der Rechner ist währungsneutral: geben Sie die Kosten der Ausfallzeit pro Minute in Ihrer Währung ein und erhalten Sie konsistente Ergebnisse (die Ausfallzeit ist in Minuten, die Uptime in Prozent). Es ist ein universelles und internationales Thema, weil die Mathematik der Verfügbarkeit nicht vom Land oder der Währung abhängt. Dieselbe Logik gilt überall.

Was schließt ein SLA von der Downtime-Zählung aus?

Das häufigste ist die geplante Wartung (im Voraus mitgeteilte Fenster). Andere häufige Ausschlüsse: höhere Gewalt, dem Kunden zuzurechnende Probleme, Drittanbieter-Ausfälle (externe Anbieter, Konnektivität), bestimmte Sicherheitsereignisse. Die «reale» wahrgenommene Downtime und die für SLA-Zwecke «gezählte» können stark differieren. Im Rechner können Sie die geplante Wartung ausschließen; die anderen Ausschlüsse hängen vom Vertrag ab.

Was sind Servicegutschriften (Service Credits)?

Sie sind das typische Rechtsmittel, wenn ein Anbieter ein vertragliches SLA verletzt: der Kunde hat Anspruch auf eine Erstattung gleich einem Prozentsatz der Gebühr, steigend mit der Verschlimmerung der Verletzung. Sie sind oft das einzige Rechtsmittel, auf ein Maximum begrenzt, und müssen in der Regel aktiv innerhalb bestimmter Fristen beantragt werden. Sie decken selten den realen Schaden des Kunden. Der Wert hängt von den spezifischen Klauseln ab.

Warum zählen die Kosten der Ausfallzeit?

Weil sie rationale Entscheidungen erlauben. Die Kosten pro Minute zu kennen hilft, Zuverlässigkeitsinvestitionen zu rechtfertigen (kostet eine Minute X, wie viel ist die Reduzierung der Ausfallzeit wert?) und das richtige Ziel zu wählen, indem man die Kosten für mehr Uptime mit den Kosten der vermiedenen Ausfallzeit abwägt. Die Kosten umfassen entgangene Erlöse, Produktivität, Wiederherstellung, Strafen und Reputationsschaden.

Ist 99,99% immer besser als 99,9%?

Nicht unbedingt. Eine höhere Uptime ist schwieriger und teurer zu garantieren: jede zusätzliche Neun kostet unverhältnismäßig. Das richtige Ziel hängt von den Kosten der Ausfallzeit, der Toleranz der Nutzer und den Kosten ab, eine Neun hinzuzufügen. Die SRE-Regel ist, dass die Zuverlässigkeit für die Nutzer «hoch genug» sein sollte, nicht «maximal»: über einen bestimmten Punkt hinaus nehmen die Nutzer die Verbesserung nicht wahr, aber die Kosten wachsen.

Muss sich die Uptime auf einen Zeitraum beziehen?

Ja, immer. 99,9% über einen Monat und 99,9% über ein Jahr erlauben sehr unterschiedliche Gesamtausfallzeiten im absoluten Wert (43 Minuten gegenüber fast 9 Stunden). Deshalb ist es wichtig, den Referenzzeitraum anzugeben. Im Rechner geben Sie den Zeitraum in Tagen ein und erhalten die erlaubte Ausfallzeit für diesen spezifischen Zeitraum. Prüfen Sie stets, über welchen Zeitraum das von Ihnen bewertete SLA definiert ist.

Ist das Ergebnis zuverlässig?

Es ist eine parametrische Schätzung der Verfügbarkeitslogik, keine vertragliche Zusage und keine offizielle Messung. Es nimmt eine einfache Definition von Downtime und einen einzigen Ausschluss (Wartung) an, während reale SLAs komplexer sind (Definition von «down», Messung, viele Ausschlüsse, Gutschriften, kumulierte Uptime mehrerer Komponenten). Nutzen Sie es, um die Logik der «Neunen» und des Error Budgets zu verstehen und für Größenordnungsschätzungen; für Zusagen und präzise Messungen nutzen Sie Monitoring-Werkzeuge.

Aktualisiert im Juli 2026