ProRail: overschakeling naar backupsysteem mislukte

ProRail stelt dat de storing die donderdagochtend het treinverkeer in een groot deel van de Randstad onmogelijk maakte, is veroorzaakt doordat een computersysteem uitviel en de automatische overschakeling op een backupsysteem faalde.

Donderdag vielen volgens ProRail de systemen uit waarmee de wissels en seinen in en rond Amsterdam worden bediend. Hierdoor stond het treinverkeer in de ochtendspits in een groot deel van de Randstad stil. Spoorbeheerder ProRail heeft inmiddels in een verklaring laten weten dat er bij het opstarten van de treindienst om 4:30 uur bij een systeem op de verkeersleidingspost Amsterdam een storing optrad. Hierdoor was ProRail genoodzaakt om over te schakelen op een backupsysteem, maar dit mislukte waardoor de wissels en seinen nog steeds niet te bedienen waren.

Volgens ProRail gaat het om een softwarefout in de 'schakelsoftware' waardoor de seinen en wissels in en rond Amsterdam niet bediend konden worden. Om 8:40 uur werd het probleem verholpen, waarna het treinverkeer langzaam weer op gang kwam. ProRail stelt verder dat het inmiddels bij andere verkeersleidingsposten heeft gecontroleerd of dezelfde softwarefout zou kunnen optreden. De spoorbeheerder stelt dat deze fout niet opnieuw is geconstateerd.

Reacties (153)

Mijn ouders werken beide bij de NS, en de praatjes over een backup systeem zijn grote kletskoek. Deze bestaat namelijk niet eens. ProRail heeft geen backup systeem. Dit feit is al vaker door personeel aangehaald maar ze weigeren te investeren.

Heel droevig natuurlijk. De waarheid achter dit achterlijke falen komt zelfs mijn ouders niet tegemoet .

Daarbij klopt het verhaal ook niet. De automatische overschakeling naar het niet bestaande backup systeem "mislukte". Waarom zou dit "backup" systeem dan niet handmatig ingeschakeld kunnen worden?

[Reactie gewijzigd door rickyy op 22 maart 2012 19:26]

Vraag ik me af wie verantwoordelijk is voor het systeem. Zo word bij de NMBS gebruik gemaakts van het EBP systeem van Siemens, ik vermoed dan ook dat het bij ons Siemens is die instaat voor de praktische uitwerking en onderhoud. Uiteraard is de klant koning, maar als leverancier van een systeem moet je ook durven zeggen wanneer klanten dom bezig zijn.

Bij ProRail zijn ook dergelijke systemen te vinden. Op de site van sporenplan is er het een en ander aan achtergrondinformatie over de beveiligingssystemen en verkeersleidingssystemen die in het verleden en heden gebruikt wordt. Het verhaal is wel inmiddels wat gedateerd omdat er een modernisering gaande is waarbij systemen zoals BEPAC voor de ouderwetse CTA's, etc wordt uitgefaseerd.

Dat het nu juist in de nacht verkeerd gaat is ook niet onverklaarbaar. In de nachtelijke uren worden nog wel eens werkzaamheden verricht waarbij ook beveiligingssystemen of wissels worden aangepast. Daarvoor is het zo nu en dan noodzakelijk de software van de bediening aan te passen, zodat de situatie op het scherm van de verkeersleider klopt met de situatie buiten. Ook de software in de onderliggende systemen moet vanzelfsprekend voor dit soort zaken geupdated worden. Het zou mij niet verbazen dat er iets verkeerd is gegaan, waardoor deze ellende is ontstaan en dat men de ellende niet kon terugdraaien voor het begin van de ochtendspits.

Dan praten jouw ouders denk ik grotere kletskoek want de systemen van ProRail zijn zeer zeker redunant uitgevoerd op een Post.

Deze systemen draaien allemaal op een High-Available cluster waardoor er dus minimaal meerdere nodes zijn waarop de software kan draaien.

[Reactie gewijzigd door Gehakt op 22 maart 2012 20:14]

Oh zeker hebben ze backup... maar ja, wat is backup. Redundante systemen in dezelfde post... ja dat merkten ze in Utrecht, de een moet ontruimt worden door rook en, tja, dan is de backup in hetzelfde gebouw niet echt handig.

ProRail is een grote faal club, dit is al de zoveelste keer dat ze falen. En het is niet alsof die mooie nieuwe borden die niet te lezen zijn in zonlicht het beter doen. Op Amsterdam zijn ze op spoor 4/5 al weer weken kapot, zelfde op Utrecht. Maar ja, het moest zo nodig anders.

De nieuwe treinen staan ook meer kapot dan dat ze rijden.

En tja ,als de backup moet werken, dan doet hij het weer eens niet.

Maar jij weet zeker dat het allemaal wel werkte, iedereen heeft gewoon gedroomd dat het hele land weer eens last had van de slapstick die zich NS/ProRail noemt.

Ik zeg niet dat niemand er last van gehad heeft. En systemen High-Available uitvoeren zoals op een Post voldoet voor heel veel gevallen. Het opzetten van een disaster tolerant (waar je op uitkomt als het dus niet op dezelfde locatie mag) cluster voor alle systemen lijkt me ondoenelijk voor een dergelijke organisatie.

Ik ben benieuwd of we eigenlijk wel Disaster Tolerant systemen hebben in ons kleine Nederland.

