castomFLOW
castomFLOW öffnen

Läufe, denen Sie vertrauen können

Niemand bemerkt eine Automatisierung, bis sie etwas zweimal sendet

Dann bemerken es alle. Die vier Mechanismen auf dieser Seite existieren, weil die Fehler dieser Art von Software immer dieselben vier Fehler sind – und alle durch Design vermeidbar sind, nicht durch Sorgfalt.

Vor der Veröffentlichung simulieren

Schieben Sie einen echten Datensatz durch einen deaktivierten Workflow und lesen Sie genau zurück, was passiert wäre: den genommenen Pfad, jeden Wert an jedem Schritt, den Wortlaut jeder Nachricht und die Anfrage, die an jedes externe System gegangen wäre.

Nichts verlässt das Haus. Keine E-Mail wird gesendet, keine Rechnung gestellt, keine Abbuchung versucht, keine Zeile geschrieben. Externe Aufrufe werden als Absichten aufgezeichnet, mit der Nutzlast, die gesendet worden wäre, damit Sie sehen können, ob das Mapping stimmt, bevor es zum Problem von jemandem wird.

Simulationen sind die Art, wie Sie die Frage beantworten, die Menschen davon abhält, eine Automatisierung einzuschalten: Was macht das eigentlich?

Simulation · Bestellung 88 214Nichts gesendet
  • 1Adresse validierenÜbereinstimmung gefunden. Hätte 6 Felder geschrieben.
  • ?BedingungBestellung über 1 000 zł? Nein — 289,00 zł. Kurzer Pfad genommen.
  • 3RechnungHätte POST an das Rechnungssystem gesendet. Nutzlast vollständig angezeigt.
  • !Hier abgefangenMehrwertsteuersatz aus dem falschen Feld gemappt. In einer Simulation gefunden statt im Posteingang eines Buchhalters.

Gesendet: nichtsAbgebucht: nichts

Ein Lauf durchläuft die Version, mit der er gestartet ist

Das Veröffentlichen einer Änderung an einem Workflow berührt nicht die Läufe, die sich bereits darin befinden. Jeder Lauf ist an die Version gebunden, auf der er gestartet ist, und schließt diese Version ab, egal wie lange es dauert und wie viel Sie in der Zwischenzeit umschreiben.

So können Sie einen Workflow umstrukturieren, während zehntausend Menschen mitten darin sind, und jeder von ihnen schließt den Ablauf ab, der ihm zugesagt wurde. Die Alternative — der Entwurf, bei dem der gesamte nachgelagerte Pfad beim Eintritt materialisiert wird — ist der Grund, warum das Bearbeiten einer live laufenden Automatisierung in den meisten Tools gefährlich wirkt. Hier ist es nichts Besonderes.

Neue Läufe erhalten die neue Version ab dem Moment, in dem Sie veröffentlichen. Welche Version ein Lauf verwendet, ist auf dem Lauf vermerkt, sodass eine Frage zum Verhalten im März im September eine Antwort hat.

Bearbeiten im Live-Betriebv4 → v5
  • 1Vorher2 918 Läufe in Bearbeitung, alle auf v4. Einige in einer zweitägigen Wartezeit.
  • 2v5 veröffentlichenZwei Schritte umgeordnet, eine Nachricht umgeschrieben.
  • 3NachherDiese 2 918 schließen v4 ab. Alles, was ab 11:40 startet, läuft auf v5.
  • §Niemanderhielt die Hälfte eines Workflows und die Hälfte eines anderen.

Version bei jedem Lauf aufgezeichnetAlte Versionen aufbewahrt

Wiederholungen, die nicht doppelt senden können

Ein Schritt ist eine reine Funktion seiner Eingaben, und seine Effekte werden zusammen mit dem eigenen Fortschreiten des Laufs zum nächsten Schritt committet. Es gibt kein Fenster, in dem die Nachricht bereits raus ist, der Lauf es aber nicht weiß.

