Für den Fehlerfall entwerfen

Die meisten Systeme werden für den guten Tag gebaut — für den Fall, dass alles funktioniert, jede Verbindung antwortet, jeder Dienst erreichbar ist, jede Annahme hält. Das ist verständlich, weil der gute Tag der häufige ist. Es ist auch der Grund, warum so viele Systeme am schlechten Tag versagen: Sie sind nie für ihn entworfen worden. Software wird nicht am guten Tag beurteilt, sondern am schlechten — und am schlechten Tag zeigt sich, ob jemand vorher an ihn gedacht hat.

Dieses Dokument behandelt das Entwerfen für den Fehlerfall — die Disziplin, Systeme so zu bauen, dass sie das unvermeidliche Versagen ihrer Teile ertragen, statt daran zu zerbrechen. Es ist framework- und cloud-neutral gehalten, weil es von einer Haltung handelt, nicht von einem Werkzeug. Es ist die Kehrseite der Beobachtbarkeit: Diese zeigt, dass etwas schiefgeht; das Entwerfen für den Fehlerfall sorgt dafür, dass das Schiefgehen nicht das ganze System mitreißt. Genannt werden keine Zahlen.

1. Alles fällt irgendwann aus

Die eine Annahme, die alles ändert, ist einfach: In einem echten System fällt jeder Teil irgendwann aus. Eine Verbindung bricht, ein Dienst antwortet nicht, eine Festplatte versagt, ein Aufruf dauert zu lange, ein Nachbarsystem ist überlastet. Das ist kein seltener Ausnahmefall, den man ignorieren dürfte, sondern die Normalität eines Systems, das lange genug läuft und aus genug Teilen besteht. Wer davon ausgeht, dass die Teile funktionieren, baut auf einer Annahme, die die Zeit widerlegt.

Diese Annahme umzukehren — davon auszugehen, dass die Teile ausfallen, und zu fragen, was dann geschieht — ist der Kern der Disziplin. Sie verlangt keinen Pessimismus, sondern Realismus: Man plant für das, was mit Sicherheit eintritt, statt zu hoffen, dass es ausbleibt. Ein System, das für den Ausfall seiner Teile entworfen ist, hat am schlechten Tag eine Antwort; eines, das ihn nicht bedacht hat, hat nur Überraschung. Der Unterschied entscheidet sich lange vor dem Vorfall, im Entwurf. Man kann den schlechten Tag nicht verhindern — man kann nur entscheiden, ob man ihm vorbereitet oder überrascht begegnet, und diese Entscheidung fällt, wenn alles noch ruhig ist.

Trade-off. Vom Ausfall auszugehen bedeutet, mehr zu entwerfen als den guten Fall — Aufwand, der sich nur am schlechten Tag auszahlt, den man im Entwurf aber nicht sieht.

Kosten. Für den Fehlerfall zu bauen macht Systeme im Moment komplexer und langsamer im Bau, weil man Fälle behandelt, die im Test selten auftreten.

Wann wir anders entscheiden. Für ein kurzlebiges, unkritisches System, dessen Ausfall folgenlos ist, ist die volle Fehlerauslegung überzogen; ihr Wert wächst mit der Zahl der Teile, der Länge des Betriebs und dem Schaden eines Ausfalls.

2. Bekannte und unbekannte Fehlermodi

Ein Fehlermodus ist eine Art, auf die ein System versagen kann. Manche kennt man: Man hat sie bedacht, behandelt, vielleicht sogar geprobt. Andere kennt man nicht — sie entstehen aus einer Kombination von Umständen, die niemand vorhergesehen hat, und zeigen sich zum ersten Mal in Produktion. Der reife Umgang besteht nicht darin, alle Fehlermodi zu kennen — das ist unmöglich —, sondern darin, die bekannten sauber zu behandeln und das System so zu bauen, dass auch ein unbekannter Fehler nicht sofort das Ganze mitreißt.

