n8n in Produktion: was Wegwerf-Workflows von wartbaren unterscheidet

Die interessante Frage zu einer Automatisierung stellt sich nicht am Tag, an dem sie gebaut wird. Sie stellt sich ein halbes Jahr später, wenn sie geändert werden soll. Entweder das ist eine Anpassung von zwanzig Minuten, oder es ist der Satz "fass das bitte nicht an, es läuft" und danach ein Neubau.

Was zwischen diesen beiden Ausgängen entscheidet, ist nicht die Komplexität des Workflows und auch nicht das Werkzeug. Es ist eine Liste von Pflichten, die entweder erfüllt wurden oder nicht.

Das Werkzeug ist nicht das Problem

Vorweg, weil dieser Text sonst falsch gelesen wird: n8n taugt für Produktion. Ein visueller Workflow ist kein minderwertiger Code, er ist Code in einer anderen Notation, mit denselben Pflichten.

Das Problem entsteht aus der Haltung, die das Werkzeug einlädt. "Das ist doch nur eine Automatisierung" führt dazu, dass niemand die Fragen stellt, die man bei einem Dienst selbstverständlich stellt. Ein Skript, das fünf Jahre lang Gehaltsläufe anstößt, ist kein Skript mehr, egal wie es entstanden ist.

Demo und Produktion unterscheiden sich nicht durch Umfang. Sie unterscheiden sich durch die folgende Liste.

Erstens: Fehlerbehandlung als Entwurf, nicht als Hoffnung

Die erste Frage an jeden Workflow lautet, was passiert, wenn ein Schritt nicht funktioniert. Der externe Dienst antwortet mit einem Serverfehler, das Modell läuft in eine Zeitüberschreitung, der Webhook kommt zweimal an.

Bei einem Wegwerf-Workflow lautet die Antwort: Er bleibt stehen und sagt niemandem Bescheid. Bei einem wartbaren gibt es Wiederholungen mit wachsendem Abstand, einen Fehlerpfad für den Fall, dass Wiederholen nicht hilft, und einen Ablageort für das, was endgültig nicht verarbeitet werden konnte.

Der letzte Punkt wird am häufigsten übersprungen. Ohne einen solchen Ablageort verschwinden fehlgeschlagene Vorgänge einfach, und niemand kann hinterher sagen, wie viele es waren.

Zweitens: Idempotenz

Die Frage, an der sich am zuverlässigsten zeigt, ob jemand Produktionserfahrung hat: Was passiert, wenn dieser Workflow zweimal mit denselben Daten läuft?

Das ist kein theoretischer Fall. Webhooks werden doppelt zugestellt, Wiederholungen laufen nach einer Zeitüberschreitung an, die in Wahrheit erfolgreich war, jemand startet einen Lauf von Hand neu. Wenn die Antwort "dann geht die E-Mail zweimal raus" oder "dann steht der Datensatz doppelt im CRM" lautet, ist der Workflow nicht produktionsreif, unabhängig davon, wie sauber der Graph aussieht.

Die Absicherung ist selten aufwendig: ein fachlicher Schlüssel, gegen den vor dem Schreiben geprüft wird, oder ein Schreibvorgang, der beim zweiten Mal folgenlos bleibt. Aufwendig ist nur, sie nachzurüsten, wenn die doppelten Datensätze schon da sind.

Drittens: Beobachtbarkeit

Ein Workflow, der nachts ausfällt, muss erzählen können, was passiert ist. Das heißt: Ausgaben an den Stellen, die später interessieren, und eine Benachrichtigung bei Fehlschlag.

Der Gegenentwurf heißt nicht "kein Logging". Er sieht konkreter aus: Der Ausfall fällt eine Woche später auf, weil jemand sich beschwert, und dann beginnt die Rekonstruktion. Zwischen den beiden Zuständen liegt keine Frage der Technik, sondern die Entscheidung, ob jemand es merken soll.

Viertens: Versionierung und Umgebungen

Änderungen am laufenden Workflow, ohne die Möglichkeit, zurückzugehen, sind der Normalzustand vieler Installationen. Das ist der Punkt, an dem sich Bastelei und Ingenieursarbeit am deutlichsten scheiden, weil hier nicht Wissen fehlt, sondern Disziplin.

Was dazugehört, ist bekannt und unspektakulär: Export in die Versionsverwaltung, eine zweite Umgebung zum Ausprobieren, und Änderungen laufen dort, bevor sie produktiv gehen. Der Aufwand ist gering und der Ertrag unsichtbar, solange nichts passiert. Genau deshalb wird er ausgelassen.