Utrecht heeft in theorie een fail-over post, maar ook die faalde (kon 't niet overnemen van Amsterdam).

Ik ben benieuwd of we eigenlijk wel Disaster Tolerant systemen hebben in ons kleine Nederland

Ik zou hopen dat de luchtverkeerleiding wel zo uitgevoerd is.
Ook defensie informatiesystemen zullen zo opgezet zijn.

Verder zal bijvoorbeeld het SVB ook wel zoiets hebben want je wilt niet dat de AOW van 2,5 miljoen ouderen ineens niet meer uitgekeerd kan worden na een brandje.

Ik vraag mij af wat jouw ouders doen bij NS dan, als je zegt dat er geen backup systemen zijn. Het feit dat je aangeeft niet te weten waarom het backup systeem niet ingeschakeld kan worden geeft aan dat je ouders wellicht niet op de juiste plek binnen NS zitten om te weten wat er echt aan de hand was. Anders had je die vraag ook niet hoeven stellen. De juiste redenen heb ik bij iemand anders al verdekt ingekleed zien staan.

Mijn ouders werken beide bij de NS, en de praatjes over een backup systeem zijn grote kletskoek. Deze bestaat namelijk niet eens. ProRail heeft geen backup systeem. Dit feit is al vaker door personeel aangehaald maar ze weigeren te investeren.

Dan voorspel ik je dat dit morgen dik in de krant staat. En dat er een minister moet aftreden, en dat als je ouders daarvoor uitkomen meteen voor de klokkeluidersregeling (klokkenluidersregeling ??) in aanmerking komen.

Ik denk echter dat je je ouders niet helemaal heb begrepen of dat ze niet erg op de hoogte zijn. Er is zeker wel een backup, die werkte helaas niet. Dat is erg genoeg, niet nodig om meteen je ouders er bij de haren bij te slepen.

Wat weet de conducteur (nu chargeer ik...) nu van de IT-systemen bij ProRail, behalve dan 'van horen zeggen'?

In welke functie werken jouw ouders bij de NS? En welk inzicht hebben ze daarbij in de processen van ProRail? Zoals het er nu staat lijken het me geen betrouwbare bronnen.

(NB: Ik had eenzelfde reactie van Pogostokje 20:25 over het hoofd gezien.)

[Reactie gewijzigd door Kalief op 22 maart 2012 22:07]

Ja, dat heb ik eerder gehoord. Ik dacht dat het inmiddels algemeen bekend was. Het is volgens mij al eens eerder gebeurd.

Gevonden: NS verkeersleiding heeft geen backup
Geen idee of dit hetzelfde systeem is.

Je moet twee zaken hier uit elkaar trekken. In het artikel waar jij aan refereert wordt gesproken over een off-site backup op het moment dat de verkeerscentrale in de fik vliegt, zoals in Utrecht een tijdje geleden is gebeurd. Dat wil niet zeggen dat er geen backup systeem op locatie aanwezig is. Volgens mij is van off-site backup geen sprake, maar wel van backup op locatie. Kun je nog steeds afvragen of dat wenselijk is, maar daar hangt ook een enorm prijskaartje aan vast gezien de complexiteit van de systemen. Het is mijns inziens weer een broodje aap verhaal van die backup die er niet zou zijn, die door iemand zonder goede kennis van zaken de wereld in is geholpen.

Nooit in geinvesteerd of sinds de brand in de enige serverruimte een aantal jaar terug niet meer?

Ik heb vanmorgen weer genoeg gelezen over de NS op social media. Allemaal een beetje sarcastische reacties over de NS. Maar eigenlijk is het diep en diep triest dat wij in Nederland, een land met een van de beste infrastructuren ter wereld, niet eens fatsoenlijk de treinen kunnen laten rijden. Valt er een mm sneeuw, dan ligt het treinverkeer plat. Waait het te hard en vallen er teveel bladeren op het spoor, dan rijden de treinen weer niet. En dan nu valt een systeem uit en dan doet je back-up systeem het niet. Ik kan niet anders concluderen dat het echt heel amateuristisch overkomt.

Gelukkig heb ik geen last van alle problemen met het OV, maar volgend jaar als ik studeer zal ik hier ook mee te maken hebben. Hopelijk gaat de NS eens nadenken en gewoon logische dingen doen. Dat betekent, test eerst een systeem uitvoerig, voordat je het gaat gebruiken. Nu is er maandelijks wel weer een probleem met het OV. Als reputatie-behoud gaan ze dan soms gratis koffie uitdelen, maar mensen willen gewoon precies weten wanneer een trein rijdt en dan ook werkelijk op die tijd worden afgeleverd. Daarmee zorgen ze voor een goed imago, niet met steeds die slappe het-spijt-ons acties.

Het is grappig hoe het werkelijk nooit goed genoeg is

De NS is een van de stiptste treindienstverleners ter wereld (die link is van 2008, inmiddels is het nog beter). Gecorrigeerd voor ons relatief drukke spoor is het zelfs het op één na meest stipte ter wereld, met enkel japan als betere. Als één organisatie in de wereld het helemaal voor elkaar heeft, is NS het wel.

Ook op het gebied van dienstverlening, veiligheid, materieel en uitstraling doet de NS het vrij geweldig internationaal gezien. Er is gewoon geen statistiek of ander bewijsmateriaal om ook maar één van de azijnpissers hier in de comments gelijk te geven.

Prorail is een ander verhaal, hoewel ook Prorail het internationaal gezien behoorlijk goed doet.

In het algemeen kun je gewoon geen blanket statement maken dat NS of Prorail altijd een slechte organisatie zijn en het nooit goed doen, en dat dat de oorzaak is van dit falen, ofzo. Dat is gewoon bewijsbaar onjuist en meegaan in de automatische reactie om elk falen van de spoorwegmaatschappijen groots uit te lichten. Je hebt geen flauw idee hoe goed we het hier hebben.

De NS is een van de stiptste treindienstverleners ter wereld (die link is van 2008, inmiddels is het nog beter

Je hebt gelijk dat er iets te veel over de NS gezeurd wordt, maar toch wil ik je nuanceren: die cijfers zijn niet zaligmakend.

Sinds de NS wordt afgerekend op vertragingen worden treinen die een bepaalde hoeveelheid vertraging oplopen gewoon uit de dienstregeling genomen. Dan zijn ze uitgevallen en niet vertraagd. Verdwijnen ze uit de statistieken.(Overigens hebben ze sinds 2010 ook hun vertragingsnorm versoepeld van 3 naar 5 minuten. Was ook goed voor de cijfers, helemaal omdat de meetpunten *buiten* de stations liggen. Vaak moet een trein nog even wachten voordat het een station kan binnenrijden.)

Daaarnaast: een forens heeft niks aan het feit dat op een dag statistisch gezien 95% van de treinen goed op tijd rijden. Die zit namelijk in de trein in de spits, wanneer de problemen het grootst zijn, vanwege de drukte.

Wat de NS zou moeten meten is hoeveel _reizigers_ op tijd zijn, niet hoeveel treinen. Ik geloof namelijk best dat de zondagse boemel tussen Beek-Elslo en Bunde altijd prima op tijd is. Maar hoe weegt dat op tegen kwartier vertraging tussen Utrecht en Amsterdam in de maandagochtendspits?

[Reactie gewijzigd door Keypunchie op 22 maart 2012 21:53]

Ik denk dat het 'nooit genoeg zijn' meer te maken heeft met de vaak zeer gebrekkige reisinformatie en het feit dat een storing 's morgens tot en met de laatste trein van die dag door werkt.

Daarnaast als je de klantgerichtheid van het personeel vergelijkt met andere landen, bijvoorbeeld Duitsland, dan vind ik de dienstverlening en uitstraling juist zeer matig. In Duitsland worden ALTIJD alle overstaps omgeroepen en wordt je keurige geïnformeerd over vertragingen en oplossingen. Hier maakt (een deel van) het personeel zich er wel heel makkelijk vanaf.

En het back-up systeem van het back-up systeem dan? Of was dat alweer te ver gedacht...

Waarschijnlijk zou het slimmer zijn als te testen of het eerste backup systeem überhaupt werkt. Een softwarefout komt er niet ineens vanzelf in. Als ze in plaats van een backup systeem twee live systemen hadden die ze om en om gebruikte, of de backup bv. elke zondag gebruikte, wisten ze al veel langer dat er "iets" mis was met hun backup systeem en hoefde de boel op een normale werkdag niet 's morgens vroeg tijdens de spits eruit te liggen.

Waarschijnlijk zou het slimmer zijn als te testen of het eerste backup systeem überhaupt werkt. Een softwarefout komt er niet ineens vanzelf in.

Nee maar hoeft ook niet bij grote testen naar voren te komen, pas bij tientallen van deze systeem jaar lang gebruiken kan een bepaalde situatie voordoet bij een van de systemen dat deze fout ineens een probleem word waar het rest van jaar wel gewoon werkte.

Kan me niet indenken dat ze er niet neerzetten en aansluiten en nooit getest hebben.

[Reactie gewijzigd door mad_max234 op 22 maart 2012 19:35]

Je hebt het wel over ProRail. Het bedrijf dat o.a. dit soort fouten maakt.

ja... ik werk ook bij een groot bedrijf en gisteravond waren er router upgrades en toen werkte alles, maar vanmorgen werkte dus niks meer! Net of het alleen aan ProRail ligt.

Het probleem is meer dat als er iets fout gaat er vaak een kettingreactie optreed bij de NS/ProRail. En dat meerdere mensen van meerdere (grote) bedrijven daar last van ondervinden. Voor één bedrijf valt het nog wel te managen maar er ontstaat een te grote chaos die meerdere delen van het land beinvloeden.

Zie:

• taxi-chauffeurs met verhoogde tarrieven,
• Mensen die hun vliegtuig missen.
• Mensen die te laat / niet op hun werk aankomen.

Mocht er overmacht zijn zoals een stroomstoring dan is dat weer anders daar valt vaak weinig aan te doen, net als updates van routers waardoor die niet meer (goed) werken, zelfs na testen.

Extreme drukte op een ServiceDesk omdat iedereen via een Remote verbinding gaat werken. SLA was flink gedropt daardoor

Maar er was neem ik aan een goed roll-back plan zodat het met minimale tijd hersteld kon worden?? Fouten maak je altijd. Het gaat erom hoe je hersteld en wat je er aan doet om ze in de toekomst tegen te gaan.

Zo joh.. 4 jaar geleden hebben zijn ze onhandig geweest. Je hebt geen flauw idee waar je over praat. De uitdaging die ProRail moet aanpakken is van een andere orde dan de gemiddelde kantoor systeem beheerder die hier op tweakers rondhangt.

Al heb ik geen kennis van de betroken systemen, het automatisch overschakelen naar een backupsysteem klinkt als een geclusterde oplossing. Als het goed is wordt dan voor updates en onderhoud de service van node gewisseld. En dan is die failover ineens getest.
Er zijn natuurlijk issues mogelijk bij een failover of er kunnen zelfs fouten in de configuratie zitten zodat een spof ontstaat, toch is mijn persoonlijke ervaring dat een cluster dat de mist ingaat met een configuratie te maken heeft, in het os, drivers, cluster, san, netwerk, sofwtare... allemaal dingen die testbaar zijn, maar handenvol resources kosten om dat ook effectief te doen. Vaak wordt dan gekozen om 'gecertifieerde' componenten dmv 'best practices' te installeren/onderhouden om al te veel testen te kunnen uitluiten.
Wat ook kan meespelen is dat bij niet-it bedrijven vaak 'handen af, dat is een kritisch systeem' telt. Dus failovers testen door kabeltjes/hardware los te halen: dat is er niet bij. Bovendien is het lang niet zeker dat een goede testomgeving bestaat waar dat wél kan.

Uit ervaring kan ik zeggen dat ondanks uitgebreid testen geen enkel systeem volledig foutloos is. Vaak is het een bizarre combinatie van factoren die niemand heeft voorzien bij het opstellen van de testspecs.

zeker; vaak wordt het probleem met bijvoorbeeld drivers en specifieke software pas ontdekt als het eens is foutgegaan... en dat is niet eens zoooo erg, als het probleem erna ook werkelijk is of wordt opgelost!
Elke failure hoort een wijze les te zijn!

Ik ben wel eens bij PR langs geweest en daar stond een 3 uit 4 systeem. Ieder individueel systeem was op zich uitgevoerd met raid (dacht 2) schijven. Elk bitje werd 8 keer weg geschreven. De politiek had alleen bedacht dat het te duur was om de systemen op verschillende locaties te plaatsen

Is software ontwikkeling is volgens mij het schrijven van een test minimaal net zo lastig als het schrijven van kwalitatieve code. Het lastige van testen is dus het bepalen van de test, verder kan je natuurlijk ook geen toekomstige mutaties (in ieder element van het systeem) testen. Test-driven development zou hierin veel moeten oplossen (http://nl.wikipedia.org/wiki/Test-driven_development), dat betekend onder andere dat je de tests al schrijft VOORDAT je uberhaubt code gaat schrijven.

[Reactie gewijzigd door DutchStoner op 22 maart 2012 21:40]

Leuk verhaal, maar denk maar niet dat de stereo type Indiër of wat mij betreft ongeïnteresseerde lokale programmeur zich daar ook allemaal wat van aantrekt.

Tel daar nog een manager bij op die geen enkele boodschap heeft aan concerns die developers uitten (het werkt toch immers, wat zeuren die gekke nerds nou?), en ik ben eigenlijk veel meer verbaast dat het niet veel en veel vaker fout gaat dan deze ene keer.

Lekker negatief beeld. Er zijn wel degelijk bedrijven die dit goed aanpakken, en ook managers die heel goed begrijpen wat de risico's van niet genoeg (unit-)testen zijn. Die komen alleen niet in het nieuws, omdat ze hun werk goed doen ;-)

Natuurlijk zijn er ook tal van bedrijven waar de mensen wel gewoon serieus met hun vak bezig zijn. Want daar komt het eigenlijk telkens op neer, gewoon je vak serieus nemen en het niet als veredelt tijdverdrijf zien.

Ik zeg ook zeker niet dat iedereen het fout doet, maar dat er een trend is naar alles steeds goedkoper en goedkoper willen (zie de hele reden voor India outsourcing) en 1 van de aspecten wat het goedkoop maakt is dingen laten zitten die niet direct zichtbaar zijn.

Van wat ik uit het artikel begrijp ging het om het overschakelen op het backup-systeem, niet om het backup-systeem zelf. Schakelen tussen 2 systemen is niet zo eenvoudig, ten eerste moet je de fout detecteren en doorhebben dat het aan het systeem ligt, ten tweede moet je alle state-informatie overzetten naar het backup-systeem, en vervolgens moet het backup-systeem gestart worden en niet in dezelfde fout trappen als het eerste systeem.

Dit zijn allemaal stappen waarbij het mis kan gaan.

Of gewoon de hele boel op een omgeving draaien waar je echt zeker bent dat je Business Critical Applicaties up en running zullen zijn.
Dus, waarom draait de applicatie die het openbare verkeer moet leiden niet gewoon in een (semi)sysplex mainframe omgeving?
Daar heb je zekerheid, ze leven daar voor de redundantie en leren je de 80/20 regel.
80 % van de code dient voor foutafhandeling, 20% voor als alles goed loopt, op die manier kom je nooit voor verrassingen te staan...

Waarom zit jij niet op een semisysplex mainframeomgeving? Het is gewoon te duur, daarom - een halve dag downtime in X jaar is acceptabel, lijkt me.

Het bedrijf waar ik op dit moment stage loop werkt met een (koude) sysplex z196 omgeving.
(dus 2 z196 IBM mainframes die up en running zijn, beide met eigen taken maar waar de taken van de andere machine klaar staan, en moesten zich een incident voordoen op de 1,e start de andere gewoon alles wat de andere running had direct door)

Ze bieden ook aan tal van bedrijven mainframe services aan, en hoewel hier en daar bedrijven van een eigen mainframe afstappen, zijn er genoeg die zoeken naar een gedeelde (optimaal gebruikte) oplossing.

Over "te duur", wat die beestjes draaien is altijd up-and-running, kost minder aan onderhoudspersoneel en plaats plus de TCO is vaak lager dan een equivalent aan open-systemen dat nodig is voor gelijkaardige taken.

Ook is er met zBX een manier om je blades aan de durability, flexibiliteit en workload management van een mainframe te koppelen,...

Ik zeg niet dat het voor elk bedrijf is, want dat is het natuurlijk niet, maar voor grote en/of belangrijke bedrijven die "kritische services" leveren in onze maatschappij is het in mijn ogen zeker geen overbodige luxe.

[Reactie gewijzigd door -ETz-candyman op 22 maart 2012 20:14]

En toen zat er een fout in de software die erop draait, en dezelfde fout zit (uiteraard) ook in je backupsstemen. Dan kun je 100'den backups hebben, als er een fout in de software zit die tot nog toe niet ontdekt is (race-conditie etc) dan kun je zoveel in HA hardware stoppen als je kan, maar dan ga je alsnog down.

Om het eenvoudig uit te leggen: op een z/OS mainframe draai je de (belangrijke) software via CICS of IMS, deze verwerken alles via transacties, volgens het ACID principe, dat systeem moet ik je vast niet uitleggen aangezien ik zie dat je MySQL expert bent.

Door het 80/20 systeem is de kans dat er een fout zich voor zou doen die niet gecatched is minimaal - en zelfs dan als het fout gaat in de software, dan zal het systeem dit merken en de software/transactie minstens 2 maal herpakken, maar de rest van de infrastructuur zal gewoon verder doen.
Komt de fout van een 'berekeningsfout' in de CPU? Geen probleem, want alles loopt tegelijk over verschillende CPUs om dit soort fouten te detecteren, en een falende CPU zal uitgeschakeld worden en door één van de spare processors vervangen worden, on the fly.

Daarmee vang je al een heleboel fouten af ja, maar nog steeds kun je plat gaan door een softwarefout.

Ik noem maar een hele simpele: een stuk software dat 29-feb niet kent, en daarom faalt. Dan kunnen alle berekeningen nog zo goed gaan, en alle hardware is prima, maar toch lukt het je niet om je omzet voor die dag te berekenen (ik noem maar wat).

En als de software 2 * 3 doet in plaats van 2 + 3 dan is gaat alles goed op die systemen, maar je krijgt wel een foute uitkomst, want zo'n systeem kan nog steeds niet de intentie van het programma analyseren en daarop programmeerfouten aanpassen.

Als het inderdaad zo'n soort fout is, dan komt dat ook aan het licht normaal, als je goeie development methoden gebruikt:
gebruik van 'testen' tijdens het programmeren is toch wel de standaard. Daar zou zeker de fout van 29 feb uit moeten komen.
Verder kan je bij uitrollen van updates via Development -> Test -> Production structuur of iets dergelijks werken. Waar Test een (gedeeltelijke) kopie is van de Productie omgeving. Hierbij moet de business goedkeuren wat in test draait alvorens naar production te migreren. (dan zou die 2 * 3 ipv 2 + 3 echt wel al boven moeten gekomen zijn)

Moest er om onverklaarbare reden dit soort slechte code toch in productie omgeving geraken is er nog een Emergency stap voorzien, waar je direct een hot-fix naar Production kan pushen.

[Reactie gewijzigd door -ETz-candyman op 22 maart 2012 21:47]

Als je niet verwacht tegen een datum/tijd issue te lopen (je hebt immers die ene geniale library gebruikt ) en niet toevallig op 29/02 test of deployed... dan gaat het toch fout en is je hele redundante systeem naar de maan.
Ik hecht sterk geloof in de technologie die je voorstaat, maar je moet opletten met iets 'onfeilbaar' te noemen. Vergeet niet dat al die geniale systemen door mensen gebouwd zijn en door mensen bediend worden!

Een onfeilbaar systeem is zoals een onzinkbaar schip

De systemen die prorail inzet zijn complexer dan wat je hierboven beschrijft. Het systeem wat ik gezien had, gebruikte niet 2 maar 4 parallel werkende systemen.

Het wordt al minder snel acceptabel als duizenden mensen afhankelijk zijn van de correcte werking van je systeem, lijkt me.

Er zijn miljoenen mensen afhankelijk van 'het systeem', alsof dat correct werkt

En zo'n sysplex mainframe is ook helemaal niet zo faalproof.. Je bent NOOIT! zeker dat je business cirital applicaties 100% up en running zijn, als jij denkt dat dat wel kan, dan ben je zeer naief... Je kunt het minimaliseren, maar je kunt het nooit uitsluiten...

Dus, waarom draait de applicatie die het openbare verkeer moet leiden niet gewoon in een (semi)sysplex mainframe omgeving?

ProRail werkt op DEC systemen, niet IBM.

(Ja, in 2012 komt VMS van HP, maar ProRail leeft nog in de vorige eeuw)

Wel zeer betrouwbaar.
een open VMS systeem kun je redelijk makkelijk een paar jaar aan 1 stuk in de lucht houden. Zeker als je een Alpha met hot swappable CPU's erin heb hanngen

Zouden ze serieus nog op die oude Microvaxen draaien? Nee toch, das toch alleen NT geworden?

Testen van failover en failback... is hier niet gebeurd waarschijnlijk.

Het testen van de redundante systemen wordt regelmatig uitgevoerd hoor!

Het probleem zat ook niet in het redundante systeem, maar in de software die bepaalt welk systeem actief / master is en dus actief de seinen en wissels bestuurd.

Irritant zo'n bug die het correct omschakelen voorkomt, maar de overige systemen hadden deze bug dus blijkbaar niet. Moet dus iets speciaals zijn geweest in Amsterdam.

Te makkelijk. Ga er maar vanuit dat het wel getest is, maar dat niet alle mogelijk foutsituaties zijn voorzien.

Heel veel voorkomend probleem: de fallback/backup nooit testen, totdat je hem daadwerkelijk nodig hebt.

En dan blijkt dat hij al heel lang stuk is.

Zelfde geldt voor kritieke data backups maken. Als je pas wanneer je uit nood een restore moet maken erachter komt dat de backup niet goed is, dan ben je zuur.

Voor kleinere organisaties, met minder kritische systemen is dat uit kostenperspectief te vergoelijken.

Bij een organisatie die zulke kritieke infrastructuur aanstuurt, waar zoveel miljoenen aan economische omzet mee gemoeid zijn, als ProRail is er maar 1 woord voor: Schandalig.

Maar goed, dat de zaakjes op het spoor niet op orde zijn hebben we van de winter gezien. Enige voordeel vandaag was voor forensen van/naar Amsterdam dat ze tenminste nog een terrasdag cadeau kregen, in plaats van dood te vriezen op een perron.

[Reactie gewijzigd door Keypunchie op 22 maart 2012 19:20]

Zo'n storing kan nog een keer gebeuren. Het is vervelend en zeker de reden daarvoor is stom maar ala, helaas. Wat ik echt schandalig vond is dat de NS weigerde bussen in te zetten. Er waren blijkbaar niet genoeg bussen om iedereen te kunnen vervoeren dus heeft de NS helemaal geen bussen ingezet. Ook zouden de bussen anders vast komen te zitten in de files.
Tevens heeft de NS besloten om niet aan te kondigen wanneer er wel een trein of bus vertrok om een grote stormloop te voorkomen. Dat is pas service van 0,0. En gezien de meeste mensen geen alternatief hebben komen ze er nog mee weg ook.

Je kunt natuurlijk ook overdrijven. Het is SPITS, dus iedereen is onderweg. Je kunt dan niet zomaar even een blikje bussen opentrekken om iedereen mee te vervoeren. Dat gaat op zich voor één of twee lijnen, maar niet voor al het verkeer rond Amsterdam.
Ik snap best dat ze dat dan ook niet gaan proberen, want a)er zijn niet genoeg bussen b)die bussen komen is druk verkeer en c)aangezien er te weinig bussen zijn wordt het chaos
Het grappige is dan dat áls ze dat gedaan zouden hebben, het ook weer niet goed zou zijn omdat het helemaal in het honderd liep. Het is dus niet goed of het deugt niet.