Daraus folgt ein Maßstab für Fertigkeit: Ein System, dessen Fehlermodi niemand kennt, ist nicht fertig, sondern nur noch nicht geprüft. Solange man nicht sagen kann, was geschieht, wenn dieser Dienst ausfällt oder jene Verbindung bricht, hat man das System nur für den guten Tag gebaut. Die Frage „was passiert, wenn das hier versagt?" bei jedem Teil zu stellen, ist die Übung, die bekannte Fehlermodi ans Licht bringt, solange man sie noch behandeln kann — und die zeigt, wo man sich auf Eindämmung verlassen muss, weil man das Versagen nicht verhindern kann.

Trade-off. Fehlermodi bewusst zu suchen kostet Zeit im Entwurf und die Bereitschaft, unbequeme „was, wenn"-Fragen zu stellen, während alle das System fertig sehen wollen.

Kosten. Die Suche ist nie vollständig; man findet die bekannten, nicht die unbekannten, und muss mit dem Rest leben, den man nicht vorhersah.

Wann wir anders entscheiden. Wo ein Teil offensichtlich unkritisch ist und sein Ausfall folgenlos, spart man sich die tiefe Analyse; die Aufmerksamkeit gilt den Teilen, deren Versagen das System oder seine Nutzer trifft.

3. Fehler eindämmen, nicht verhindern

Man kann Fehler nicht verhindern — man kann nur ihre Folgen begrenzen. Das ist die zentrale Verschiebung: weg von dem aussichtslosen Ziel, dass nichts versagt, hin zu dem erreichbaren, dass das Versagen eines Teils nicht das Ganze mitreißt. Dazu isoliert man die Teile voneinander, sodass ein Fehler an seiner Grenze aufgehalten wird, statt sich auszubreiten. Ein überlasteter oder ausgefallener Teil darf die anderen nicht mit sich ziehen; er wird abgetrennt, sein Ausfall bleibt lokal, und der Rest des Systems arbeitet weiter.

Schema: Ohne Grenze pflanzt sich ein Ausfall durch das ganze System fort; mit Grenze bleibt er dort, wo er entstand. Eindämmung schlägt Verhinderung.

Zur Eindämmung gehört auch, sich beim Aufruf eines anderen Teils nie unbegrenzt auf dessen Antwort zu verlassen: Man wartet nicht ewig, sondern nur eine begrenzte Zeit und behandelt das Ausbleiben der Antwort als das, was es ist — einen Fehler, auf den man vorbereitet ist. Ein Aufruf ohne Zeitgrenze ist eine offene Tür, durch die der Ausfall eines Nachbarn ins eigene System eindringt.

Die wichtigsten Werkzeuge der Fehlerauslegung im Überblick — jedes eine Entwurfshaltung, keine nachträgliche Einstellung:

Ein besonders wirksames Muster der Eindämmung ist, einen Teil, der wiederholt versagt, vorübergehend gar nicht mehr aufzurufen. Statt immer wieder gegen eine geschlossene Tür zu laufen und dabei Ressourcen zu binden, erkennt das System, dass ein Nachbar gerade nicht antwortet, und lässt ihn eine Weile in Ruhe — es fällt sofort auf die vorgesehene Fehlerbehandlung zurück und versucht es erst nach einer Pause wieder. Das schützt zwei Seiten zugleich: das eigene System, das nicht in aussichtslosen Wiederholungen erstickt, und den überlasteten Nachbarn, dem man die Chance zur Erholung gibt, statt ihn mit Anfragen weiter unter Wasser zu drücken. Eindämmung heißt hier, den Fehler nicht nur lokal zu halten, sondern ihn auch nicht durch blindes Beharren zu verschlimmern.

Trade-off. Eindämmung kauft Widerstandskraft mit Grenzen und Isolation, die man entwerfen und pflegen muss — Struktur, die im guten Fall überflüssig wirkt.

Kosten. Jede Grenze, jede Zeitschranke, jede Abtrennung ist zusätzliche Logik mit eigenen Grenzfällen, die man versteht und testet.

