Was "99,9 Prozent Verfügbarkeit" wirklich bedeutet

"99,9 Prozent" steht in jedem zweiten Angebot, klingt beruhigend und sagt dir trotzdem wenig. Hinter der Zahl steckt eine konkrete Rechnung: wie viele Minuten oder Stunden dein Produkt im Jahr stillstehen darf, ohne dass du das Versprechen brichst. In diesem Artikel rechne ich dir die gängigen Stufen in echte Ausfallzeit um, zeige dir, womit man Verfügbarkeit überhaupt erreicht, und erkläre, warum 99,9 Prozent für die meisten kleinen Produkte die vernünftige Wahl ist. Am Ende weisst du, welche Stufe zu deinem Produkt passt und welche du dir sparen kannst.

Was die Zahl 99,9 Prozent überhaupt misst

Verfügbarkeit ist der Anteil der Zeit, in dem dein Produkt für die Nutzer erreichbar und funktionsfähig ist. Man drückt sie als Prozentsatz über einen Zeitraum aus, üblich ist das Jahr. Wenn ein Anbieter dir 99,9 Prozent Verfügbarkeit verspricht, sagt er damit: Über zwölf Monate gerechnet darf das System für 0,1 Prozent der Zeit nicht erreichbar sein. Klingt nach nichts. Rechnet man es aber in Stunden um, wird es greifbar.

Ein Jahr hat rund 8'760 Stunden. 0,1 Prozent davon sind etwa 8 Stunden und 45 Minuten Ausfallzeit pro Jahr, die du dir bei 99,9 Prozent leisten darfst. Das ist die zentrale Übersetzung, die in Angeboten fast nie dabeisteht. Die Zahl selbst beeindruckt, die Konsequenz dahinter zählt.

Wichtig ist auch das Kleingedruckte: Über welchen Zeitraum wird gemessen, und was zählt als Ausfall? Manche Anbieter rechnen pro Monat, andere pro Jahr. Manche zählen geplante Wartungsfenster nicht mit, andere schon. Eine geplante nächtliche Wartung, die du sauber ankündigst, ist betrieblich etwas ganz anderes als ein Absturz um zehn Uhr morgens, wenn alle arbeiten. Wenn dir jemand eine Verfügbarkeitszahl nennt, ist die erste sinnvolle Rückfrage deshalb nicht wie hoch, sondern gemessen woran.

SLA, SLO und Uptime: was die Begriffe trennt

Drei Begriffe tauchen rund um Verfügbarkeit immer wieder auf, und sie meinen nicht dasselbe.

Uptime ist der gemessene Ist-Zustand. Sie beschreibt, wie viel Prozent der Zeit dein System tatsächlich lief, rückblickend. Uptime ist eine Beobachtung, kein Versprechen.

Ein SLO (Service Level Objective) ist das Ziel, das du dir intern setzt. Wir wollen 99,9 Prozent erreichen ist ein SLO. Es richtet die Arbeit aus: Wenn du dieses Ziel kennst, weisst du, wie viel Aufwand für Redundanz und Überwachung angemessen ist und wo Übertreibung beginnt.

Ein SLA (Service Level Agreement) ist die vertragliche Zusage gegenüber einem Kunden, oft mit einer Folge, wenn sie gebrochen wird, etwa einer Gutschrift. Ein SLA ist ein SLO mit Konsequenzen und Unterschrift. Der Unterschied ist betrieblich gross: Ein internes Ziel verfehlst du im Stillen und besserst nach. Ein gebrochenes SLA kostet dich Geld oder Vertrauen. Versprich also nur vertraglich, was du auch unter Druck halten kannst.

Die gängigen Stufen, in echter Ausfallzeit gerechnet

Verfügbarkeit wird oft in Neunen angegeben. Jede zusätzliche Neun verzehnfacht die Anforderung, weil sie die erlaubte Ausfallzeit auf ein Zehntel drückt. Hier die Stufen, die dir in der Praxis begegnen, gerechnet auf ein Jahr:

  • 99 Prozent (zwei Neunen): rund 3 Tage und 15 Stunden Ausfall pro Jahr. Für ein produktives Geschäftssystem zu wenig, das merkt jeder.
  • 99,9 Prozent (drei Neunen): rund 8 Stunden 45 Minuten pro Jahr. Das ist der Standard, auf den die meisten gut gebauten kleinen und mittleren Produkte zielen.
  • 99,99 Prozent (vier Neunen): rund 52 Minuten pro Jahr. Du hast also pro Jahr knapp eine Stunde, in der etwas schiefgehen darf, inklusive aller Updates und Pannen.
  • 99,999 Prozent (fünf Neunen): rund 5 Minuten pro Jahr. Dieses Niveau ist die Welt von Telefonnetzen, Zahlungsinfrastruktur und Plattformen, an denen tausende andere Systeme hängen.