Das ist der ganze Trick, und er ist eine strukturelle Eigenschaft rather als ein Versprechen. Ein Worker, der mitten im Schritt getötet wird — ein Deployment, ein Absturz, eine Maschine, die verschwindet — lässt den Lauf genau dort, wo er war. Ein anderer Worker nimmt ihn auf und führt den Schritt erneut aus. Da Effekt und Fortschreiten als eines committet werden, ist entweder beides passiert oder nichts.

Ausgehende Aufrufe an Systeme, die Idempotenzschlüssel unterstützen, tragen einen solchen, abgeleitet aus Lauf und Schritt, damit die Gegenseite die Wiederholung ebenfalls erkennen kann.

Worker mitten im Senden getötetWiederhergestellt
  • 1Schritt 5 beginntVersandbenachrichtigung senden.
  • ✕Worker stirbtDeployment. Nichts war committet.
  • 2AufgegriffenEin anderer Worker findet den Lauf noch auf Schritt 5.
  • ✓Einmal gesendetDer Kunde erhielt eine E-Mail, nicht zwei.

Effekte werden mit dem Fortschritt committetIdempotenzschlüssel pro Lauf und Schritt

Ein Protokoll, das für Menschen geschrieben ist

Jeder Lauf, jeder Schritt, der eingeschlagene Zweig und der Wert, der darüber entschied. Zeitangaben pro Schritt. Anfrage und Antwort jedes externen Aufrufs, mit geschwärzten Zugangsdaten. Die Version, auf der der Lauf lief. Wo ein Lauf wartet und bis wann.

Wenn jemand fragt, was mit der Bestellung vom Vierzehnten passiert ist, gibt es eine Antwort – und sie zu finden dauert eine Minute statt eines Nachmittags, in dem man die Protokolle von drei Systemen abgleicht.

Fehlgeschlagene Läufe sammeln sich an einem Ort, mit gruppiertem Grund, sodass „41 Fehler über Nacht“ zu „ein Lieferant lieferte 503 für neun Minuten“ wird statt zu 41 einzelnen Untersuchungen.

Über Nacht, gruppiert41 Fehler
  • 1Eine UrsacheLieferanten-API gab zwischen 02:41 und 02:50 503 zurück.
  • 2Was passiert istAlle 41 wurden erneut versucht; 39 gelangen beim zweiten Versuch.
  • 3Übrig gebliebenZwei wurden angehalten und warten auf eine Person. Beide sind mit der fehlgeschlagenen Zeile aufgelistet.
  • §Nicht einundvierzigUntersuchungen. Eine – und eine Entscheidung über zwei Datensätze.

Zugangsdaten geschwärztVersion erfasst

Was wir nicht behaupten

Wir veröffentlichen keine Verfügbarkeitszahl auf einer Marketingseite, denn eine Zahl ohne Messfenster und ohne Definition von „verfügbar“ ist Dekoration. Wenn Sie eine vertraglich benötigen, fragen Sie – wir besprechen dann, was wir tatsächlich zusagen können.

Wir können auch die API eines anderen nicht zuverlässig machen. Ist ein Anbieter ausgefallen, wartet ein Workflow, der von ihm abhängt, versucht es erneut und stoppt schließlich mit einem klaren Grund. Was wir versprechen können: Der Fehler ist sichtbar, er beschädigt nichts, und das Fortsetzen sendet die Nachricht kein zweites Mal.

Zu Wartezeiten: Ein Lauf, der zwei Tage wartet, ist ein wake_at am Lauf, kein Auftrag, der in einer Warteschlange liegt. Deshalb kann ein Workflow hunderttausend Läufe in einer dreiwöchigen Wartezeit halten, ohne dass etwas davon kostet – und warum Sie über die Zahl der aktuell wartenden Läufe nicht nachdenken müssen.

Der Lauf, über den Sie nie nachdenken, ist der, der funktioniert hat.