Execucións nas que podes confiar

Ninguén repara nunha automatización ata que envía algo dúas veces

Entón repáranos todos. Os catro mecanismos desta páxina existen porque os fallos deste tipo de software son sempre os mesmos catro fallos, e todos son evitables por deseño en vez de por coidado.

Simula antes de publicar

Pasa un rexistro real por un fluxo desactivado e le exactamente o que pasaría: o camiño seguido, cada valor en cada paso, a redacción de cada mensaxe e a petición que se enviaría a cada sistema externo.

Nada sae fóra. Non se envía ningún correo, non se emite ningunha factura, non se tenta ningún cobro, non se escribe ningunha fila. As chamadas externas rexístranse como intencións, coa carga que se enviaría, para que poidas ver se a correspondencia é correcta antes de que se converta no problema de alguén.

As simulacións son como respondes á pregunta que impide á xente activar unha automatización: que fará isto exactamente?

Simulación · pedido 88 214Nada enviado

1Validar enderezoCoincidencia. Escribiría 6 campos.
?CondiciónPedido superior a 1 000 zł? Non — 289,00 zł. Tómase o camiño curto.
3FacturaFaríase un POST ao sistema de facturación. Amósase a carga completa.
!Detectado aquíO tipo de IVE asignouse desde o campo errado. Atopouse nunha simulación en vez de na caixa dun contable.

Enviado: nadaCobrado: nada

Cada execución percorre a versión na que entrou

Publicar un cambio nun fluxo de traballo non afecta ás execucións que xa están dentro del. Cada execución está ancorada á versión na que comezou e remata esa versión, por moi que tarde e por moito que reescribas mentres tanto.

Así podes reestruturar un fluxo de traballo mentres dez mil persoas están a metade del, e cada unha completa o fluxo que se lle prometeu. A alternativa — o deseño no que todo o camiño posterior se materializa na entrada — é a razón pola que editar unha automatización en vivo parece perigoso na maioría das ferramentas. Aquí non ten nada de extraordinario.

As execucións novas obteñen a versión nova desde o momento en que publicas. A versión na que está cada execución queda rexistrada nela, así que unha pregunta sobre o comportamento en marzo ten resposta en setembro.

Edición en vivov4 → v5

1Antes2 918 execucións en curso, todas na v4. Algunhas nunha espera de dous días.
2Publicar v511:40Dous pasos reordenados, unha mensaxe reescrita.
3DespoisEsas 2 918 rematan a v4. Todo o que comece a partir das 11:40 executa a v5.
§Ninguénrecibiu metade dun fluxo de traballo e metade doutro.

Versión rexistrada en cada execuciónVersións antigas conservadas

Reintentos que non poden enviar por duplicado

Un paso é unha función pura das súas entradas, e os seus efectivos confirmanse xunto co propio avance da execución ao seguinte paso. Non hai ningunha fiestra na que a mensaxe xa saíra pero a execución non o saiba.

Ese é todo o truco, e é unha propiedade estrutural, non unha promesa. Un traballador morto a metade dun paso — un despregue, un fallo, unha máquina que desaparece — deixa a execución exactamente onde estaba. Outro traballador recóllea e volve executar o paso. Como o efecto e o avance confírmanse como un, ou ocorren os dous ou non ocorre ningún.

As chamadas de saída a sistemas que admiten claves de idempotencia levan unha, derivada da execución e do paso, para que o outro lado tamén recoñeza a repetición.

Traballador morto a metade do envíoRecuperado

1Comeza o paso 509:14:06Enviar o aviso de envío.
✕O traballador morre09:14:07Despregue. Non se confirmara nada.
2Recollido09:14:31Outro traballador atopa a execución aínda no paso 5.
✓Enviado unha vez09:14:32O cliente recibiu un correo electrónico, non dous.

Os efectivos confírmanse co avanceClave de idempotencia por execución e paso

Un rexistro escrito para que o lea unha persoa

Cada execución, cada paso, a rama que tomou e o valor que o decidiu. Tempos por paso. A solicitude e a resposta de cada chamada externa, con credenciais ocultas. A versión na que estaba a execución. Onde está á espera unha execución e ata cándo.

Cando alguén pregunta que lle pasou ao pedido feito o catorce, hai unha resposta, e atopala leva un minuto en vez dunha tarde correlacionando os rexistros de tres sistemas.

As execucións que fallan recóllense nun só lugar coa razón agrupada, así que «corenta e un fallos durante a noite» resólvese en «un provedor devolveu 503 durante nove minutos» en vez de corenta e un investigacións separadas.

Durante a noite, agrupado41 fallos

1Unha causaA API do provedor devolveu 503 entre as 02:41 e as 02:50.
2Que pasouOs 41 reintentáronse; 39 tiveron éxito no segundo intento.
3PendentesDous detivéronse e están á espera dunha persoa. Ambos están listados coa fila que fallou.
§Non corenta e uninvestigacións. Unha, e unha decisión sobre dous rexistros.

Credenciais ocultasVersión rexistrada

O que non afirmamos

Non publicamos unha cifra de dispoñibilidade nunha páxina de marketing, porque un número sen unha ventá de medición e sen unha definición de «dispoñible» é decoración. Se a necesitas contractualmente, pregúntanos e falaremos do que podemos comprometernos de verdade.

Tamén non podemos facer fiable a API de outra persoa. Se un provedor está caído, un fluxo que dependa del espera, reintenta e finalmente detense cun motivo claro. O que podemos prometer é que o fallo é visible, que non corrompe nada e que retomar non envía a mensaxe unha segunda vez.

Sobre as esperas: unha execución á espera durante dous días é un wake_at na execución, non un traballo sentado nunha cola. Por iso un fluxo pode manter cen mil execucións nunha espera de tres semanas sen que custe nada, e por iso o número de execucións á espera non é algo no que teñas que pensar.