Ausfallzeit ist die Zeit, in der eine Website ihre Aufgabe nicht erfüllen kann. Besucher sehen vielleicht eine Fehlerseite, eine Seite, die nie fertig lädt, oder eine Browserwarnung. Entscheidend ist das Ergebnis: Sie können die Website nicht nutzen.
Ausfallzeit ist das Gegenstück zur Verfügbarkeit (Uptime). Eine Website mit 99,9 % Verfügbarkeit hat in einem Monat mit 30 Tagen etwa 43 Minuten Ausfallzeit.
Geplante und ungeplante Ausfallzeit
Geplante Ausfallzeit wird im Voraus festgelegt. Typische Gründe sind eine Datenbankmigration, ein Server-Upgrade oder ein großes Release, das nicht neben der alten Version laufen kann. Gute Praxis ist, sie in ruhige Stunden zu legen, die Nutzer vorher zu informieren und eine klare Wartungsseite anzuzeigen. Ein Server, der für Wartungsarbeiten bewusst abgeschaltet wird, antwortet oft mit 503 Service Unavailable. Das zeigt einen vorübergehenden Zustand an und kann einen Retry-After-Header enthalten, der den Clients sagt, wann sie wiederkommen sollen.
Ungeplante Ausfallzeit ist alles andere: Störungen, die niemand angesetzt hat. Sie ist die Art, die wehtut, denn sie kommt ohne Vorwarnung, und die Uhr läuft, bis jemand sie bemerkt und behebt.
Verträge und Berichte behandeln beides oft unterschiedlich. Viele Service-Level-Agreements nehmen angekündigte Wartung aus der Berechnung aus. Ob das für eine bestimmte Website gilt, hängt ganz vom vereinbarten Wortlaut ab.
Häufige Ursachen
| Ursache | Was passiert | Was ein Besucher oft sieht |
|---|---|---|
| Serverausfall | Die Maschine oder der virtuelle Server stürzt ab, hat keinen Arbeitsspeicher oder Speicherplatz mehr oder ist überlastet | Verbindung abgelehnt, Zeitüberschreitung oder ein 5xx-Fehler |
| Netzwerkproblem | Eine Leitung, eine Firewall-Regel oder ein Fehler beim Anbieter stoppt den Datenverkehr zwischen Besucher und Server | Zeitüberschreitung, „Website nicht erreichbar“ |
| DNS-Problem | Der Domainname wird nicht aufgelöst, weil ein Eintrag falsch oder gelöscht ist oder die Domain abgelaufen ist | „Server nicht gefunden“ |
| Zertifikatsproblem | Das TLS-Zertifikat ist abgelaufen oder passt nicht zur Domain | Eine ganzseitige Sicherheitswarnung des Browsers |
| Anwendungsfehler | Ein Bug, ein fehlgeschlagenes Deployment oder eine defekte Abhängigkeit bringt die Anwendung zum Absturz | Ein 500-Fehler oder eine leere Seite |
| Überlastung | Eine Lastspitze oder ein rechenintensiver Job verbraucht die gesamte verfügbare Kapazität | Sehr langsame Seiten, 503- oder 504-Fehler |
| Drittanbieter-Abhängigkeit | Ein Zahlungs-, Login- oder Datenbankdienst, auf den sich die Website stützt, antwortet nicht mehr | Eine funktionierende Seite, auf der eine Funktion fehlschlägt |
Viele Ausfälle haben mehrere Ursachen zugleich. Ein überlasteter Server fällt aus, und der Neustart verzögert sich, weil das Zertifikat auf dem Ersatzsystem abgelaufen ist. Der erste Fehler ist meist wichtiger als das letzte Symptom.
Wie sich Ausfallzeit in HTTP zeigt
Wenn ein Besucher eine Seite lädt, gibt der Server einen HTTP-Statuscode zurück. Codes im 5xx-Bereich, etwa 500, 502, 503 und 504, melden, dass der Server versagt hat. Ist der Server gar nicht erreichbar, gibt es keinen Statuscode, sondern nur eine Zeitüberschreitung oder einen Verbindungsfehler. Was die einzelnen Klassen bedeuten, steht unter HTTP-Statuscodes.
Was eine Prüfung per Webanfrage nicht sehen kann
Das ist die wichtigste Grenze, die man verstehen muss. Eine Überwachungsprüfung, die eine Seite anfordert und die Antwort liest, kann nur wiedergeben, was der Server sagt. Ob die Website funktioniert, kann sie nicht beurteilen.
Ein Server kann 200 OK zurückgeben, während:
- der Warenkorb versagt, wenn jemand auf „Hinzufügen“ klickt,
- das Login-Formular jedes Passwort ablehnt,
- die Seite zwar lädt, aber leer ist, weil ein Backend-Aufruf fehlgeschlagen ist,
- in einer sonst normalen Seite eine Fehlermeldung ausgegeben wird.
Aus Sicht des Monitors ist die Website erreichbar. Aus Sicht eines Kunden ist sie ausgefallen. Solche Fehler zu erkennen, erfordert Prüfungen, die echten Nutzerwegen folgen, oder Benachrichtigungen auf Anwendungsebene, oder beides. Eine einfache Adressprüfung ist eine verlässliche erste Verteidigungslinie bei Ausfällen, in denen der Server nicht antwortet oder mit einem Fehler antwortet, und nicht mehr als das.
Folgen
Die Auswirkungen von Ausfallzeit hängen davon ab, wofür die Website da ist:
- Umsatzverlust, wenn Kunden nicht bestellen oder bezahlen können.
- Vertrauensverlust, wenn Nutzer dort auf einen Fehler stoßen, wo sie einen Dienst erwartet haben.
- Mehraufwand im Support, weil Leute fragen, ob das Problem bei ihnen liegt.
- Vertragsstrafen, wenn eine Vereinbarung Verfügbarkeitsziele und Gutschriften festlegt.
Erkennen und Wiederherstellen
Ausfallzeit wird durch drei Dinge verkürzt: schnell bemerken, die Ursache verstehen und einen Weg zurück haben.
- Erkennen. Ein Monitor prüft die Website in einem festen Intervall und löst nach wiederholten Fehlschlägen eine Benachrichtigung aus, damit eine einzelne verlorene Anfrage niemanden aufweckt. UptimeWire wiederholt zum Beispiel eine fehlgeschlagene Prüfung zweimal im Abstand von etwa 20 Sekunden, bevor es einen Vorfall eröffnet.
- Diagnostizieren. Die fehlgeschlagene Prüfung hält einen Grund fest, etwa eine Zeitüberschreitung, einen Verbindungsfehler oder einen Statuscode. Das grenzt die Suche ein: Ein DNS-Fehler und ein 500-Fehler weisen auf völlig verschiedene Stellen.
- Wiederherstellen. Übliche Maßnahmen sind, einen Dienst neu zu starten, ein Release zurückzunehmen, ein Zertifikat zu erneuern oder einen DNS-Eintrag zu korrigieren. Sobald die Website wieder korrekt antwortet, bestehen die Prüfungen, und der Vorfall wird geschlossen.
- Lernen. Eine kurze Notiz zu Ursache und Behebung, die beim Vorfall bleibt, hilft beim nächsten Mal.
Die Zeit vom Beginn des Ausfalls bis zu dem Moment, in dem jemand davon weiß, gehört ebenfalls zur Ausfallzeit. Deshalb zählt das Prüfintervall: Eine Website, die jede Minute geprüft wird, fällt früher auf als eine, die alle zehn Minuten geprüft wird.