Ein Incident-Runbook für Website-Störungen schreiben

Mit einem konkreten Auslöser beginnen

Ein Runbook ist eine Arbeitsanleitung für eine bestimmte Situation. Sein erster Satz sollte die Situation erkennbar machen: „Wichtige öffentliche Seiten antworten bei wiederholten Prüfungen mit Fehlern“ oder „Die Redaktion kann keine Inhalte mehr speichern“. Eine allgemeine Sammlung von Serverbefehlen erfüllt diese Aufgabe schlecht. Der Auslöser hilft der zuständigen Person zu entscheiden, ob diese Anleitung passt. Beschreiben Sie auch benachbarte Fälle, für die ein anderer Weg vorgesehen ist, etwa eine einzelne fehlerhafte URL oder eine reine Störung des Messsystems.

Der Google-Leitfaden zum Incident Management bietet Hintergrund zu vorbereiteten Rollen und Abläufen. Die Umsetzung für eine kleine Website darf deutlich schlanker sein. Sie benötigt jedoch dieselben praktischen Antworten: Wer übernimmt die Koordination? Wer darf welchen Eingriff ausführen? Wer hält den Verlauf fest? Wer prüft das Ergebnis aus Nutzersicht? In einem kleinen Team kann eine Person mehrere Aufgaben tragen. Die Aufgaben sollten trotzdem benannt sein, damit bei einer Übergabe keine wichtige Funktion unbeachtet bleibt.

Die ersten Minuten als Lesestrecke gestalten

Beginnen Sie mit wenigen lesenden Prüfungen. Bestätigen Sie den betroffenen Namen, die URL, den Zeitpunkt und die tatsächliche Nutzerhandlung. Prüfen Sie den Zustand über einen unabhängigen Weg, soweit verfügbar. Ein Alarm kann auf einem Messpunkt beruhen, der selbst Probleme hat. Das Runbook sollte deshalb eine kurze Bestätigung verlangen, ohne die Bearbeitung unnötig zu verzögern. Wenn der Vorfall eindeutig ist, wird er eröffnet und erhält eine Kennung. Diese Kennung verbindet später Beobachtungen, Änderungen und Supportanfragen.

Legen Sie einen gemeinsamen Protokollort fest, der auch bei einer gestörten Website verfügbar ist. Er enthält Originalzeiten, beteiligte Personen, Beobachtungen, Entscheidungen und Maßnahmen. Schreiben Sie kurze Sätze mit klaren Verben. „Geprüft: statische Datei erreichbar; Speichern weiterhin fehlerhaft“ ist brauchbarer als „wahrscheinlich PHP“. Eine Hypothese darf danebenstehen, muss aber als Hypothese erkennbar bleiben. Das Protokoll dient der Koordination im laufenden Vorfall und später dem Lernen. Es soll keine nachträglich geglättete Erfolgsgeschichte werden.

Identität und Scope vor Schreibschritten prüfen

Hostingoberflächen können mehrere Kunden und Domains nebeneinander zeigen. Das Runbook braucht deshalb eine kurze Identitätsprüfung vor jeder Änderung: Zielhost, Kundenzuordnung, Abonnement, Domain und betroffener Pfad. Für eine Datenbankänderung kommen Datenbankname und Anwendungszuordnung hinzu. Diese Prüfung kostet wenig Zeit und schützt vor Eingriffen am falschen Projekt. Ein kopierter Tabtitel ist kein zuverlässiger Nachweis. Verwenden Sie aktuelle Angaben aus der tatsächlichen Oberfläche oder aus dem kontrollierten Systembestand. Dokumentieren Sie nur Metadaten, keine Zugangsdaten.

