ProRail-storing veroorzaakt door applicatie die back-up niet kon benaderen
Een applicatie die geen verbinding met een back-upsysteem kon maken was de oorzaak van de grote treinstoring waar ProRail eind juli mee te maken kreeg, zo heeft staatssecretaris Heijnen van Infrastructuur en Waterstaat laten weten. Ze stelt dat bij het gebruik van digitale systemen het onvermijdelijk is dat er soms storingen optreden.
Vanwege een ict-storing werd eind juli het treinverkeer rond Rotterdam stilgelegd, wat het treinverkeer in het westen van het land ernstig ontregelde. Via de computers van de verkeersleidingspost in Rotterdam komt belangrijke informatie binnen over onder andere de positie van de treinen in de regio Rotterdam. Door een storing in één van de systemen kon ProRail niet zien waar de treinen zich bevonden.
Het computersysteem is redundant uitgevoerd. In het geval van een storing zou ProRail op een back-upsysteem moeten kunnen terugvallen. "Helaas heeft deze back-up niet goed gefunctioneerd. Er wordt uitgebreid onderzoek gedaan naar de oorzaak hiervan, maar het lijkt erop dat dit komt vanwege een fout in de software. Meerdere systemen werkten hierdoor niet meer", aldus ProRail in een verklaring destijds.
Vanwege de storing besloot de VVD om opheldering aan Heijnen te vragen en of het klopte dat het back-upsysteem niet functioneerde. Volgens Heijnen heeft ProRail haar laten weten dat de back-up van het uitgevallen systeem functioneerde, maar dat één van de applicaties die verbinding moet maken met dat systeem niet omschakelde naar de back-up. De applicatie bleef proberen verbinding te maken met het uitgevallen systeem, wat mislukte.
"Al met al was er in de praktijk dus geen werkende terugvaloptie terwijl terugvalopties, vanzelfsprekend inclusief de omschakelfunctie, behoren te werken", merkt Heijnen op. Het treinverkeer kreeg het afgelopen jaar met meerdere storingen te maken. Al die storingen hadden echter een andere oorzaak, aldus de staatssecretaris. "Ik realiseer mij dat het voor een treinreiziger of goederenvervoerder in de praktijk geen verschil maakt dat storingen een verschillende oorzaak kennen, omdat het effect – geen treinverkeer – voor hen hetzelfde is."
Heijnen zegt dat ze in gesprek is met ProRail en NS om te kijken in hoeverre storingen in digitale systemen in het algemeen kunnen worden voorkomen en – als een storing onverhoopt toch optreedt – de impact daarvan op het treinverkeer te beperken.
Assumption is the mother of all f***ups :-)
Assumption is the mother of all f***ups :-)
Assumption is the mother of all f***ups :-)
Sinds wanneer een een back-up systeem gelijk aan een backup.
Het was beter geweest om de termen active-standby te gebruiken of redundant
Assumption is the mother of all f***ups :-)
En jij doet nu de "assumption" dat alle situaties waarin een reservesysteem nodig is te testen zijn - technische, practische, financiele of bedrijfsmatige omstandigheden kunnen het onmogelijk maken om alles mee te nemen in een test. Het is geen kwestie van "effe een testrondje", je moet de volledige ICT van een miljardenbedrijf lam leggen als je echt goed wilt testen.
Assumption is the mother of all f***ups :-)
In dit geval was dat echter het probleem niet. De fout zat ook niet in de software. Maar in te lui zijn om te testen.
Als er een toegewijde tester bij de slager binnenkomt dan moet die altijd iedereen voor laten gaan. Want dat is toch maar een dom vak.
Het klopt wel dat het relatief lang kan duren voordat een TCP sessie waarvan verkeer gedropt wordt uiteindelijk time-out .
En er is een hoop wat een applicatie _kan_ doen om voorbereid te zijn op failovers naar een ander back-end en dat niet iedere applicatie dat netjes doet .
Echter, de duur van de prorail storing was zodanig dat we echt niet meer praten over TCP timeout die met een loop een paar keer geprobeerd werd .
Mijn natte-vinger speculatie is dat één van de applicaties niet geconfigureerd was op een virtueel IP dat overgeschakeld kon worden, maar direct op het IP van één server - die uitviel.
Of misschien geconfigureerd op IP in plaats van op hostname, als men failover-op-basis-van DNS aanpassing gekozen had.
Zo'n soort scenario .
Wat er op hoger niveau duidelijk mis was : failovers moet je testen .
En dat kost inderdaad zweet en spanning de eerste keer, want grote kans _dat_ er wat vergeten is .
Het google-verhaal om in een DC gewoon her en der een rack eruit te rukken is en blijft een hoge norm.
En tijdens de storing waren er blijkbaar geen mensen die de samenhang van dat applicatie landschap goed genoeg snapten om z'n failure-to-failover snel te onderkennen en op te lossen. (of, wie weet, mochten ze het niet oplossen wegens dichtgetimmerd change proces) .,
goud dit! maar the bleeding obvious om dan dus niet het kind met de digitalisatie bad water weg te flikkeren is een denk stapje te veel gevraagd!
Echt gewoon nooit de IT oorlog meegemaakt en dabedoelikdus. Gewoon nooit getest en hoe stom wil je ze nog hebben. Je kunt het wel uit commerciële redenen gelijk uit willen rollen, maar test het dan gelijk er na! Wat da foek kost dat nou?
Nee hoor. Als de bom is afgegaan dan maken we wel een update als we tijd hebben en het nog ondersteunen. En daarnaast zijn we ISO 9001.
IT? Het is oplichting, maffia en witwassen. Het zijn allemaal muizen die met de grote Amerikaanse olifanten over een houten bruggetje lopen. En wat stampen we lekker. Daar kun je natuurlijk nooit een oorlog mee winnen. Ik ken helden uit het verleden die tegenwoordig hun brood verdienen met klanten ondersteunen om wix sites te maken. Ja. Met Wix. Zo triest is het momenteel. Alle watergeuzen zijn blijkbaar al lang dood. Want die waren niet ISO 9001 dus maar goed ook.
dat komt natuuuurlijk door mijn beperkte leefwereld, maar tegelijkertijd bespeur ik toch een hoog prutseritus gehalte her en der waarbij mensen wel kosten en moeite steken in iets dat uiteindelijk dan toch niet werkt. ja testen is belangrijk en daarbij zal het in het begin een paar keer mis gaan. je moet die kosten dus ook onderdeel van je buisness case laten zijn en goed af vragen of je niet beter af bent met dan maar een enkele storing te accepteren ooit eens in de x jaar tov die gegarandeerde storingen die je krijgt in het begin tijdens het inregelen en testen.
voorbeeldje dichtbij is een HPC cluster(tje) (waar je er dus maar eentje van hebt obviously). die moest en zou een redundante head node hebben. dat grapje heeft dat machine zeker 25k duurder gemaakt [don't ask, het gaat om 30 compute nodes maar] en een 3d interruptie (lees down tijd) opgeleverd om de zaak op te zetten. het testen zou nu moeten gaan gebeuren (maar wordt dus niet gedaan). over een jaar moet die gehele machine toch al van de CentOS 7 af EN verhuizen van DC. hier is dus geen enkele business case meer maar toch het moest en zou. het apparaat heeft dus al 5j vrolijk aangestaan met de spare head node 2j op de plank, zonder problemen, maar voor dit ene jaartje...
het had zo eenvoudig opgelost kunnen zijn door het jaartje nog even uit te zingen en dmv disaster recovery images op de 2e spare klaar in het rack up and running voor een fysieke fail over op moment dat er zich nog een storing voordoet. eenvoudig kabeltje omwisselen, of met het handje een virtueel ip nummer schakelen and bobs-your-uncle (30 min down time hooguit).
nee, de HPC moest en zou 3d plat hiervoor. en dus zoals gezegd, getest is het nog steeds niet dus maar afwachten nu he?
waanzin! misplaatste mangelment trots die de aanschaf moesten verantwoorden is hier de grondslag geweest.
dit is typerend voor veel dingen zoals het hier in NL gaat.
Assumption is the mother of all f***ups :-)
Dus jij doet de aanname dat ze niet getest hebben als dan niet geautomatiseerd of handmatig?
Waarschijnlijk doe jij nu exact hetzelfde: Assumption is the mother of all f***ups
De maatschappij wordt op een desastreuze wijze volgens sommigen opzettelijk verkl**t. Personeelstekorten, oversterfte, Informatie Gleichschaltung.
Niet de globale olifant, die overal door de porseleinkast dendert, durven of willen benoemen. Laat staan benoemen. Wanneer komen de ongemakkelijke antwoorden los?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