disclaimer: ik ben geen OV fan, geen NS medewerker. Ik heb zelfs een hekel aan OV, maar sommige dingen vergen gewoon een beetje gezond verstand. Soms gaan dingen gewoon niet. Klaar.

Je kunt natuurlijk ook overdrijven. Het is SPITS, dus iedereen is onderweg. Je kunt dan niet zomaar even een blikje bussen opentrekken om iedereen mee te vervoeren.

Om het treinverkeer te vervangen heb je ongeveer 5000 bussen met 5000 chauffeurs nodig. De gemiddelde reistijd is dan 75% langer dan per trein. We hebben de bussen en de mensen niet.

[...]


Om het treinverkeer te vervangen heb je ongeveer 5000 bussen met 5000 chauffeurs nodig. De gemiddelde reistijd is dan 75% langer dan per trein. We hebben de bussen en de mensen niet.

en de bandbreedte op de weg ook niet.

Daarom moet je dat ook minimaal 1x in de 6 maanden testen of het wel werkt, of de backupservers nog wel staan waar ze zouden moeten staan etc. etc. Dat heet een business continuity plan en wordt door veel bedrijven als een noodzakelijk (duur) kwaad gezien. Echter de afhankelijkheid van IT is dusdanig hoog bij zoveel bedrijven dat je het onder hand wel wettelijk verplicht mag stellen iets wat voor financiele instellingen ook geldt.

