Ihre Website ist offline: was in den ersten fünfzehn Minuten zu tun ist

Eine Website, die nicht mehr antwortet, wird selten im Code repariert. Der Reflex ist, den Editor zu öffnen: widerstehen Sie ihm zehn Minuten lang. Der Fehler liegt fast nie dort, wo Sie zuerst gesucht hätten, und diese zehn Minuten, in denen Sie das Problem eingrenzen, ersparen Ihnen eine Stunde Herumraten. Die Reihenfolge, die funktioniert, besteht aus fünf Schritten: bestätigen, dass der Ausfall echt ist, die schuldige Ebene finden, herausfinden, was sich geändert hat, denen Bescheid geben, die es gleich merken werden, und erst danach reparieren.

Die fünfzehn Minuten auf einen Blick

Dieser Zeitplan hat nichts Militärisches. Er leistet genau eine Sache: Er verhindert, dass Sie die vollen fünfzehn Minuten mit der erstbesten Hypothese verbringen, die zugleich die ist, an die Sie am liebsten glauben möchten.

1. Den Ausfall von außen bestätigen

Ihr Browser lügt. Er speichert zwischen, er hält alte DNS-Einträge fest, und Ihr Büronetz ist womöglich das einzige weltweit, das betroffen ist.

Drei Prüfungen genügen, und sie dauern zusammen weniger als eine Minute:

• Die Seite über Mobilfunk, WLAN aus. Lädt sie, liegt das Problem an Ihrer Verbindung, nicht an der Website. Der lohnendste Test der Liste.
• Ein privates Browserfenster. Es schließt eine abgelaufene Sitzung aus, eine Erweiterung, einen Service Worker, der nach einem Deployment übrig blieb.
• Jemand in einer anderen Stadt. Eine regionale Störung beim Provider sieht vom eigenen Schreibtisch aus exakt wie ein Serverausfall aus.

Scheitern alle drei, ist der Ausfall echt, und Sie wissen das, bevor Sie eine einzige Datei geöffnet haben. Gelingt einer davon, haben Sie sich gerade eine Stunde Suche nach einem Ausfall gespart, den es nie gab. Dieser Schritt wird regelmäßig übersprungen, weil er zu einfach wirkt, und er ist derjenige, der die meisten verlorenen Vormittage verhindert hat.

2. Die schuldige Ebene bestimmen

Die exakte Fehlermeldung ist mehr wert als jede Intuition. Notieren Sie sie wortgenau, mit der Uhrzeit, bevor Sie weitermachen: In einer halben Stunde erinnern Sie sich nicht mehr daran, und es ist die einzige Information, die niemand nachträglich rekonstruieren kann.

Die drei Codes der 500er-Familie lassen sich mit bloßem Auge kaum unterscheiden und werden völlig verschieden repariert: was jeder Code bedeutet verdient zwei Minuten Lektüre vor dem ersten Befehl.

3. Fünf Befehle, die in dreißig Sekunden antworten

Für diesen Schritt taugt ein Terminal besser als ein Browser: Es speichert nichts zwischen und liefert den rohen Statuscode.

curl -I https://beispiel.de           # der zurückgegebene Code, ohne Browser
dig +short beispiel.de                # zeigt die Domain noch an die richtige Stelle
ping -c 3 beispiel.de                 # ist die Maschine überhaupt erreichbar
echo | openssl s_client -connect beispiel.de:443 2>/dev/null | openssl x509 -noout -dates
tail -n 100 /var/log/nginx/error.log  # oder storage/logs/laravel.log je nach Stack

Die erste Zeile genügt, um zwischen „nichts antwortet“ und „etwas antwortet falsch“ zu unterscheiden, und das sind zwei völlig verschiedene Ausfälle. Die zweite fängt den Fall, den niemand früh genug vermutet: ein DNS-Eintrag, letzte Woche geändert und erst jetzt propagiert. Die letzte überspringt man immer, und fast immer enthält gerade sie die Antwort. Wer sie zuerst liest, spart sich die drei Hypothesen davor.

4. Fragen, was sich geändert hat

Fast jeder Ausfall folgt auf eine Änderung, und die Änderung ist nicht immer Ihre.

