Ein «immer verfügbarer» Dienst existiert nicht: jedes System, wie gut auch gebaut, fällt früher oder später aus. Die richtige Frage ist nicht «wird es ausfallen?», sondern «wie lange wird es ausfallen?» — und das ist eine messbare Eigenschaft, genannt Verfügbarkeit (Availability). Dieser Rechner schätzt die Verfügbarkeit eines Systems aus zwei grundlegenden Parametern der Zuverlässigkeitstechnik: der MTBF (Mean Time Between Failures), der mittleren Betriebszeit zwischen einem Ausfall und dem nächsten, und der MTTR (Mean Time To Repair), der mittleren Zeit, um das System nach einem Ausfall wieder in Betrieb zu bringen. Daraus erhalten Sie die Verfügbarkeit in Prozent, die berühmte Anzahl von «Neunen» (99,9% = «drei Neunen»), die erwartete Ausfallzeit im Zeitraum, und den Effekt der Architektur: Komponenten in Reihe (die die Verfügbarkeit reduzieren) und Redundanz parallel (die sie erhöht). Es ist das grundlegende Werkzeug derer, die zuverlässige Systeme entwerfen und verwalten — von den SRE- und DevOps-Teams, die Cloud-Dienste betreiben, bis zu den Ingenieuren industrieller Systeme und kritischer Infrastrukturen. Ein parametrisches und universelles Modell, gültig in jedem Kontext. Die Ergebnisse sind eine Schätzung: das Modell nimmt unabhängige Ausfälle und konstante Raten an, Annahmen, die in der Realität sorgfältig berücksichtigt werden müssen.

Verfügbarkeit eines Systems: MTBF, MTTR und die «Neunen»

Die Verfügbarkeit ist der Prozentsatz der Zeit, in der ein System funktioniert und einsatzbereit ist. Es scheint ein einfaches Konzept, aber dahinter verbirgt sich eine überraschende Mathematik und enorme wirtschaftliche Implikationen. Der Ausgangspunkt sind zwei mittlere Zeiten. Die MTBF (Mean Time Between Failures) misst, wie lange das System im Durchschnitt korrekt funktioniert, bevor es ausfällt: je höher, desto zuverlässiger das System. Die MTTR (Mean Time To Repair) misst, wie viel Zeit im Durchschnitt nötig ist, um das System zu reparieren und nach einem Ausfall wieder in Betrieb zu bringen: je niedriger, desto schneller erholt man sich. Die Verfügbarkeit entsteht aus dem Verhältnis zwischen diesen zwei Zeiten: intuitiv ist es der Bruchteil der Gesamtzeit, in dem das System «funktioniert» relativ zum vollständigen Zyklus «funktioniert + wird repariert». Eine bequeme und verbreitete Art, die Verfügbarkeit auszudrücken, ist das Zählen der «Neunen»: 99% sind «zwei Neunen», 99,9% sind «drei Neunen», 99,99% sind «vier Neunen», und so weiter. Jede zusätzliche Neun repräsentiert eine zehnfache Reduktion der Ausfallzeit — ein enormer Sprung an Qualität (und Kosten). Die Verbindung zwischen MTBF, MTTR, Neunen und Downtime zu verstehen ist die Grundlage des Entwurfs zuverlässiger Systeme. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Was ist Verfügbarkeit

Formal ist die Verfügbarkeit einer Komponente das Verhältnis zwischen der Zeit, in der sie betriebsbereit ist (Uptime), und der Gesamtzeit (Uptime + Downtime). Mit den mittleren Zeiten wird sie ausgedrückt als A = MTBF / (MTBF + MTTR). Es lohnt sich, bei der Bedeutung dieser Formel zu verweilen, denn sie ist tiefer, als sie scheint. Der Nenner, MTBF + MTTR, repräsentiert die mittlere Dauer eines vollständigen Zyklus: das System funktioniert für eine Zeit gleich der MTBF, fällt dann aus und wird in einer Zeit gleich der MTTR repariert, dann startet es neu. Die Verfügbarkeit ist der Bruchteil dieses Zyklus, in dem das System nützlich ist. Aus dieser Formel ergibt sich eine kontraintuitive, aber entscheidende Tatsache: die Verfügbarkeit hängt nicht von den absoluten Werten von MTBF und MTTR ab, sondern von ihrem Verhältnis. Ein System, das alle 1.000 Stunden ausfällt, aber in 1 Stunde repariert (A = 1000/1001 = 99,9%), hat dieselbe Verfügbarkeit wie eines, das alle 100 Stunden ausfällt, aber in 6 Minuten repariert (A = 100/100,1 = 99,9%). Das hat eine mächtige praktische Implikation: wenn die Reparaturen sehr schnell sind, können Sie häufige Ausfälle tolerieren; wenn die Reparaturen langsam sind, brauchen Sie seltene Ausfälle. Die Verfügbarkeit ist von der Zuverlässigkeit (Reliability) zu unterscheiden, die die Wahrscheinlichkeit betrifft, in einem gegebenen Intervall nicht auszufallen: ein System kann unzuverlässig sein (fällt oft aus), aber sehr verfügbar (repariert sofort). Der Rechner arbeitet an der Verfügbarkeit, der relevantesten Metrik für Dienste, die «da sein» müssen, wenn sie gebraucht werden. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Wie es berechnet wird: MTBF und MTTR

Die Tabelle zeigt die Berechnung im Standardfall — MTBF 8.760 Stunden (ein Ausfall pro Jahr im Durchschnitt), MTTR 4 Stunden, eine einzelne Komponente ohne Redundanz:

