Website nicht erreichbar: was mir ein Ausfall 2016 beigebracht hat

Kurz nach Mitternacht am 15. November 2016 veröffentlichte ich einen Beitrag mit dem Titel "Mein Blog ist nicht erreichbar". Auf genau der Seite, die gerade ausgefallen war, erklärte ich, warum sie nicht mehr antwortete, mit der etwas naiven Begeisterung von jemandem, der entdeckt, dass eine gute Sicherheitspraxis sich gegen einen wenden kann. Zehn Jahre später habe ich Plattformen betreut, bei denen sich Ausfall nicht mehr in verlorenen Besuchern misst, sondern in Gemeinden, die von ihrem Wahlwerkzeug abgeschnitten sind. Dieser Beitrag geht vom Vorfall von 2016 aus und leitet daraus die Methode ab, die ich heute anwende, wenn eine Website ausfällt.

November 2016: von der eigenen Sicherheit ausgesperrt

Damals wurde mein Blog über HTTPS mit einem kostenlosen Let's-Encrypt-Zertifikat ausgeliefert. Ich hatte außerdem selbst HSTS aktiviert und die Domain sogar in die Preload-Liste der Browser eingetragen. HSTS sagt dem Browser im Wesentlichen: Diese Seite wird nur über eine sichere Verbindung ausgeliefert, verweigere alles andere, ohne Ausnahme.

An jenem Tag migrierte ich auf einen Server mit mehr Ressourcen. Während der Migration musste ich mein SSL-Zertifikat neu erzeugen, über ein "Ein-Klick"-Werkzeug. Ein Feld war falsch, also war es das Zertifikat auch. Und da HSTS jede unsichere Verbindung untersagte, taten die Browser genau das, worum ich sie gebeten hatte: Sie weigerten sich, meine Seite zu laden. Kein Hack, kein Datenverlust. Eine Seite, verriegelt durch die Regel, die ich selbst geschrieben hatte, bis ich ein korrektes Zertifikat neu erzeugen konnte.

Ich stellte schon damals klar, dass ich Let's Encrypt keine Schuld gab; die "Ein-Klick"-Neuerzeugung stammte nicht von ihnen. Die eigentliche Lehre war nicht "Sicherheit ist riskant". Sie war: Ein kritischer Vorgang, überstürzt und ohne Prüfung ausgeführt, rächt sich sofort.

Was ich richtig machte, ohne es zu wissen

Beim erneuten Lesen dieses Beitrags fällt mir eine Sache auf. Mein erster Reflex, mitten in der Nacht, war nicht, so zu tun, als wäre nichts gewesen. Ich schrieb öffentlich, was passiert war, was ich versäumt hatte und was ich daraus mitnahm. Das ist, ohne dass ich es damals so formulierte, die Grundlage des Incident-Managements: sagen, was man weiß, sobald man es weiß.

Ein Kunde, der vom Ausfall durch Ihre Nachricht erfährt, verzeiht ihn. Ein Kunde, der ihn selbst entdeckt und dann Ihr Schweigen bemerkt, behält vor allem das Schweigen in Erinnerung.

Lektion 1: einen Ausfall stellt man nicht fest, man misst ihn

2016 entdeckte ich das Problem, indem ich meine eigene Seite besuchte. Mit anderen Worten, ich war mein einziges Monitoring-Werkzeug. Heute prüft meine Seite ihre Dienste selbst fortlaufend und veröffentlicht das Ergebnis auf einer öffentlichen Statusseite: Webserver, Anwendung, Datenbank, E-Mail, Galerien, mit einer tagesgenauen Historie über 90 Tage und der Liste vergangener Vorfälle.

Eine Statusseite verändert zwei Dinge. Erstens hängt die Erkennung nicht mehr vom Zufall eines Besuchs ab. Zweitens wird Transparenz überprüfbar: Wenn ich eine Verfügbarkeitszahl angebe, kann jeder auf die grünen Balken schauen.

Lektion 2: eine Sicherung bereitet man vorher vor, niemals währenddessen