Definieren Sie, welche Eingriffe der Betreiber selbst durchführen darf und welche bei der Administration liegen. Auf einem geteilten Server kann ein Dienstneustart mehrere Kunden betreffen. Ein Hostingkunde darf vielleicht einen eigenen PHP-Prozess steuern, besitzt aber keinen Zugriff auf zentrale Dienste. Diese Grenze gehört in die Anleitung. Der Zuständigkeitsratgeber hilft bei der Arbeitsmatrix. Ein Runbook soll einen Berechtigungsumfang abbilden, der bereits tatsächlich besteht. Es darf keine neue allgemeine Vollmacht erfinden, nur weil ein Schritt im Notfall nützlich wäre.

Einen Entscheidungsbaum klein halten

Die Anleitung sollte an wenigen beobachtbaren Unterschieden verzweigen. Sind alle Seiten betroffen oder nur eine Aktion? Antworten statische Dateien? Ist die Domain über beide Adressfamilien gleich erreichbar? Gibt es eine bekannte laufende Wartung? Diese Fragen führen zu unterschiedlichen Prüfwegen. Der 502/503-Ratgeber liefert eine passende technische Strecke. Verlinken Sie vertiefte Anleitungen, statt sie vollständig in jedes Runbook zu kopieren. Dadurch bleiben die ersten Schritte lesbar und die technische Fachanleitung kann an einer Stelle gepflegt werden.

Jede Verzweigung braucht einen klaren Abschluss für den Schritt. „Logs prüfen“ ist zu offen. Besser lautet der Auftrag: „Im genannten Zeitfenster nach der betroffenen URL suchen, vorhandene Fehlermeldung sichern und den nächsten Prüfpfad wählen.“ Wenn der gesuchte Zugriff nicht verfügbar ist, führt die Anleitung zu einem benannten Ansprechpartner. Sie verlangt kein improvisiertes Umgehen von Schutzmaßnahmen. Eine konkrete Blockade wird mit Ursache protokolliert. Parallel kann die zuständige Person weiterhin den Nutzerzustand und einen vorhandenen Ersatzweg prüfen.

Änderungen mit Rückweg planen

Vor einem Schreibschritt stehen Ausgangszustand, beabsichtigte Wirkung und Rückweg fest. Bei einer kleinen Konfigurationsänderung kann eine dokumentierte vorherige Einstellung genügen. Bei Datenänderungen oder einem Restore wird ein geeigneter Sicherungspunkt benötigt. Der Backup-Ratgeber behandelt die Prüfbarkeit eines solchen Punktes. Im Runbook nennen Sie den konkreten Zugriffspfad auf das Sicherungssystem und dessen Verantwortlichen. Zugangsdaten liegen separat geschützt. Ein Notfallplan mit einem offen ausgeschriebenen Adminpasswort schafft ein neues Betriebsrisiko.

Ändern Sie möglichst eine klar abgegrenzte Sache und prüfen Sie danach dieselbe betroffene Handlung. Mehrere gleichzeitige Eingriffe können den Zustand verbessern, lassen aber offen, welche Maßnahme wirkte. In einer akuten Lage kann parallele Arbeit nötig sein; sie braucht dann eine abgestimmte Aufteilung. Eine Person verändert den Anwendungszustand, während eine andere unkoordiniert Caches oder Dienste zurücksetzt, macht die Befundlage unlesbar. Die Koordination hat die Aufgabe, Änderungen zu bündeln und ihre Überschneidungen zu erkennen. Das ist auch mit zwei Personen sinnvoll.

Entlastung und Ursachenklärung unterscheiden

Eine temporäre Maßnahme kann den Betrieb wieder ermöglichen, obwohl die Ursache offen bleibt. Das Runbook sollte diese beiden Ziele ausdrücklich besitzen. Ein pausierter Import kann Ressourcen freigeben. Ein Rückgriff auf einen bekannten Stand kann ein fehlgeschlagenes Update zurücknehmen. Beide Maßnahmen beantworten nicht automatisch, weshalb der ursprüngliche Zustand scheiterte. Dokumentieren Sie deshalb den wiederhergestellten Umfang und die offene Analyse getrennt. Ein Vorfall darf technisch stabilisiert werden, ohne dass eine unbestätigte Erklärung als Tatsache kommuniziert werden muss.