nee, bij de meeste bedrijven wordt het enkel als een duur kwaad gezien, niet als noodzakelijk.

helaas

In het geval van de NS is het geen "duur" kwaad,
wat nu is gebeurt kost vele malen meer dan 3 backup-systemen.

Prorail, niet NS.

Boeit voor de reiziger niet zoveel. Die rekent op de NS om van A naar B te komen. Welke toeleveranciers de NS gebruikt moet voor de reiziger niets uitmaken. Desnoods klimt de reiziger op de rug van de topman om vervoerd te worden maar steeds dat afschuiven naar Prorail is te makkelijk. Prorayl was ooit gewoon onderdeel van diezelfde NS.

Vergeet niet dat hier in garantiediscussies altijd naar de winkelier wordt verwezen als er iets met een product is. De fabrikant en tussenhandel boeit de consument vrij weinig, waarom zou dit bij het openbaar vervoer anders zijn?

De NS heeft alleen weinig keuze betreft toeleverancier. Prorail is een staatsbedrijf en monopolist.

Heel veel ellende met het spoor die de NS wordt aangeschreven is echter juist een probleem van ProRail. Ook de winterse ellende van een paar maanden geleden was vrijwel volledig ProRail. Maar ondertussen staat er wel een miep van de NOS lekker populair een NS persoon af te katten ...

