image

ProRail-storing veroorzaakt door applicatie die back-up niet kon benaderen

maandag 5 september 2022, 13:42 door Redactie, 15 reacties

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.

Reacties (15)
05-09-2022, 15:48 door _Martin_
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

Assumption is the mother of all f***ups :-)
05-09-2022, 16:13 door Anoniem
Door _Martin_:
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

Assumption is the mother of all f***ups :-)
Je maakt nu toch ook een aanname, dat ze niet getest hebben!
05-09-2022, 16:23 door Anoniem
Door Anoniem:
Door _Martin_:
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

Assumption is the mother of all f***ups :-)
Je maakt nu toch ook een aanname, dat ze niet getest hebben!

Sinds wanneer een een back-up systeem gelijk aan een backup.
Het was beter geweest om de termen active-standby te gebruiken of redundant
05-09-2022, 16:27 door Anoniem
Door _Martin_:
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

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.
05-09-2022, 17:05 door Anoniem
Door Anoniem:
Door _Martin_:
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

Assumption is the mother of all f***ups :-)
Je maakt nu toch ook een aanname, dat ze niet getest hebben!
Jullie doen nu, lijkt me, de aanname dat het een back-up betreft i.p.v. een redundant systeem waarvan de failover niet gewerkt heeft.
05-09-2022, 17:20 door Anoniem
Redundante systemen goed laten werken is een uitdaging op zich, aangezien veel sw engineers geen kaas gegeten hebben van (in dit geval) de werking van TCP. Ook al is een server er niet meer, TCP reageert daar heel traag op, en als de sw engineer daar ook nog een loop omheen programmeert om het nog eens opnieuw te proberen, ja dan schiet het allemaal niet op. De bovenliggende appplicatie sw kan dan niet omschakelen want het 'hangt' onderin. Als je geduld genoeg hebt lukt het wel, maar ja tegen die tijd staan al tienduizenden reizigers in de halt.
05-09-2022, 19:06 door Anoniem
Meester In Redundancy had al lang een academische graad moeten zijn. Dat je er ook mee voor mag gaan bij de slager. Want er komt wel een Meester in Redundacy binnen!

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.
05-09-2022, 21:06 door Anoniem
Door Anoniem: Redundante systemen goed laten werken is een uitdaging op zich, aangezien veel sw engineers geen kaas gegeten hebben van (in dit geval) de werking van TCP. Ook al is een server er niet meer, TCP reageert daar heel traag op, en als de sw engineer daar ook nog een loop omheen programmeert om het nog eens opnieuw te proberen, ja dan schiet het allemaal niet op. De bovenliggende appplicatie sw kan dan niet omschakelen want het 'hangt' onderin. Als je geduld genoeg hebt lukt het wel, maar ja tegen die tijd staan al tienduizenden reizigers in de halt.
Dat is alleen onder windows.
05-09-2022, 21:12 door Anoniem
Door Anoniem: Redundante systemen goed laten werken is een uitdaging op zich, aangezien veel sw engineers geen kaas gegeten hebben van (in dit geval) de werking van TCP. Ook al is een server er niet meer, TCP reageert daar heel traag op, en als de sw engineer daar ook nog een loop omheen programmeert om het nog eens opnieuw te proberen, ja dan schiet het allemaal niet op. De bovenliggende appplicatie sw kan dan niet omschakelen want het 'hangt' onderin. Als je geduld genoeg hebt lukt het wel, maar ja tegen die tijd staan al tienduizenden reizigers in de halt.

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) .,
05-09-2022, 21:33 door Anoniem
" Ze stelt dat bij het gebruik van digitale systemen het onvermijdelijk is dat er soms storingen optreden. "


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!
05-09-2022, 21:36 door Anoniem
he he he voor die 'alles testen mensen' ... zou de NASA ook een 2e mars rover op mars hebben om even iets 'te testen'?
06-09-2022, 02:12 door Anoniem
Door Anoniem: he he he voor die 'alles testen mensen' ... zou de NASA ook een 2e mars rover op mars hebben om even iets 'te testen'?

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.
06-09-2022, 08:36 door Anoniem
ik heb menig zogenaamd redundante fail over systemen nat zien gaan precies op het moment van fail over. zeg maar daar waar ze oorspronkelijk voor opgezet waren. vooralsnog heb ikzelf geen real life situatie mee gemaakt waarin de vooropgezette kosten en complexiteit de moeite achteraf waard was.

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.
06-09-2022, 09:31 door Anoniem
Door _Martin_:
"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.
Er is een verschil tussen een back-up maken en een back-up testen zodat je zeker weet dat een back-up correct functioneert. Die fout in de software had met een testrondje (geautomatiseerd of handmatig) gewoon naar voren moeten komen. Ze hebben waarschijnlijk de aanname gedaan dat het wel zou werken.

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
06-09-2022, 10:14 door Anoniem
De analoge wereld laat het afweten en dan is het digitaal ook niet te redden.

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?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.