Wann wir anders entscheiden. In einem kleinen, eng gekoppelten System, dessen Teile ohnehin gemeinsam stehen und fallen, bringt Isolation wenig; ihr Wert wächst mit der Unabhängigkeit der Teile und dem Schaden einer Ausbreitung.

4. Sichere Wiederholung

Viele Fehler sind vorübergehend: Eine Verbindung bricht kurz, ein Dienst ist einen Moment überlastet, ein Aufruf läuft in eine Zeitschranke. Auf solche Fehler mit einer Wiederholung zu reagieren, ist naheliegend und oft richtig — aber nur, wenn die Operation eine Wiederholung sicher verträgt. Eine Operation blind zu wiederholen, die bei doppelter Ausführung doppelt wirkt, verwandelt einen harmlosen vorübergehenden Fehler in einen echten Schaden: eine doppelte Abbuchung, eine doppelte Bestellung, einen doppelten Effekt, den niemand wollte.

Deshalb gehören Wiederholung und Idempotenz untrennbar zusammen. Man wiederholt nur, was ohne Schaden wiederholbar ist — und sorgt dafür, dass zustands- und geldändernde Operationen diese Eigenschaft haben, bevor man sie automatisch wiederholt. Eine sichere Wiederholung ist damit keine reine Betriebseinstellung, sondern eine Entwurfsentscheidung: Man baut die Operationen so, dass ein zweiter Versuch dasselbe Ergebnis hat wie der erste. Wer wiederholt, ohne das sicherzustellen, hat den Fehler nicht behandelt, sondern verdoppelt.

Trade-off. Sichere Wiederholung kauft die Erholung von vorübergehenden Fehlern mit dem Aufwand, Operationen idempotent zu machen — Mechanik, die man baut und pflegt.

Kosten. Idempotenz herzustellen verlangt Zustand und Sorgfalt bei Nebenläufigkeit; das ist echte Arbeit, die pro wiederholbarer Operation anfällt.

Wann wir anders entscheiden. Reine Lesevorgänge und natürlich idempotente Operationen wiederholt man ohne Zusatzaufwand; die Sorgfalt gilt den Operationen, die von sich aus nicht wiederholbar sind — dort wiederholt man erst, wenn sie es sind (siehe Idempotenz in verteilten Systemen).

5. Würdevoller Abbau statt Totalausfall

Wenn ein Teil ausfällt, gibt es fast immer mehr als zwei Möglichkeiten. Zwischen „alles funktioniert" und „nichts funktioniert" liegt ein weites Feld: das System kann seine wichtigste Aufgabe weiter erfüllen, während eine nebensächliche pausiert; es kann eine ältere, gecachte Antwort liefern, statt gar keine; es kann eine Funktion vorübergehend abschalten, statt zusammenzubrechen. Würdevoller Abbau heißt, diese Zwischenstufen bewusst zu entwerfen, sodass der Ausfall eines Teils zu weniger Funktion führt, nicht zu keiner.

Schema: Zwischen voller Funktion und Totalausfall liegen Stufen. Würdevoller Abbau steigt sie ab, statt zu stürzen — die gestrichelte Stufe erreicht man nur, wenn keine andere mehr trägt.

Der Wert liegt darin, dass ein Nutzer einen teilweisen Dienst fast immer einem völligen Ausfall vorzieht. Ein System, das bei einem Problem eine Nebenfunktion abschaltet und die Hauptaufgabe weiterträgt, wirkt verlässlich; eines, das beim ersten Ausfall ganz stehenbleibt, wirkt zerbrechlich — obwohl vielleicht nur ein kleiner Teil betroffen war. Den Abbau zu entwerfen bedeutet, im Voraus zu entscheiden, was wichtig genug ist, um es unter Fehlern zu erhalten, und was verzichtbar genug, um es fallen zu lassen. Diese Reihenfolge trifft man am Schreibtisch, nicht im Vorfall.

