Deploy-Fehler als Ausfallursache: in Minuten zurückrollen

Die wahrscheinlichste Ursache sitzt im eigenen Haus

Google SRE hat aus dem eigenen Betrieb eine Zahl veröffentlicht, die seit Jahren unverändert zitiert wird: Rund 70 Prozent der Ausfälle gehen auf Änderungen am laufenden System zurück (Google SRE). Der zweite Band bestätigt sie im Zusammenhang mit dem Fehlerbudget und nennt Änderungen eine wesentliche Quelle der Instabilität (Google SRE Workbook). Für einen Betrieb, der wöchentlich veröffentlicht, heißt das: Die Wahrscheinlichkeit, dass der nächste Vorfall am Dienstagvormittag beginnt und nicht in der Nacht zum Sonntag, ist deutlich höher, als es die Sicherheitsdebatte nahelegt.

Konkreter wird es bei den Auslösern. Eine Auswertung tausender Rückblicke über sieben Jahre nennt als häufigsten Auslöser die Binärauslieferung mit 37 Prozent, gefolgt von der Konfigurationsänderung mit 31 Prozent (Google SRE Workbook). Zusammen sind das gut zwei Drittel; geändertes Nutzerverhalten folgt mit 9 Prozent weit dahinter. Unter den Ursachenkategorien steht der Fehler im Entwicklungsprozess mit 20,23 Prozent an zweiter Stelle, die mangelhafte Auslieferungsplanung mit 6,74 Prozent an vierter (Google SRE Workbook). Auch das Kapitel zur stufenweisen Auslieferung hält fest, dass die Mehrheit der Vorfälle durch Binär- oder Konfigurationsschübe ausgelöst wird (Google SRE Workbook).

Was in der Praxis hinter diesen Kategorien steckt, lässt sich auf fünf wiederkehrende Muster eindampfen:

• Ein Artefakt mit zu vielen Änderungen - drei Wochen Arbeit in einem Schritt. Fällt etwas aus, stehen achtzehn Änderungen gleichzeitig unter Verdacht.
• Eine Konfiguration, die nur im Testsystem stimmt - andere Zwischenspeicherzeiten, andere Kopfzeilen, ein anderer Endpunkt in der Bezahlstrecke.
• Eine Abhängigkeit, die sich still verändert hat - eine Schnittstelle, ein Zustimmungsbanner, ein Skript aus einer fremden Quelle.
• Ein Deploy ohne Rückweg - das Datenbankschema wurde geändert, die vorige Fassung läuft darauf nicht mehr, der Rücksprung ginge nur über eine Wiederherstellung.
• Ein Fenster ohne Zuständigkeit - freitags um 17 Uhr veröffentlicht, ab 17:30 Uhr ist niemand mehr erreichbar.

Alle fünf Punkte haben eine Gemeinsamkeit: Sie sind planbar. Der Angreifer wählt seinen Zeitpunkt selbst, die eigene Veröffentlichung nicht - die wird terminiert. Damit ist der Deploy die einzige große Ausfallursache, die man in den Kalender schreiben kann. Genau daraus entsteht die Ordnung, die dieser Beitrag beschreibt.

Was ein Ausfall kostet

Die Kostenseite ist gut dokumentiert. In der Jahresumfrage, die dem Ausfallbericht des Uptime Institute für 2026 zugrunde liegt, geben 57 Prozent der Befragten an, dass ihr letzter größerer Ausfall mehr als 100.000 US-Dollar gekostet hat; im zweiten Jahr in Folge nennt jeder Fünfte einen Betrag über einer Million US-Dollar (Uptime Institute). Etwa jeder Zehnte berichtet von schweren oder sehr schweren Auswirkungen (Uptime Institute). Für eine mittelständische Website sind die absoluten Zahlen kleiner, das Verhältnis bleibt: Der Schaden wächst mit der Dauer, nicht mit der Schwere des ursprünglichen Fehlers.

Bemerkenswerter als die Beträge ist die Ursachenzuschreibung. Für 2026 bleibt das Nichtbefolgen vorgeschriebener Verfahren der wichtigste Treiber menschlich verursachter Ausfälle; daneben stehen uneinheitliche oder unklare Prozesse sowie Fehler bei Installation und Inbetriebnahme (Uptime Institute). Das ist kein Werkzeugproblem. Ein Verfahren, das niemand einhält, wirkt wie kein Verfahren - und ein Verfahren, das nur in einem Dokument steht, wird im Ernstfall nicht eingehalten, sondern erinnert.

Das Änderungsfenster: wann veröffentlicht werden darf

