Een zelf gehoste automatiseringsserver die maanden achterloopt, is een risico dat groeit. De procedure die wij aanhouden bij elke upgrade, en waarom je een beveiligingsmelding op het bereik toetst en niet op het versienummer.
De meest voorkomende reden dat een zelf gehoste automatiseringsserver maanden achterloopt, is angst. Er draaien workflows waar het bedrijf op leunt, updaten voelt als sleutelen aan iets dat werkt, en dus schuift het door. Tot er een beveiligingsmelding verschijnt en de sprong opeens niet meer klein is.
Die angst is terecht zolang er geen procedure is, en onnodig zodra die er wel is. Wij draaien zelf een automatiseringsserver waar klantwerkstromen op staan, en houden bij elke upgrade dezelfde volgorde aan.
Twee redenen, en de tweede weegt zwaarder dan mensen denken.
De eerste is veiligheid. Een automatiseringsserver heeft per definitie sleutels naar andere systemen: je mail, je database, je boekhouding, je CRM. Het is daarmee een van de aantrekkelijkste onderdelen van je infrastructuur, en dat is precies de reden dat er beveiligingsmeldingen voor uitkomen.
De tweede is de omvang van de sprong. Een update van twee versies is een middag met een terugvaloptie. Een update van vijftien versies is een project waarin je meerdere wijzigingen tegelijk over je heen krijgt en niet meer weet welke van de twee het probleem veroorzaakte.
Back-up eerst. Van de database en van de omgevingsvariabelen, vóór de wijziging en niet erna. En niet alleen maken: minstens één keer moet je een herstel echt geprobeerd hebben. Een back-up die nooit teruggezet is, is een aanname.
Lees de release-notes van alles ertussen. Niet alleen van de nieuwste versie. Een wijziging die jouw workflows raakt, kan in een tussenliggende versie zitten die je overslaat.
Toets een beveiligingsmelding op het bereik. Dit is de stap waar het het vaakst misgaat. Een melding noemt vaak een versie waarin het is opgelost, maar wat telt is het bereik van versies dat geraakt wordt. Er zijn meldingen die meerdere reeksen raken, en dan zegt dat ene versienummer niets over jouw situatie.
Blijf op een stabiele uitgave. Een testversie op een productiesysteem is een keuze die je precies één keer maakt.
Draai je belangrijkste workflows met de hand. Met echte gegevens, na de update, voordat je aanneemt dat het goed is. Automatische tests bestaan hier meestal niet, dus dit is de test.
Zelden de hele installatie. Wel deze vier dingen, in volgorde van hoe vaak we ze zien.
Een onderdeel dat is verdwenen of hernoemd, waardoor een workflow bij het openen een leeg blok toont. Een expressie die strenger wordt gecontroleerd dan voorheen, waardoor iets wat altijd werkte nu een foutmelding geeft. Een koppeling die opnieuw geautoriseerd moet worden. En een wijziging in de standaardwaarden, waardoor een stap zich net anders gedraagt zonder dat er iets rood kleurt.
Die laatste is de vervelendste, want hij valt in de categorie stil falen. Zie foutafhandeling in automation pipelines.
Wie workflows draait waar het bedrijf op leunt, heeft baat bij een tweede installatie waar je de update eerst op doet. Dat klinkt als dubbele kosten en is het zelden.
Zo'n omgeving hoeft namelijk niet te draaien. Je zet hem aan op de dag van de update, importeert een kopie van je belangrijkste workflows, voert de update uit, kijkt of alles nog opent en werkt, en zet hem daarna weer uit. Dat kost een uur en een paar euro aan serverkosten.
Belangrijk is wel dat die omgeving geen echte koppelingen heeft. Een testinstallatie die met dezelfde sleutels naar je productiesystemen schrijft, veroorzaakt precies de schade die je wilde voorkomen. Gebruik lege testaccounts of zet de uitgaande stappen uit.
Deze hele procedure hoort bij zelf hosten. Wie op de gehoste versie zit, krijgt updates, back-ups en beveiligingspatches inbegrepen en heeft dit artikel grotendeels niet nodig.
De redenen om toch zelf te hosten zijn reëel: gegevens die het pand niet uit mogen, veel uitvoeringen per maand, eigen uitbreidingen, of systemen die alleen binnen het eigen netwerk bereikbaar zijn. Maar reken het onderhoud dan mee in de vergelijking. Enkele uren per maand, en een half dagdeel bij een grotere sprong. Zie n8n zelf hosten of in de cloud.
Updates zijn niet het enige. Drie dingen lopen stilletjes vol of aflopen.
De uitvoeringsgeschiedenis groeit. Zonder opruimbeleid loopt op een dag de schijf vol en stopt alles tegelijk. De certificaten verlopen, meestal automatisch verlengd, maar niet als er iets in de configuratie is veranderd. En de sleutels naar externe diensten verlopen, soms zonder waarschuwing.
Zet daarom een controle op die meldt dat de installatie draait, niet alleen een controle die meldt dat er een fout was. Een server die stilstaat, meldt namelijk niets.
Een vast ritme werkt beter dan een gelegenheid. Maandelijks kijken, en bijwerken zodra er een beveiligingsmelding is die jouw bereik raakt.
Niet installeren, wel lezen. De release-notes van de tussenliggende versies vertellen waar je op moet letten.
Dan zet je de vorige versie terug en herstel je de back-up. Dat is de reden dat stap één stap één is.
Ja, en voor veel bedrijven is dat de goedkoopste vorm. Het is een paar uur per maand, en dat is lastig te organiseren als je niemand hebt die dit vaker doet.
Die staat in de beheerinterface van je installatie. Noteer hem bij elke update, samen met de datum, zodat je de sprong kunt reconstrueren als er later iets opvalt.
Met de vraag wanneer je voor het laatst een back-up hebt teruggezet. Is het antwoord nooit, dan is dat de eerste oefening, en die doe je op een kopie en niet op de productieomgeving.
Wilt u het onderhoud van uw automatiseringsserver uit handen geven, neem contact op.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056