• Ein Deployment heute Morgen, und sei es noch so klein und „ungefährlich“.
• Ein automatisches Update in der Nacht: System, Erweiterung oder Abhängigkeit.
• Ein Zertifikat, das um zwei Uhr morgens abgelaufen ist.
• Eine Domain, deren Verlängerung fällig war.
• Eine abgelehnte Abbuchung beim Hoster, deren Hinweis im Spam liegt.
• Eine fremde API, die ohne Ankündigung die Version gewechselt hat.

In dem seltenen Fall, dass sich bei Ihnen nichts bewegt hat, hat sich die Änderung woanders ereignet, und keine Nachricht bringt sie zu Ihnen: Ihr Hoster warnt Sie nicht, und das ist kein böser Wille, sondern die Bauart seiner Alarmierung.

5. Etwas sagen, bevor man Sie fragt

Dauert der Ausfall länger als zehn Minuten, sind drei Zeilen auf dem Kanal, den Ihre Kunden tatsächlich lesen, mehr wert als eine perfekte Erklärung drei Tage später.

Die Website ist seit 14:20 Uhr nicht erreichbar. Wir haben die Ursache gefunden und arbeiten daran. Nächste Meldung um 15 Uhr, an gleicher Stelle.

Diese Nachricht sagt drei Dinge und kein viertes: seit wann, wo Sie stehen, wann Sie sich wieder melden. Versprechen Sie keine Wiederherstellungszeit, solange die Ursache unbekannt ist: Ein gebrochenes Versprechen kostet mehr als Schweigen. Bei einem Kunden mit Vertrag landet der Vorfall ohnehin im Bericht des Monats; besser, er kommt dort mit Ihren Worten an als mit seinen.

6. Die fünf Handgriffe, die alles schlimmer machen

• Den Server neu starten, bevor man das Log gelesen hat. Der Neustart löscht meist die Spur dessen, was kaputtgegangen ist. Der Ausfall kehrt zwei Stunden später zurück, und Sie wissen nicht mehr als vorher.
• Am DNS drehen. Eine Zonenänderung braucht Stunden zur Verbreitung, und Sie legen damit einen Ausfall auf den Ausfall.
• Einen ungetesteten Fix ausrollen. Unter Druck übersteigt die Wahrscheinlichkeit, etwas zu verschlimmern, die, etwas zu reparieren, deutlich.
• Alle Caches gleichzeitig leeren. Sie verlieren die Information, die Ihnen gesagt hätte, welcher schuld war, und belasten die Datenbank im ungünstigsten Moment.
• Eine Wiederherstellungszeit ankündigen. Solange die Ursache unbekannt ist, ist jeder angekündigte Termin ein Termin, der gerissen wird.

7. Danach die einzige Frage, die zählt

Nicht warum ist es kaputtgegangen: Das wissen Sie jetzt. Die eigentliche Frage lautet: Wie lange habe ich gebraucht, um es zu erfahren?

Lautet die Antwort „ein Kunde hat es mir gesagt“, war der Ausfall nicht der Vorfall. Der Vorfall war, der Letzte gewesen zu sein, der es erfuhr. Und die Rechnung ist nicht symbolisch: was eine Ausfallstunde wirklich kostet lässt sich beziffern, auch für eine Website, die online nichts verkauft.

Dieser Teil ist in wenigen Minuten erledigt: eine Prüfung, die von selbst läuft, eine E-Mail in dem Moment, in dem die Website nicht mehr antwortet, und eine zweite bei der Rückkehr. Zwei Einstellungen zählen dann so viel wie das Werkzeug selbst, wie oft geprüft wird und was aus einer Prüfung einen Alarm macht; ohne sie haben Sie das Schweigen bloß durch Lärm ersetzt. Und falls Sie noch zwischen einem eigenen Skript und einem externen Dienst schwanken, steht der ehrliche Vergleich in eigene oder externe Überwachung.

Wenn es kein Ausfall ist

Ein Fall verdient seinen eigenen Reflex, weil er wie ein Ausfall aussieht, ohne einer zu sein: ein abgelaufenes Zertifikat. Der Server antwortet einwandfrei, es ist der Browser, der die Anzeige verweigert. Nichts in Ihren Anwendungslogs wird das erwähnen, ein Neustart ändert daran nichts, und der einzige Hinweis ist jene rote Warnung, die Ihre Besucher vor Ihnen sehen. Der Reflex, der eine Stunde spart: Öffnen Sie die Website in einem Browser, den Sie nie benutzen, bevor Sie irgendetwas neu starten.