Die Berechnung ist direkt. Mit einer MTBF von 8.760 Stunden funktioniert das System im Durchschnitt ein ganzes Jahr gut, bevor ein Ausfall auftritt. Wenn es ausfällt, dauert es 4 Stunden (MTTR), um es zu reparieren. Die Verfügbarkeit beträgt daher 8.760 / (8.760 + 4) = 8.760 / 8.764 = 99,9544%. In konkrete Ausfallzeit übersetzt: über ein Jahr (8.760 Stunden) bedeutet eine Nichtverfügbarkeit von 0,0456% etwa 4 Stunden Ausfall — was, nicht zufällig, mit der MTTR übereinstimmt, weil im Durchschnitt ein Ausfall pro Jahr erwartet wird. In Bezug auf «Neunen» entspricht 99,9544% etwa 3,34 Neunen: wir sind über den «drei Neunen» (99,9%), aber noch nicht bei den «vier Neunen» (99,99%). Von hier aus können Sie die zwei architektonischen Hebel erkunden. Wenn Sie Komponenten in Reihe hinzufügen — Teile, die alle funktionieren müssen, damit das System funktioniert — sinkt die Gesamtverfügbarkeit, weil die Arten, wie das System ausfallen kann, zunehmen. Wenn Sie Redundanz hinzufügen — parallele Einheiten, die sich gegenseitig ersetzen — steigt die Verfügbarkeit, oft spektakulär. Ändern Sie die Werte im Rechner, um diese Effekte auf Ihr System zu sehen. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Die «Neunen» und die Ausfallzeit: was sie wirklich bedeuten

Über «Neunen» zu sprechen ist bequem, aber es ist leicht zu unterschätzen, wie groß der Unterschied zwischen einer Neun und der nächsten ist. Die Tabelle übersetzt jedes Verfügbarkeitsniveau in konkrete Ausfallzeit:

Die Tabelle offenbart die exponentielle Natur der Neunen und erklärt, warum sie zur universellen Sprache der Verfügbarkeit geworden sind. Der Unterschied zwischen 99% und 99,9% ist nicht «etwas besser»: es ist der Übergang von 3,65 Tagen Ausfall pro Jahr zu weniger als 9 Stunden, eine zehnfache Reduktion. Jede zusätzliche Neun teilt die Ausfallzeit durch zehn. Das hat zwei enorme praktische Konsequenzen. Erstens ist jede Neun drastisch schwieriger und teurer als die vorherige: von zwei auf drei Neunen zu gehen kann gutes Monitoring und geordnete Verfahren erfordern; von vier auf fünf Neunen zu gehen erfordert vollständige Redundanz, automatisches Failover in Sekunden, und operative Teams, die 24/7 reagieren — eine Investition um Größenordnungen höher. Zweitens ist die Wahl des Verfügbarkeitsziels eine wirtschaftliche Entscheidung: man muss die Kosten jeder zusätzlichen Neun gegen die Kosten der Ausfallzeit, die sie vermeidet, abwägen. Für einen persönlichen Blog sind «zwei Neunen» in Ordnung; für ein Zahlungssystem oder einen kritischen Cloud-Dienst reichen selbst «fünf Neunen» möglicherweise nicht. Diese Werte sind universell: 99,9% bedeutet 8,76 Stunden pro Jahr überall auf der Welt, was die Neunen zu einer gemeinsamen Sprache unter Ingenieuren jedes Landes macht. Nutzen Sie diese Tabelle, um ein Verfügbarkeitsziel in ein konkretes Ausfallzeit-Budget zu übersetzen. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

MTBF vs MTTR: zwei verschiedene Hebel

Um die Verfügbarkeit zu verbessern, haben Sie zwei unabhängige Hebel, und den Unterschied zwischen ihnen zu verstehen ist wesentlich, um wirksam einzugreifen. Der erste Hebel ist, die MTBF zu erhöhen, das heißt das System seltener ausfallen zu lassen. Man erreicht es mit Komponenten besserer Qualität, vorbeugender Wartung, Beseitigung der wiederkehrenden Ausfallursachen, Reduktion des Stresses auf die Komponenten und gutem Design. Es ist ein «Präventions»-Hebel: er wirkt auf die Häufigkeit der Probleme. Der zweite Hebel ist, die MTTR zu reduzieren, das heißt schneller zu reparieren, wenn der Ausfall auftritt. Man erreicht es mit Monitoring, das das Problem sofort erkennt, wirksamen Alarmen, schneller Diagnose, Automatisierung der Reparaturen, bereiten Ersatzteilen, eingespielten Verfahren und vorbereiteten Teams. Es ist ein «Reaktions»-Hebel: er wirkt auf die Dauer der Probleme. Hier ist die mathematische Schlüsseltatsache, die die Wahl leitet: da die Verfügbarkeit vom Verhältnis MTBF/(MTBF+MTTR) abhängt, hat die MTTR zu halbieren denselben Effekt wie die MTBF zu verdoppeln. Aber in der Praxis haben die zwei Hebel sehr unterschiedliche Kosten. Die MTBF zu erhöhen (Dinge zuverlässiger machen) ist oft schwierig und teuer: es erfordert bessere Komponenten oder Neugestaltungen. Die MTTR zu reduzieren (schneller reparieren) ist oft einfacher und günstiger: eine Investition in Monitoring und Automatisierung kann die MTTR schnell senken. Deshalb wird in der modernen SRE-Kultur großer Wert auf die Reduktion der MTTR gelegt — «Ausfälle sind unvermeidlich, was zählt, ist wie schnell man sich erholt». Der Rechner zeigt Ihnen den Effekt beider Hebel: versuchen Sie, sie zu variieren. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Komponenten in Reihe: das schwache Glied