Dus het is juist nodig dat de ogen bij veel Nederlanders en zelfs de politiek open gaat dat veel ellende bij het spoor juist bij de eigen overheid zit en niet bij de NS (hetgeen overigens ook nog steeds een genationaliseerd bedrijf is).

De NS heeft alleen weinig keuze betreft toeleverancier. Prorail is een staatsbedrijf en monopolist.

Heel veel ellende met het spoor die de NS wordt aangeschreven is echter juist een probleem van ProRail.

Tja, maar omgekeerd is ProRail ook weer aardig de pineut. Want je knipt eerst de tak die daadwerkelijk inkomsten genereert (NS) los van de tak die de grootste kosten qua onderhoud moet maken (ProRail) en gaat vervolgens klagen dat die laatste het onderhoud niet goed doet omdat er te weinig geld voor is om het goed te doen.

ProRail krijgt weliswaar een vergoeding van de NS voor het gebruik van hun infrastructuur, maar die vergoedingen liggen vast. Als de NS extra geld nodig heeft om de treinen te onderhouden of extra bonussen uit te delen, dan kunnen ze gewoon de tarieven verhogen, maar ProRail moet het doen met de vergoeding die vooraf is afgesproken. Als zij ineens zouden komen "we hebben meer geld nodig om de wissels goed te kunnen onderhouden", dan geeft de NS uiteraard niet thuis.

