castomFLOW
Отворете castomFLOW

Изпълнения, на които можете да разчитате

Никой не забелязва автоматизация, докато не изпрати нещо два пъти

Тогава всички го забелязват. Четирите механизма на тази страница съществуват, защото провалите на този вид софтуер са винаги същите четири, и всички те се избягват чрез замисъл, а не чрез внимателност.

Симулирайте, преди да публикувате

Прекарайте реален запис през работен процес, който е изключен, и прочетете точно какво би се случило: избрания път, всяка стойност на всяка стъпка, формулировката на всяко съобщение и заявката, която би отишла към всяка външна система.

Нищо не излиза навън. Не се изпраща имейл, не се издава фактура, не се опитва плащане, не се записва ред. Външните повиквания се записват като намерения, с данните, които биха били изпратени, така че да видите дали съпоставката е правилна, преди да стане проблем на някого.

Симулациите са начинът да отговорите на въпроса, който спира хората да включат автоматизация: какво всъщност ще направи това?

Симулация · поръчка 88 214Нищо не е изпратено
  • 1Проверка на адресаСъвпадение. Биха били записани 6 полета.
  • ?УсловиеПоръчка над 1 000 zł? Не — 289,00 zł. Избран е краткият път.
  • 3ФактураБи изпратил POST към системата за фактуриране. Заявката е показана изцяло.
  • !Хванато тукСтавката на ДДС е взета от грешното поле. Открито при симулация, а не във входящата поща на счетоводителя.

Изпратено: нищоНачислено: нищо

Всяко изпълнение следва версията, на която е влязло

Публикуването на промяна в работен процес не засяга изпълненията, които вече са в него. Всяко изпълнение е обвързано с версията, на която е започнало, и я завършва — колкото и да отнеме и колкото и да промените междувременно.

Така можете да преструктурирате работен процес, докато десет хиляди души са по средата му, и всеки от тях завършва потока, който му е обещан. Алтернативата — дизайнът, при който целият следващ път се материализира при влизане — е причината редактирането на работеща автоматизация да изглежда опасно в повечето инструменти. Тук това е обикновено нещо.

Новите изпълнения получават новата версия от момента на публикуване. Версията, на която е дадено изпълнение, е записана върху него, така че въпрос за поведението през март има отговор през септември.

Редактиране в движениеv4 → v5
  • 1Преди2 918 изпълнения в ход, всички на v4. Някои чакат по два дни.
  • 2Публикуване на v5Разменени са две стъпки, едно съобщение е пренаписано.
  • 3СледТези 2 918 завършват v4. Всичко, което започва от 11:40, работи с v5.
  • §Никойне е получил половината от един работен процес и половината от друг.

Версията е записана на всяко изпълнениеСтарите версии се съхраняват

Повторни опити, които не могат да изпратят двукратно

Стъпката е чиста функция на своите входове, а ефектите ѝ се записват заедно с напредването на изпълнението към следващата стъпка. Няма прозорец, в който съобщението да е изпратено, а изпълнението да не го знае.

Това е целият трик и той е структурно свойство, а не обещание. Работник, прекъснат по средата на стъпка — внедряване, срив, машина, която изчезва — оставя изпълнението точно там, където е било. Друг работник го поема и изпълнява стъпката отново. Тъй като ефектът и напредването се записват като едно, или и двете са се случили, или нито едно.

Изходящите повиквания към системи, поддържащи ключове за идемпотентност, носят такъв — извлечен от изпълнението и стъпката — така че другата страна също да разпознае повторението.

Работник прекъснат по време на изпращанеВъзстановено
  • 1Стъпка 5 започваИзпратете известие за пратката.
  • ✕Работникът умираВнедряване. Нищо не е било записано.
  • 2ПоетоДруг работник открива изпълнението все още на стъпка 5.
  • ✓Изпратено веднъжКлиентът е получил един имейл, а не два.

Ефектите се записват заедно с напредванетоКлюч за идемпотентност за всяко изпълнение и стъпка

Дневник, писан за четене от човек

Всяко изпълнение, всяка стъпка, избраният клон и стойността, която го е решила. Времета за всяка стъпка. Заявката и отговорът на всяко външно повикване, с премахнати идентификационни данни. Версията, на която е било изпълнението. Къде чака изпълнението и до кога.

Когато някой попита какво се е случило с поръчката, направена на четиринадесети, има отговор, а намирането му отнема минута, а не следобед по съпоставяне на дневниците на три системи.

Неуспешните изпълнения се събират на едно място с групирана причина, така че „четиридесет и един неуспеха през нощта“ се превръща в „един доставчик връщаше 503 в продължение на девет минути“, а не в четиридесет и едно отделни разследвания.

През нощта, групирано41 неуспеха
  • 1Една причинаAPI на доставчика връщаше 503 между 02:41 и 02:50.
  • 2Какво се случиВсичките 41 бяха изпробвани отново; 39 успяха от втория опит.
  • 3ОстаналиДве спряха и чакат човек. И двете са изброени с реда, при който се провалиха.
  • §Не четиридесет и едноразследвания. Едно, и решение за два записа.

Удостоверенията са скритиВерсията е записана

Какво не твърдим

Не публикуваме цифра за работоспособността на маркетингова страница, защото число без период на измерване и дефиниция на „работещо“ е украса. Ако ви е необходима договорно, попитайте и ще поговорим за това на какво можем реално да се ангажираме.

Не можем да направим и чужд API надежден. Ако доставчикът е недостъпен, работният процес, който зависи от него, изчаква, опитва отново и в крайна сметка спира с ясна причина. Това, което можем да обещаем, е, че неуспехът е видим, че не поврежда нищо и че подновяването не изпраща съобщението втори път.

За изчакванията: изпълнение, което изчаква два дни, е wake_at върху изпълнението, а не задача, седяща в опашка. Затова един работен процес може да задържи сто хиляди изпълнения в триседмично изчакване, без това да струва нищо, и затова броят на изпълненията, които в момента чакат, не е нещо, за което трябва да мислите.

Изпълнението, за което никога не мислите, е това, което е успяло.