Wenige reale Systeme bestehen aus einer einzigen Komponente. Die meisten sind eine Kette von Komponenten, die alle funktionieren müssen, damit das System als Ganzes funktioniert: eine Webanwendung hängt vom Server, von der Datenbank, vom Netzwerk, vom Load Balancer, vom Storage ab. Das ist eine Reihen-Konfiguration, und sie hat eine entscheidende Eigenschaft: das System fällt aus, wenn auch nur eine einzige der Komponenten ausfällt. Es ist das Prinzip des «schwachen Glieds der Kette». Mathematisch ist die Verfügbarkeit von Komponenten in Reihe das Produkt der einzelnen Verfügbarkeiten. Und hier verbirgt sich eine kontraintuitive Falle: zuverlässige Komponenten zusammenzusetzen produziert ein System, das weniger zuverlässig ist als jede von ihnen. Ein konkretes Beispiel: wenn Sie 5 Komponenten haben, jede mit einer Verfügbarkeit von 99,9% («drei Neunen»), ist die Systemverfügbarkeit nicht 99,9%, sondern 0,999⁵ = 99,5% — Sie sind unter «drei Neunen» gesunken. Mit 10 Komponenten bei 99,9% sinken Sie auf 99% («zwei Neunen»). Jede in Reihe hinzugefügte Komponente erodiert die Gesamtverfügbarkeit, weil sie eine weitere Art hinzufügt, wie das Ganze kaputtgehen kann. Das ist einer der Gründe, warum moderne verteilte Systeme, bestehend aus Dutzenden oder Hunderten von Microservices, Mühe haben, hohe Verfügbarkeit zu erreichen: die lange Kette von Abhängigkeiten senkt das Ergebnis. Die Gegenmaßnahmen sind zwei: die Anzahl der kritischen Reihenabhängigkeiten reduzieren (die Architektur vereinfachen), oder — wo hohe Verfügbarkeit nötig ist — Redundanz auf den kritischen Komponenten einführen und die einzelnen schwachen Glieder in redundante Blöcke verwandeln. Der Rechner zeigt Ihnen diesen Effekt: erhöhen Sie die Reihenkomponenten und beobachten Sie die Verfügbarkeit sinken. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Die Redundanz: wie man Neunen hinzufügt

Wenn die Reihe die Verfügbarkeit erodiert, multipliziert die Redundanz (oder Parallelschaltung) sie. Die Tabelle zeigt den Effekt redundanter Einheiten auf eine Komponente mit einer Ausgangsverfügbarkeit von 99,9544% (MTBF 8.760, MTTR 4):

Das Ergebnis ist spektakulär und erklärt, warum die Redundanz die Säule der hohen Verfügbarkeit ist. Mit einer einzigen Backup-Einheit (2 Einheiten parallel) geht die Verfügbarkeit von 3,34 auf 6,68 Neunen: die jährliche Ausfallzeit bricht von 4 Stunden auf etwa 7 Sekunden ein. Der Grund ist mathematisch: damit der redundante Block ausfällt, müssen alle parallelen Einheiten gleichzeitig ausfallen, und die Wahrscheinlichkeit, dass zwei unabhängige und seltene Ereignisse zusammen auftreten, ist das Produkt ihrer Wahrscheinlichkeiten — eine viel kleinere Zahl. In der Praxis potenziert die Redundanz die Zuverlässigkeit: parallele Einheiten hinzuzufügen kann die Neunen verdoppeln oder verdreifachen. Es ist das Prinzip hinter RAID für Festplatten, Server-Clustern, doppelten Stromversorgungssystemen, mehreren Rechenzentren. Vorsicht jedoch bei zwei grundlegenden Bedingungen, ohne die die Magie verschwindet. Erstens müssen die redundanten Einheiten wirklich unabhängig sein: wenn sie einen gemeinsamen Ausfallpunkt teilen (dieselbe Stromversorgung, dasselbe Netzwerk, denselben Softwarefehler), legt ein einziges Ereignis sie alle zusammen lahm und die Redundanz nützt nichts. Zweitens muss der Failover-Mechanismus (der automatische Wechsel zur Backup-Einheit) funktionieren: ein Backup, das sich nicht aktiviert, wenn es gebraucht wird, ist nutzlos. Reale Redundanz erfordert Unabhängigkeit und zuverlässiges Failover. Der Rechner nimmt ideale Redundanz an; in der Praxis bewerten Sie immer die gemeinsamen Ausfallpunkte. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Verfügbarkeit, Zuverlässigkeit und SLA

Im Bereich der Zuverlässigkeit werden Begriffe verwendet, die leicht zu verwechseln sind, die aber präzise und unterschiedliche Bedeutungen haben. Die Verfügbarkeit (Availability), mit der sich dieser Rechner befasst, ist der Prozentsatz der Zeit, in der das System betriebsbereit ist. Es ist die richtige Metrik, wenn das, was zählt, «ist das System da, wenn ich es brauche?» ist. Die Zuverlässigkeit (Reliability) ist ein anderes Konzept: es ist die Wahrscheinlichkeit, dass das System ohne auszufallen für ein ganzes Zeitintervall funktioniert. Ein System kann eine hohe Verfügbarkeit, aber eine niedrige Zuverlässigkeit haben: wenn es oft ausfällt, aber blitzschnell repariert, ist es fast immer verfügbar, aber wenig zuverlässig. Umgekehrt kann eine Einweg-Komponente (wie eine Sicherung) in einer einzigen Mission sehr zuverlässig sein, aber, einmal ausgefallen, null Verfügbarkeit haben, weil sie sich nicht repariert. Die Unterscheidung zählt: für eine Website ist die Verfügbarkeit entscheidend; für eine Raumsonde, die nicht repariert werden kann, ist die Zuverlässigkeit entscheidend. Ein drittes Konzept ist das SLA (Service Level Agreement): die vertragliche Verpflichtung, die ein Anbieter zur Verfügbarkeit eingeht (zum Beispiel «wir garantieren 99,9%»), oft mit Strafen, wenn es nicht eingehalten wird. Das SLA ist ein Geschäftsziel, während die hier berechnete Verfügbarkeit eine technische Schätzung dessen ist, was die Architektur realistisch bieten kann. Die Rolle des Zuverlässigkeitsingenieurs ist, ein System zu entwerfen, dessen geschätzte Verfügbarkeit das versprochene SLA mit Spielraum übertrifft. In der SRE-Kultur spricht man auch von SLO (Objective) und SLI (Indicator): dem internen Ziel und der tatsächlichen Messung. Dieser Rechner hilft Ihnen zu verstehen, ob Ihre Architektur das Ziel halten kann. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Die MTTR reduzieren: erkennen, diagnostizieren, reparieren

