castomFLOW

Execucions en què pots confiar

Ningú no es fixa en una automatització fins que envia alguna cosa dues vegades

Llavors tothom s'hi fixa. Els quatre mecanismes d'aquesta pàgina existeixen perquè els errors d'aquest tipus de programari són sempre els mateixos quatre errors, i tots són evitables per disseny, no per cura.

Simula abans de publicar

Fes passar un registre real per un flux de treball desactivat, i llegeix exactament què hauria passat: el camí seguit, cada valor a cada pas, la redacció de cada missatge i la petició que hauria anat a cada sistema extern.

Res surt de l'edifici. No s'envia cap correu, no s'emite cap factura, no s'intenta cap càrrec, no s'escriu cap fila. Les crides externes es registren com a intencions, amb la càrrega que s'hauria enviat, perquè puguis veure si el mapatge és correcte abans que es converteixi en problema d'algú.

Les simulacions són com respones la pregunta que impedeix la gent activar una automatització: què farà realment?

Simulació · comanda 88 214Res enviat
  • 1Valida l'adreçaCoincidència. S'haurien escrit 6 camps.
  • ?CondicióComanda de més de 1 000 zł? No — 289,00 zł. S'ha pres el camí curt.
  • 3FacturaFaria una petició POST al sistema de facturació. La càrrega es mostra sencera.
  • !Aturat aquíTipus d'IVA assignat des del camp equivocat. Detectat en una simulació en lloc de a la safata d'entrada d'un comptable.

Enviat: resCobrat: res

Una execució recorre la versió en què ha entrat

Publicar un canvi en un flux de treball no toca les execucions que ja hi són. Cada execució queda fixada a la versió en què ha començat i acaba aquesta versió, trigui el que trigui i per molt que reescriguis mentrestant.

Així pots reestructurar un flux de treball mentre deu mil persones el tenen a mig fer, i cadascuna completa el flux que se li havia promès. L'alternativa —el disseny on tot el camí posterior es materialitza en entrar— és el motiu pel qual editar una automatització en marxa sembla perillós a la majoria d'eines. Aquí no té cap importància.

Les execucions noves reben la versió nova des del moment en què publiques. La versió en què és cada execució queda escrita a la pròpia execució, així que una pregunta sobre el comportament al març té resposta al setembre.

Edició en marxav4 → v5
  • 1Abans2 918 execucions en curs, totes a la v4. Algunes en una espera de dos dies.
  • 2Publica la v5Dos passos reordenats, un missatge reescrit.
  • 3DesprésAquelles 2 918 acaben la v4. Tot el que comenci a partir de les 11:40 executa la v5.
  • §Ningúha rebut la meitat d'un flux de treball i la meitat d'un altre.

Versió registrada a cada execucióVersions antigues conservades

Reintents que no poden enviar dues vegades

Un pas és una funció pura de les seves entrades, i els seus efectes es confirmen juntament amb l'avanç propi de l'execució cap al pas següent. No hi ha cap finestra en què el missatge ja hagi sortit però l'execució no ho sàpiga.

Aquest és tot el truc, i és una propietat estructural i no una promesa. Un treballador mort a mig pas —un desplegament, una fallada, una màquina que desapareix— deixa l'execució exactament on era. Un altre treballador la recull i torna a executar el pas. Com que l'efecte i l'avanç es confirmen com un sol acte, o han passat tots dos o no n'ha passat cap.

Les crides sortints a sistemes que admeten claus d'idempotència en porten una, derivada de l'execució i del pas, perquè l'altra banda també pugui reconèixer la repetició.

Treballador mort a mig enviamentRecuperat
  • 1Comença el pas 5Envia l'avís d'enviament.
  • ✕El treballador morDesplegament. Res no s'havia confirmat.
  • 2RecollidaUn altre treballador troba l'execució encara al pas 5.
  • ✓Enviat un copEl client ha rebut un correu electrònic, no dos.

Els efectes es confirmen amb l'avançClau d'idempotència per execució i pas

Un registre escrit perquè el llegeixi una persona

Cada execució, cada pas, la branca que va prendre i el valor que ho va decidir. Temps per pas. La petició i la resposta de cada crida externa, amb les credencials ocultes. La versió en què va córrer l'execució. On espera una execució i fins quan.

Quan algú pregunta què va passar amb la comanda feta el catorze, hi ha una resposta, i trobar-la triga un minut en lloc d'una tarda creuant els registres de tres sistemes.

Les execucions que fallen es recullen en un lloc amb la causa agrupada, de manera que «quaranta-una fallades durant la nit» es resol en «un proveïdor va retornar 503 durant nou minuts» en lloc de quaranta-una investigacions separades.

Durant la nit, agrupades41 fallades
  • 1Una causaL'API del proveïdor va retornar 503 entre les 02:41 i les 02:50.
  • 2Què va passarLes 41 es van reintentar; 39 van tenir èxit al segon intent.
  • 3PendentsDues s'han aturat i esperen una persona. Totes dues apareixen llistades amb la fila que va fallar.
  • §No quaranta-unainvestigacions. Una, i una decisió sobre dos registres.

Credencials ocultesVersió registrada

El que no afirmem

No publiquem una xifra de disponibilitat en una pàgina de màrqueting, perquè un número sense una finestra de mesurament i una definició de «disponible» és decoració. Si en necessites una contractualment, pregunta'ns i parlarem del que realment podem comprometre'ns a oferir.

Tampoc no podem fer que l'API d'algú altre sigui fiable. Si un proveïdor cau, un flux que en depèn espera, reintenta i finalment s'atura amb un motiu clar. El que podem prometre és que la fallada és visible, que no corromp res, i que reprendre l'execució no envia el missatge una segona vegada.

Sobre les esperes: una execució que espera dos dies és un wake_at a l'execució, no una feina asseguda en una cua. Per això un flux pot mantenir cent mil execucions en una espera de tres setmanes sense que cap d'elles costi res, i per això el nombre d'execucions que esperen ara mateix no és una cosa de la que hagis de preocupar-te.

L'execució en què mai penses és la que ha funcionat.