Der Sprung von 99,9 auf 99,99 sieht auf dem Papier winzig aus. In der Betriebsrealität ist er es nicht. Du gehst von ein Nachmittag Ausfall im Jahr ist verkraftbar zu jede Störung über ein paar Minuten ist bereits ein Problem. Genau hier entscheidet sich, wie viel ein Produkt im Betrieb kostet, und darüber reden wir gleich.

Womit man Verfügbarkeit tatsächlich erreicht

Eine hohe Verfügbarkeitszahl ist kein Schalter, den man umlegt. Sie ist das Ergebnis von ein paar Bausteinen, die zusammenspielen. Drei davon tragen den grössten Teil.

Redundanz heisst: Es gibt für jeden kritischen Teil einen Ersatz, der einspringt, wenn das Original ausfällt. Läuft deine Anwendung nur auf einem einzigen Server, ist dieser Server dein Schicksal. Fällt er aus, bist du offline, bis jemand ihn wieder hochbringt. Verteilst du die Anwendung auf mehrere Instanzen und legst eine Datenbank mit automatischem Failover dahinter, übersteht das System den Ausfall einer einzelnen Komponente, ohne dass die Nutzer es merken. Redundanz ist der grösste Hebel für Verfügbarkeit und zugleich der teuerste, weil du Dinge doppelt vorhältst, die meistens nicht gebraucht werden.

Monitoring und Alerting sorgen dafür, dass jemand vom Problem erfährt, bevor der Kunde anruft. Ein System kann technisch redundant sein und trotzdem stundenlang halb kaputt laufen, weil niemand hinschaut. Überwachung misst laufend, ob die wichtigen Funktionen antworten, und schlägt Alarm, wenn etwas aus dem Rahmen fällt. Was hier das Minimum ist und wie man es einrichtet, haben wir in Monitoring, Backups und Alerting als Minimum im Detail beschrieben. Ohne Überwachung ist deine gemessene Uptime im Grunde geraten.

Schnelle Wiederherstellung ist die dritte Säule und die unterschätzte. Es geht nicht nur darum, Ausfälle zu vermeiden, sondern darum, wie lange du brauchst, um nach einer Störung wieder zu laufen. Wenn ein Failover automatisch in Sekunden greift, verbrauchst du kaum Ausfallzeit. Wenn dagegen erst jemand geweckt werden, sich einloggen und die Ursache suchen muss, sind deine 8 Stunden Jahresbudget schnell aufgebraucht. Saubere Backups, getestete Wiederanlauf-Abläufe und klare Zuständigkeit entscheiden hier mehr als jede zusätzliche Neun im Angebot.

Diese Bausteine sind übrigens der Grund, warum Betrieb Geld kostet, das im reinen Baupreis nicht steckt. Wer wissen will, welche Posten da monatlich anfallen, findet die Aufschlüsselung unter was der Betrieb eines SaaS pro Monat kostet.

Warum 99,9 Prozent für die meisten kleinen Produkte reicht

Die Versuchung, möglichst viele Neunen zu fordern, ist verständlich. Niemand will, dass sein Produkt ausfällt. Nur kostet jede zusätzliche Neun überproportional, und der Nutzen davon hängt vollständig davon ab, was dein Produkt eigentlich tut.

Nimm ein internes Werkzeug, mit dem dein Team Aufträge erfasst, oder ein KMU-Produkt, das während der Geschäftszeiten genutzt wird. Fällt es nachts um drei für zwanzig Minuten aus und ist morgens wieder da, hat das niemand bemerkt. Für solche Produkte ist die Frage nicht 99,9 oder 99,99, sondern merkt überhaupt jemand den Unterschied. In aller Regel nicht. 99,9 Prozent bedeutet, dass ein einzelner Ausfall-Nachmittag pro Jahr im Rahmen liegt, und genau das verträgt ein normales Geschäftsprodukt.