Da die Reduktion der MTTR oft der wirksamste und günstigste Hebel zur Verbesserung der Verfügbarkeit ist, lohnt es sich, sie zu zerlegen. Die MTTR ist nicht nur «die Zeit zum Reparieren»: es ist das gesamte Intervall zwischen dem Moment, in dem der Ausfall auftritt, und dem Moment, in dem der Dienst wieder betriebsbereit ist. Sie kann in Phasen zerlegt werden. Die erste ist die Erkennungszeit: wie lange vergeht, bevor jemand (oder etwas) den Ausfall bemerkt. In vielen schlecht überwachten Systemen ist dies der größte Teil der MTTR — der Ausfall tritt um 3 Uhr nachts auf und niemand bemerkt es bis zum Morgen. Gutes Monitoring mit automatischen Alarmen kann die Erkennung von Stunden auf Sekunden reduzieren und ist oft die Investition mit der besten Rendite. Die zweite Phase ist die Diagnose: verstehen, was schiefgelaufen ist und warum. Beobachtbare Systeme (Logs, Metriken, Traces) und Debug-Tools verkürzen diese Phase. Die dritte ist die eigentliche Reparatur: das System wieder in Betrieb nehmen. Automatisierung (automatische Neustarts, Rollback, Auto-Scaling), klare Runbooks, bereite Ersatzteile und geschulte Teams verkürzen sie. Eine vierte, oft vernachlässigte Komponente ist die Aktivierungszeit: wie lange es dauert, bis die richtige Person den Alarm erhält und beginnt, daran zu arbeiten (Bereitschaftsschichten, Eskalation). Die moderne SRE-Kultur investiert stark in all diese Phasen, weil sie von der Annahme ausgeht, dass Ausfälle unvermeidlich sind und dass der wahre Unterschied durch die Wiederherstellungsgeschwindigkeit gemacht wird. Die MTTR zu reduzieren verbessert nicht nur die Verfügbarkeit, sondern reduziert auch die Auswirkung und den Stress jedes Vorfalls. Der Rechner zeigt Ihnen, wie stark die MTTR auf die Verfügbarkeit wiegt: probieren Sie es. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Hohe Verfügbarkeit: Architekturen und Patterns

Hohe Verfügbarkeit (High Availability, HA) zu erreichen — typischerweise «vier Neunen» oder mehr — ist keine Frage eines einzelnen Tricks, sondern einer Reihe architektonischer Patterns, die alle darauf abzielen, die «Single Points of Failure» (SPOF) zu eliminieren, das heißt die Komponenten, deren Ausfall das gesamte System stoppt. Das grundlegende Pattern ist die Redundanz, bereits gesehen: die kritischen Komponenten duplizieren (oder verdreifachen), sodass der Ausfall einer den Dienst nicht stoppt. Aber Redundanz allein reicht nicht: man braucht das Failover, den Mechanismus, der den Ausfall einer Einheit erkennt und die Last automatisch auf die gesunden verschiebt, idealerweise in Sekunden und ohne menschlichen Eingriff. Ein wichtiges Pattern ist die geografische Verteilung: das System in verschiedenen Rechenzentren oder Regionen replizieren, sodass ein lokaler Katastrophenfall (Brand, Überschwemmung, Stromausfall) es nicht lahmlegt — es ist der Grund für die «Availability Zones» und «Regions» der Cloud-Anbieter. Es gibt dann die Unterscheidung zwischen Aktiv-Aktiv-Redundanz (alle Einheiten arbeiten und teilen sich die Last) und Aktiv-Passiv (eine arbeitet, die andere ist in Bereitschaft, bereit zu übernehmen), jede mit ihren eigenen Kompromissen von Kosten und Komplexität. Weitere Elemente der HA umfassen Load Balancing, Health Checks, die die kranken Einheiten erkennen, die Entkopplung der Komponenten (sodass sich der Ausfall einer nicht ausbreitet), und die Fähigkeit, sich anmutig zu degradieren (einen reduzierten Dienst anbieten, statt vollständig zusammenzubrechen). HA zu bauen ist komplex und teuer und muss durch den Wert des Dienstes gerechtfertigt werden: nicht alles verdient fünf Neunen. Dieser Rechner hilft Ihnen zu schätzen, wie viel Verfügbarkeit eine bestimmte architektonische Wahl bringt. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Häufige Fehler in der Verfügbarkeitsberechnung