[Reactie gewijzigd door RagingR2 op 23 maart 2012 09:04]

Daarom is ProRail ook een staatsbedrijf, en hoeven ze ook geen winst te maken. Dat hebben ze in Groot Britannië geprobeerd maar is in een faillisement van de Britse ProRail geëindigd.

Als ProRail meer geld nodig heeft moet ze bij de Nederlandse overheid aankloppen. Dan zal Schultz moeten kijken of er meer geld nodig is, en zo ja hoe dat gevonden kan worden. De minister stelt ook de gebruikskosten vast voor vervoerders als de NS.

Er wordt ook niet over de reiziger gesproken in S0epkip's reactie, integendeel.
Het ging er om of het testen en back-up proces een noodzakelijk kwaad was of niet.

Dat heeft toch niets te maken met de reiziger in deze context?

Eerst lezen!

Valt wel mee. ProRail heeft een monopolie op spoorbeheer, dus de klanten kunnen nergens heen en komen morgen weer terug.

Gelukkig dat ze een monopolie hebben overigens. Want hoe mooi het in theorie zou moeten werken met meerdere spoorbeheerders die op elkaar aansluiten, zo slecht werkt dat in de praktijk.

Daarnaast staat redundantie over het algemeen hoog in het vaandel bij iedereen die iets in bedrijfskritische besturingstechniek doet. Helaas krijg je nu gelijk een ROVER die, voor ze de specifieke details van het incident kennen, allemaal dingen roept maar van toeten noch blazen weet voor wat betreft de techniek.

