Kjøringer du kan stole på

Ingen legger merke til en automatisering før den sender noe to ganger

Så legger alle merke til det. De fire mekanismene på denne siden finnes fordi feilene i denne typen programvare alltid er de samme fire feilene, og de er alle unngåelige ved design i stedet for ved flid.

Simuler før du publiserer

Send en ekte post gjennom en arbeidsflyt som er slått av, og les nøyaktig hva som ville skjedd: banen som ble fulgt, alle verdier ved hvert steg, ordlyden i hver melding og forespørselen som ville gått til hvert eksternt system.

Ingenting forlater bygningen. Ingen e-post sendes, ingen faktura opprettes, ingen belastning forsøkes, ingen rad skrives. Eksterne kall registreres som intensjoner, med nyttelasten som ville blitt sendt, slik at du kan se om mappingen er riktig før det blir noens problem.

Simuleringer er måten du svarer på spørsmålet som stopper folk fra å slå på en automatisering: hva gjør den egentlig?

Simulering · ordre 88 214Ingenting sendt

1Valider adresseFunnet match. Ville skrevet 6 felt.
?BetingelseOrdre over 1 000 zł? Nei — 289,00 zł. Kort vei fulgt.
3FakturaVille sendt POST til faktureringssystemet. Nyttelast vist i sin helhet.
!Fanget herMva-sats mappet fra feil felt. Oppdaget i en simulering i stedet for i en regnskapsførers innboks.

Sendt: ingentingBelastet: ingenting

En kjøring følger versjonen den startet på

Å publisere en endring i en arbeidsflyt påvirker ikke kjøringene som allerede er i den. Hver kjøring er låst til versjonen den startet på og fullfører den versjonen, uansett hvor lang tid det tar og hvor mye du skriver om i mellomtiden.

Så du kan omstrukturere en arbeidsflyt mens ti tusen mennesker er halvveis i den, og hver enkelt fullfører flyten de ble lovet. Alternativet — designet der hele nedstrømsbanen materialiseres ved inngang — er grunnen til at det føles farlig å redigere en live automatisering i de fleste verktøy. Her er det helt uproblematisk.

Nye kjøringer får den nye versjonen fra øyeblikket du publiserer. Hvilken versjon en kjøring er på skrives på selve kjøringen, så et spørsmål om oppførsel i mars har et svar i september.

Redigering mens den er livev4 → v5

1Før2 918 kjøringer underveis, alle på v4. Noen i et to-dagers ventepunkt.
2Publiser v511:40To steg omorganisert, én melding skrevet om.
3EtterDe 2 918 fullfører v4. Alt som starter fra 11:40 kjører v5.
§Ingenfikk halvparten av én arbeidsflyt og halvparten av en annen.

Versjon registrert på hver kjøringGamle versjoner beholdes

Nye forsøk som ikke kan sende dobbelt

Et steg er en ren funksjon av inndataene sine, og effektene committer sammen med kjøringens eget avansement til neste steg. Det finnes ikke et vindu der meldingen er sendt ut, men kjøringen ikke vet det.

Det er hele trikset, og det er en strukturell egenskap snarere enn et løfte. En worker som dør midt i et steg — en utrulling, et krasj, en maskin som forsvinner — etterlater kjøringen nøyaktig der den var. En annen worker plukker den opp og kjører steget på nytt. Fordi effekten og avansementet committer som ett, skjedde enten begge eller ingen.

Utgående kall til systemer som støtter idempotensnøkler inneholder én, avledet fra kjøringen og steget, slik at den andre siden også kan gjenkjenne gjentakelsen.

Worker drept midt i sendingGjenopprettet

1Steg 5 begynner09:14:06Send forsendelsesvarslet.
✕Worker dør09:14:07Utrulling. Ingenting var committet.
2Plukket opp09:14:31En annen worker finner kjøringen fortsatt på steg 5.
✓Sendt én gang09:14:32Kunden mottok én e-post, ikke to.

Effekter forpliktes med avanseringenIdempotensnøkkel per kjøring og steg

En logg skrevet for et menneske å lese

Hver kjøring, hvert steg, grenen den tok og verdien som bestemte det. Tidspunkter per steg. Forespørselen og svaret fra hvert eksterne kall, med påloggingsinformasjon slettet. Versjonen kjøringen gikk på. Hvor en kjøring venter, og til når.

Når noen spør hva som skjedde med bestillingen fra den fjortende, finnes det et svar, og å finne det tar et minutt i stedet for en ettermiddag med å sammenstille loggene fra tre systemer.

Kjøringer som feiler samles på ett sted med årsaken gruppert, så «41 feil i natt» blir til «én leverandør returnerte 503 i ni minutter» i stedet for 41 separate undersøkelser.

Over natten, gruppert41 feil

1Én årsakLeverandørens API returnerte 503 mellom 02:41 og 02:50.
2Hva som skjeddeAlle 41 ble forsøkt på nytt; 39 lyktes på andre forsøk.
3Til oversTo ble stoppet og venter på et menneske. Begge er oppført med raden som feilet.
§Ikke førtiénundersøkelser. Én, og en avgjørelse om to poster.

Påloggingsinformasjon slettetVersjon registrert

Hva vi ikke hevder

Vi publiserer ikke en oppetidstall på en markedsføringsside, fordi et tall uten et målevindu og en definisjon av «oppe» er pynt. Hvis du trenger én kontraktsmessig, spør oss, så snakker vi om hva vi faktisk kan forplikte oss til.

Vi kan heller ikke gjøre en annens API pålitelig. Hvis en leverandør er nede, venter en arbeidsflyt som er avhengig av den, prøver på nytt og stopper til slutt med en tydelig årsak. Det vi kan love, er at feilen blir synlig, at den ikke ødelegger noe, og at gjenopptak ikke sender meldingen en gang til.

Om ventetid: en kjøring som venter i to dager er en wake_at på kjøringen, ikke en jobb som ligger i en kø. Det er derfor en arbeidsflyt kan holde hundre tusen kjøringer i en tre ukers ventetid uten at det koster noe, og hvorfor antall kjøringer som for øyeblikket venter, ikke er noe du trenger å tenke på.