Ein Änderungsfenster ist eine schriftliche Verabredung darüber, wann veröffentlicht werden darf und wann nicht. Es kostet nichts und wirkt sofort, weil es die drei teuersten Umstände ausschließt: Veröffentlichung ohne Bereitschaft, Veröffentlichung in der Spitzenlast, Veröffentlichung ohne Zeugen. Fünf Angaben genügen.

1. Fester Termin - zum Beispiel Dienstag und Donnerstag, 09:00 bis 11:00 Uhr. Außerhalb wird nur veröffentlicht, was eine laufende Störung behebt.
2. Benannte Bereitschaft - eine Person führt aus, eine zweite sieht zu und misst. Beide sind für die volle Dauer des Fensters erreichbar.
3. Vorher festgehaltener Ausgangsstand - Messwerte und Bildschirmfotos der wichtigsten Seiten, damit der Vergleich danach eine Grundlage hat.
4. Abbruchbedingung - vorher aufgeschrieben, welche Abweichung den Rücksprung auslöst. Nicht während des Fensters aushandeln.
5. Zeitfenster für die Nachmessung - die Veröffentlichung endet nicht mit dem Hochladen, sondern mit dem Messergebnis.

Der vierte Punkt ist der, an dem Fenster scheitern. Solange die Abbruchbedingung nicht vorher feststeht, wird sie im Ereignis ausgehandelt - von Menschen, die gerade etwas veröffentlicht haben, an das sie glauben. Eine Regel wie "mehr als zwei Prozent Fehlerrate über fünf Minuten" oder "ein Browser-Flow bricht zweimal hintereinander ab" ist unbequem, aber sie entscheidet ohne Diskussion und ohne Ansehen der Person.

Der Ausgangsstand: messen, bevor sich etwas ändert

Ohne Ausgangsstand ist jede Nachmessung ein Bauchgefühl. "Die Seite kommt mir langsam vor" ist keine Aussage, "der größte Inhaltsbereich lädt jetzt in 3,4 statt in 1,9 Sekunden" ist eine. Der Ausgangsstand ist deshalb nichts Großes: eine feste Liste von Adressen, dazu je Adresse ein Satz Werte und ein Bildschirmfoto, aufgenommen unmittelbar vor der Auslieferung. Zehn Minuten Arbeit, die im Ereignis eine Stunde Diskussion sparen.

Drei Werte reichen für den Anfang: Statuscode, Antwortzeit und die Ladeschwelle des größten Inhaltsbereichs. Als guter Wert gilt dort eine Ladezeit von 2,5 Sekunden oder weniger (web.dev). Wer die Web-Vitals-Werte ohnehin fortlaufend erhebt, hat den Ausgangsstand bereits und muss ihn nicht eigens erzeugen. Dazu gehört ein Bildschirmfoto je Seitentyp - Startseite, Kategorie, Leistung oder Produkt, Formular, Kasse -, damit die Änderungserkennung nach dem Deploy etwas hat, wogegen sie vergleichen kann. Die Liste bleibt über Monate dieselbe; nur so entsteht eine Reihe statt einer Momentaufnahme.

Die Nachmessung: fünf Fragen in zehn Minuten

Die Nachmessung beantwortet fünf Fragen, und zwar in dieser Reihenfolge: Antwortet der Server? Sieht die Seite aus wie vorher? Funktionieren die Wege, mit denen Geld verdient wird? Ist die Seite noch so schnell wie vorher? Und: Ist sie noch auffindbar? Jede Frage hat einen eigenen Messpunkt, und keiner davon ist ein Mensch mit einem Browser - der misst nicht, der schaut.

Der vierte und der fünfte Punkt werden am häufigsten vergessen, weil sie keinen Ausfall erzeugen, sondern einen Schaden mit Verzögerung. Eine Seite, die nach dem Deploy eine Sekunde langsamer ist, meldet niemand; eine Seite, die versehentlich auf noindex steht, fällt erst auf, wenn der Verkehr aus der Suche wegbricht. Wie ein solcher Deploy-Unfall mit noindex abläuft, ist ein eigenes Thema. Dasselbe gilt für veraltete Inhalte aus einer Zwischenspeicherschicht, die nach der Auslieferung noch minutenlang die alte Fassung ausliefert, und für Zustimmungsmerkmale, die nach einem Deploy verrutschen.

Stufenweise ausliefern statt auf einmal

Die von Google SRE empfohlene Gegenmaßnahme besteht aus drei Teilen: stufenweise Auslieferung, schnelle und genaue Fehlererkennung sowie sicheres Zurücknehmen von Änderungen. Dieser Dreiklang verringert wirksam die Zahl der Nutzer und Vorgänge, die einer schlechten Änderung ausgesetzt sind (Google SRE). Der Gedanke dahinter ist nicht Technik, sondern Arithmetik: Wer eine fehlerhafte Fassung zuerst an fünf Prozent des Verkehrs ausliefert, hat im schlechtesten Fall fünf Prozent Schaden.

