Uptime ist der Anteil der Zeit, in der ein System läuft und erreichbar ist, meist als Prozentwert wie 99,9 Prozent angegeben. Verfügbarkeit ist das umfassendere Maß dafür, ob ein Service seine Nutzer erfolgreich bedient, häufig berechnet als erfolgreiche Requests geteilt durch alle Requests. Jede zusätzliche Neun senkt die erlaubte Ausfallzeit um den Faktor zehn.
Was ist Uptime?
Uptime ist der prozentuale Anteil eines Zeitraums, in dem ein Service in Betrieb ist. War ein Service in einem Monat mit 30 Tagen 43 Minuten lang nicht erreichbar, lag seine Uptime bei 99,9 Prozent. Der Begriff ist in Hosting-Verträgen und auf Statusseiten verbreitet und leicht zu kommunizieren.
Verfügbarkeit ist das präzisere Konzept, mit dem Engineers arbeiten. Ein Service kann „up“ sein, weil sein Prozess läuft und der Health-Endpunkt antwortet, während er die Hälfte aller Checkout-Requests mit Fehlern beantwortet. Verfügbarkeit fragt deshalb, ob der Service seine Aufgabe für Nutzer erfüllt hat, und wird meist als Verhältnis gemessen:
- Zeitbasiert: gute Minuten geteilt durch alle Minuten, wobei eine Minute als schlecht gilt, wenn etwa Fehlerrate oder Latenz einen Schwellenwert überschreiten.
- Request-basiert: erfolgreiche Requests geteilt durch gültige Requests. Stark ausgelastete Stunden zählen so mehr als ruhige, was dem Nutzererleben näherkommt.
Die Neunen: erlaubte Ausfallzeit je Verfügbarkeitsziel
Die Tabelle zeigt die maximale Ausfallzeit für gängige Ziele, bezogen auf ein Jahr mit 365 Tagen, einen Monat mit 30 Tagen und eine Woche mit 7 Tagen.
| Verfügbarkeit | Pro Jahr | Pro Monat (30 Tage) | Pro Woche |
|---|---|---|---|
| 99 % („zwei Neunen“) | 3,65 Tage (87,6 h) | 7,2 h | 1 h 40,8 min |
| 99,5 % | 1,83 Tage (43,8 h) | 3,6 h | 50,4 min |
| 99,9 % („drei Neunen“) | 8,76 h | 43,2 min | 10,08 min |
| 99,95 % | 4,38 h | 21,6 min | 5,04 min |
| 99,99 % („vier Neunen“) | 52,56 min | 4,32 min | 60,48 s |
| 99,999 % („fünf Neunen“) | 5,26 min | 25,92 s | 6,05 s |
Die Formel ist einfach: erlaubte Ausfallzeit = (1 − Verfügbarkeit) × Zeitraum. Bei vier Neunen verbraucht ein einziger Incident, dessen Erkennung und Behebung 15 Minuten dauert, mehr als das Budget von drei Monaten. Höhere Ziele erfordern daher automatisierte Erkennung und Behebung, nicht nur schnellere Menschen.
Wie sich Abhängigkeiten multiplizieren
Ein Request, der mehrere Komponenten nacheinander durchlaufen muss, kann höchstens so verfügbar sein wie das Produkt ihrer Verfügbarkeiten. Drei unabhängige Services mit je 99,9 Prozent ergeben 0,999 × 0,999 × 0,999, also rund 99,70 Prozent Ende-zu-Ende. Ein Service mit 99,9 Prozent, der von einer Datenbank mit 99,95 Prozent abhängt, erreicht höchstens etwa 99,85 Prozent.
Redundanz wirkt umgekehrt. Zwei unabhängige Replikate mit je 99,9 Prozent, von denen jedes den Request bedienen kann, ergeben 1 − (0,001 × 0,001) = 99,9999 Prozent, solange die Ausfälle wirklich unabhängig sind. In der Praxis sind sie das selten: Gemeinsame Konfiguration, Deployments, Regionen und DNS erzeugen korrelierte Ausfälle. Deshalb garantiert Redundanz allein keine Hochverfügbarkeit.
So messen Sie Verfügbarkeit
- Serverseitige SLIs: Erfolgsquoten aus Load-Balancer- oder Service-Metriken berechnen; präzise und günstig, aber blind für Probleme, bevor der Request bei Ihnen ankommt.
- Synthetisches Monitoring: Skriptbasierte Checks von mehreren Standorten erkennen Ausfälle auch ohne Traffic und prüfen DNS, TLS und CDN-Pfade.
- Real User Monitoring: zeigt, was echte Nutzer erlebt haben, einschließlich clientseitiger Fehler.
Kombinieren Sie die Verfahren: synthetische Checks für schnelle Erkennung, request-basierte SLIs für das SLO und Nutzerdaten, um beides zu validieren. Einfache Liveness Probes und Health Checks sind für die Orchestrierung nützlich, für sich genommen aber kein Maß für Verfügbarkeit.
Uptime in SLAs und SLOs
Ein SLA ist eine vertragliche Zusage mit Konsequenzen, meist Gutschriften, wenn die Verfügbarkeit unter einen Schwellenwert fällt. Ein SLO ist ein internes Ziel, in der Regel strenger als das SLA, das dem Team ein Error Budget gibt. Lesen Sie SLA-Definitionen genau: Was zählt als Ausfall, ist geplante Wartung ausgenommen, wie wird gemessen und über welchen Zeitraum?
Best Practices und typische Fehler
- Das Ziel aus Nutzerbedarf und Abhängigkeiten ableiten, nicht aus Ehrgeiz. Ein Service kann nicht verfügbarer sein als die Abhängigkeiten, die er nacheinander aufruft.
- Teilausfälle mitzählen. Fällt eine Region oder ein Kundensegment aus, ist das für diese Nutzer Ausfallzeit, auch wenn der globale Durchschnitt gut aussieht.
- Dort messen, wo die Nutzer sind. Monitoring aus demselben Rechenzentrum übersieht Ausfälle bei DNS, CDN und Netzwerk.
- Sich nicht hinter Wartungsfenstern verstecken. Geplante Ausfallzeiten auszuklammern verschönert Berichte, ändert aber nichts an dem, was Nutzer erlebt haben.
- In die Wiederherstellung investieren. Ausfallzeit ist grob die Zahl der Incidents mal der Zeit bis zur Wiederherstellung. Schnellere Erkennung und Rollbacks helfen daher oft mehr, als jeden einzelnen Fehler zu verhindern.
Wie Obseria unterstützt
Obseria misst Verfügbarkeit aus serverseitigen Metriken, synthetischen Checks von über 50 Standorten und Real User Monitoring und macht daraus SLOs mit Error Budgets und Burn-Rate-Alerts. Öffentliche oder interne Statusseiten kommunizieren Incidents, und die Obseria-Plattform selbst wird mit einem SLA von 99,95 Prozent angeboten. Wie Sie die verbleibende Ausfallzeit verkürzen, lesen Sie im Artikel zur MTTR.
