Rulări de încredere

Nimeni nu observă o automatizare până când nu trimite ceva de două ori

Apoi o observă toată lumea. Cele patru mecanisme de pe această pagină există pentru că eșecurile acestui tip de software sunt întotdeauna aceleași patru eșecuri, și toate sunt evitabile prin design, nu prin grijă.

Simulați înainte de publicare

Trimiteți o înregistrare reală printr-un flux de lucru oprit și citiți exact ce s-ar fi întâmplat: calea parcursă, fiecare valoare la fiecare pas, formularea fiecărui mesaj și cererea care s-ar fi trimis către fiecare sistem extern.

Nimic nu iese din clădire. Nu se trimite niciun e-mail, nu se emite nicio factură, nu se încearcă nicio plată, nu se scrie niciun rând. Apelurile externe sunt înregistrate ca intenții, cu sarcina utilă care ar fi fost trimisă, astfel încât să puteți vedea dacă maparea este corectă înainte să devină problema cuiva.

Simulările sunt modul în care răspundeți la întrebarea care împiedică oamenii să pornească o automatizare: ce va face aceasta în realitate?

Simulare · comanda 88 214Nimic trimis

1Validare adresăPotrivire. S-ar fi scris 6 câmpuri.
?CondițieComandă peste 1 000 zł? Nu — 289,00 zł. S-a parcurs calea scurtă.
3FacturăS-ar fi trimis un POST către sistemul de facturare. Sarcina utilă afișată în întregime.
!Prins aiciCota TVA mapată din câmpul greșit. Descoperită într-o simulare, nu în căsuța unui contabil.

Trimis: nimicÎncasat: nimic

O rulare parcurge versiunea cu care a intrat

Publicarea unei modificări într-un flux de lucru nu afectează rulările aflate deja în el. Fiecare rulare este fixată pe versiunea cu care a început și o finalizează, indiferent cât durează și cât rescrieți între timp.

Astfel puteți restructura un flux de lucru în timp ce zece mii de oameni sunt la jumătatea lui, și fiecare dintre ei finalizează fluxul care i-a fost promis. Alternativa — designul în care întreaga cale din aval este materializată la intrare — este motivul pentru care editarea unei automatizări active pare periculoasă în majoritatea instrumentelor. Aici este ceva obișnuit.

Rulările noi primesc versiunea nouă din momentul publicării. Versiunea pe care se află o rulare este înscrisă pe rulare, astfel încât o întrebare despre comportamentul din martie are un răspuns în septembrie.

Editare în timp ce este activv4 → v5

1Înainte2 918 rulări în curs, toate pe v4. Unele într-o așteptare de două zile.
2Publicare v511:40Doi pași reordonați, un mesaj rescris.
3DupăAcele 2 918 finalizează v4. Tot ce începe de la 11:40 rulează v5.
§Nimeninu a primit jumătate dintr-un flux de lucru și jumătate din altul.

Versiune înregistrată la fiecare rulareVersiunile vechi sunt păstrate

Reîncercări care nu pot trimite de două ori

Un pas este o funcție pură a intrărilor sale, iar efectele sale se comit împreună cu avansul propriu al rulării la pasul următor. Nu există nicio fereastră în care mesajul a plecat, dar rularea nu știe asta.

Acesta este tot trucul, și este o proprietate structurală, nu o promisiune. Un worker ucis în mijlocul unui pas — un deployment, o eroare, o mașină care dispare — lasă rularea exact acolo unde era. Un alt worker o preia și reia pasul. Pentru că efectul și avansul se comit ca unul singur, fie ambele s-au întâmplat, fie niciunul.

Apelurile externe către sisteme care acceptă chei de idempotență poartă una, derivată din rulare și din pas, astfel încât cealaltă parte să recunoască și ea repetarea.

Worker ucis în mijlocul trimiteriiRecuperat

1Pasul 5 începe09:14:06Trimiteți notificarea de expediere.
✕Workerul moare09:14:07Deployment. Nimic nu se comitase.
2Preluat09:14:31Un alt worker găsește rularea încă la pasul 5.
✓Trimis o dată09:14:32Clientul a primit un singur e-mail, nu două.

Efectele se finalizează odată cu avansulCheie de idempotență per rulare și pas

Un jurnal scris pentru a fi citit de o persoană

Fiecare rulare, fiecare pas, ramura urmată și valoarea care a decis-o. Durate per pas. Cererea și răspunsul fiecărui apel extern, cu datele de autentificare ascunse. Versiunea pe care se afla rularea. Unde așteaptă o rulare și până când.

Când cineva întreabă ce s-a întâmplat cu comanda plasată pe paisprezece, există un răspuns, iar găsirea lui durează un minut, nu un afternoon de corelare a jurnalelor din trei sisteme.

Rulările eșuate se adună într-un singur loc, cu motivul grupat, astfel încât „patruzeci și unu de eșecuri peste noapte” se rezolvă în „un furnizor a returnat 503 timp de nouă minute”, nu în patruzeci și una de investigații separate.

Peste noapte, grupat41 de eșecuri

1O singură cauzăAPI-ul furnizorului a returnat 503 între 02:41 și 02:50.
2Ce s-a întâmplatToate 41 au fost reîncercate; 39 au reușit la a doua încercare.
3Rămase în așteptareDouă s-au oprit și așteaptă o persoană. Ambele sunt listate împreună cu rândul care a eșuat.
§Nu patruzeci și unude investigații. Una singură, și o decizie despre două înregistrări.

Date de autentificare ascunseVersiune înregistrată

Ce nu afirmăm

Nu publicăm o cifră de disponibilitate pe o pagină de marketing, pentru că un număr fără o fereastră de măsurare și o definiție a „disponibil” este decorațiune. Dacă aveți nevoie contractuală de una, întrebați și vom discuta la ce ne putem angaja în realitate.

De asemenea, nu putem face API-ul altcuiva fiabil. Dacă un furnizor nu funcționează, un flux care depinde de el așteaptă, reîncearcă și, în cele din urmă, se oprește cu un motiv clar. Ce putem promite este că eșecul este vizibil, că nu corupe nimic și că reluarea nu trimite mesajul a doua oară.

Despre așteptări: o rulare care așteaptă două zile este un wake_at pe rulare, nu un job așezat într-o coadă. De aceea un flux poate păstra o sută de mii de rulări într-o așteptare de trei săptămâni fără ca vreuna să coste ceva, și de aceea numărul rulărilor aflate în așteptare nu este ceva la care trebuie să vă gândiți.