Daar hoef je geen techniek voor te kennen.
NS/ Prorail is een cruciale dienstverlener en die dienen gewoon een goed backup systeem te hebben. En daar heeft Rover terecht kritiek op.

Misschien doen ze dat ook wel, maar heeft zich hier een situatie voorgedaan die niet was getest (of te testen was)..

Nog wat olie op t vuur. Kan me niet aan de indruk ontrekken dat NS geen bussen heeft ingezet, omdat t een 'Prorail-probleem' is. De betrekkingen tussen beide 'bedrijven' zijn op zn zachtst gezegd suboptimaal. Mooi voorbeeld van hoe privatisering niet altijd beter is. Er is nog steeds geen marktwerking, maar nu is de kwaliteit ook nog, eh, suboptimaal...

NS heeft wel bussen ingezet maar hield dit stil om een stormloop te voorkomen...

http://www.nu.nl/binnenla...t-bussen-bewust-stil.html

Waarom duurt het in godsnaam bijna een hele dag om het weer werkend te krijgen? Is het systeem dan zo complex dat niemand er wat vanaf weet?

Over 2 maanden voorspel ik weer een grote storing, de zon schijnt dan te hard waardoor de machinisten niets kunnen zien

Het Nederlandse spoorsysteem is 1 van de drukste ter wereld. Alles moet zo nauw aansluiten om zo ontzettend veel mensen per dag te kunnen vervoeren. Zodra er ergens een kink in de kabel zit, klopt het niet meer. Het probleem oplossen is 1, maar zorgen dat alle treinen weer op de plek zijn waar ze zouden moeten zijn is een veel grotere opgave.

Maar als je het beter weet, wordt consultant bij de NS en/of Prorail. Ik denk dat ze best wel geïnteresseerd zijn hoe jij het zou willen oplossen (en het moet natuurlijk wel betaalbaar blijven).

Juist daarom is het van groot belang, dat de backup systemen grondig getest worden en proef gedraaid, op momenten dat ze het het beste uit komt en ze de dingen in de hand hebben. Zodat ze een grote mate van zekerheid hebben, dat het backup systeem vlekkeloos zal werken. Dit kos tijd, moeite en geld maar dat moet je gewoon voor over hebben. Juist omdat het zo'n cruciaal netwerk is.

Ze denk ik bijv aan "backup" systemen, of beter gezegt dual-systemen die om en om geswitched worden zodat de werking op beide systemen bewezen is. Drie maanden op A en drie maanden op B, om en om. Alleen zo kan je eventuele conflicten snel boven water krijgen en daarop maatregelen nemen. Dat is pas redundancy. Beide systemen krijgen zo "bedrijfskilometers".

[Reactie gewijzigd door Madrox op 23 maart 2012 12:33]

Ik weet niet of je het met een paar bussen wel voor rijdt als er een post neer is. Hoeveel mensen zouden er in 1 trein gaan? Stel dat een trein op een druk traject om het kwartier rijdt dan zijn er aardig wat bussen nodig al voor 1 enkele lijn. Bussen groeien ook niet aan een boom lijkt me zo.

Jammer dat de gemiddelde bezoeker zonder inside info weer alleen op de geen-stijl manier kan reageren.

Prorail heeft een tikkie meer geavanceerde systemen staan dan menigeen hier in zijn leven heeft gezien, flink complexer dan een gemiddeld datacenter, volledig interlocking en heeft elk systeem redundant uitgevoerd. Helaas geeft ook dat geen garantie op 100% uptime van alle systemen, dat blijkt. Tenslotte is het ook een gedeelte mensenwerk, en die maken fouten, net als bij elk ander bedrijf.

Desondanks jammer dat het gebeurd, ik stond zelf ook stil en ben vandaag niet op mijn bestemming aangekomen.

Jij weet dus iets van ProRail. Bronnen?

Alles redundant zeer geavanceerd maar een backup werkt niet en een rollback kost een halve dag. En het enige antwoord daarop: het is mensenwerk? Enig idee wat je voor een stoeltje betaald? Enig idee wat voor een bonus de chef krijgt? Een barman die een glas pils over zijn kassa mikt; dat is mensen werk. 100000 mensen later verrotten op een station omdat is niet goed te praten.

Jij weet dus iets van ProRail. Bronnen?

Je mag alles weten, maar niet zijn personeelsnummer.

Ja, ik weet wel 'iets', in 25 jaar pik je wel eens wat op.

Geloof dat je het geheel niet volledig begrijpt, er is geen backup (als in systeem-backup) teruggezet. Het redundante backup systeem is niet automatische ingeschakeld. Vervolgens is het gehele systeem down gehaald, en opstarten van de vele duizenden sub-systemen (elk infra element moet ingelezen worden) duurt nu eenmaal een poosje. Wanneer de systemen weer betrouwbaar draaien word dit aan de vervoerders te kennen gegeven. De NS kiest bewust voor een bepaald scenario van opstarten en daardoor staan jij en ik te wachten op een trein. In die treinen zitten namelijk ook mensen die op een bepaalde plek en tijd naar huis moeten.

Overigens probeer ik het zeker niet goed te praten, dit zou niet zo'n grote impact mogen hebben. Maar Murphy's Law is nog best actueel.

@Heppieboeddah: inderdaad, dat lijkt me een goed idee

Om daar nog even op aan te haken. Ook het applicatielandschap van een organisatie als ProRail is natuurlijk enorm wat ook weer problemen met zich meebrengt omdat alle software op elkaar is aangesloten.