Für eine Website mit einem einzigen Server ist die Stufung gröber, aber nicht unmöglich: ein Verzeichnis je Fassung und ein Verweis, der umgelegt wird; ein Vorlauf auf einer zweiten Adresse; eine Umleitung eines Teils des Verkehrs über die Serverkonfiguration. Der Aufwand fällt einmal an, der Nutzen wiederholt sich bei jeder Veröffentlichung.

Der Rücksprung: geprobt, nicht improvisiert

Ein Rücksprung, der nur auf dem Papier existiert, ist kein Rücksprung. Er wird einmal im Quartal ohne Anlass geprobt, am besten im regulären Änderungsfenster: Fassung ausliefern, Rücksprung auslösen, Zeit messen, Ergebnis notieren. Wer das dreimal gemacht hat, kennt seine eigene Zahl - und die liegt in aller Regel deutlich über der geschätzten.

#!/usr/bin/env bash
# Rücksprung auf eine vorhandene Fassung: Verweis umlegen, Zwischenspeicher leeren, nachmessen
set -euo pipefail

ZIEL="/var/www/fassungen/$1"
test -d "$ZIEL" || { echo "Fassung $1 fehlt"; exit 1; }

ln -sfn "$ZIEL" /var/www/aktuell
systemctl reload nginx
redis-cli -n 2 FLUSHDB >/dev/null

for pfad in / /kasse/ /kontakt/; do
  code=$(curl -sS -o /dev/null -w '%{http_code}' "https://www.beispiel.example.invalid${pfad}")
  printf '%s %s\n' "$pfad" "$code"
done

Drei Dinge entscheiden über die Dauer: ob der Verweis auf die Fassung umgelegt werden kann statt neu gebaut zu werden, ob die Zwischenspeicherschichten in einem Schritt geleert werden und ob das Datenbankschema die vorige Fassung noch bedient. Der dritte Punkt ist der teuerste. Eine Spalte, die in der neuen Fassung hinzukommt, stört den Rücksprung nicht; eine Spalte, die umbenannt oder entfernt wurde, macht ihn unmöglich. Die Regel dagegen ist einfach: erst hinzufügen, dann umstellen, und erst eine Fassung später aufräumen.

Die Frage im Ereignis lautet nie "Was ist die Ursache?", sondern "Wie komme ich in fünf Minuten in den Zustand von vorhin zurück?". Die Ursache klärt der Rückblick am nächsten Tag.

— XICTRAQ

Was ein Rücksprung nicht heilt

Der Rücksprung nimmt die Änderung zurück, nicht ihre Folgen. Diese Unterscheidung fehlt in den meisten Notfallplänen und kostet nach dem eigentlichen Ereignis noch einmal Zeit - meistens genau dann, wenn alle glauben, es sei vorbei.

• Geschriebene Daten bleiben geschrieben - Bestellungen, die vierzig Minuten lang mit falschem Steuersatz berechnet wurden, sind nach dem Rücksprung immer noch falsch.
• Zwischenspeicher halten die kaputte Fassung - Dienste vor der Anwendung, Browser der Besucher und Zwischenspeicher der Anbieter liefern die fehlerhafte Seite weiter aus, bis sie gezielt geleert wurde oder abgelaufen ist.
• Suchmaschinen haben den Zwischenstand gesehen - ein versehentliches noindex wirkt, sobald es abgerufen wurde, und verschwindet nicht in dem Moment, in dem es zurückgenommen wird.
• Zustimmungs- und Messmerkmale laufen weiter - ein Skript, das in der kaputten Fassung ohne Einwilligung geladen wurde, hat in dieser Zeit Daten erhoben.
• Die Barrierefreiheit bleibt gebrochen - ein entfernter Beschriftungstext oder ein verlorener Fokusring löst keinen Alarm aus; dafür braucht es eine fortlaufende Prüfung gegen die WCAG-Kriterien.

Kennzahlen, die den Fortschritt zeigen

Für die Frage, ob die eigene Veröffentlichungspraxis besser wird, genügen zwei Kennzahlen. Die erste ist der Anteil der Auslieferungen, die unmittelbar nach der Auslieferung ein Eingreifen verlangen - in aller Regel einen Rücksprung oder eine schnelle Fehlerbehebung (DORA). Die zweite ist die Zeit, die es braucht, sich von einer fehlgeschlagenen Auslieferung zu erholen, die sofortiges Eingreifen verlangt (DORA). Beide sagen nichts über die Qualität des Codes und alles über die Beherrschung des Vorgangs.

