Was passiert, wenn eine Automatisierung nachts abstürzt?

Automatisierungen laufen erfolgreich, indem nichts passiert. Genau das macht ihren Ausfall unsichtbar: Ein Ablauf, der nicht startet, erzeugt keine Fehlermeldung, keine leere Datei, keinen Eintrag. Er erzeugt gar nichts, und gar nichts sieht aus wie ein ruhiger Tag.

Bemerkt wird es an zweiter Stelle. Eine Anfrage bleibt liegen, ein Angebot geht nicht raus, eine Übergabe zwischen zwei Abteilungen findet nicht statt — jedes Mal Tage später als der eigentliche Ausfall.

Bis dahin sind im Schnitt Tage vergangen.

Sie hängen aneinander, und keiner ersetzt einen anderen. Der Fehlerzweig macht den Ausfall sichtbar, die Protokollierung macht ihn nachvollziehbar, die Wiederholung fängt den häufigsten Fall ab, und der Export macht den Stand wiederherstellbar.

Der häufigste Fehler in einem Ablauf ist kein Fehler im Ablauf. Es ist ein Zielsystem, das gerade nicht antwortet: eine Schnittstelle in Wartung, eine Drossel, die greift, ein Netzwerkweg, der für zehn Sekunden weg ist.

Genau dagegen hilft ein zweiter Versuch. Nur eben nicht sofort.

Eine Wiederholung ohne Wartezeit trifft den Dienst in derselben Sekunde noch einmal, in der er ohnehin überlastet ist — und macht aus einem kurzen Ausfall einen längeren. Drei Versuche mit wachsendem Abstand fangen den Normalfall ab, ohne Schaden anzurichten.

Was nach dem dritten Versuch noch scheitert, ist kein Aussetzer. Es gehört gemeldet, nicht wiederholt.

Sobald ein Ablauf bei jedem Fehler eine Nachricht schickt, entsteht ein neues Risiko. Eine Automatisierung, die in einer Schleife scheitert, flutet genau den Kanal, über den der Alarm ankommen soll. Nach zweihundert Meldungen liest sie niemand mehr.

In dieser Website sitzt die Bremse in einer eigenen Datei. Sie zählt Meldungen je Kennung in einem Fenster von zehn Minuten und lässt darüber hinaus nichts durch.

Der Zähler liegt bewusst je Zweck getrennt — damit sich zwei Routen nicht gegenseitig aussperren, wenn eine davon unter Last steht.

Sie hält versehentliches Dauerfeuer auf und einfache Skripte. Gegen jemanden, der sie gezielt umgehen will, hilft sie nicht. Die Kennung stammt aus einem Kopfzeilenfeld, das der vorgelagerte Netzwerkdienst setzt — und dieses Feld ist fälschbar. Wer es bei jeder Anfrage variiert, bekommt jedes Mal ein frisches Kontingent.

Der zweite Punkt steht im Code selbst: Der Speicher liegt im Prozess. Läuft die Anwendung als ein Server, trägt das. Bei mehreren Instanzen zählt jede für sich, und die Sperre greift entsprechend später.

Eine Grenze, die im Kommentar steht, ist billiger als eine, die jemand nach einem Vorfall herausfindet.

Im selben Modul stehen zwei Funktionen, die beide dieselbe Kopfzeile auslesen und fast dasselbe zurückgeben. Sie sehen aus wie eine Dublette, die jemand aufräumen sollte. Sie sind es nicht.

Die eine liefert eine Kennung, die im Arbeitsspeicher bleibt und nur zum Zählen dient. Die andere liefert eine IP-Adresse, die an einen externen Dienst geht.

Der Unterschied ist keine Frage des Stils, sondern die Stelle, an der die Einwilligung hängt: Zählen im eigenen Speicher braucht keine, die Weitergabe an einen Dritten schon. Wer die beiden zusammenlegt, verliert diese Grenze — und merkt es am Code nicht mehr.

Solche Entscheidungen gehören dorthin, wo jemand sie liest. Der Unterschied zwischen einer Zusammenlegung und einem Datenschutzverstoß steht in diesem Fall in vier Zeilen Kommentar.

Nach dem, was sie tun. Ein Knoten heißt „Filter: Leads ohne Email“, nicht „IF1“ — wer nachts um drei einen Alarm liest, braucht einen Namen und keine Nummer.

Der Aufwand fällt einmal an, beim Bauen. Der Nutzen fällt jedes Mal an, wenn etwas schiefgeht. Die Meldung aus dem Fehlerzweig trägt den Knotennamen — damit steht die halbe Diagnose schon in der Nachricht.

Dieselbe Überlegung trägt den vierten Bestandteil. Ein Export unter Versionsverwaltung macht sichtbar, was sich zwischen zwei Ständen geändert hat. Genau das ist die Frage, die nach einem Ausfall als erste gestellt wird.

Nicht daran, dass nichts mehr ausfällt. Ausfälle gehören zum Betrieb — ein Ablauf, der von fremden Schnittstellen abhängt, wird scheitern.

Sondern daran, dass der Ausfall vor dem Kunden bemerkt wird.

Die Gegenprobe ist einfach: Schalte in einem Testlauf die Zugangsdaten eines Zielsystems auf einen falschen Wert. Kommt binnen Minuten eine Meldung mit dem Namen des gescheiterten Knotens, trägt der Aufbau. Bleibt es still, war der Ablauf nie überwacht, sondern nur bisher erfolgreich.