Trade-off. Würdevoller Abbau kauft Verlässlichkeit im Teilausfall mit dem Aufwand, mehrere Stufen von Funktion zu entwerfen statt nur ein Alles-oder-Nichts.

Kosten. Jede Abbaustufe ist ein eigener Zustand, den man baut, versteht und testet; zu viele Stufen können das System selbst komplex und schwer durchschaubar machen.

Wann wir anders entscheiden. Wo eine teilweise Funktion keinen Wert hat — ein Vorgang ist nur ganz oder gar nicht sinnvoll —, entwirft man keinen Abbau; er lohnt sich dort, wo ein Rest an Funktion dem Nutzer noch dient.

6. Den Fehlerfall proben

Man weiß nicht, ob ein System einen Ausfall erträgt, bis man es ausprobiert hat. Die gefährlichste Annahme in der Resilienz ist, dass die Vorkehrung schon funktioniert, weil man sie gebaut hat — die Sicherung, die nie zurückgespielt wurde, die Ausweichlösung, die nie ausgelöst hat, das Zeitlimit, das nie gegriffen hat. Solche ungeprüften Vorkehrungen sind kein Schutz, sondern eine Hoffnung mit dem Anschein von Schutz. Erst wenn man den Fehlerfall bewusst herbeiführt und beobachtet, ob das System reagiert wie gedacht, weiß man, dass die Resilienz real ist.

Den Fehlerfall zu proben ist deshalb kein Luxus, sondern die einzige Art, Resilienz zu beweisen statt sie zu behaupten. Man schaltet einen Teil bewusst ab und prüft, ob die Eindämmung hält; man lässt eine Antwort ausbleiben und prüft, ob das Zeitlimit greift; man spielt eine Sicherung zurück, um zu wissen, dass man es im Ernstfall kann. Was man nicht geprobt hat, darf man nicht als Schutz zählen. Diese Übung verwandelt vermutete Resilienz in belegte — und deckt die Lücke auf, solange sie noch billig zu schließen ist, statt im echten Vorfall.

Trade-off. Den Fehlerfall zu proben kostet Zeit und ein wenig Mut, ein laufendes System absichtlich zu stören — gegen den Gewinn, die Resilienz zu kennen, statt sie zu hoffen.

Kosten. Proben verlangt Vorbereitung und einen sicheren Rahmen, damit die Übung selbst keinen echten Schaden anrichtet — Aufwand, der sich nur im vermiedenen Ausfall zeigt.

Wann wir anders entscheiden. Für ein unkritisches System, dessen Ausfall folgenlos ist, genügt es, die Vorkehrungen zu durchdenken; das aktive Proben lohnt sich dort, wo ein echter Ausfall ernsten Schaden anrichtet.

7. Fehler sichtbar machen

Für den Fehlerfall zu entwerfen setzt voraus, den Fehlerfall zu bemerken. Eine noch so gute Eindämmung, ein noch so kluger Abbau nützen nichts, wenn niemand sieht, dass sie gerade wirken — dann arbeitet das System zwar weiter, aber unbemerkt in einem beschädigten Zustand, und der eigentliche Fehler bleibt ungeklärt, bis er sich verschlimmert. Resilienz und Beobachtbarkeit gehören deshalb zusammen: Die eine sorgt dafür, dass ein Fehler nicht das Ganze mitreißt; die andere sorgt dafür, dass man ihn sieht und darauf reagieren kann.

Das bedeutet konkret, dass der Fehlerfall selbst sichtbar sein muss — nicht nur der Totalausfall, sondern auch der stille Teilausfall, die ausgelöste Ausweichlösung, die gegriffene Zeitschranke. Ein System, das würdevoll abbaut, ohne es zu melden, verbirgt seine eigenen Wunden; man hält es für gesund, während es blutet. Die Vorkehrungen für den Fehlerfall gehören deshalb so entworfen, dass ihr Auslösen bemerkt wird — im Sinne der Beobachtbarkeit als Architekturprinzip, die die Voraussetzung dafür ist, auf Fehler überhaupt zu reagieren.

