Was einen Make-Prototyp von einem Produktionssystem trennt
Das Szenario läuft. An einem Nachmittag gebaut, mit fünf Datensätzen getestet, alle fünf sind durchgekommen. Es fühlt sich fertig an, und genau da fängt das Problem an: ein Prototyp beweist, dass der Prozess möglich ist; ein Produktionssystem beweist, dass er es Dienstag um drei Uhr nachts immer noch ist — mit einem seltsamen Datensatz und der API auf der anderen Seite im Ausfall. Dazwischen liegt Arbeit, und zwar nicht die Sorte, bei der man Module zieht.
Wenn eine Make-Automatisierung nicht skaliert, versagt fast nie die Geschäftslogik. Es versagen vier Dinge, die der Prototyp nicht hatte, weil er sie nicht brauchte: eine Laufzeitgrenze, die erst mit Volumen auftaucht, ein Fehlerverhalten, das du von Hand entscheiden musst, komplett fehlende Versionierung und eine Rechnung, die genau dann wächst, wenn du es richtig machst.
| Dimension | Prototyp, der läuft | System in Produktion |
|---|---|---|
| Volumen | Fünf Testdatensätze | Die Monatsendspitze, unangekündigt |
| Fehler | Gab es keine | Werden vorausgesetzt — samt Entscheidung, was mit dem Datensatz passiert |
| Verantwortung | Wer es gebaut hat, falls er sich erinnert | Jemand in Rufbereitschaft, mit Alarm und Handlungsanweisung |
| Änderungen | Wird live editiert | Wird versioniert, separat getestet und dann promotet |
| Kosten | Passt locker in den Tarif | Auf zwölf Monate hochgerechnet, mit den gehärteten Schritten |
Keine dieser fünf Zeilen ist ein Mangel von Make. Make ist ein ausgezeichnetes Werkzeug, um herauszufinden, ob ein Prozess überhaupt automatisierbar ist, und diese Phase zählt. Der Fehler ist nicht, dort anzufangen: der Fehler ist, dort zu bleiben und es Produktion zu nennen.
Die Zeitgrenze: 40 Minuten und was passiert, wenn du sie triffst
Make bricht jede Ausführung ab, die die maximale Laufzeit überschreitet. In den Bezahltarifen liegt diese Grenze bei 40 Minuten, im kostenlosen bei 10. Wenn du sie triffst, gibt es keine höfliche Warnung: der Lauf endet mit einem Fehler in der Art von «MAXIMUM EXECUTION TIMEOUT [40 minutes] had elapsed», und was halb fertig war, bleibt halb fertig.
Ein Prototyp trifft sie nie. Er verarbeitet fünf Zeilen und ist in zwölf Sekunden durch. Das Muster, das alles sprengt, ist immer dasselbe und kommt immer überraschend: ein Iterator über eine Liste, die wächst. Du synchronisierst 200 Bestellungen, alles gut; sechs Monate später sind es 4.000 und das Szenario stirbt auf halbem Weg — nachdem es die Operationen der ersten 2.700 verbrannt hat. Der Prozess hat sich nicht verändert. Das Geschäft hat sich verändert, und genau das war das Ziel.
Der richtige Ausweg ist fast nie ein größerer Tarif, denn die Zeitgrenze kauft man nicht: man designt um sie herum. Das Muster, das funktioniert, ist die Arbeit auf zwei Szenarien aufzuteilen — eins, das sammelt und in eine Warteschlange schreibt, und eins, das die Warteschlange in kleinen Stapeln mit eigenem Zeitplan abarbeitet — damit kein einzelner Lauf in die Nähe des Limits kommt. Das ist mehr Arbeit, als ein Modul mehr zu ziehen, und es ist der Unterschied zwischen einem Flow, der Wachstum aushält, und einem, der genau dann reißt, wenn das Geschäft gut läuft.
Was Make tut, wenn etwas schiefgeht (und was es nicht für dich tut)
Make bringt ein Sicherheitsnetz mit, das viele nicht einmal einschalten: unvollständige Ausführungen. Wenn ein Szenario mittendrin platzt, verliert die Plattform den Datensatz nicht, sondern speichert den unfertigen Lauf, damit du ihn fortsetzen oder reparieren kannst. Ein gutes Netz, nutze es. Es hat aber Kanten, und diese Kanten sind das Kleingedruckte, das darüber entscheidet, ob dein System Daten verliert.
Dieser Speicher ist nicht unendlich: es gibt ein Limit pro ungelöstem Szenario — in der Größenordnung von 10 MB — und eine Obergrenze pro Team — in der Größenordnung von 500 MB — und gelöste Einträge werden nach 30 Tagen automatisch entfernt. Unangenehm wird es, wenn dieser Speicher voll läuft, denn dann hängt das Verhalten an einer Checkbox, die vor Monaten jemand gedankenlos gesetzt hat: ist Datenverlust deaktiviert, deaktiviert Make das Szenario; ist er aktiviert, plant Make weiter Läufe ein und verwirft die unvollständige Ausführung, die nicht mehr hineinpasst. Keine der beiden Optionen ist gut. Die eine stoppt dein Geschäft, die andere leert es leise.
| Was ausfällt | Was Make standardmäßig tut | Was du entscheiden musst |
|---|---|---|
| 429 der Ziel-API (Rate Limit) | Der Lauf stirbt; sind unvollständige Ausführungen aktiv, landet der Datensatz dort | Wie viele Wiederholungen, mit welcher Wartezeit, und was passiert, wenn sie aufgebraucht sind |
| Transienter 503 von der Gegenseite | Dasselbe: es stoppt, wo es war | Ob du erneut versuchst oder der Datensatz in eine Prüfschlange für Menschen geht |
| Unerwartete Daten (leeres Feld, seltsames Format) | Nichts Besonderes: das Modul, das sie anfasst, bricht ab | Beim Eingang validieren und den Sonderfall an eine Person leiten |
| Speicher für unvollständige Läufe voll | Deaktiviert das Szenario oder verwirft den Lauf — je nach Checkbox | Welches der beiden Übel du bevorzugst — und wie du davon erfährst |
Es gibt einen zweiten Klassiker, und der ist selbstverschuldet: die Wiederholung ohne Obergrenze. Ein Fehlerhandler, der endlos gegen eine API wiederholt, die 429 zurückgibt, repariert nichts; er verbrennt Operationen im Flächenbrandtempo und blockiert das Szenario. Jede Wiederholung braucht drei Dinge — eine Maximalzahl, eine wachsende Wartezeit zwischen den Versuchen und ein Endziel für den Datensatz, wenn sie aufgebraucht sind — und dieses Endziel ist meistens ein Mensch. Diesen Ausgang zu bauen, ohne ihn zum Engpass zu machen, ist genau das Problem des Menschen in der Schleife.
Versionierung: das Szenario, bei dem keiner weiß, wer es angefasst hat
Make bringt keine Versionskontrolle im Sinne eines Code-Repositories mit. Die verbreitete Praxis, die fast alle empfehlen, ist: das Szenario klonen, bevor du es anfasst, und gegen Entwicklungsdaten testen. Das funktioniert, solange du allein bist. Sobald ihr zu dritt seid, füllt sich der Ordner mit Kopien namens «Bestellungen v2 FINAL (die gute)» und niemand weiß, welche live ist.
Die echten Kosten fehlender Versionierung sind nicht die Unordnung, sondern dass du an dem Tag, an dem etwas kaputtgeht, drei Fragen nicht mehr beantworten kannst: was hat sich geändert, wer hat es geändert, und wie kommt man zurück. Ohne diese drei Antworten wird jeder Vorfall zur Archäologie. Und Archäologie bezahlt man in Produktion mit Stunden teurer Leute, während der Prozess stillsteht.
- Ein exportierter Blueprint pro Änderung. Make kann das Szenario als JSON exportieren: leg es ins Firmen-Repository. Das ist der Diff, den dir die Plattform nicht gibt.
- Langweilige, strenge Namensgebung. Ein Name pro Szenario, ein Suffix für die Arbeitskopie, null Adjektive. «FINAL» ist kein Zustand.
- Eine echte Testumgebung, mit eigenen Zugangsdaten und Fake-Daten. In Produktion an einem echten Datensatz zu testen, ist genau das, wonach es aussieht.
- Eine Person, die promotet. Jeder darf eine Änderung vorschlagen; eine Einzige bringt sie in Produktion. Das ist keine Bürokratie, das ist zu wissen, wen man um drei Uhr nachts anruft.
- Ein Änderungsprotokoll aus zwei Zeilen. Datum, was angefasst wurde, warum. Niemand liest es bis zu dem Tag, an dem man es braucht — und dieser Tag bezahlt alle anderen.
Das ist keine Ingenieursmarotte: es ist der Mindestanteil an Governance und Kontrolle über die Automatisierung, ohne den man nicht sagen kann, dass ein Prozess in Produktion ist. Ein Flow, der Geld oder Kundendaten bewegt und den jeder live und spurlos ändern kann, ist kein System: er ist ein Risiko mit hübscher Oberfläche.
Die Rechnung steigt genau dann, wenn du es richtig machst
Hier ist die Falle, die viele stillschweigend dazu bringt, das Szenario absichtlich fragil zu lassen. Make rechnet pro Operation ab: jedes Modul, das Daten verarbeitet, geht durch die Kasse. Und alles, was wir gerade beschrieben haben — Eingaben validieren, Fehler behandeln, mit Wartezeit wiederholen, protokollieren, einen Menschen rufen, wenn der Fall mehrdeutig ist — sind Module. Den Flow zu härten vervielfacht den Verbrauch desselben Prozesses, ohne einen einzigen neuen Fall zu automatisieren.
Das Ergebnis ist ein exakt messbarer Fehlanreiz: die Plattform berechnet dir mehr dafür, dass du das System robuster machst. Das ist keine Bosheit von Make, sondern die arithmetische Folge der Abrechnung pro Schritt — und sie trifft jedes Werkzeug mit diesem Modell. Der vollständige Vergleich der drei Abrechnungseinheiten — Schritt, Operation und Ausführung — steht in Preise der Automatisierungswerkzeuge, und das ist die Lektüre, die diesen Leitfaden zu einer Entscheidung mit Zahlen macht.
Die praktische Konsequenz: wenn du die Kosten des Produktionsgangs hochrechnest, rechne nicht das heutige Szenario hoch. Rechne das gehärtete hoch, das dreimal so viele Module haben wird, auf das Volumen, das du in zwölf Monaten erwartest. Fällt diese Rechnung schlecht aus, ist das Problem keine Konfiguration mehr; es ist das Werkzeug, und dann steht das Gespräch Make gegen n8n an.
Drei Auswege: härten, aufteilen oder die Engine wechseln
Nicht jedes festgefahrene Szenario braucht dasselbe, und eine falsche Diagnose ist in beide Richtungen teuer: aus Lust zu migrieren kostet Wochen, aus Trägheit zu bleiben kostet Ausfälle. Das sind die drei echten Auswege und das Signal, das sie unterscheidet.
| Deine Lage | Was zu tun ist | Zeichen, dass es dein Fall ist |
|---|---|---|
| Das Szenario ist korrekt, aber fragil | Dort härten, wo es ist: Validierung, Fehlerbehandlung, Alarme, Logs | Es fällt selten aus, aber wenn, merkt es keiner, bis ein Kunde fragt |
| Das Szenario erstickt an der Größe | Aufteilen: eins schreibt in die Warteschlange, eins arbeitet sie in Stapeln ab | Du triffst die Zeitgrenze, oder der Iterator wächst jeden Monat |
| Das Preismodell bestraft dich | Die Engine auf ein Werkzeug umziehen, das pro Ausführung abrechnet | Die Rechnung steigt, und du hast keinen einzigen neuen Prozess ergänzt |
Alle drei verlangen dieselbe Vorentscheidung, und die ist organisatorisch, nicht technisch: jemand muss den Flow besitzen. Ein automatisierter Prozess ohne Eigentümer verfällt von selbst, weil APIs sich ändern, Formate verrutschen und Sonderfälle mit dem Volumen zunehmen. Diese Disziplin — wer schaut worauf, wie oft, mit welchen Alarmen — beschreibt die Wartung der Automatisierungen, und sie ist der Unterschied zwischen einem System, das gut altert, und einem, das eines Tages einfach aufhörte zu laufen, ohne dass es jemand bemerkte.