Ekzekutime që mund t'i besoni

Askush nuk vëren një automatizim derisa të dërgojë diçka dy herë

Pastaj e vërejnë të gjithë. Katër mekanizmat në këtë faqe ekzistojnë sepse dështimet e këtij lloji softueri janë gjithmonë të njëjtat katër dështime, dhe të gjitha shmangen me dizajn, jo me kujdes.

Simuloni para se të publikoni

Shtyni një regjistrim real përmes një rrjedhe pune që është e fikur, dhe lexoni saktësisht çfarë do të kishte ndodhur: rrugën e ndjekur, çdo vlerë në çdo hap, formulimin e çdo mesazhi dhe kërkesën që do të ishte dërguar në secilin sistem të jashtëm.

Asgjë nuk del nga sistemi. Nuk dërgohet e-postë, nuk lëshohet faturë, nuk tentohet pagesë, nuk shkruhet asnjë rresht. Thirrjet e jashtme regjistrohen si synime, me të dhënat që do të ishin dërguar, kështu që mund të shihni nëse hartëzimi është i saktë përpara se të bëhet problem i dikujt.

Simulimet janë mënyra si i përgjigjeni pyetjes që i ndal njerëzit të aktivizojnë një automatizim: çfarë do të bëjë në të vërtetë kjo?

Simulim · porosia 88 214Asgjë e dërguar

1Vlerëso adresënU përputh. Do të kishte shkruar 6 fusha.
?KushtPorosi mbi 1 000 zł? Jo — 289,00 zł. U ndoq rruga e shkurtër.
3FaturaDo të bënte një POST te sistemi i faturimit. Të dhënat e dërguar të shfaqura të plota.
!Kapur këtuTarifa e TVSH-së u hartëzua nga fusha e gabuar. U gjet në një simulim dhe jo në kutinë postare të një kontabilisti.

Dërguar: asgjëFaturuar: asgjë

Një ekzekutim ecën në versionin me të cilin hyri

Publikimi i një ndryshimi në një rrjedhë pune nuk prek ekzekutimet që janë tashmë brenda saj. Çdo ekzekutim fiksohet në versionin ku filloi dhe e përfundon atë version, sa kohë të marrë dhe sa të rishkruani në mesjetë.

Kështu mund të riorganizoni një rrjedhë pune ndërsa dhjetë mijë njerëz janë në gjysmë të saj, dhe secili prej tyre e përfundon rrjedhën që iu është premtuar. Alternativa — dizajni ku e gjithë rruga e mëpasshme materializohet në hyrje — është arsyeja pse redaktimi i një automatizimi të gjallë duket i rrezikshëm në shumicën e mjeteve. Këtu është diçka e zakonshme.

Ekzekutimet e reja marrin versionin e ri nga momenti që e publikoni. Versioni në të cilin ndodhet një ekzekutim shkruhet mbi të, kështu që një pyetje për sjelljen në mars ka përgjigje në shtator.

Redaktim gjatë funksionimitv4 → v5

1Para2 918 ekzekutime në zhvillim, të gjitha në v4. Disa në një pritje dy-ditore.
2Publiko v511:40Dy hapa u rirenditën, një mesazh u rishkrua.
3PasAto 2 918 e përfundojnë v4. Çdo gjë që nis nga ora 11:40 ekzekuton v5.
§Askushnuk mori gjysmën e një rrjedhe pune dhe gjysmën e një tjetre.

Versioni i regjistruar në çdo ekzekutimVersionet e vjetra ruhen

Ripërsëritje që nuk mund të dërgojnë dyfish

Një hap është funksion i pastër i hyrjeve të tij, dhe efektet e tij përfundojnë së bashku me përparimin e vetë ekzekutimit drejt hapit tjetër. Nuk ka asnjë dritare në të cilën mesazhi është dërguar por ekzekutimi nuk e di.

Kjo është e gjithë zgjidhja, dhe është një veti strukturore dhe jo një premtim. Një punonjës i vrarë në mes të hapit — një publikim versioni, një rrëzim, një makinë që zhduket — e lë ekzekutimin saktësisht aty ku ishte. Një punonjës tjetër e merr dhe e ripërsërit hapin. Meqë efekti dhe përparimi përfundojnë si një, ose ndodhën të dyja ose asnjëri.

Thirrjet e jashtme drejt sistemeve që mbështesin çelësa idempotencie mbajnë një të tillë, të nxjerrë nga ekzekutimi dhe hapi, kështu që edhe ana tjetër mund ta njohë përsëritjen.

Punonjësi u vra në mes të dërgesësU rikuperua

1Hapi 5 fillon09:14:06Dërgo njoftimin e dërgesës.
✕Punonjësi vdes09:14:07Publikim versioni. Asgjë nuk ishte përfunduar.
2U marr09:14:31Një punonjës tjetër e gjen ekzekutimin ende në hapin 5.
✓Dërguar një herë09:14:32Klienti mori një e-postë, jo dy.

Efektet regjistrohen me avansinÇelës idempotencie për çdo ekzekutim dhe hap

Një regjistër i shkruar për t'u lexuar nga një person

Çdo ekzekutim, çdo hap, degën që ndoqi dhe vlerën që e vendosi atë. Kohëmatje për çdo hap. Kërkesën dhe përgjigjen e çdo thirrjeje të jashtme, me kredencialet e fshehura. Versionin mbi të cilin ishte ekzekutimi. Ku po pret një ekzekutim dhe deri kur.

Kur dikush pyet çfarë ndodhi me porosinë e bërë të katërmbëdhjetën, ka një përgjigje, dhe gjetja e saj zgjat një minutë e jo një pasdite korrelimi i regjistrave të tre sistemeve.

Ekzekutimet që dështojnë mblidhen në një vend me arsyet e grupuara, kështu që «dyzet e një dështime gjatë natës» zgjidhet në «një furnitor ktheu 503 për nëntë minuta» e jo dyzet e një hetime të veçanta.

Gjatë natës, e grupuar41 dështime

1Një shkakAPI-ja e furnitorit ktheu 503 midis 02:41 dhe 02:50.
2Çfarë ndodhiTë 41 u provuan përsëri; 39 dolën në përfundim në tentativën e dytë.
3Të mbeturaDy u ndalën dhe po presin për një person. Të dyja janë të listuara me rreshtin që dështoi.
§Jo dyzet e njëhetime. Një, dhe një vendim për dy regjistrime.

Kredencialet e fshehuraVersioni i regjistruar

Çfarë nuk pretendojmë

Ne nuk publikojmë një shifër disponueshmërie në një faqe marketingu, sepse një numër pa një dritare matje dhe pa një përkufizim të «në funksion» është thjesht dekor. Nëse ju duhet një e tillë kontraktualisht, pyesni dhe do të flasim për atë që mund të garantojmë në të vërtetë.

Ne gjithashtu nuk mund ta bëjmë të besueshme API-në e dikujt tjetër. Nëse një ofrues është jashtë funksionit, një rrjedhë pune që varet prej tij pret, provon përsëri dhe në fund ndalet me një arsye të qartë. Ajo që mund të premtojmë është që dështimi është i dukshëm, që nuk dëmton asgjë, dhe që rifillimi nuk e dërgon mesazhin një herë të dytë.

Për pritjet: një ekzekutim që pret dy ditë është një wake_at mbi ekzekutimin, jo një punë që rri në një radhë. Prandaj një rrjedhë pune mund të mbajë njëqind mijë ekzekutime në një pritje trejavore pa kushtuar asgjë, dhe prandaj numri i ekzekutimeve që presin aktualisht nuk është diçka me të cilën duhet të merreni.