Trade-off. Den Fehlerfall sichtbar zu machen kauft die Fähigkeit zu reagieren mit dem Aufwand, jede Vorkehrung zu instrumentieren — auch die, die im guten Fall nie auslöst.

Kosten. Diese Instrumentierung ist zusätzliche Arbeit an Stellen, die selten aktiv werden, und muss gepflegt werden, damit sie im Ernstfall verlässlich meldet.

Wann wir anders entscheiden. Wo eine Vorkehrung so unkritisch ist, dass ihr stilles Auslösen folgenlos bleibt, darf man auf die Instrumentierung verzichten; sie ist Pflicht dort, wo ein unbemerkter Teilausfall sich verschlimmern kann.

8. Typische Fehler

Die wiederkehrenden Muster, an denen Systeme am schlechten Tag scheitern — fast alle sind Varianten davon, nur für den guten Tag gebaut zu haben:

• Davon ausgehen, dass die Teile funktionieren, statt für ihren unvermeidlichen Ausfall zu entwerfen.
• Ein System für fertig halten, ohne zu wissen, was bei den bekannten Ausfällen geschieht.
• Fehler verhindern wollen statt eindämmen — und beim ersten unvorhergesehenen Versagen das ganze System verlieren.
• Andere Teile ohne Zeitgrenze aufrufen, sodass der Ausfall eines Nachbarn ins eigene System eindringt.
• Nicht idempotente Operationen automatisch wiederholen — den vorübergehenden Fehler zum doppelten Schaden machen.
• Nur Alles-oder-Nichts kennen, wo ein würdevoller Abbau dem Nutzer einen Rest an Funktion erhalten hätte.
• Vorkehrungen als Schutz zählen, die nie geprobt wurden — die Sicherung, die nie zurückgespielt, das Zeitlimit, das nie ausgelöst hat.
• Den Fehlerfall würdevoll abbauen, aber nicht melden — das System blutet unbemerkt weiter.

9. Entscheidungs-Checkliste

Beim Entwurf eines Systems für den Fehlerfall der Reihe nach zu klären:

• Vom Ausfall ausgegangen? Ist das System dafür entworfen, dass seine Teile ausfallen — nicht dafür, dass sie funktionieren?
• Fehlermodi bekannt? Ist bei jedem wichtigen Teil gefragt worden, was geschieht, wenn er versagt?
• Eingedämmt? Bleibt der Ausfall eines Teils lokal, statt sich auszubreiten — durch Isolation und Zeitgrenzen?
• Sicher wiederholbar? Werden nur idempotente Operationen automatisch wiederholt, sodass ein zweiter Versuch keinen Schaden anrichtet?
• Würdevoller Abbau? Gibt es Zwischenstufen zwischen voller Funktion und Totalausfall, die die Hauptaufgabe erhalten?
• Geprobt? Sind die Vorkehrungen bewusst ausgelöst worden, statt nur gebaut — hält, was schützen soll?
• Sichtbar? Wird das Auslösen jeder Vorkehrung bemerkt, auch der stille Teilausfall?
• Angemessen? Ist der Aufwand dem Schaden angemessen — streng, wo ein Ausfall teuer wäre, schlank, wo er folgenlos ist?

Wer diese Fragen beantworten kann, hat ein System gebaut, das den schlechten Tag übersteht — nicht nur eines, das am guten Tag funktioniert.

FAQ

Kann man nicht einfach dafür sorgen, dass nichts ausfällt? Nein. In einem echten System fällt jeder Teil irgendwann aus — eine Verbindung, ein Dienst, eine Festplatte, ein überlasteter Nachbar. Das ist die Normalität, nicht die Ausnahme. Deshalb ist das Ziel nicht, Ausfälle zu verhindern, sondern ihre Folgen zu begrenzen, sodass der Ausfall eines Teils nicht das ganze System mitreißt.