Ich halte diesen Punkt für den ehrlichsten Prüfstein der ganzen Liste. Die anderen vier kann man beim Bauen vergessen. Diesen lässt man bewusst aus.

Fünftens: die Grenze der Zuständigkeit

Wenn in einem Funktionsknoten zweihundert Zeilen JavaScript stehen, ist die richtige Antwort nicht, sie besser zu strukturieren. Sie lautet, dass diese Logik nicht dorthin gehört.

Ein Orchestrierungswerkzeug verbindet Dienste. Es ist kein Ort für Anwendungslogik, weil dort das fehlt, was man für Anwendungslogik braucht: Tests, Typen, Fehlersuche mit Werkzeugen, die Ausdruck für Ausdruck vorgehen. Logik dieser Größe gehört in einen Dienst, den der Workflow aufruft.

Zu wissen, wo der Klebstoff aufhört, ist der Unterschied zwischen jemandem, der ein Werkzeug bedient, und jemandem, der es einsetzt.

Der Knoten, der die Regeln ändert

Sobald ein Sprachmodell im Graph steht, gelten die bisherigen Annahmen nicht mehr vollständig. Jeder andere Knoten ist im Prinzip vorhersagbar: gleiche Eingabe, gleiche Ausgabe, und wenn er scheitert, scheitert er sichtbar.

Ein Modellknoten scheitert leise. Er liefert etwas, das aussieht wie ein Ergebnis, und der Workflow verarbeitet es weiter, weil ihm nichts anderes gesagt wurde.

Praktisch folgt daraus eine Regel: Die Ausgabe eines Modells ist so lange kein Datensatz, wie sie nicht geprüft wurde. Die Prüfung liegt hinter dem Knoten und beantwortet mindestens zwei Fragen. Hat die Antwort die Form, die der nächste Schritt erwartet, also Struktur, Felder, Typen. Und ergibt ihr Inhalt fachlich Sinn, gemessen an dem, was an dieser Stelle überhaupt herauskommen darf.

Was danach passiert, ist eine Entscheidung, kein Zufall: noch einmal versuchen, in den Fehlerpfad geben oder einem Menschen vorlegen. Ohne diese Prüfung wandert der Fehler weiter und wird zu einer Zahl in einem Bericht, die niemand mehr hinterfragt.

Der Aufschlag auf die Bauzeit

Der Preis ist Bauzeit, und er fällt vollständig am Anfang an. Ein Workflow mit Fehlerpfaden, Idempotenzprüfung und Kontrollpunkten braucht deutlich länger als derselbe Workflow ohne. Beide sehen am Ende gleich aus, wenn alles funktioniert.

Dazu kommt Reibung im Alltag: Wer über eine zweite Umgebung geht, ändert nichts mehr in zwei Minuten. Das ist der eigentliche Grund, warum dieser Punkt so oft ausgelassen wird, und er ist nachvollziehbar.

Wer bezahlt, bezahlt also für etwas, das er zunächst nicht sieht. Sichtbar wird es beim ersten Änderungswunsch. Ein Wegwerf-Workflow ist billiger im Bau und teurer im Besitz, weil jede Änderung zum Neubau wird und Neubau erneut den Bau kostet.

Wo Wegwerf die richtige Wahl ist

Nicht jede Automatisierung muss das alles erfüllen, und das zu behaupten wäre eine Ideologie und keine Entscheidungshilfe.

Eine einmalige Datenmigration wird einmal ausgeführt und danach gelöscht. Ein persönliches Hilfsmittel hat genau einen Benutzer, der jeden Fehler sofort bemerkt. Ein Versuchsaufbau für eine Woche soll eine Frage beantworten und danach verschwinden. In allen drei Fällen ist der Aufwand nicht gerechtfertigt.

Der Unterschied liegt nicht im Ergebnis, sondern in der Absicht. Reife heißt nicht, alles solide zu bauen. Sie heißt, bewusst zu entscheiden, was man baut.

Problematisch wird es erst, wenn aus dem Versuchsaufbau ohne Entscheidung ein Produktionssystem wird. Das geschieht selten durch einen Beschluss. Es geschieht, weil niemand einen trifft.

Fünf Fragen, vor der ersten Verbindung

Die fünf Punkte sind kein Qualitätsanspruch, sondern eine Liste von Fragen, die vor dem Bauen beantwortet werden sollten: Was passiert bei einem Fehler. Was passiert bei doppelter Ausführung. Wer erfährt vom Ausfall. Wie komme ich zurück. Und wo hört die Zuständigkeit dieses Werkzeugs auf.

Wer sie beantwortet hat, baut eine Automatisierung, die geändert werden kann. Wer sie nicht gestellt hat, baut eine, die ersetzt werden muss, und weiß es nur noch nicht.