Uptime Calculator
Uptime Calculator
Berechne die Verfügbarkeit (SLA/SLO) von Servern und Diensten. Mit Ausfallzeiten-Budget, Monats-, Wochen- und Jahresansicht von 90% bis 99.999%.
Datenschutz-Garantie: Alle Berechnungen erfolgen zu 100% lokal in deinem Browser. Es werden keine Daten an Server gesendet. Perfekt für SREs, Systemadministratoren und DevOps-Engineers.
Inhaltsverzeichnis
Schnellübersicht
- SLA-Rechner: Verfügbarkeit in Ausfallzeit umrechnen
- Reverse-Rechner: Aus Ausfallzeit die Verfügbarkeit berechnen
- SLA-Klassen: 90%, 95%, 99%, 99.9%, 99.99%, 99.999%
- Zeiträume: Tag, Woche, Monat, Quartal, Jahr
- Downtime-Budget: Wieviel Ausfall ist erlaubt?
- Theorie: Was ist ein SLA? (Anfängerfreundlich)
- Geschichte: Von Telefon zu Cloud-SLA
- FAQ: Häufige Fragen zu Verfügbarkeit
1. Uptime Calculator
Berechne die Verfügbarkeit in Ausfallzeit – oder umgekehrt.
- Ein Monat hat 43.200 Minuten (30 Tage × 24 h × 60 min).
- Bei 43,2 Minuten Ausfall sind das 99,9% Verfügbarkeit.
- Bei 4,32 Minuten Ausfall sind das 99,99% Verfügbarkeit.
- Bei 26 Sekunden Ausfall sind das 99,999% Verfügbarkeit.
| SLA | Verfügbarkeit | Ausfallzeit | Kategorie | Beispiel |
|---|
- Zwischen 99% und 99,9% liegt der Faktor 10 – 3,65 Tage vs. 8,76 Stunden.
- Zwischen 99,9% und 99,99% liegt wiederum der Faktor 10 – 8,76 Stunden vs. 52,56 Minuten.
- Jede zusätzliche "9" macht die Umsetzung erheblich teurer.
- Die 99,999% ("Five Nines") Verfügbarkeit ist der Industriestandard für kritische Systeme.
- Bei 99,9% Verfügbarkeit ist mehr als ein Arbeitstag Ausfall pro Jahr erlaubt.
- Die berühmte AWS S3 hat ein SLA von 99,9% – gemessen monatlich.
- Moderne Cloud-Anbieter garantieren zwischen 99,9% und 99,99% – selten mehr.
- Google Cloud Spanner ist der einzige Dienst mit 99,999% SLA weltweit.
- Eine "Neun" mehr bedeutet meist 10x höhere Kosten für Redundanz, Monitoring und Personal.
2. Theorie – Verfügbarkeit einfach erklärt
Verstehe die Grundlagen von SLA, SLO und Verfügbarkeit – ohne Vorkenntnisse.
Was ist Uptime / Verfügbarkeit?
Verfügbarkeit ist der Anteil der Zeit, in der ein System nutzbar ist:
- Formel: (Gesamtzeit − Ausfallzeit) / Gesamtzeit × 100
- Einheit: Prozent (z.B. 99,9%)
- Gegenteil: Downtime = Ausfallzeit
- Messung: Meist monatlich
Warum sind SLAs wichtig?
SLAs regeln das Verhältnis zwischen Anbieter und Kunde:
- Vertraglich: Verbindliche Zusicherung
- Erwartung: Klare Messgröße
- Konsequenz: Rückerstattung bei Verstoß
- Planung: Budget für Ausfälle
- Wettbewerb: Vergleich zwischen Anbietern
SLA vs. SLO vs. SLI
Die drei Begriffe werden oft verwechselt:
- SLI (Indicator): Gemessener Wert (z.B. 99,95%)
- SLO (Objective): Zielwert (z.B. 99,9%)
- SLA (Agreement): Vertraglich zugesichert (z.B. 99,5%)
- Error Budget: Erlaubter Ausfall (100% − SLO)
Tipps zur SLA-Wahl
- Realistisch bleiben: 99,999% ist teuer
- Kritikalität: Nicht jedes System braucht 5 Nines
- Messung: Klar definieren, was "verfügbar" ist
- Error Budget: Für Innovation nutzen
- Monitoring: Ohne Messung keine SLA
- Wartungsfenster: Vorher vertraglich regeln
Wussten Sie schon? Die "Nine"-Skala stammt ursprünglich aus der Telekommunikationsbranche der 1980er Jahre. Ein Festnetztelefon musste damals 99,99% verfügbar sein – das entspricht 52 Minuten Ausfall pro Jahr. Heute ist die 99,999%-Klasse (5 Minuten pro Jahr) der Goldstandard für kritische Infrastruktur. Kurios: Nur Google Cloud Spanner und Amazons DynamoDB haben ein SLA von 99,999% – die meisten anderen Cloud-Dienste bleiben bei 99,9% bis 99,99%. Der Grund: Um eine zusätzliche Neun zu erreichen, muss man die Kosten für Redundanz oft verzehnfachen.
3. Geschichte der Verfügbarkeits-SLAs
Von Telefonnetzen zu Cloud-nativen SLAs.
Telekommunikations-SLAs
Die ersten SLAs entstehen in der Telekommunikationsbranche. Telefonnetze mussten extrem zuverlässig sein – der Begriff "Five Nines" (99,999%) wird geprägt.
IT-Outsourcing
Mit dem Aufstieg des IT-Outsourcings (EDS, IBM Global Services) werden SLAs zum Standard in Unternehmensverträgen. Klare Definitionen von Verfügbarkeit und Reaktionszeiten entstehen.
Amazon Web Services
AWS startet und führt transparente SLAs für Cloud-Dienste ein. Erstmals können Kunden die Verfügbarkeit ihres Anbieters nachvollziehen und Vergleiche anstellen.
ITIL v3
ITIL v3 standardisiert Service-Level-Management als eigenen Prozess. SLAs werden als wesentlicher Bestandteil des IT-Service-Managements etabliert.
SRE & Error Budgets
Google veröffentlicht sein Buch "Site Reliability Engineering" – und etabliert Error Budgets als Konzept: SLI/SLO/Error-Budget statt reiner SLA-Verträge.
Cloud-übergreifende SLAs
Multi-Cloud-Strategien und Cloud-übergreifende SLAs werden populär. Unternehmen fordern einheitliche Verfügbarkeitsgarantien über AWS, Azure und GCP hinweg.
Data-Driven Availability
Moderne Verfügbarkeit ist datengetrieben: Observability, Tracing, Error Budgets und Chaos Engineering werden Standard. DevOps-Teams steuern die Zuverlässigkeit aktiv.
4. FAQ – Spannende Fragen & Antworten
Häufige Fragen zur Verfügbarkeit
Die "Nine"-Skala beschreibt die Anzahl der Neunen in der Verfügbarkeitsangabe:
| Bezeichnung | Verfügbarkeit | Ausfall/Monat |
|---|---|---|
| One Nine | 90% | 72 Stunden |
| Two Nines | 99% | 7,2 Stunden |
| Three Nines | 99,9% | 43,2 Minuten |
| Four Nines | 99,99% | 4,32 Minuten |
| Five Nines | 99,999% | 26 Sekunden |
Faustregel: Jede zusätzliche Neun bedeutet 10x weniger Ausfall – aber auch 10x höhere Kosten!
Praxis-Empfehlungen:
- 99%: Interne Tools, Dev-Umgebungen
- 99,9%: Standard-Produktion, Webanwendungen
- 99,99%: Kritische Business-Anwendungen
- 99,999%: Zahlungssysteme, Notfalldienste
Die Verfügbarkeitsmessung ist komplexer als sie scheint:
Verschiedene Messmethoden:
- Uptime-Roboter: Externe Systeme testen die Erreichbarkeit von außen
- Monitoring: Interne Systeme überwachen Dienste
- Kundenbeschwerden: Tickets pro Zeitraum
- Log-Analyse: Fehlerraten aus Anwendungslogs
Wichtige Fragen zur Definition:
- Was wird gemessen? Ping? Login? Transaktion?
- Wie oft? Jede Minute? Jede Sekunde?
- Von wo? Ein Standort? Weltweit?
- Was ist "verfügbar"? HTTP 200? <2s Antwortzeit?
- Wartungsfenster? Eingerechnet oder nicht?
Beispiel AWS: "Monatliche Uptime" wird als Prozentsatz der Zeit definiert, in der mindestens zwei Availability Zones erreichbar sind.
Faustregel: Ein System kann nie 100% messen – der Messfehler liegt bei ~0,05%.
Das Error Budget ist das Gegenstück zur Verfügbarkeit und stammt aus dem Site Reliability Engineering (SRE):
Berechnung:
Die Idee:
- Realismus: 100% ist unerreichbar
- Planung: Ausfälle sind eingeplant
- Balance: Zwischen Stabilität und Innovation
- Messbar: Konkrete Zahl statt Bauchgefühl
Was passiert bei Verbrauch?
- Wenig verbraucht: Mehr Releases, mehr Innovation
- Viel verbraucht: Fokus auf Stabilität, keine riskanten Änderungen
- Überschritten: Postmortem, Root-Cause-Analyse, Prozessverbesserung
Vorteil gegenüber klassischem SLA:
- Entwickler und Betrieb haben dasselbe Ziel
- Ausfälle sind normal, nicht "Katastrophen"
- Datengetriebene Entscheidungen
Die richtige SLA hängt von Kritikalität und Budget ab:
| System-Typ | Empfehlung | Ausfall/Monat |
|---|---|---|
| Entwicklung / Test | 99% – 99,5% | 3,6 – 7,2 h |
| Interne Tools | 99,5% – 99,9% | 43 min – 3,6 h |
| Öffentliche Website | 99,9% | 43 Minuten |
| Business-Anwendung | 99,95% | 22 Minuten |
| Kritische Infrastruktur | 99,99% | 4,3 Minuten |
| Zahlungssysteme | 99,995% | 2,2 Minuten |
| Notfalldienste | 99,999% | 26 Sekunden |
Kosten-Nutzen-Faktor:
- 99% → 99,9%: Faktor 3-5 (Architektur, Personal)
- 99,9% → 99,99%: Faktor 5-10 (Redundanz, Multi-Region)
- 99,99% → 99,999%: Faktor 10-20 (Chaos Engineering, aktives Failover)
Wichtig: Nicht jedes System braucht 5 Nines. Oft reicht 99,9% völlig aus – der Aufwand für höhere Klassen steht in keinem Verhältnis zum Nutzen.
Tipp: Starte mit 99,9% und erhöhe nur, wenn Kunden es fordern und du die Kosten tragen kannst.
Hohe Verfügbarkeit ist das Ergebnis mehrerer Maßnahmen:
1. Redundanz (Grundlage):
- Hardware: RAID, Dual-Netzteil, Cluster
- Software: Load-Balancer, mehrere App-Server
- Daten: Replikation, Master-Slave, Multi-Master
- Standorte: Multi-AZ, Multi-Region, Geo-Redundanz
2. Fehlertoleranz:
- Graceful Degradation: Teilausfall statt Totalausfall
- Circuit Breaker: Fehlerhafte Dienste isolieren
- Retry-Logic: Automatisches Wiederholen
- Timeouts: Hängende Requests abbrechen
3. Monitoring & Alerting:
- Proaktiv: Probleme erkennen, bevor sie eskalieren
- Synthetisch: Uptime-Roboter testen kontinuierlich
- Real-User-Monitoring: Echte Nutzererfahrung
- Alerting: Automatische Benachrichtigung
4. Prozesse:
- Change-Management: Keine unkontrollierten Änderungen
- Rollback-Plan: Schnelles Zurückrollen bei Problemen
- Postmortems: Blameless, was können wir lernen?
- Chaos Engineering: Ausfälle simulieren, bevor sie passieren
5. Team & Kultur:
- SRE-Prinzipien: 50% Ops, 50% Dev
- On-Call: Erreichbarkeit im Notfall
- Runbooks: Für bekannte Probleme
Faustregel: Jede zusätzliche Neun verlangt Architektur, Monitoring, Prozesse und Personal.
Die Begriffe sind ähnlich, haben aber unterschiedliche Bedeutungen:
| Aspekt | SLA | SLO |
|---|---|---|
| Bedeutung | Service Level Agreement | Service Level Objective |
| Charakter | Vertraglich | Internes Ziel |
| Verbindlichkeit | Verbindlich | Empfehlung |
| Konsequenz | Strafe / Erstattung | Prozessverbesserung |
| Wert | Meist niedriger | Meist höher |
| Beispiel | 99,5% | 99,9% |
Die Beziehung:
Warum unterschiedlich?
- Puffer: Intern höher, um SLA zu garantieren
- Konsequenzen: SLA-Verstoß = Rückerstattung
- Flexibilität: SLOs können angepasst werden
- Motivation: Höhere SLOs = besserer Service
Best Practice: SLO = SLA + 0,3% bis 0,5% Puffer. Damit hat man Luft, bevor Vertragsstrafen drohen.
Die Definition von "Ausfall" ist entscheidend für SLAs und muss vertraglich festgelegt werden:
Typische Definitionen:
- Erreichbarkeit: HTTP 5xx-Fehler oder Timeout
- Antwortzeit: P95 über 1 Sekunde
- Funktion: Login nicht möglich, Zahlung schlägt fehl
- Ende-zu-Ende: Kunde kann Bestellung nicht abschließen
Was NICHT als Ausfall zählt (meist vertraglich ausgeschlossen):
- Geplante Wartung: Vorher angekündigt
- Höhere Gewalt: Naturkatastrophen, Krieg
- Kundenverschulden: Falsche Konfiguration
- Drittanbieter: Ausfall des ISPs, DNS
- Beta-Features: Nicht-SLA-relevante Funktionen
Berühmte Beispiele für "Ausfall"-Definitionen:
| Anbieter | Definition |
|---|---|
| AWS S3 | <99,9% erfolgreiche GET-Anfragen |
| Google Cloud | <99,95% erfolgreiche Requests |
| Azure | <99,9% Minuten mit 2+ AZ erreichbar |
Tipp: Als Betreiber sollte man strengere Definitionen wählen als der SLA-Vertrag verlangt. Das schafft Puffer.
Das Downtime-Budget (auch Error Budget genannt) gibt an, wie viel Ausfall erlaubt ist:
Formel:
Verwendung:
- Monatlich: SLA-Ziel pro Monat
- Rollierend: Letzte 30 Tage
- Quartalsweise: Für langfristige Trends
- Kumulativ: Über das Jahr
Praxis-Beispiele:
| SLA | Monat | Jahr |
|---|---|---|
| 99% | 7,2 h | 87,6 h |
| 99,9% | 43,2 min | 8,76 h |
| 99,99% | 4,32 min | 52,6 min |
| 99,999% | 26 s | 5,26 min |
Wie nutze ich das Budget?
- Am Monatsanfang: Voll verfügbar
- Nach Vorfall: Budget wird reduziert
- Bei 50% verbraucht: Warnung, keine riskanten Releases
- Bei 100% verbraucht: Code Freeze, Fokus auf Stabilität
- Nicht verbraucht: Kann für Innovation genutzt werden
Vorteil: Es macht Zuverlässigkeit zu einer messbaren Größe, die mit Business-Zielen verknüpft ist.
Zusammenfassung
Die wichtigsten Punkte
- Uptime: Verfügbarkeit eines Systems in Prozent
- "Nines": Jede 9 bedeutet 10x weniger Ausfall – und 10x höhere Kosten
- 99,9%: Standard für Produktionsanwendungen (43 min/Monat)
- 99,99%: Kritische Systeme (4,3 min/Monat)
- 99,999%: "Five Nines" für Notfall- und Zahlungssysteme (26 s/Monat)
- SLA: Vertragliche Zusicherung mit Konsequenzen
- SLO: Internes Ziel mit Puffer (meist 0,3-0,5% höher)
- Error Budget: Erlaubter Ausfall (100% − SLO)
- Realismus: 100% Verfügbarkeit ist nicht erreichbar
- Unser Tool: Umrechnung zwischen SLA und Downtime
Weitere Tools
Strukturierte Checklisten für Systemadministratoren.
Zum ToolUnix-Zeitstempel in lesbare Daten umwandeln und umgekehrt.
Zum ToolErstelle AD-Testdaten für Windows-Server-Importe.
Zum ToolTestdatenbanken mit Beziehungen für Entwicklung und Tests.
Zum Tool