Die Verfügbarkeit zu berechnen ist einfach, aber sie gut zu interpretieren und anzuwenden erfordert, einige Fallen zu vermeiden. Der erste Fehler ist, die Reihenabhängigkeiten zu ignorieren: die Verfügbarkeit einer Komponente zu schätzen und sie als die des Systems zu präsentieren, wobei man vergisst, dass das System eine Kette ist und dass jede Abhängigkeit das Gesamt senkt. Der zweite ist, anzunehmen, dass die Redundanz perfekt ist: zwei parallele Einheiten als unabhängig zu zählen, wenn sie in Wirklichkeit einen gemeinsamen Ausfallpunkt teilen (dieselbe Stromversorgung, dasselbe Rack, denselben Fehler, denselben Bediener). Korrelierte Ausfälle sind der Feind Nummer eins der hohen Verfügbarkeit, und «Papier»-Redundanz schützt nicht. Der dritte ist, die Erkennungs- und Aktivierungszeit in der MTTR zu vergessen: nur die eigentliche Reparaturzeit zu zählen und die Stunden zu ignorieren, die verloren gehen, um den Ausfall zu bemerken und die Personen zu mobilisieren. Der vierte ist, die nominale MTBF des Herstellers zu verwenden, als wäre sie die Realität der eigenen Umgebung, die sehr unterschiedlich sein kann (Stress, Temperatur, Last). Der fünfte ist, Verfügbarkeit und Zuverlässigkeit zu verwechseln und die falsche Metrik auf das Problem anzuwenden. Der sechste ist, konstante Ausfallraten anzunehmen, wenn viele Komponenten eine «Badewannenkurve» haben (mehr Ausfälle am Anfang und Ende des Lebens). Der siebte ist, die geplante Wartung zu vernachlässigen: Updates und geplante Wartungen sind Ausfallzeit und müssen berücksichtigt (oder mit Techniken wie Zero-Downtime-Deployments vermieden) werden. Diese Fehler zu vermeiden erfordert Rigorosität und Kenntnis des eigenen realen Systems. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Grenzen der Berechnung

Dieser Rechner liefert eine parametrische Schätzung der Verfügbarkeit, keine professionelle Zuverlässigkeitsanalyse noch eine Servicegarantie. Die verwendeten Formeln (A = MTBF/(MTBF+MTTR), Produkt für die Reihe, Komplement für die Redundanz) sind Standard und korrekt, ruhen aber auf wichtigen vereinfachenden Annahmen. Erstens, und am wichtigsten: sie nimmt an, dass die Ausfälle der verschiedenen Komponenten (und der redundanten Einheiten) statistisch unabhängig sind. In der Realität sind die korrelierten Ausfälle — ein fehlerhaftes Update, das alle Repliken kaputtmacht, eine geteilte Stromversorgung, die ausfällt, ein gemeinsamer Softwarefehler, ein menschlicher Fehler — häufig und machen einen großen Teil des Nutzens der Redundanz zunichte; das Modell ignoriert sie und tendiert daher dazu, die Verfügbarkeit redundanter Systeme zu überschätzen. Zweitens: sie nimmt konstante Ausfall- und Reparaturraten an (Exponentialverteilung), während viele Komponenten altern oder eine Frühausfallrate haben. Drittens: die Qualität der Schätzung hängt vollständig von der Genauigkeit Ihrer MTBF und MTTR ab, die oft unsicher oder auf Herstellerdaten basieren, die nicht repräsentativ für Ihre Umgebung sind. Viertens: das Reihen-/Parallelmodell ist vereinfacht; reale Systeme haben komplexe Topologien (k-aus-n, geteilte Abhängigkeiten), die fortgeschrittenere Methoden erfordern (Fehlerbäume, Markov-Ketten, Simulation). Fünftens: es berücksichtigt weder die geplante Wartung noch die Fähigkeit, sich anmutig zu degradieren. Vor allem ersetzt dieses Werkzeug nicht eine Zuverlässigkeitsanalyse (RAMS), die von einem spezialisierten Ingenieur mit rigorosen Methoden und spezifischen Daten durchgeführt wird. Nutzen Sie das Ergebnis, um die Größenordnungen und den Effekt der architektonischen Entscheidungen zu verstehen, nicht als Garantie realer Verfügbarkeit. Dies ist kein professioneller Rat.

Beispiel: wie viel Ausfallzeit kostet

Die Verfügbarkeit ist nicht nur eine technische Zahl: sie übersetzt sich direkt in Geld. Die Tabelle zeigt für hypothetische Ausfallkosten von 1.000 (währungsneutral) für jede Stunde Nichtverfügbarkeit, wie viel Sie jedes Verfügbarkeitsniveau in einem Jahr kostet:

Die Tabelle macht die wirtschaftliche Entscheidung hinter der Wahl des Verfügbarkeitsziels konkret. Von «zwei Neunen» auf «drei Neunen» zu gehen spart in diesem Beispiel fast 80.000 pro Jahr an Ausfallkosten. Aber jede zusätzliche Neun kostet auch mehr in der Umsetzung: die korrekte Logik ist, die Ersparnis der vermiedenen Ausfallzeit mit den Kosten der nötigen Investition zu vergleichen. Das richtige Ziel ist das, wo die Grenzkosten der nächsten Neun dem Grenznutzen der vermiedenen Ausfallzeit entsprechen. Das erklärt, warum verschiedene Dienste verschiedene Ziele haben: wenn eine Stunde Ausfall Sie 100.000 kostet (ein Trading-System, ein E-Commerce an Spitzentagen), sind «fünf Neunen» leicht gerechtfertigt; wenn es Sie 100 kostet, sind «zwei Neunen» mehr als ausreichend. Die Kosten der Ausfallzeit sind nicht nur der während des Ausfalls verlorene Umsatz: sie umfassen auch den Reputationsschaden, die verlorenen Kunden, die vertraglichen Strafen (SLA), die Überstunden für die Wiederherstellung, und manchmal regulatorische Konsequenzen. Eine ehrliche Schätzung der Stundenkosten Ihrer Ausfallzeit ist der Ausgangspunkt, um zu entscheiden, wie viel in die Verfügbarkeit zu investieren ist. Dies ist eine parametrische Schätzung.