Der Sprung auf 99,99 Prozent verlangt mehrfache Redundanz über verschiedene Standorte, automatisierte Wiederherstellung ohne menschliches Eingreifen, oft eine Bereitschaft rund um die Uhr. Das ist kein einmaliger Aufpreis, sondern ein dauerhaft höheres Betriebsniveau, das jeden Monat Geld bindet. Diesen Aufwand für ein Produkt zu zahlen, das von vierzig Leuten zu Bürozeiten genutzt wird, ist Geld, das du besser in Funktionen steckst, die deine Nutzer tatsächlich brauchen.

Wir bauen und betreiben eigene Produkte, etwa Wortfreunde und Reazon, und sehen dort denselben Effekt aus der Betreiber-Perspektive. Die teuren Stunden im Betrieb entstehen nicht durch die letzte Neun, sondern durch sauberes Monitoring, getestete Backups und klare Abläufe für den Fall, dass doch etwas passiert. Eine Stufe höher zu zielen, als das Produkt verlangt, macht den Betrieb teurer, ohne dass ein Nutzer je davon profitiert.

Wann mehr Neunen doch ihr Geld wert sind

Es gibt Produkte, bei denen 99,99 Prozent oder mehr keine Spielerei ist, sondern Pflicht. Drei Muster machen den Unterschied.

Das erste ist Geld, das in Echtzeit fliesst. Eine Bezahlplattform oder ein Checkout, der während einer Kampagne läuft, verliert mit jeder Minute Ausfall direkt Umsatz. Hier rechtfertigt der Schaden pro Ausfallminute den höheren Betriebsaufwand sofort.

Das zweite ist die Rolle als Infrastruktur für andere. Wenn fremde Systeme über eine Schnittstelle von deinem Produkt abhängen, multipliziert sich jeder Ausfall. Du legst dann nicht ein Produkt lahm, sondern alle, die auf dir aufbauen. Eine Schnittstelle, an der ein ERP-System hängt, hat ein anderes Verfügbarkeitsprofil als ein internes Dashboard, mehr dazu in Schnittstellen und ERP-Anbindung.

Das dritte ist echte Rund-um-die-Uhr-Nutzung über Zeitzonen hinweg. Wenn dein Produkt nie ein ruhiges Wartungsfenster hat, weil immer irgendwo jemand arbeitet, kannst du Ausfallzeit nicht in die Nacht schieben. Dann musst du sie technisch wegredundieren, statt sie zeitlich zu verstecken.

Der naheliegende Einwand lautet: Lieber gleich auf Nummer sicher gehen und hoch zielen, dann hat man Ruhe. In der Praxis ist das Gegenteil der Fall. Ein überdimensioniertes Verfügbarkeitsziel macht das System komplexer, und Komplexität ist selbst eine Ausfallquelle. Mehr bewegliche Teile bedeuten mehr Stellen, an denen etwas brechen kann. Du kaufst dir mit der vierten Neun also nicht nur Kosten ein, sondern unter Umständen genau die Instabilität, die du vermeiden wolltest. Die richtige Stufe ist die, die zu deinem tatsächlichen Schaden pro Ausfallminute passt, nicht die höchstmögliche.

So bestimmst du dein eigenes Ziel

Statt eine Zahl aus einem Angebot zu übernehmen, dreh die Frage um. Überleg dir zuerst, was ein Ausfall dich tatsächlich kostet, pro Stunde und je nach Tageszeit. Frag dann, wann dein Produkt genutzt wird und ob es ein ruhiges Fenster für Wartung gibt. Schau, ob andere Systeme von dir abhängen. Aus diesen Antworten ergibt sich dein Ziel fast von selbst, und es liegt für die allermeisten kleinen und mittleren Produkte bei soliden 99,9 Prozent.

Genauso wichtig ist, wie das Ziel im Betrieb verankert wird. Eine Verfügbarkeitszusage ohne Monitoring, ohne getestete Backups und ohne klare Zuständigkeit ist eine Zahl auf Papier. Wie wir Betrieb von Tag eins an produktionsreif aufsetzen, beschreibt der Beitrag Betrieb ab Tag eins. Und wenn du wissen willst, wie wir den laufenden Betrieb deines Produkts insgesamt übernehmen, findest du das unter Produkt-Betrieb.

Die Zahl in einem Angebot ist am Ende nur so viel wert wie der Betrieb dahinter. 99,9 Prozent, sauber überwacht und mit getesteter Wiederherstellung, schlagen 99,99 Prozent, die niemand misst und die beim ersten echten Vorfall in sich zusammenfallen. Sprich über die echte Ausfallzeit, die du verträgst, und über die Bausteine, die sie halten. Die Neunen ordnen sich dann von selbst.