Formulieren Sie Kriterien für eine Entlastung. Welche Aufgabe wird pausiert? Wer bestätigt, dass sie gefahrlos unterbrochen werden kann? Welcher Zustand muss danach geprüft werden? Wann wird die Aufgabe wieder aufgenommen? Solche Fragen verhindern, dass eine Notmaßnahme dauerhaft vergessen wird. Das Protokoll sollte temporäre Änderungen sichtbar markieren. Nach dem Vorfall folgt eine kontrollierte Rücknahme oder eine bewusste dauerhafte Entscheidung. Ein still liegengebliebener Import kann sonst später als neue Inhaltslücke auftauchen, obwohl der Websitecheck schon lange grün ist.

Einen Ersatzweg für Nutzer bereitstellen

Wenn wichtige Funktionen länger ausfallen, kann ein vorbereiteter Ersatzweg helfen. Eine Kontaktmöglichkeit, ein Hinweis auf verzögerte Bearbeitung oder eine statische Informationsseite benötigt jedoch korrekte Angaben und eine zuständige Person. Versprechen Sie keine Wiederherstellungszeit, die nicht belastbar feststeht. Eine knappe Meldung kann sagen, welche Funktion betroffen ist, welche Alternative besteht und wann der nächste Stand geplant ist. Der Kommunikationsplan soll sich am tatsächlichen Nutzerbedarf orientieren. Ein Betreiber muss nicht jede interne Diagnose öffentlich ausbreiten.

Prüfen Sie, wo ein solcher Hinweis erscheint. Eine Statusseite auf derselben ausgefallenen Infrastruktur kann im entscheidenden Moment ebenfalls fehlen. Ein vorbereiteter unabhängiger Kanal ist deshalb für kritische Prozesse überlegenswert. Für eine kleine Informationswebsite kann ein erreichbarer alternativer Kontakt genügen. Das Runbook nennt die konkret vorhandenen Wege, keine hypothetischen Kommunikationskanäle. Ebenso gilt: Ein vorbereiteter Text ist noch keine versandte Nachricht. Im Protokoll werden Vorbereitung, Freigabe und tatsächliche Veröffentlichung oder Zustellung als unterschiedliche Zustände festgehalten.

Belege sichern, ohne Daten zu verbreiten

Fehlerbilder, Logausschnitte und Statusdaten können für die Ursachenklärung wichtig sein. Erfassen Sie das notwendige Material vor einer Maßnahme, die den Zustand verändert, sofern Dringlichkeit und Zugriff das erlauben. Halten Sie dabei den Scope klein. Screenshots aus Verwaltungsoberflächen können Zugangsnamen, Kundendaten oder interne Adressen enthalten. Speichern Sie sie geschützt und bereinigen Sie Material vor einer externen Übergabe. Ein Bericht braucht technische Identitäten und Zeitangaben, aber üblicherweise keine vollständigen Geheimnisse oder gesamten Datenbankbestände.

Bewahren Sie Originalfehler und spätere Erfolge nebeneinander auf. Wenn ein Wiederherstellungsjob zunächst scheitert und nach einer Korrektur erfolgreich läuft, sind das zwei Ausführungen. Der erste Fehler bleibt Teil des Ablaufs. Diese Trennung ermöglicht später eine genaue Bewertung: War das Archiv beschädigt, der Zielzugriff falsch oder die Umgebung unvollständig? Eine nachträglich geänderte Erfolgsmeldung würde die Lernchance entfernen. Der Verlauf muss nicht umfangreich sein. Eine eindeutige Ausführungskennung, Zeit und ein kurzer Befund pro Schritt reichen häufig.

Den Wiederanlauf fachlich abnehmen

