Körningar du kan lita på

Ingen lägger märke till en automatisering förrän den skickar något två gånger

Sedan lägger alla märke till det. De fyra mekanismerna på den här sidan finns för att felen hos den här typen av mjukvara alltid är samma fyra fel, och de är alla undvikbara genom design i stället för genom omsorg.

Simulera innan du publicerar

Skicka en riktig post genom ett arbetsflöde som är avstängt, och läs tillbaka exakt vad som skulle ha hänt: vägen som togs, varje värde i varje steg, formuleringen av varje meddelande och begäran som skulle ha gått till varje externt system.

Ingenting lämnar byggnaden. Inget e-postmeddelande skickas, ingen faktura ställs ut, inget debiteringsförsök görs, ingen rad skrivs. Externa anrop registreras som avsikter, med den nyttolast som skulle ha skickats, så att du kan se om mappningen stämmer innan den blir någons problem.

Simuleringar är hur du svarar på frågan som hindrar folk från att slå på en automatisering: vad gör den egentligen?

Simulering · order 88 214Inget skickat

1Validera adressMatchad. Skulle ha skrivit 6 fält.
?VillkorOrder över 1 000 zł? Nej — 289,00 zł. Kort väg togs.
3FakturaSkulle göra POST till faktureringssystemet. Nyttolast visas i sin helhet.
!Fångad härMomssats mappad från fel fält. Upptäckt i en simulering i stället för i en revisors inkorg.

Skickat: ingentingDebiterat: ingenting

En körning går igenom den version den kom in på

Att publicera en ändring i ett arbetsflöde påverkar inte de körningar som redan är inne i det. Varje körning är låst till versionen den startade på och avslutar den versionen, hur lång tid det än tar och hur mycket du än skriver om under tiden.

Så du kan bygga om ett arbetsflöde medan tiotusen personer är halvvägs igenom det, och var och en av dem slutför flödet de lovats. Alternativet — designen där hela den nedströms vägen materialiseras vid inträdet — är orsaken till att det känns farligt att redigera en live-automatisering i de flesta verktyg. Här är det ingenting att nämna.

Nya körningar får den nya versionen från det ögonblick du publicerar. Vilken version en körning är på skrivs på körningen, så en fråga om beteendet i mars har ett svar i september.

Redigering medan livev4 → v5

1Före2 918 körningar pågår, alla på v4. Några i ett tvådagars vänteläge.
2Publicera v511:40Två steg omordnade, ett meddelande omskrivet.
3EfterDe där 2 918 avslutar v4. Allt som startar från 11:40 kör v5.
§Ingenfick hälften av ett arbetsflöde och hälften av ett annat.

Version registrerad på varje körningGamla versioner sparas

Retries som inte kan skicka dubbelt

Ett steg är en ren funktion av sina indata, och dess effekter committas tillsammans med körningens eget framsteg till nästa steg. Det finns inget fönster där meddelandet har gått ut men körningen inte vet det.

Det är hela tricket, och det är en strukturell egenskap snarare än ett löfte. En worker som dödas mitt i ett steg — en utrullning, en krasch, en maskin som försvinner — lämnar körningen exakt där den var. En annan worker plockar upp den och kör om steget. Eftersom effekten och framsteget committas som ett är det antingen båda eller ingetdera som hänt.

Utgående anrop till system som stöder idempotensnycklar bär en sådan, härledd från körningen och steget, så att andra sidan också kan känna igen upprepningen.

Worker dödades mitt i utskickÅterställd

1Steg 5 börjar09:14:06Skicka leveransaviseringen.
✕Worker dör09:14:07Utrullning. Ingenting hade committats.
2Plockad upp09:14:31En annan worker hittar körningen fortfarande på steg 5.
✓Skickad en gång09:14:32Kunden fick ett e-postmeddelande, inte två.

Effekter committas med framstegetIdempotensnyckel per körning och steg

En logg skriven för att en människa ska läsa den

Varje körning, varje steg, grenen den tog och värdet som avgjorde det. Tider per steg. Förfrågan och svaret från varje externt anrop, med inloggningsuppgifter borttagna. Versionen som körningen körde på. Var en körning väntar och till när.

När någon frågar vad som hände med ordern som lagts den fjortonde finns det ett svar, och att hitta det tar en minut i stället för en eftermiddag av att korrelera tre systems loggar.

Körningar som misslyckas samlas på ett ställe med orsaken grupperad, så att "fyrtioett misslyckanden över natten" blir "en leverantör returnerade 503 i nio minuter" i stället för fyrtioett separata utredningar.

Över natten, grupperat41 misslyckanden

1En orsakLeverantörens API returnerade 503 mellan 02:41 och 02:50.
2Vad som händeAlla 41 försöktes igen; 39 lyckades vid andra försöket.
3Kvar överTvå stannade och väntar på en människa. Båda listas med raden som misslyckades.
§Inte fyrtioettutredningar. En, och ett beslut om två poster.

Inloggningsuppgifter borttagnaVersion registrerad

Det vi inte påstår

Vi publicerar ingen upptidsiffra på en marknadsföringssida, eftersom en siffra utan mätperiod och utan definition av "uppe" är dekoration. Om du behöver en avtalsenligt, fråga oss så pratar vi om vad vi faktiskt kan åta oss.

Vi kan inte heller göra någon annans API pålitligt. Om en leverantör ligger nere väntar ett arbetsflöde som är beroende av den, försöker igen och stannar till slut med en tydlig orsak. Vad vi kan lova är att felet syns, att det inte förstör något, och att återupptagning inte skickar meddelandet en andra gång.

Om väntan: en körning som väntar i två dagar är en wake_at på körningen, inte ett jobb som ligger i en kö. Därför kan ett arbetsflöde hålla hundra tusen körningar i ett tre veckors väntande utan att något av det kostar något, och därför är antalet körningar som för närvarande väntar inget du behöver tänka på.