Mga run na mapagkakatiwalaan mo

Walang nakapapansin sa isang automation hanggang sa magpadala ito ng dalawang beses

Pagkatapos, mapapansin na ng lahat. Ang apat na mekanismo sa pahinang ito ay umiiral dahil ang mga pagkabigo ng ganitong uri ng software ay palaging iisa lamang apat na pagkabigo, at lahat ng ito ay naiiwasan sa pamamagitan ng disenyo at hindi sa pamamagitan ng pag-iingat.

I-simulate bago i-publish

Ipasa ang isang tunay na record sa isang workflow na naka-off, at basahin nang eksakto ang mangyayari: ang daang tinakbo, bawat halaga sa bawat hakbang, ang pagkakasulat ng bawat mensahe, at ang request na ipapadala sa bawat external system.

Walang lumalabas. Walang naipapadala na e-mail, walang ginagawang invoice, walang sinubukang singilin, walang isinusulat na row. Ang mga external call ay nire-record bilang mga intensyon, kasama ang payload na sana ay naipadala, kaya makikita mo kung tama ang mapping bago pa ito maging problema ng ibang tao.

Ang mga simulation ang paraan para masagot ang tanong na pumipigil sa mga taong i-on ang isang automation: ano talaga ang gagawin nito?

Simulasyon · order 88 214Walang naipadala

1I-validate ang addressNatugma. Sana ay nakasulat ng 6 na field.
?KondisyonOrder na higit 1 000 zł? Hindi — 289,00 zł. Naikot ang maikling daan.
3PakturaSana ay nag-POST sa invoicing system. Ipinapakita nang buo ang payload.
!Nahuli ditoAng VAT rate ay nakuha sa maling field. Natagpuan sa isang simulation sa halip na sa inbox ng isang accountant.

Naipadala: walaNasingil: wala

Ang isang run ay sumusunod sa bersyon kung saan ito pumasok

Ang pag-publish ng pagbabago sa isang workflow ay hindi umaapekto sa mga run na nasa loob na nito. Ang bawat run ay naka-pinned sa bersyon kung saan ito nagsimula at tinatapos ang bersyong iyon, gaano man ito katagal at gaano man kalaki ang muling isulat mo sa pagitan.

Kaya maaari mong muling istrukturahin ang isang workflow habang sampung libong tao ay nasa kalagitnaan nito, at ang bawat isa sa kanila ay tinatapos ang daloy na ipinangako sa kanila. Ang alternatibo — ang disenyo kung saan ang buong downstream path ay ginagawang materyal sa pagpasok — ang dahilan kung bakit pakiramdam ay mapanganib ang pag-edit ng isang live automation sa karamihan ng mga tool. Dito, ito ay karaniwan lamang.

Ang mga bagong run ay nakakakuha ng bagong bersyon mula sa sandaling i-publish mo. Ang bersyon kung saan naka-angkop ang isang run ay nakasulat sa run mismo, kaya ang tanong tungkol sa pag-uugali noong Marso ay may sagot sa Setyembre.

Pag-edit habang livev4 → v5

1Bago2 918 na run ang nasa proseso, lahat sa v4. Ang ilan ay nasa dalawang araw na paghihintay.
2I-publish ang v511:40Dalawang hakbang ang pinalitan ng pagkakasunod, isang mensahe ang muling isinulat.
3PagkataposAng mga 2 918 na iyon ay tinatapos ang v4. Lahat ng magsisimula mula 11:40 ay tumatakbo sa v5.
§Walang sinumanang nakatanggap ng kalahati ng isang workflow at kalahati ng iba pa.

Bersyon na naka-record sa bawat runMga lumang bersyon na naka-imbak

Mga retry na hindi maaaring magpadala nang dalawang beses

Ang isang hakbang ay purong function ng mga input nito, at ang mga epekto nito ay naka-commit kasama ng pag-usad ng run sa susunod na hakbang. Walang bintana kung saan lumabas na ang mensahe ngunit hindi pa alam ng run.

