Kørsler, du kan stole på

Ingen lægger mærke til en automatisering, før den sender noget to gange

Så lægger alle mærke til den. De fire mekanismer på denne side findes, fordi fejlene i denne slags software altid er de samme fire fejl, og de kan alle undgås ved design frem for ved omhu.

Simulér, før du udgiver

Send en rigtig post gennem en workflow, der er slået fra, og læs præcis, hvad der ville være sket: den vej, der blev taget, hver værdi ved hvert trin, formuleringen af hver besked og den forespørgsel, der ville være gået til hvert eksternt system.

Intet forlader bygningen. Ingen e-mail sendes, ingen faktura oprettes, ingen opkrævning forsøges, ingen række skrives. Eksterne kald registreres som intentioner med den payload, der ville være sendt, så du kan se, om mappingen er rigtig, før det bliver nogens problem.

Simulationer er måden, du besvarer det spørgsmål på, der får folk til at holde sig fra at slå en automatisering til: hvad gør den egentlig?

Simulation · ordre 88 214Intet sendt

1Validér adresseMatchet. Ville have skrevet 6 felter.
?BetingelseOrdre over 1 000 zł? Nej — 289,00 zł. Kort vej taget.
3FakturaVille lave et POST-kald til faktureringssystemet. Payload vist i sin helhed.
!Fanget herMomsats mappet fra det forkerte felt. Fundet i en simulation frem for i en revisors indbakke.

Sendt: intetOpkrævet: intet

En kørsel følger den version, den kom ind på

At publicere en ændring i et workflow rører ikke de kørsler, der allerede er i det. Hver kørsel er fastlåst til den version, den startede på, og afslutter den version, uanset hvor lang tid det tager, og hvor meget du omskriver i mellemtiden.

Så du kan omstrukturere et workflow, mens ti tusind mennesker er halvvejs igennem det, og hver enkelt af dem gennemfører det flow, de blev lovet. Alternativet — designet, hvor hele den efterfølgende vej materialiseres ved indgang — er grunden til, at det føles farligt at redigere en live automatisering i de fleste værktøjer. Her er det intet bemærkelsesværdigt.

Nye kørsler får den nye version fra det øjeblik, du publicerer. Hvilken version en kørsel er på, skrives på selve kørslen, så et spørgsmål om adfærd i marts har et svar i september.

Redigering mens det kørerv4 → v5

1Før2 918 kørsler i luften, alle på v4. Nogle i en to dages ventetid.
2Publicér v511:40To trin flyttet rundt, én besked omskrevet.
3EfterDe 2 918 afslutter v4. Alt, der starter fra 11:40, kører v5.
§Ingenmodtog halvdelen af ét workflow og halvdelen af et andet.

Version registreret på hver kørselGamle versioner gemmes

Forsøg, der ikke kan sende dobbelt

Et trin er en ren funktion af sine input, og dets effekter committer sammen med kørselens eget fremrykning til næste trin. Der er intet vindue, hvor beskeden er sendt ud, men kørslen ikke ved det.

Det er hele tricket, og det er en strukturel egenskab frem for et løfte. En worker, der dør midt i et trin — en deploy, et crash, en maskine, der forsvinder — efterlader kørslen præcis, hvor den var. En anden worker samler den op og kører trinnet igen. Fordi effekten og fremrykningen committer som ét, er det enten sket begge dele eller ingen af delene.

Udgående kald til systemer, der understøtter idempotensnøgler, medtager én, afledt af kørslen og trinnet, så modparten også kan genkende gentagelsen.

Worker dræbt midt i en afsendelseGendannet

1Trin 5 begynder09:14:06Send forsendelsesvarslen.
✕Worker dør09:14:07Deploy. Intet var committet.
2Afhentet09:14:31En anden worker finder kørslen stadig på trin 5.
✓Sendt én gang09:14:32Kunden modtog én e-mail, ikke to.

Effekter committes med forskuddetIdempotensnøgle pr. kørsel og trin

En log skrevet til at blive læst af et menneske

Hver kørsel, hvert trin, den gren, den tog, og den værdi, der afgjorde det. Tidstagninger pr. trin. Forespørgslen og svaret fra hvert eksternt kald, med legitimationsoplysninger fjernet. Den version, kørslen kørte på. Hvor en kørsel venter, og indtil hvornår.

Når nogen spørger, hvad der skete med ordren, der blev afgivet den fjortende, findes der et svar, og det tager et minut at finde frem til det i stedet for en eftermiddag med at korrelere tre systems logfiler.

Kørsler, der fejler, samles ét sted med årsagen grupperet, så "enogfyrre fejl i løbet af natten" bliver til "én leverandør returnerede 503 i ni minutter" i stedet for enogfyrre separate undersøgelser.

I løbet af natten, grupperet41 fejl

1Én årsagLeverandørens API returnerede 503 mellem 02:41 og 02:50.
2Hvad der sketeAlle 41 blev forsøgt igen; 39 lykkedes ved andet forsøg.
3TilbageværendeTo er standset og venter på et menneske. Begge er opført med den række, der fejlede.
§Ikke enogfyrreundersøgelser. Én, og en beslutning om to poster.

Legitimationsoplysninger fjernetVersion registreret

Hvad vi ikke påstår

Vi publicerer ikke en oppetidstal på en markedsføringsside, for et tal uden et målevindue og en definition af "oppe" er pynt. Hvis du har brug for et kontraktuelt, så spørg, og vi taler om, hvad vi reelt kan forpligte os til.

Vi kan heller ikke gøre en andens API pålidelig. Hvis en udbyder er nede, venter en arbejdsgang, der afhænger af den, prøver igen og stopper til sidst med en klar årsag. Det, vi kan love, er, at fejlen er synlig, at den ikke ødelægger noget, og at genoptagelse ikke sender beskeden en anden gang.

Om ventetider: en kørsel, der venter i to dage, er en wake_at på kørslen, ikke et job, der ligger i en kø. Det er derfor, en arbejdsgang kan holde hundrede tusind kørsler i en tre ugers ventetid uden at det koster noget, og hvorfor antallet af kørsler, der i øjeblikket venter, ikke er noget, du skal tænke over.