De gevaarlijkste storing is de storing zonder foutmelding: een proces dat draait, succes meldt en de helft van de berichten laat vallen. Vier soorten fouten, vier antwoorden, en de controles die het zichtbaar maken.
Een geautomatiseerd proces dat omvalt met een luide foutmelding is een ongemak. Een proces dat er wekenlang uitziet alsof het draait terwijl het de helft van de berichten laat vallen, is een probleem. Het eerste merk je binnen een uur. Het tweede merk je als een klant belt over iets wat hij drie weken geleden aanvroeg.
Het verschil zit niet in de kwaliteit van de koppelingen. Het zit in wat er is bedacht voor het moment dat er iets misgaat. En er gaat iets mis: een dienst is even traag, een sleutel verloopt, iemand hernoemt een kolom, een bestand komt in een ander formaat binnen.
Niet elke fout verdient dezelfde reactie, en die verwarren kost tijd.
Tijdelijk. Een netwerkhapering, een dienst die kort onbereikbaar is, een limiet die net wordt geraakt. Antwoord: opnieuw proberen met oplopende wachttijd. Drie pogingen vangen het merendeel af.
Permanent op dit item. Een adres dat niet bestaat, een corrupt bestand, een leeg verplicht veld. Opnieuw proberen helpt hier nooit. Antwoord: apart zetten en doorgaan met de rest.
Structureel. De sleutel is verlopen, het schema veranderde, de dienst is gestopt. Antwoord: stoppen en iemand waarschuwen, want doorgaan maakt het erger.
Stil. Het proces meldt succes maar het resultaat klopt niet: nul rijen verwerkt, lege velden, een bedrag dat plots duizend keer zo groot is. Antwoord: controles op de uitkomst, niet op de status.
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, of boek je dezelfde betaling dubbel.
Dat regel je met een sleutel per bewerking: een uniek kenmerk dat meereist, bijvoorbeeld het ordernummer plus de naam van de stap. Voordat de stap iets doet, kijkt hij of die sleutel al verwerkt is, en zo ja slaat hij over.
Zet er bovendien een grens op. Oneindig blijven proberen betekent dat één kapotte koppeling je systeem urenlang bezet houdt en je rekening bij externe diensten laat oplopen. Zie foutafhandeling in automation pipelines.
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, en niemand kan achteraf zeggen hoeveel er weg zijn.
De veelgemaakte fout is dat die wachtrij bestaat en dat niemand hem opent. Koppel er daarom een teller aan: staan er meer items in dan afgesproken, dan gaat er een bericht uit. En zorg dat een item opnieuw aangeboden kan worden nadat de oorzaak verholpen is, want handmatig overtypen is precies de manier waarop fouten er alsnog verkeerd ingaan.
Dit is het deel dat het vaakst ontbreekt. Leg per proces een paar verwachtingen vast en laat het systeem ze toetsen.
Aantallen: er komen doorgaans tussen de tien en honderd items per dag binnen, dus nul of tienduizend is een signaal, ook zonder foutmelding. Verplichte velden: een record zonder bedrag gaat naar de wachtrij en niet door de keten. Bereik: een bedrag onder nul of boven een plafond wordt tegengehouden voordat een mens ernaar kijkt.
En de meest onderschatte: tijd. Een dagelijkse taak die om zeven uur hoort te draaien en om negen uur nog niets deed, hoort te melden. Monitoring die alleen op fouten let, ziet een proces dat helemaal niet begonnen is namelijk nooit.
Een melding vertelt wat er misging, waar, hoe vaak, en wat de eerstvolgende handeling is. Een kale technische foutregel leidt tot doorsturen en navragen.
Belangrijker nog is het onderscheid 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 dagoverzicht en houd directe meldingen voor wat werkelijk stilligt.
Foutafhandeling die nooit is uitgeprobeerd, is een aanname met code eromheen. Loop daarom voor de ingebruikname vier opzettelijke storingen door.
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. Zet de externe dienst op onbereikbaar en tel of er echt drie pogingen worden gedaan. Bied hetzelfde bericht twee keer aan en controleer of er één resultaat uitkomt.
Die vier kosten samen een uur. Herhaal ze na een grotere verbouwing, want foutafhandeling is precies het deel dat stilletjes sneuvelt terwijl het gewone geval blijft werken.
Ongeveer een derde van de bouwtijd van een pipeline. Dat voelt duur bij een proces dat in de demo prima werkte, en het is precies de reden dat het ook werkt in de week dat er iets misgaat.
Deels. Meldingen en controles zijn achteraf in te bouwen, maar het veilig kunnen herhalen van een stap raakt het ontwerp en is later duurder.
Tel een week lang wat er aan de ene kant ingaat en aan de andere kant uitkomt. Een verschil dat niemand kan verklaren, is het antwoord.
Iemand met de bevoegdheid om te handelen. Een melding naar een gedeelde postbus die niemand beheert, is geen melding.
Ja, in lichtere vorm. Zelfs een workflow van vijf stappen verdient een wachtrij en een teller. Zie n8n pipeline-architectuur.
Met de vraag welk proces het langst kan stilstaan zonder dat iemand het merkt. Dat is niet het proces dat het vaakst draait, maar het proces met de minste ogen erop. Daar hoort de eerste controle.
Wilt u weten waar uw processen stil kunnen falen, neem contact op.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056