Kennisbank / Automation pipelines
Een pipeline die omvalt met een luide foutmelding is een ongemak. Een pipeline die er wekenlang uitziet alsof hij draait terwijl hij de helft van de berichten laat vallen, is een probleem. Het verschil zit niet in de kwaliteit van de koppelingen, maar in wat er is bedacht voor het moment dat er iets misgaat.
En er gaat iets mis. Een externe dienst is even traag, een sleutel verloopt, iemand hernoemt een kolom, een bestand komt in een ander formaat binnen. Wie ervan uitgaat dat dit uitzonderingen zijn, bouwt een proces dat bij de eerste uitzondering stilvalt. Zie wat is een automation pipeline voor de opbouw.
Niet elke fout verdient dezelfde reactie. In de praktijk vallen ze in vier groepen uiteen.
Tijdelijk. Een netwerkhapering, een dienst die kort niet bereikbaar is, een limiet die net overschreden wordt. Antwoord: opnieuw proberen, met oplopende wachttijd. Drie pogingen met een paar seconden ertussen vangt het merendeel af.
Permanent op dit item. Een e-mailadres dat niet bestaat, een bestand dat corrupt is, een verplicht veld dat leeg is. Opnieuw proberen helpt hier nooit. Antwoord: apart zetten en doorgaan met de rest.
Structureel. De sleutel is verlopen, het schema is veranderd, de dienst is gestopt. Antwoord: meteen stoppen en iemand waarschuwen. Doorgaan maakt het alleen erger.
Stil. De pipeline meldt succes maar het resultaat klopt niet: nul rijen verwerkt, lege velden, een bedrag dat plots duizend keer zo groot is. Antwoord: controles die de uitkomst toetsen, niet alleen de status.
Die laatste is de gevaarlijkste, omdat er geen foutmelding is om op te reageren.
Opnieuw proberen is alleen veilig als een stap twee keer uitvoeren hetzelfde oplevert als één keer. Anders stuur je bij elke poging een tweede factuur.
Dat regel je met een sleutel per bewerking: een uniek kenmerk dat meereist, bijvoorbeeld het ordernummer plus de stapnaam. Voordat de stap iets doet, kijkt hij of die sleutel al verwerkt is. Zo ja, dan slaat hij over.
Verder hoort er een grens op te zitten. Oneindig blijven proberen betekent dat een kapotte koppeling je systeem urenlang bezet houdt en je rekening bij externe diensten laat oplopen. Drie tot vijf pogingen, dan naar de wachtrij voor mislukte items.
Elke serieuze pipeline heeft een plek waar mislukte items terechtkomen, met het bericht zelf, de foutmelding, het tijdstip en het aantal pogingen. Zonder die plek verdwijnt een mislukt item in het niets, en niemand kan achteraf zeggen hoeveel er weg zijn.
Belangrijk is dat die wachtrij bekeken wordt. Een lijst die volloopt en die niemand opent, is precies zo nuttig als geen lijst. Koppel er daarom een teller aan: staan er meer dan een afgesproken aantal items in, dan gaat er een bericht uit.
En zorg dat een item opnieuw aangeboden kan worden nadat de oorzaak verholpen is. Handmatig overtypen is de gebruikelijke noodgreep, en het is de manier waarop fouten er alsnog verkeerd ingaan.
Dit is wat stil falen zichtbaar maakt. Leg per pipeline een paar verwachtingen vast en laat het systeem ze toetsen.
Die laatste is de meest onderschatte: monitoring die alleen op fouten let, ziet een proces dat gewoon niet begonnen is helemaal niet.
Een melding hoort te vertellen wat er misging, waar, hoe vaak, en wat de eerstvolgende handeling is. Een technische foutregel zonder context leidt tot doorsturen en navragen.
Verder hoort er onderscheid te zijn tussen dringend en informatief. Als elke hapering een bericht oplevert, wordt binnen twee weken alles genegeerd, inclusief het bericht dat er wel toe deed. Bundel het onbelangrijke tot een dagelijks overzicht en houd directe meldingen voor wat echt stilligt.
Na een storing staat er meestal een stapel werk klaar. Twee dingen maken dan het verschil: de pipeline weet welk item hij als laatste volledig verwerkte, en hij kan vanaf dat punt verder zonder opnieuw te beginnen.
Dat vraagt dat de voortgang ergens wordt vastgelegd, en dat een halve verwerking niet als heel telt. Een stap die drie systemen bijwerkt, hoort zo ingericht te zijn dat hij na een onderbreking te herhalen is zonder dubbele boekingen.
Foutafhandeling die nooit is uitgeprobeerd, is een aanname met code eromheen. De enige manier om te weten of hij werkt, is hem laten afgaan.
Neem voor elke pipeline een korte lijst met opzettelijke storingen en loop die door voordat hij in productie gaat. Trek de sleutel eruit en kijk of je een melding krijgt. Stuur een bericht met een leeg verplicht veld en kijk of het in de wachtrij belandt in plaats van halverwege te stranden. Zet de externe dienst op onbereikbaar en tel of er werkelijk drie pogingen worden gedaan. Bied hetzelfde bericht twee keer aan en controleer of er één resultaat uitkomt en geen twee.
Die vier toetsen kosten samen een uur en vangen het merendeel van wat er in het eerste kwartaal fout kan gaan. Herhaal ze bij een grotere wijziging, want foutafhandeling is precies het deel dat stilletjes sneuvelt bij een verbouwing: alles werkt nog in het gewone geval, en dat is het geval dat je test als je haast hebt.
Foutafhandeling kost ruwweg een derde van de bouwtijd van een pipeline. Dat voelt duur bij een proces dat in de demo prima werkte. Het is de reden dat een proces ook nog werkt in de week dat er iets misgaat, en dat is de week die telt.
Hoe zo'n stille storing er in het echt uitziet, staat in automatisering die stil faalt. Zie verder n8n pipeline-architectuur voor de opbouw en rapportages automatiseren voor het zicht op wat er dagelijks doorheen gaat.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056