Verfügbarkeit berechnen: die Neun-Regel

Hier geht's um den Königsweg der Systemverlässlichkeit: Wie sorgst du dafür, dass IT-Systeme nie ausfallen? Wie misst man Verfügbarkeit überhaupt? Was bedeuten die berühmten „fünf Neunen"? Und was passiert wenn es trotzdem kracht?

Die erste Lektion startet mit dem Fundament: Verfügbarkeit berechnen. Bevor du über USV, Cluster oder Failover redest, musst du verstehen was 99,9% Uptime eigentlich heißt, wie man Verfügbarkeit komponiert, und warum jede zusätzliche „Neun" exponentiell teurer wird. Dieses Wissen brauchst du in jedem SLA-Gespräch, in der IHK-Prüfung und in Architektur-Entscheidungen.

1) Was ist Verfügbarkeit überhaupt?

Die Verfügbarkeit (englisch: Availability) eines Systems ist das Verhältnis der Zeit, in der es korrekt funktioniert, zur Gesamtzeit. Üblicherweise ausgedrückt als Prozentwert. Ein System mit 99% Verfügbarkeit funktioniert in 99 von 100 Stunden – die fehlende Stunde ist Ausfallzeit (Downtime).

Die Formel ist denkbar einfach:

2) Die Neun-Regel – berühmte Schwellenwerte

In der IT-Branche werden Verfügbarkeits-Klassen mit der Anzahl der Neunen ausgedrückt. „Drei Neunen" bedeutet 99,9%, „fünf Neunen" 99,999%. Mit jeder zusätzlichen Neun reduziert sich die erlaubte Ausfallzeit um den Faktor 10. Hier die Übersicht:

3) Die Tabelle in der Praxis nutzen

Hinter der Neun-Tabelle steckt eine einfache Mathematik. Lass uns das nachvollziehen. Ein Jahr hat:

• 365 Tage × 24 Stunden = 8.760 Stunden
• 8.760 × 60 = 525.600 Minuten
• 525.600 × 60 = 31.536.000 Sekunden

Davon ist 99,9% = 8.751,24 Stunden „up". Die Differenz von 8,76 Stunden ist die maximal akzeptable Downtime. Hier zwei konkrete Rechnungen:

4) Visualisierung als Uptime-Bar

Damit du ein Gefühl bekommst, wie wenig „99%" eigentlich ist – hier die Klassen als Balken nebeneinander. Die Skala ist absichtlich nicht-linear, da sonst alle ab 99% gleich aussehen würden:

5) Geplante vs. ungeplante Downtime

Eine wichtige Unterscheidung im SLA-Vertragstext: zählt geplante Wartung als Downtime oder nicht? Beide Sichtweisen existieren:

• Nur ungeplante Downtime zählt: Wartungsfenster sind vereinbart und werden nicht eingerechnet. Häufig bei klassischen Hosting-Anbietern. SLA leichter erreichbar.
• Alle Downtime zählt: jede Minute, in der das System nicht voll funktioniert, ist Downtime – egal ob geplant. Strenger, üblich bei Cloud-Hyperscalern und kritischen Systemen.

In modernen Architekturen mit Rolling Updates (siehe K55) und Zero-Downtime-Deployments ist die Unterscheidung weniger relevant – Wartung passiert ohne sichtbare Auswirkung. Bei klassischen Setups muss man genau lesen was im Vertrag steht.

6) Verfügbarkeit messen vs. zusichern

Zwei verwandte aber unterschiedliche Konzepte:

• Tatsächliche Verfügbarkeit (gemessen): was war im vergangenen Jahr wirklich der Wert? Aus Monitoring-Daten berechnet.
• Zugesicherte Verfügbarkeit (SLA): was verspricht der Anbieter vertraglich? Mit Strafen bei Unterschreitung.

Eine zugesicherte 99,9% Verfügbarkeit ist nicht garantiert – sondern eine Vertragsklausel. Bei Nichterreichung gibt's typischerweise Service Credits (Gutschrift in Prozent der Monatsgebühr). Das deckt aber selten die echten Schäden bei Ausfällen ab.

7) SLAs großer Anbieter

Wie viel Verfügbarkeit versprechen die Hyperscaler? Ein Auszug der wichtigsten Cloud-SLAs (Stand 2024/2025, kann sich ändern):

8) Verfügbarkeit kombinieren – das Komponieren

Spannend wird's wenn mehrere Komponenten beteiligt sind. Eine Web-Anwendung besteht aus Frontend-Server, Datenbank, Load Balancer, Netzwerk. Wie berechnet sich die Gesamt-Verfügbarkeit?

Bei serieller Verkettung (alle müssen funktionieren) multiplizieren sich die Einzel-Verfügbarkeiten:

Bei paralleler Redundanz (einer reicht aus) ist die Berechnung anders. Die Ausfallwahrscheinlichkeiten multiplizieren sich:

9) Wichtiger Vorbehalt: unabhängige Ausfälle

Die obige Redundanz-Rechnung gilt nur wenn die Ausfälle unabhängig voneinander sind. In der Praxis ist das oft nicht der Fall:

• Zwei Server im selben Rack → gleicher Stromkreis → korrelierter Ausfall
• Zwei Festplatten aus derselben Charge → gleiche Materialfehler → korrelierter Ausfall
• Zwei VMs auf dem selben Hypervisor → Host-Ausfall trifft beide
• Zwei Server im gleichen Rechenzentrum → Brand betrifft beide
• Zwei Anbieter mit gleicher Software-Version → gleicher Bug