Legen Sie vorab die wenigen wichtigsten Abnahmehandlungen fest. Bei einem Redaktionsportal gehören dazu öffentliche Inhalte, Medien, Anmeldung und ein kontrollierter Schreibtest. Für eine Buchungsplattform kommen Datenabgleich und die sichere Wiederaufnahme verändernder Aktionen hinzu. Der RPO/RTO-Ratgeber erklärt die Abgrenzung zwischen Datenstand und Wiederanlauf. Führen Sie dieselben Prüfungen nach der Maßnahme erneut aus. Eine beliebige erreichbare Seite ist kein Ersatz für die ursprünglich betroffene Funktion. Auch die endgültige Zieladresse und relevante Weiterleitungen gehören zum Ergebnis.

Prüfen Sie anschließend Monitoring und Hintergrundaufgaben. Sind Wartungsunterdrückungen beendet? Laufen pausierte Aufgaben wieder im vorgesehenen Umfang? Wird eine Fehlerantwort möglicherweise noch aus einem Cache ausgeliefert? Halten Sie offene Punkte mit Verantwortlichem fest. Ein teilweise wiederhergestellter Zustand kann fachlich akzeptabel sein, wenn seine Grenzen bewusst abgestimmt wurden. Die Meldung muss diese Grenzen enthalten. So versteht der Betreiber, welcher Betrieb wieder möglich ist und welche Nacharbeit weiterhin ein Risiko oder eine Einschränkung darstellt.

Eine Übung mit realistischer Übergabe durchführen

Ein brauchbares Runbook wird gelesen und erprobt, bevor es im Ernstfall nötig ist. Wählen Sie eine kontrollierte Übung auf einem geschützten Ziel. Lassen Sie möglichst eine Person arbeiten, die die Anleitung nicht selbst geschrieben hat. Gerade dadurch werden fehlende Pfade, unklare Begriffe und vorausgesetzte Kenntnisse sichtbar. Das SRE-Workbook zur Incident Response bietet vertiefenden Kontext. Für Ihr Projekt zählen vor allem die tatsächlichen Fragen der übenden Person. Ergänzen Sie diese Lücken direkt im dokumentierten Ablauf.

Testen Sie auch eine Übergabe: Die erste Person übergibt den aktuellen Stand, die zweite führt den nächsten Schritt aus. Kann sie erkennen, welche Änderungen bereits erfolgt sind und welche Hypothese noch offen ist? Eine gute Übergabe nennt Scope, Nutzerwirkung, letzte bestätigte Beobachtung und die nächste geplante Handlung. Sie enthält keinen vollständigen Gesprächsverlauf als Ersatz. Wenn diese kurze Übergabe gelingt, gewinnt das Runbook auch für längere Vorfälle an Wert. Das Team kann Verantwortung wechseln, ohne den Zustand erneut von Anfang an zu rekonstruieren.

Nachbereitung mit konkreten Maßnahmen abschließen

• Den tatsächlichen Auslöser und die Nutzerwirkung dokumentieren.
• Erkennung, Maßnahmen und Abnahme in einer gemeinsamen Zeitleiste zusammenführen.
• Unbestätigte Ursachen als offene Untersuchung kennzeichnen.
• Temporäre Eingriffe kontrolliert zurücknehmen oder dauerhaft entscheiden.
• Verbesserungen mit Verantwortlichem, Zielzustand und Prüfung versehen.
• Das Runbook versionieren und nach relevanten Änderungen erneut üben.

Vermeiden Sie Maßnahmen wie „zukünftig besser aufpassen“. Sie ändern keinen nachvollziehbaren Prozess. Eine konkrete Verbesserung lautet beispielsweise: Der Alarm verlinkt künftig den passenden Logpfad, und eine Testmeldung prüft diese Änderung. Oder: Der Restorebericht enthält künftig einen Nachweis für Schreibzugriff. Eine solche Maßnahme kann später tatsächlich abgenommen werden. Das Runbook wächst dadurch aus echten Betriebsfragen heraus und bleibt ein nutzbares Werkzeug für den nächsten Vorfall, ohne sich in einer immer längeren Sammlung allgemeiner Ratschläge zu verlieren.