Ik snap niet dat iedereen zo zeikt op ns/prorail. Ze brengen me bijna dagelijks probleemloos op mn bestemming, terwijl ze te maken hebben met een zeer complex netwerk.

Misschien is dat dan ook wel een van de problemen van ze, een overcomplex netwerk.

Dingen zoals dit of het ov chip fiasco kun je testen, testen en nog eens testen, en dit kost ze veel meer dan een tijdje een dure jongen (of meerdere) inhuren die dat allemaal zal gaan testen.

Testdriven is toch wel het sleutelwoord van de afgelopen tijd, tientallen security problemen die je daar mee kan afvangen, vreemde bugs, wazige resultaten,
zijn allemaal met tests te vinden.

En eerlijk gezegd kost het helemaal niet zoveel extra tijd als je ze voordat je begint met programmeren maakt, het probleem is dat we (de meeste programmeurs) te lui zijn en meteen door willen naar het 'echte werk'

De tweede optie,maar die is toch wel minder aanwezig, zijn managers die in je nek aan het hijgen zijn met de vraag 'is het al af, mag ik al, werkt het al' dan roep je gewoon problemen over je af.

Punt is dat er gewoon maar wat gedaan wordt, en met zo'n kritiek systeem moet je gewoon minder downtime hebben dan ze de afgelopen aantal jaren hebben laten zien.

Het is geen tech bedrijf zoals google die hun zaakjes piekfijn in orde hebben, maar ze vertrouwen wel op tech, zorg dan dat je een expert op dat gebied een paar weekjes in huis haalt..

Centjes, centjes, centjes

In principe leveren ze top werk (het wegennet is veel vaker verstoord). Maar ze hebben wel altijd teveel moeilijk om een storing op te vangen en snel te verhelpen. Dat zou naar buiten toe eigenlijk geruisloos moeten gaan.

ten opzichte van het wegennet leveren ze helemaal geen topwerk.
Bij het spoor weet je een jaar van te voren al dat de trein van Amsterdam naar utrecht op maandag om 08:30 vertrekt van spoor 4, dat plannen is geen rocket science.
op de weg weet je niet of het straks druk is of niet. dat is afhankelijk ven erg veel factoren.
Ik vermoed als je gaat kijken naar de kosten per gereisde kilometer per persoon, dat die verhouding ook al niet spreekt in het voordeel van het spoor. (Kan er echter niets over terug vinden)

Dat laatste kon nog weleens tegenvallen als je voor je werk de trein neemt. Werkgevers vergoeden de trein doorgaans helemaal, terwijl je voor de auto een vergoeding per kilometer krijgt, die meestal gelijk is aan het wettelijke bedrag.

"Automatisch" naar een "back-up" systeem, mag toch hopen dat hier goed over nagedacht is want dat kan dan nog voor aardig wat problemen gaan zorgen.

Wij zeggen toch echt dat er eerst altijd een menselijke handeling plaats moet vinden, hoe simpel die dan ook mag zijn

<edit>
Ik hoop trouwns dat het back-up systeem gewoon een mirror is?
Neem van 5m terug bijvoorbeeld...

Dan heb je zelfs helemaal niet te maken met back-ups restoren e.d ....

[Reactie gewijzigd door mpijnen op 22 maart 2012 19:33]

"Automatisch" naar een "back-up" systeem, mag toch hopen dat hier goed over nagedacht is want dat kan dan nog voor aardig wat problemen gaan zorgen.

Wij zeggen toch echt dat er eerst altijd een menselijke handeling plaats moet vinden, hoe simpel die dan ook mag zijn

euh, nee? Als een server van T.net er vandaag uitklapt wil je toch ook het liefst dat de loadbalancer het verkeer automatisch naar de andere server routeert, ipv dat je moet wachten op een beheerder totdat die een knopje omzet? Plus, het is wel bewezen dat menselijke fouten vaker de oorzaak van calamiteiten zijn dan automatische handelingen.

Als je praat over een Load Balancer dan geef ik je helemaal gelijk!

Maar ik doelde meer in het geval van een "Disaster Recovery"

die 'backup' kan even goed een andere node in dezelfde cluster te zijn. de data waar die dan mee werkt is 'real time', alleen de handeling die net op het moment van de failover plaatshad op de falende node is dan wellicht mislukt

Prorail gebruikt een OpenVMS cluster dat is ingericht voor dergelijke zaken.
Effectief kan je met zo'n cluster een systeem shadowen en zo direct overschakelen naar het andere systeem in het cluseter zodat het taken overneemt zonder dat een gebruiker dat merkt. Ingelogd gebruikers worden niet eens uitgelogd.

Dan blijf ik me afvragen waarom vandaag, om 16.17 de trein vanuit Hilversum naar Utrecht nog steeds niet reed. Vanwege de eerdere storing, hebben ze op dat traject (en waarschijnlijk een stuk meer) gewoon de hele dienstverlening naar 'winter' dienst veranderd. Best wel belachelijk als om 08.40 het probleem werd verholpen en het treinverkeer op gang moet komen (dus rond het middaguur moet het dan toch wel normaal rijden). Lijkt wel of de NS de fout van Pro Rail gelijk als reden gebruikt minder treinen te laten rijden...

dat ligt er aan, langs die route staan zo veel straatkasten/onderstations/relaishuisjes etc, als in een van die gebouwtjes de boel niet wil opkomen moet je alles bij langs, en dat is geen makkelijk klusje, plus er kan nog met stom toeval zoveel meer zijn.

Verdiep je eens in het logistieke proces van NS. Dan zal je het waarschijnlijk wel begrijpen

Ik werk voor prorail en zit 24/7 langs het spoor, dus weet hoe en wat;) en dat het vanaf een bureaustoel heel makkelijk praten is, en als monteur het je toch in de schoenen word geschoven.