Iyon ang buong trick, at ito ay istruktural na katangian at hindi pangako. Ang worker na namatay sa gitna ng hakbang — isang deploy, isang crash, isang makinang naglaho — iiwan ang run eksaktong kung saan ito naroon. Aalisin ito ng isa pang worker at muling tatakbuhin ang hakbang. Dahil ang epekto at ang pag-usad ay naka-commit bilang isa, alinman sa dalawa ang nangyari o wala.

Ang mga papalabas na tawag sa mga sistemang sumusuporta sa idempotency key ay may dala nito, hango sa run at sa hakbang, upang makilala rin ng kabilang panig ang pag-uulit.

Namatay ang worker sa gitna ng pagpapadalaNakabawi

1Nagsisimula ang hakbang 509:14:06Ipadala ang abiso ng pagpapadala.
✕Namatay ang worker09:14:07Deploy. Walang na-commit.
2Sinungkaban09:14:31Nakita ng isa pang worker na nasa hakbang 5 pa rin ang run.
✓Naipadala nang isang beses09:14:32Tumanggap ang customer ng isang e-mail, hindi dalawa.

Naka-commit ang mga epekto kasama ng pag-usadIdempotency key kada run at hakbang

Isang log na isinulat para basahin ng tao

Bawat run, bawat hakbang, ang sangang kinuha nito at ang halagang nagpasya doon. Mga timing kada hakbang. Ang request at response ng bawat panlabas na tawag, na may tinanggal na credentials. Ang bersyon kung saan nakasalalay ang run. Kung saan naghihintay ang run at hanggang kailan.

Kapag may nagtanong kung ano ang nangyari sa order noong ika-apat na araw, may sagot, at ang paghahanap nito ay isang minuto sa halip na isang hapon ng pagtutugma ng mga log ng tatlong sistema.

Ang mga run na nabigo ay nagtitipon sa isang lugar na may pinagsasama-sama na dahilan, kaya ang “apatnapu't-isang pagkabigo kagabi” ay nagiging “isang supplier na nagbalik ng 503 sa loob ng siyam na minuto” sa halip na apatnapu't-isang hiwalay na imbestigasyon.

Kagabi, pinagsama-sama41 na pagkabigo

1Isang dahilanNagbalik ang Supplier API ng 503 sa pagitan ng 02:41 at 02:50.
2Ano ang nangyariLahat ng 41 ay muling sinubukan; 39 ang tagumpay sa ikalawang pagsubok.
3NatiraDalawa ang huminto at naghihintay ng tao. Parehong nakalista kasama ang hanay na nabigo.
§Hindi apatnapu't-isana imbestigasyon. Isa, at isang desisyon tungkol sa dalawang rekord.

Tinanggal ang mga credentialNaitala ang bersyon

Ang hindi namin ipinangangako

Hindi kami naglalathala ng figura ng uptime sa pahinang pangmarketing, dahil ang bilang na walang window ng pagsukat at kahulugan ng “up” ay palamuti lamang. Kung kailangan mo ito nang contractual, magtanong at pag-uusapan natin kung ano ang talaga naming maipangako.

Hindi rin namin magawang gawing maaasahan ang API ng iba. Kung bumagsak ang isang provider, ang workflow na nakasalalay dito ay maghihintay, muling susubok, at sa huli ay hihinto na may malinaw na dahilan. Ang matitiyak namin ay na nakikita ang pagkabigo, na hindi nito sinisira ang anuman, at na ang pagpapatuloy ay hindi magpapadala ng mensahe nang ikalawang beses.

Tungkol sa mga paghihintay: ang run na naghihintay ng dalawang araw ay isang wake_at sa run, hindi isang trabahong nakatambak sa queue. Kaya nga ang isang workflow ay maaaring maghawak ng isandaang libong run sa tatlong-linggong paghihintay nang walang anumang gastos, at kung bakit hindi mo na kailangang isipin ang bilang ng mga run na kasalukuyang naghihintay.