Der Besprechungsraum heißt „Aquarium“, weil eine Wand aus Glas ist, und an diesem Donnerstag saßen drei Leute darin und haben einen Server abgeschaltet.

Es war ein geplanter Test, elfte Stunde, ein Pod von acht, mitten am Tag, mit einem Abbruchkriterium auf einem Zettel. Der Dienst hat es nicht gemerkt. Kein Alert, keine Fehlermeldung, keine langsamere Antwort. Wir haben uns abgeklatscht, und dann ist etwas passiert, das ich nicht erwartet hatte: nichts.

Die Erkenntnis stand in einem Notizbuch. Sie stand nicht in einem Ticket, nicht in einem Postmortem, nicht in einem Satz, den irgendwer außerhalb dieses Raums je gelesen hat. Zwei Wochen später habe ich jemanden gefragt, ob er weiß, dass der Checkout einen Pod-Verlust übersteht. Die Antwort war: „Keine Ahnung, wahrscheinlich nicht.“

Der Channel hatte zwei Mitglieder

#chaos-eng, zwei Mitglieder, vierzehn Nachrichten, alle von uns. Das ist keine Übung. Das ist ein Hobby mit einem Serverzugang.

Ich habe das nicht gesagt, um gemein zu sein. Ich habe es gesagt, weil mir in dem Moment klar wurde, dass wir die ganze Arbeit gemacht und nichts verändert hatten. Ein Experiment, dessen Ergebnis nur die drei Menschen kennen, die es durchgeführt haben, verändert genau drei Menschen. Und die drei wussten es vorher schon.

Das ist der Punkt, an dem Chaos Engineering aufhört, Ingenieursarbeit zu sein, und anfängt, ein Ritual zu werden. Man trifft sich, man schaltet etwas ab, man ist erleichtert, man geht essen.

Was wir getestet haben

Leerer Besprechungsraum mit Glaswand und einem Laptop auf dem Tisch
Drei Leute, ein Zettel, ein Ergebnis, das den Raum nicht verlässt.

Drei Dinge, an drei Donnerstagen. Erstens: einen Pod von acht getötet. Ergebnis: nichts, der Load Balancer hat in 400 Millisekunden umverteilt. Zweitens: 300 Millisekunden Verzögerung zum Zahlungsdienstleister. Ergebnis: 40 Prozent mehr abgebrochene Checkouts, weil unser Timeout bei 800 Millisekunden liegt und der Retry nicht greift. Drittens: ein Datenbank-Failover. Ergebnis: 22 Sekunden, in denen die Seite einen Fehler zeigt.

Die zweite Zahl war die interessante. 40 Prozent mehr Abbrüche heißt: Viermal so viele Menschen geben auf, obwohl das System „nur“ langsamer ist. Und die dritte Zahl war die, die niemand gesehen hat, weil unser Diagramm über eine Minute mittelt und eine 22-Sekunden-Lücke darin wie ein normaler Ausschlag aussieht.

Beides sind Erkenntnisse, für die man normalerweise einen Ausfall braucht. Wir hatten sie an einem Donnerstagnachmittag, für den Preis von zwei Stunden und einem Kaffee. Und dann haben wir sie weggelegt.

Der Kreislauf, der keinen Ausgang hatte

flowchart LR A[Hypothese] --> B[Blast Radius in Prozent] B --> C[Experiment starten] C --> D[Abbruchkriterium beobachten] D --> E[Ergebnis dokumentieren] E --> F[Ticket mit Datum] F --> A

Der Kreislauf sieht vollständig aus. Er hatte einen Ausgang, den niemand genommen hat: das Ticket. Wir haben drei Experimente gemacht und null Tickets geschrieben, weil das Ergebnis jeweils „hat funktioniert“ war. „Hat funktioniert“ ist kein Ticket. Es ist eine Beruhigung.

Dabei war das zweite Experiment alles andere als beruhigend. 300 Millisekunden Verzögerung, 40 Prozent Abbrüche — das ist ein Ticket, ein großes sogar, mit einem Timeout, einem Retry und einem Satz im Frontend. Es ist nie entstanden, weil im Raum alle wussten, was zu tun wäre, und niemand es aufgeschrieben hat.

Wissen, das nur im Raum existiert, ist Wissen, das mit der nächsten Kündigung geht.

Ein Publikum ist Teil des Experiments

Wir haben drei Dinge geändert. Erstens: Ein Experiment pro Monat wird im Engineering-Weekly in fünf Minuten vorgestellt, mit dem einen Diagramm, das die Lücke zeigt. Nicht der Ablauf, nicht die Methode — die Lücke.

Zweitens: Jedes Experiment endet mit einem Ticket oder mit dem Satz „kein Ticket, weil …“ im Dokument. Die zweite Option ist erlaubt und wird benutzt. Sie zwingt zu einem Satz, den jemand anders lesen kann, und das ist der ganze Unterschied.

Drittens, und das war die wichtigste Änderung: Der Blast Radius wird vorher in Prozent der Nutzer aufgeschrieben, nicht in Pods. „Wir killen einen Pod“ klingt nach Technik. „Wir nehmen zwölf Prozent der Checkouts für neunzig Sekunden aus dem Pool“ klingt nach einer Entscheidung, die jemand treffen muss, und für die jemand die Verantwortung trägt.

Diese dritte Änderung hat unsere Experimente kleiner gemacht und ihre Wirkung größer. Wir testen jetzt öfter, mit weniger Risiko, und jedes Ergebnis hat einen Leser, der nicht im Raum war.

Fazit

Chaos Engineering ist kein Werkzeug. Es ist eine Behauptung darüber, was du über dein System weißt, und eine Behauptung, die niemand liest, ist ein Gerücht.

Der teuerste Teil ist nicht das Abschalten. Es ist das Aufschreiben und das Vorstellen, und beides fühlt sich an wie Verwaltung. Es ist aber der Teil, der aus einem Nachmittag im Aquarium eine Änderung am System macht.

Wenn morgen ein Drittel deiner Infrastruktur ausfällt: Wer in deinem Team wüsste, was dann passiert — und wo genau steht das?