Ein amüsantes Detail: Der Beitrag von 2016 riet bereits, "eine Sicherung anzulegen, bevor man fortfährt". Ich hatte das Prinzip verstanden, bevor ich sein Gewicht ermaß. Ein Zertifikatsausfall lässt sich ohne Verlust beheben. Eine beschädigte Datenbank, eine tote Festplatte oder ein Hack nicht: Da rettet Sie nur die Sicherung von vor dem Vorfall.

Deshalb enthalten meine Pakete für Managed Hosting standardmäßig Sicherungen über 14 Tage (30 Tage im Business-Paket), verwaltete Updates und Verfügbarkeits-Monitoring. Nicht als Option, in der Basis. Die Frage, die Sie Ihrem Hoster stellen sollten, lautet nicht "Macht ihr Sicherungen?", sondern "Wann habt ihr zuletzt eine Wiederherstellung getestet?".

Lektion 3: Zuverlässigkeit wird beziffert und dann bewiesen

2024 baute und betreute ich bei der Imprimerie Wallonne des Communes die digitale Infrastruktur, auf die sich 123 belgische Gemeinden für die Parlaments- und Kommunalwahlen verließen, darunter gebel.be, die mehrsprachige Plattform zur Verwaltung der Wahlbüros. Von 2.000 bis 4.500 Besucher pro Tag, vier Sprachen und eine einfache Pflicht: Am Wahltag musste alles laufen, Wochenenden und Feiertage inbegriffen. Der kleinste Fehler konnte den Wahlprozess eines ganzen Landes gefährden. Die Plattform ist nie ausgefallen.

Ein Wahlabend lässt sich nicht wiederholen. Ein solches Projekt zwingt dazu, Zuverlässigkeit als Ausgangsanforderung zu behandeln: Redundanz, Überwachung, schriftliche Verfahren und kein ungeprüfter "Ein-Klick"-Vorgang auf einem Produktivsystem. Genau das Gegenteil meiner Migration von 2016.

Ihre Website ist ausgefallen: die Methode, der Reihe nach

Wenn Ihre Website jetzt, in diesem Moment, nicht erreichbar ist, würde ich an Ihrer Stelle Folgendes tun.

1. Bestätigen Sie den Ausfall. Testen Sie von einem anderen Gerät oder über 4G. Wenn die Seite anderswo antwortet, liegt das Problem auf Ihrer Seite (Cache, lokales DNS, Netzwerk).
2. Lesen Sie die genaue Fehlermeldung. "Unsichere Verbindung" deutet auf das Zertifikat hin, wie bei mir 2016. Ein 500-Fehler deutet auf die Anwendung hin, eine Zeitüberschreitung auf den Server, eine Parkseite auf eine abgelaufene Domain.
3. Prüfen Sie die Fristen. Abgelaufene Domainnamen und Zertifikate bleiben banale, vermeidbare Ausfallursachen.
4. Ändern Sie immer nur eine Sache. Notieren Sie jede Aktion. Drei gleichzeitige Änderungen bedeuten dreifache Mühe zu verstehen, was funktioniert hat.
5. Kommunizieren Sie früh. Eine kurze, ehrliche Nachricht an Ihre Kunden ist besser als eine Stunde Schweigen: "Die Seite ist ausgefallen, ich habe die Spur gefunden, Rückkehr gegen soundso viel Uhr erwartet".
6. Stellen Sie bei Bedarf wieder her. Wenn Daten betroffen sind, starten Sie von der letzten sauberen Sicherung, statt an einem beschädigten System herumzubasteln.
7. Schreiben Sie das Post-mortem. Und seien es nur drei Zeilen. Mein Beitrag von 2016 war eines, und ihm verdanke ich, dass ich diesen hier schreiben kann.

Zehn Jahre zwischen zwei Beiträgen

2016 war ein Ausfall meines Blogs ein Ärgernis und eine Anekdote zum Erzählen. 2026 ist ein Ausfall bei einem Kunden stockender Umsatz, und meine Aufgabe ist es, ihn selten, kurz und angekündigt zu machen. Wenn Ihre Website gerade ausgefallen ist oder Sie möchten, dass ein Ausfall nie wieder eine Überraschung ist, sprechen wir darüber.