Kort svar: Automatiseringer fejler sjældent på teknikken – de fejler på de manglende sikkerhedsnet. De syv historier her (alle genkendelige fra virkelighedens webshops og bureauer) koger ned til fem net, ethvert flow bør have: idempotens (samme hændelse må aldrig udløse dobbelt handling), opsamlings-tjek (mål resultatet, ikke kørslen), dead man’s switch (alarm når flowet UDEBLIVER), mindste privilegium (nøgler og adgange kan højst gøre det nødvendige) og backup + dry-run før alt, der skriver. Læs historierne, og tæl selv, hvor mange af nettene dine flows har – de fleste finder huller.
Denne hub har handlet om alt det, automatisering KAN. Denne sidste artikel handler om det, den også kan: gå galt – hurtigt, stille og i skala. Historierne er anonymiserede sammenfatninger af klassiske forløb, som enhver, der drifter integrationer, før eller siden møder varianter af. Pointen er ikke skadefryd, men mønstergenkendelse: hver historie mangler præcis ÉT sikkerhedsnet – og alle fem net er billige at spænde ud, FØR man har brug for dem.
1) Mail-løkken. Et flow sendte en bekræftelsesmail, når en ordre blev OPDATERET – og mailsystemet skrev et lille felt tilbage på ordren, hvilket… opdaterede ordren. Kunderne fik beskeden igen. Og igen – op mod hundrede gange, før nogen så det. Nettet, der manglede: idempotens og løkke-værn. Flows, der kan udløse deres egen trigger, skal mærke deres handlinger („er beskeden for denne hændelse allerede sendt? Så stop“) – og vælge smallere triggere („status ændret til gennemført“ frem for „ordre opdateret“). 2) Dobbeltoprettelsen. Under en migrering kørte både gammelt og nyt bogføringsflow i tre dage – alt salg bogført to gange, opdaget ved momsafstemningen. Nettet: én klar ejer pr. opgave under overgange (parallel-kørsel er til at SAMMENLIGNE, ikke til at lade begge handle – jf. migreringsguiden) – plus dedup-tjek på ordrenummer i alt, der opretter.
3) Valuta-importen. En leverandør ændrede sit feed fra kroner til euro uden varsel. Import-flowet kørte grønt hver nat – og satte i to uger indkøbspriser, der var 7,5 gange for lave, hvilket prisreglerne loyalt omsatte til udsalgspriser med negativ margin. Bestsellerne SOLGTE fantastisk. Nettet: opsamlings-tjek og bremseregler – mål på resultatet („er nogen pris ændret mere end X %? Sæt varen på pause til manuelt blik“), som beskrevet i feed-guiden. 4) Den døde webhook. Efter en række timeouts deaktiverede WooCommerce stille en webhook – og lagersystemet fik ingen salg i tre uger. Først da oversalgene begyndte, gravede nogen. Nettet: dead man’s switch – flowet, der IKKE kører, sender ingen fejl; kun udeblevne heartbeats afslører det (overvågningsguiden viser hvordan).
5) Autosvaret på klagen. En skabelon-besked („tak for din henvendelse! Se vores FAQ …“) blev sendt til en kunde, hvis pakke var blevet væk for anden gang – kunden skrev en anmeldelse med skærmbillede af svaret. Nettet: følelses-filteret – klager og skuffelser skal rutes til mennesker, altid (kundeservice-guiden tegner grænsen). 6) Nøglen i repo’et. En udvikler committede et hjælpescript – med en skrivedygtig API-nøgle – til et offentligt kodearkiv. Automatiske scannere fandt den på minutter; heldigvis var det en læsenøgle… nej, det var det ikke. Nettet: mindste privilegium og opbevaringsdisciplin fra nøgleguiden – og hurtig rotation som beredskab. 7) Oprydningsscriptet. Et script, der skulle slette gamle kladder, matchede bredere end tænkt og tog også ti rigtige sider. Ingen dry-run, ingen frisk backup – to timers genskabelse fra cache-kopier. Nettet: backup før alt, der skriver – og én testkørsel, der VISER, hvad der rammes, før noget rammes.
Læg historierne ved siden af hinanden, og mønstret står klart: ingen af dem skyldtes dårlig teknik – alle skyldtes et manglende net, der kunne være sat op på minutter. Derfor tjeklisten til HVERT flow, der sættes i drift: 1) Kan samme hændelse udløse dobbelt handling – og er der værn? 2) Måles der på RESULTATET (opsamlings-tjek), eller kun på grønne kørsler? 3) Opdages det, hvis flowet slet ikke kører? 4) Kan flowets nøgler højst gøre det nødvendige? 5) Er der backup og testkørsel før alt, der skriver eller sletter? Fem spørgsmål, to minutter – gør dem til fast del af jeres flow-dokumentation, så arver hvert nyt flow disciplinen automatisk. Automatisering uden sikkerhedsnet er bare fejl med motor på; med nettene er den det stærkeste værktøj, en lille forretning kan give sig selv – og på en stabil bund som Hostious’ WooCommerce-hosting er infrastrukturen i det mindste aldrig det svage led.
Den stille: flowet, der holder op med at køre (eller kører med forkerte data), uden at nogen får besked. Derfor er dead man’s switch og opsamlings-tjek de to net med størst effekt.
Med testdata gennem alle grene (også fejlgrenene), en dry-run af alt, der skriver – og et bevidst fremprovokeret fejlscenarie: hvad sker der, når API’et svarer 500? Får nogen besked?
Skalér efter konsekvens: notifikations-flows kan nøjes med fejlbesked, mens alt, der rører penge, lager eller kundedata, bør have hele sættet. Spørgsmålet „hvad koster det, hvis dette kører forkert i en uge?“ sætter niveauet.