Cluster und k-aus-n-Systeme

Die einfache Redundanz («nur 1 Einheit von N nötig») ist nur ein Sonderfall einer breiteren Familie: die k-aus-n-Systeme, in denen mindestens k funktionierende Einheiten von n insgesamt nötig sind. Die Tabelle vergleicht einige Konfigurationen mit Komponenten von je 99,9544%:

Die Tabelle veranschaulicht den Reichtum der Redundanz-Patterns. Die 1-aus-2-Konfiguration ist die klassische «Aktiv-Passiv»- oder «Aktiv-Aktiv»-Redundanz: es reicht, dass eine der beiden Einheiten funktioniert, und die Verfügbarkeit steigt auf fast fünf Neunen. Die 2-aus-3-Konfiguration ist typisch für Systeme, die ein Quorum oder eine Mehrheit zum Funktionieren erfordern — sehr verbreitet in verteilten Systemen, die abstimmen müssen, um konsistente Entscheidungen zu treffen (replizierte Datenbanken, Konsens-Systeme): mindestens 2 der 3 Knoten müssen am Leben sein. Beachten Sie eine interessante Tatsache: 2-aus-3 gibt eine leicht niedrigere Verfügbarkeit als 1-aus-2, weil es eine strengere Bedingung ist (es toleriert einen einzigen Ausfall von drei statt einen von zwei), aber sie bleibt sehr hoch. Am entgegengesetzten Extrem ist 2-aus-2 in Wirklichkeit eine Reihe: beide Einheiten müssen funktionieren, und die Verfügbarkeit sinkt unter die der einzelnen Komponente. Das zeigt, dass «mehr Einheiten» nicht automatisch «zuverlässiger» bedeutet: es hängt davon ab, wie viele zum Funktionieren nötig sind. Der Rechner modelliert den häufigsten Fall (Redundanz «1-aus-n»); für komplexere k-aus-n-Konfigurationen sind kombinatorische Formeln oder dedizierte Methoden nötig. Aber das Prinzip ist klar: die Topologie — wer funktionieren muss, damit das Ganze funktioniert — bestimmt die Verfügbarkeit ebenso wie die Zuverlässigkeit der einzelnen Teile. Dies ist eine parametrische Schätzung.

Das Paradox der Redundanz

Die Redundanz scheint magisch — wir haben gesehen, dass eine einzige Backup-Einheit von drei auf fast sieben Neunen gehen kann — aber in der Praxis enttäuscht sie oft die Erwartungen, aus einem grundlegenden Grund: ihre Wirksamkeit hängt vollständig von einer Annahme ab, die die Berechnung macht, die aber die Realität oft verletzt, der Unabhängigkeit der Ausfälle. Die Redundanzformel funktioniert, weil sie sehr kleine Ausfallwahrscheinlichkeiten multipliziert: wenn eine Einheit eine Ausfallwahrscheinlichkeit von 0,05% hat, sind zwei unabhängige Einheiten beide ausgefallen mit einer Wahrscheinlichkeit von 0,05% × 0,05% = 0,000025%, einer winzigen Zahl. Aber das gilt nur wenn die zwei Ausfälle wirklich unkorreliert sind. In der Realität sind sehr viele Ausfälle korreliert: ein fehlerhaftes Software-Update wird auf alle Repliken verteilt und macht sie alle zusammen kaputt; ein Ausfall der geteilten Stromversorgung oder Kühlung legt das gesamte Rack lahm; ein latenter Bug manifestiert sich gleichzeitig auf allen Instanzen bei demselben Input; ein menschlicher Konfigurationsfehler wird auf alle Einheiten angewandt. In diesen Fällen schützt die «Papier»-Redundanz nicht: zwei Einheiten, die einen gemeinsamen Ausfallpunkt teilen, verhalten sich für diesen Ausfall wie eine einzige. Das ist das Paradox der Redundanz: gerade die Systeme, die entworfen wurden, um ultra-zuverlässig zu sein, können durch ein einziges korreliertes Ereignis fallen, das die gesamte Redundanz umgeht. Die Gegenmaßnahmen sind die reale Unabhängigkeit: getrennte Stromversorgungen, getrennte Netzwerke, verschiedene Rechenzentren, gestaffelte Softwareversionen (um nicht denselben Bug zu verbreiten), Verfahren, die vermeiden, alle Repliken zusammen anzufassen. Für Unabhängigkeit zu entwerfen ist schwieriger, als Kopien hinzuzufügen, und es ist das, was die echte hohe Verfügbarkeit von der nur scheinbaren unterscheidet. Der Rechner nimmt ideale Unabhängigkeit an: in der Realität bewerten Sie immer, was Ihre redundanten Einheiten teilen. Dies ist eine parametrische Schätzung.

Geplante Wartung und Verfügbarkeit