Messbar sind sie ohne zusätzliches Werkzeug, sobald das Änderungsfenster protokolliert wird: Zahl der Veröffentlichungen, Zahl der Rücksprünge, Dauer je Rücksprung. Nach zehn Fenstern ergibt das eine Reihe, nach dreißig eine Aussage. Wichtig ist nur, dass die zweite Kennzahl vom Messpunkt aus gerechnet wird und nicht vom Zeitpunkt der Erkenntnis: Die Uhr beginnt mit der Auslieferung, nicht mit dem Anruf des Kunden.

Meldewege während des Fensters

Während des Fensters ändert sich die Alarmlage. Ein Team, das seine Benachrichtigungswege sonst auf ruhige Schwellen eingestellt hat, braucht für zwei Stunden eine schärfere Einstellung: kürzere Prüfintervalle, niedrigere Schwellen, ein zweiter Empfänger. Danach wird zurückgestellt, sonst gewöhnt sich das Team an Meldungen, die nichts bedeuten - und überhört die eine, die etwas bedeutet.

Zum Meldeweg gehört die Gegenrichtung. Wer eine Statusseite oder einen regelmäßigen Bericht pflegt, sollte dort während des Fensters etwas stehen haben, und zwar bevor die erste Anfrage kommt. Kommt es zum Ausfall, sind zwei Sätze auf der Statusseite der Unterschied zwischen einem Betreiber, der Bescheid weiß, und einem, der nichts gemerkt hat. Für Hintergrundverarbeitung, die nach einem Deploy stillsteht, meldet nur ein Herzschlagsignal den Stillstand überhaupt, und für die Gegenstelle einer Schnittstelle braucht es eine Prüfung der Antwortstruktur, nicht nur des Statuscodes.

Der Rückblick nach dem Ereignis

Ein Rücksprung verdient einen Rückblick - nicht als Formalie, sondern weil er beweist, dass etwas durch alle Prüfungen gekommen ist, das nicht hätte durchkommen sollen. Google SRE nennt den Eingriff der Bereitschaft, ausdrücklich einschließlich des Rücksprungs bei einer Veröffentlichung, als einen der üblichen Auslöser für einen Rückblick (Google SRE). Fünf Fragen genügen für das Protokoll:

1. Was war der Auslöser? - die konkrete Änderung, nicht "der Deploy".
2. Warum hat die Prüfung vor der Auslieferung sie nicht gesehen? - fehlender Testfall, fehlende Konfiguration, fehlende Datenlage.
3. Wie lange hat die Erkennung gedauert? - von der Auslieferung bis zur ersten Meldung.
4. Wie lange hat der Rücksprung gedauert? - von der Entscheidung bis zum gemessenen Normalzustand.
5. Was hat die Entscheidung verzögert? - meistens eine fehlende oder unklare Abbruchbedingung.

Google SRE empfiehlt, die Kriterien für einen Rückblick festzulegen, bevor ein Ereignis eintritt, damit alle wissen, wann einer nötig ist (Google SRE). Derselbe Satz gilt für die Abbruchbedingung im Fenster. Beides sind Entscheidungen, die man in Ruhe trifft oder gar nicht.

Ein Fahrplan für die nächsten vier Wochen

Der Einstieg braucht keine Plattform, sondern vier Wochen und eine Person, die es aufschreibt. Jede Woche endet mit einem Ergebnis, das man vorzeigen kann.

1. Woche 1: Fenster setzen. Zwei feste Termine, benannte Bereitschaft, schriftliche Abbruchbedingung. Eine Seite Text genügt.
2. Woche 2: Ausgangsstand herstellen. Feste Seitenliste, Erreichbarkeitsprüfung, Bildschirmfotos, erste Werte für den größten Inhaltsbereich.
3. Woche 3: Nachmessung automatisieren. Browser-Flows für Anmeldung, Formular und Kasse aufzeichnen, den Lauf nach dem Deploy anstoßen, Schwellen setzen.
4. Woche 4: Rücksprung proben. Einmal ohne Anlass zurückspringen, Dauer messen, Ergebnis notieren, die gefundenen Lücken schließen.

Nach diesen vier Wochen ist der Deploy nicht sicherer geworden, sondern beobachtbar - und das ist der eigentliche Fortschritt. Die Änderungserkennung meldet, was sich sichtbar verändert hat; die Erreichbarkeitsprüfung meldet, ob der Server überhaupt antwortet; die aufgezeichneten Flows melden, ob die Wege noch funktionieren, mit denen Geld verdient wird. Die wahrscheinlichste Ausfallursache steht damit unter Beobachtung, und zwar zu einem Zeitpunkt, den der Betrieb selbst gewählt hat.