Was heißt „ein System ist nicht fertig, wenn seine Fehlermodi unbekannt sind"? Dass ein System, von dem niemand sagen kann, was bei den bekannten Ausfällen geschieht, nur für den guten Tag gebaut wurde. Solange man nicht weiß, was passiert, wenn dieser Dienst ausfällt oder jene Verbindung bricht, hat man den schlechten Tag nicht bedacht — und Software wird am schlechten Tag beurteilt.

Warum ist Wiederholung ohne Idempotenz gefährlich? Weil eine Operation, die bei doppelter Ausführung doppelt wirkt, durch eine blinde Wiederholung echten Schaden anrichtet — eine doppelte Abbuchung aus einem harmlosen vorübergehenden Fehler. Man wiederholt nur, was sich ohne Schaden wiederholen lässt, und macht zustands- oder geldändernde Operationen erst idempotent, bevor man sie automatisch wiederholt.

Was ist würdevoller Abbau? Das bewusste Entwerfen von Zwischenstufen zwischen voller Funktion und Totalausfall: eine Nebenfunktion abschalten, während die Hauptaufgabe weiterläuft; eine ältere Antwort liefern statt keiner. Ein Nutzer zieht einen teilweisen Dienst fast immer einem völligen Ausfall vor. Welche Funktion man unter Fehlern erhält und welche man fallen lässt, entscheidet man im Entwurf.

Warum muss man den Fehlerfall proben? Weil eine ungeprobte Vorkehrung kein Schutz ist, sondern eine Hoffnung mit dem Anschein von Schutz — die Sicherung, die nie zurückgespielt, das Zeitlimit, das nie gegriffen hat. Erst wenn man den Ausfall bewusst herbeiführt und beobachtet, ob das System reagiert wie gedacht, ist die Resilienz belegt statt behauptet.

Wie hängt das mit Beobachtbarkeit zusammen? Untrennbar. Resilienz sorgt dafür, dass ein Fehler nicht das Ganze mitreißt; Beobachtbarkeit sorgt dafür, dass man ihn sieht. Eine Vorkehrung, die still auslöst, ohne es zu melden, verbirgt die Wunde des Systems — man hält es für gesund, während es beschädigt weiterläuft. Deshalb gehört zu jeder Vorkehrung für den Fehlerfall, dass ihr Auslösen bemerkt wird.

Weiterführend

• Observability ist Architektur — die andere Hälfte: man kann nur abwehren, was man sieht.
• Idempotenz in verteilten Systemen — die Voraussetzung dafür, dass Wiederholung heilt statt schadet.
• Reversibilität vor Vorhersage — Schaden umkehrbar halten als Form der Resilienz.
• Queue oder synchrone Verarbeitung — Arbeit entkoppeln, damit der Ausfall eines Teils den anderen nicht mitreißt.

Grundlage ist die Batunet Engineering Method: für den Fehlerfall entwerfen, das Unsichere eindämmen, Resilienz proben statt hoffen, Beobachtbarkeit ab Tag eins.

Abschließendes Engineering-Prinzip

Ein System ist erst fertig, wenn man weiß, wie es versagt. Der gute Tag stellt keine Fragen; er verzeiht jede Nachlässigkeit, weil nichts schiefgeht. Erst der schlechte Tag prüft, ob jemand vorher an ihn gedacht hat — und an diesem Tag ist es zu spät, ihn noch zu bedenken. Deshalb ist das Entwerfen für den Fehlerfall keine Zutat für besonders kritische Systeme, sondern das Zeichen, dass ein System zu Ende gedacht wurde. Man baut nicht ein System, das nie versagt — das gibt es nicht —, sondern eines, das versagt, ohne zu zerbrechen. Der Unterschied zwischen beiden entscheidet sich lange vor dem Vorfall, im ruhigen Moment des Entwurfs.

Software wird nicht am guten Tag beurteilt, sondern am schlechten. Für den guten Tag baut jeder; der Unterschied zeigt sich daran, ob jemand auch für den schlechten gebaut hat.