Das auf MTBF und MTTR basierende Verfügbarkeitsmodell erfasst die ungeplante Ausfallzeit, das heißt die Ausfälle. Aber im realen Leben eines Systems gibt es eine weitere zu berücksichtigende Quelle der Nichtverfügbarkeit: die geplante Wartung. Software-Updates, Sicherheitspatches, Hardware-Upgrades, Migrationen, geplante Neustarts: all diese Aktivitäten sind, wenn sie das Stoppen des Systems erfordern, in jeder Hinsicht Ausfallzeit, auch wenn «freiwillig». Historisch wurde zwischen geplanter Ausfallzeit (von den SLAs ausgeschlossen, weil in nächtlichen Wartungsfenstern vereinbart) und ungeplanter (der für die Zuverlässigkeit zählenden) unterschieden. Aber für einen globalen Dienst existiert «nachts» nicht — irgendwo ist immer Tag — und die Nutzer unterscheiden einen geplanten Ausfall nicht von einem Ausfall: für sie ist der Dienst sowieso down. Deshalb ist der moderne Trend, besonders in der Cloud- und SRE-Welt, auf null geplante Ausfallzeit abzuzielen, mit Techniken, die es erlauben, ohne das Stoppen des Dienstes zu aktualisieren und zu warten: schrittweise Deployments (Rolling Update, wo wenige Instanzen auf einmal aktualisiert werden, während die anderen den Verkehr bedienen), Blue-Green-Deployment (zwei Umgebungen, die sich abwechseln), Canary Release (Rollout an einen kleinen Bruchteil der Nutzer vor der Verallgemeinerung), und die Redundanz selbst (eine Einheit wird gewartet, während die anderen arbeiten). Diese Techniken verwandeln die Wartung von einer Ausfallquelle in eine transparente Operation. Wenn Sie eine Verfügbarkeit berechnen oder versprechen, fragen Sie sich immer: schließt sie die geplante Wartung ein oder aus? Und ist Ihr System darauf ausgelegt, sich ohne Stopp zu warten? Dieser Rechner modelliert die Ausfallzeit durch Ausfälle; addieren Sie gedanklich die eventuelle Wartungsausfallzeit, wenn Ihr System sie erfordert. Dies ist eine parametrische Schätzung.

Fragen, die man sich vor der Festlegung eines Ziels stellen sollte

Bevor Sie sich auf ein Verfügbarkeitsziel festlegen (oder es in einem SLA versprechen), stellen Sie sich einige Fragen, die eine Zahl in eine bewusste Entscheidung verwandeln. Wie viel kostet eine Stunde Ausfallzeit wirklich? Summieren Sie verlorenen Umsatz, Reputationsschaden, Strafen, Wiederherstellungskosten: es ist der Parameter, der jede Investition in Zuverlässigkeit rechtfertigt. Habe ich alle Reihenabhängigkeiten berücksichtigt? Die Verfügbarkeit des Systems ist die der vollständigen Kette, nicht der einzelnen besten Komponente. Ist meine Redundanz wirklich unabhängig? Was teilen die Backup-Einheiten — Stromversorgung, Netzwerk, Software, Bediener? Gemeinsame Ausfallpunkte machen die Redundanz zunichte. Sind meine MTBF und MTTR realistisch? Sind sie auf meiner Umgebung gemessen oder aus den optimistischen Herstellerdatenblättern genommen? Schließe ich die geplante Wartung ein? Aktualisiert sich mein System ohne Stopp? Schließt meine MTTR die Erkennungszeit ein? Oft ist das Bemerken des Ausfalls langsamer als das Reparieren. Ist das Ziel durch den Wert des Dienstes gerechtfertigt? Nicht alles verdient fünf Neunen; jede Neun kostet exponentiell mehr. Habe ich einen Plan für korrelierte Ausfälle und Katastrophen? Geografische Verteilung und Resilienztests (Chaos Engineering) zählen ebenso wie Redundanz. Diese Fragen zu beantworten verwandelt die Berechnung in eine Zuverlässigkeitsstrategie. Für ein kritisches Ziel verlassen Sie sich auf einen Zuverlässigkeitsingenieur und eine rigorose RAMS-Analyse. Dies ist eine parametrische Schätzung, keine professionelle Zuverlässigkeitsanalyse.

Häufig gestellte Fragen

Was ist die Verfügbarkeit eines Systems?

Es ist der Prozentsatz der Zeit, in der ein System betriebsbereit und einsatzbereit ist. Sie wird als A = MTBF / (MTBF + MTTR) berechnet, das heißt die Betriebszeit geteilt durch die Gesamtzeit (Betrieb + Reparatur). Sie wird in Prozent oder in Anzahl von «Neunen» ausgedrückt: 99,9% = «drei Neunen». Es ist die Schlüsselmetrik für Dienste, die verfügbar sein müssen, wenn sie gebraucht werden, von Cloud-Diensten bis zu kritischen Infrastrukturen.

Was sind MTBF und MTTR?

Die MTBF (Mean Time Between Failures) ist die mittlere Betriebszeit zwischen einem Ausfall und dem nächsten: je höher, desto zuverlässiger das System. Die MTTR (Mean Time To Repair) ist die mittlere Zeit, um das System nach einem Ausfall zu reparieren: je niedriger, desto schneller erholt man sich. Die Verfügbarkeit hängt von ihrem Verhältnis ab, nicht von den absoluten Werten.

Was sind die «Neunen»?

Es ist eine bequeme Art, die Verfügbarkeit auszudrücken, indem man die Ziffern 9 zählt: 99% sind «zwei Neunen», 99,9% sind «drei Neunen», 99,99% sind «vier Neunen». Jede zusätzliche Neun reduziert die Ausfallzeit um das Zehnfache: 99% = 3,65 Tage Ausfall pro Jahr, 99,9% = 8,76 Stunden, 99,99% = 52,6 Minuten. Es ist eine universelle Sprache unter Ingenieuren jedes Landes.

Warum reduzieren Komponenten in Reihe die Verfügbarkeit?

Weil in einer Reihenkonfiguration alle Komponenten funktionieren müssen: das System fällt aus, wenn auch nur eine einzige ausfällt («schwaches Glied»). Die Gesamtverfügbarkeit ist das Produkt der einzelnen, sodass zuverlässige Komponenten zusammenzusetzen ein System produziert, das weniger zuverlässig ist als jede von ihnen. Beispiel: 5 Komponenten bei 99,9% geben 0,999⁵ = 99,5%, unter «drei Neunen».