Echte Hochverfügbarkeit erfordert echte Unabhängigkeit: verschiedene Racks, verschiedene Stromkreise, verschiedene Hardware-Chargen, verschiedene Rechenzentren, verschiedene Software-Versionen oder gar Anbieter. Das ist teuer, aber unausweichlich für hohe SLA-Klassen.

10) Was kostet eine zusätzliche Neun?

Eine alte Branchen-Faustregel: jede zusätzliche Neun verdoppelt mindestens die Kosten der Infrastruktur. Von 99% auf 99,9% relativ günstig, von 99,99% auf 99,999% schon sehr teuer. Konkrete Beispiele:

Daher die Faustregel: Verfügbarkeits-Anforderungen nicht überspezifizieren. „Wir wollen fünf Neunen" klingt cool, kostet aber das 15-fache der Standard-Infrastruktur. Realistisch fragen: wie viel Downtime können wir tolerieren? Wie viel kostet uns 1 Stunde Ausfall? Daraus folgt das angemessene SLA-Ziel.

11) SLA, SLO, SLI – die drei Begriffe

Drei verwandte Abkürzungen, die du in modernen Setups (besonders DevOps, Site Reliability Engineering) hörst:

• SLI – Service Level Indicator: eine konkrete Metrik, die du misst. Z.B. „Verfügbarkeit der API in Prozent", „Latenz unter 200ms in %".
• SLO – Service Level Objective: das interne Ziel für eine SLI. Z.B. „SLI Verfügbarkeit ≥ 99,95%". Wird ständig überwacht.
• SLA – Service Level Agreement: vertragliche Zusage gegenüber Kunden, oft mit Strafen. Konservativer als SLO. Z.B. „99,9% Verfügbarkeit, sonst 10% Gutschrift".

Best Practice: SLO ist immer strenger als SLA (Puffer für interne Probleme bevor der Kunde betroffen ist). SLIs werden in Monitoring-Dashboards (Grafana, Datadog) live verfolgt.

12) Error Budget – Verfügbarkeit als Werkzeug

Ein modernes Konzept aus Google's Site Reliability Engineering: das Error Budget. Wenn dein SLO 99,9% ist, hast du ein „Budget" von 0,1% Downtime – das sind etwa 43 Minuten pro Monat. Solange du im Budget bist, kannst du:

• Risikoreiche Deployments machen
• Features schneller ausrollen
• Wartungen durchführen

Wenn das Budget aufgebraucht ist, friert die Entwicklung weitere Risiken ein – Fokus auf Stabilität. Diese Sichtweise verbindet Verfügbarkeit mit Geschäfts-Entscheidungen: 100% Verfügbarkeit ist nicht das Ziel (zu teuer, zu langsam), sondern das vereinbarte Niveau einzuhalten – und das Budget bewusst zu nutzen.

13) Was du in K59 lernst

K59 baut auf diesem Verständnis auf. Die weiteren Lektionen zeigen, wie man Verfügbarkeit erreicht:

• L2 – MTBF und MTTR: die zwei Kennzahlen die Verfügbarkeit messbar machen
• L3 – SPoF identifizieren: die Achillesferse jedes Systems
• L4 – USV: Schutz vor Stromausfällen
• L5 – Load Balancing: Last verteilen, Redundanz nutzen
• L6 – Clustering: Active-Active vs. Active-Passive
• L7 – Failover: automatischer Wechsel im Notfall
• L8 – Disaster-Recovery-Plan: was tun wenn alles ausfällt?
• L9 – Business Continuity Plan: Geschäftsbetrieb sichern
• L10 – IHK-Aufgaben

K59 ergänzt K57 (RAID) für Storage-Verfügbarkeit und K58 (Backup) für Datenwiederherstellung. Drei Kurse, die zusammen die Säulen der Daten- und System-Sicherheit bilden.

Zusammenfassung

Verfügbarkeit = Uptime / (Uptime + Downtime) oder MTBF / (MTBF + MTTR). Ausgedrückt in Prozent. Neun-Regel: 99% = 3,65 Tage Downtime/Jahr, 99,9% = 8h45min, 99,99% = 52min, 99,999% = 5min, 99,9999% = 32 Sek. Jede zusätzliche Neun reduziert Downtime um Faktor 10. Berechnung: Stunden/Jahr × (1 − SLA-Wert). Geplant vs. ungeplant: SLA-Vertrag genau lesen, was als Downtime zählt. SLAs großer Anbieter: AWS/Azure/GCP meist 99,99% bei Multi-AZ, Single 99,5-99,9%. Komposition: serielle Komponenten multiplizieren (Gesamt schlechter als Einzel), parallele Redundanz multipliziert Ausfallwahrscheinlichkeiten (Gesamt besser). Voraussetzung: echte Unabhängigkeit (verschiedene Racks, Stromkreise, RZ). Kosten: jede Neun verdoppelt mindestens Kosten. SLI/SLO/SLA: gemessene Metrik / internes Ziel / vertragliche Zusage. Error Budget: 100% Verfügbarkeit ist nicht das Ziel – das vereinbarte Niveau einhalten und Budget bewusst nutzen.