Wie funktioniert die Redundanz?

Die Redundanz schaltet Einheiten parallel, die sich gegenseitig ersetzen: der Block fällt nur aus, wenn alle Einheiten gleichzeitig ausfallen. Da die Wahrscheinlichkeit unabhängiger gleichzeitiger Ausfälle das Produkt der Wahrscheinlichkeiten ist (eine sehr kleine Zahl), «potenziert» die Redundanz die Zuverlässigkeit. Im Standard geht das Hinzufügen einer einzigen Backup-Einheit von 3,34 auf 6,68 Neunen: die Ausfallzeit bricht von 4 Stunden auf ~7 Sekunden pro Jahr ein.

Besser die MTBF erhöhen oder die MTTR reduzieren?

Mathematisch sind sie äquivalent: die MTTR zu halbieren hat denselben Effekt wie die MTBF zu verdoppeln, weil die Verfügbarkeit von ihrem Verhältnis abhängt. Aber in der Praxis ist die MTTR zu reduzieren (schneller reparieren mit Monitoring und Automatisierung) oft einfacher und günstiger als die MTBF zu erhöhen (die Komponenten zuverlässiger machen). Deshalb betont die moderne SRE-Kultur die Wiederherstellungsgeschwindigkeit.

Was ist der Unterschied zwischen Verfügbarkeit und Zuverlässigkeit?

Die Verfügbarkeit ist der Prozentsatz der Zeit, in der das System betriebsbereit ist. Die Zuverlässigkeit ist die Wahrscheinlichkeit, ohne auszufallen für ein ganzes Intervall zu funktionieren. Ein System kann eine hohe Verfügbarkeit, aber eine niedrige Zuverlässigkeit haben (fällt oft aus, aber repariert blitzschnell). Für eine Website zählt die Verfügbarkeit; für eine nicht reparierbare Raumsonde zählt die Zuverlässigkeit.

Was ist ein SLA und wie hängt es mit der Verfügbarkeit zusammen?

Das SLA (Service Level Agreement) ist die vertragliche Verpflichtung, die ein Anbieter zur Verfügbarkeit eingeht (z.B. «wir garantieren 99,9%»), oft mit Strafen, wenn es nicht eingehalten wird. Es ist ein Geschäftsziel, während die hier berechnete Verfügbarkeit eine technische Schätzung dessen ist, was die Architektur bieten kann. Ein gutes Design hat eine geschätzte Verfügbarkeit, die das versprochene SLA mit Spielraum übertrifft.

Warum ist jede zusätzliche «Neun» so teuer?

Weil jede Neun die Ausfallzeit um das Zehnfache reduziert, und die Ausfallzeit exponentiell zu reduzieren erfordert wachsende Investitionen. Von zwei auf drei Neunen zu gehen kann mit gutem Monitoring reichen; von vier auf fünf Neunen zu gehen erfordert vollständige Redundanz, automatisches Failover in Sekunden und 24/7-Teams. Die Wahl des Ziels ist eine wirtschaftliche Entscheidung: die Kosten jeder Neun gegen die Kosten der vermiedenen Ausfallzeit abwägen.

Berücksichtigt die Berechnung korrelierte Ausfälle?

Nein, und das ist ihre Hauptgrenze. Das Modell nimmt unabhängige Ausfälle an. In der Realität sind korrelierte Ausfälle — ein fehlerhaftes Update, das alle Repliken kaputtmacht, eine geteilte Stromversorgung, die ausfällt, ein gemeinsamer Fehler, ein menschlicher Fehler — häufig und machen einen großen Teil des Nutzens der Redundanz zunichte. Deshalb tendiert das Modell dazu, die Verfügbarkeit redundanter Systeme zu überschätzen: bewerten Sie immer die gemeinsamen Ausfallpunkte.

Wie reduziert man die MTTR in der Praxis?

Durch Zerlegung der Wiederherstellungszeit: (1) Erkennung — gutes Monitoring mit automatischen Alarmen reduziert die Zeit, den Ausfall zu bemerken, von Stunden auf Sekunden; (2) Diagnose — Logs, Metriken und Traces verkürzen das Verstehen, was passiert ist; (3) Reparatur — Automatisierung, Runbooks und geschulte Teams; (4) Aktivierung — wirksame Bereitschaftsschichten und Eskalation. Oft ist die Erkennung der größte Teil und der am leichtesten zu reduzierende.

Welchen Verfügbarkeitswert sollte ich anstreben?

Es hängt vom Wert des Dienstes und den Kosten der Ausfallzeit ab. Für einen persönlichen Blog sind «zwei Neunen» (99%) in Ordnung. Für eine Geschäftsanwendung ist «drei Neunen» (99,9%) der gängige Standard. Für Zahlungssysteme, kritische Cloud-Dienste oder Infrastrukturen braucht man «vier oder fünf Neunen». Es gibt keinen universellen richtigen Wert: wägen Sie die Kosten jeder zusätzlichen Neun gegen die Kosten der Ausfallzeit ab, die Sie vermeiden.

Ersetzt dieser Rechner eine professionelle Zuverlässigkeitsanalyse?

Nein. Er liefert eine parametrische Schätzung basierend auf Standardformeln (Reihe, Parallel), nützlich, um die Größenordnungen und den Effekt der architektonischen Entscheidungen zu verstehen. Aber er nimmt unabhängige Ausfälle und konstante Raten an, modelliert keine komplexen Topologien (k-aus-n, geteilte Abhängigkeiten) noch die geplante Wartung. Für eine offizielle RAMS-Analyse sind rigorose Methoden (Fehlerbäume, Markov-Ketten, Simulation) und ein spezialisierter Ingenieur mit spezifischen Daten nötig.

Aktualisiert im Juli 2026