ProRail: stroomstoring bevond zich in datacenter British Telecom - update

De oorspronkelijke oorzaak voor de grote sein- en wisselstoring in en rond Utrecht, lag in een rekencentrum van British Telecom in Nieuwegein. Een onafhankelijke partij gaat daar nu onderzoek naar doen, maakte ProRail dinsdag bekend.

ProRails computersystemen en netwerken voor de treinbesturing rond Utrecht bevinden zich bij British Telecom, zo zegt ProRail. Het rekencentrum voldoet aan allerlei beveiligingseisen. Zo zijn voorzieningen als voeding en airconditioning dubbel uitgevoerd en voldoen die aan het zogeheten Tier 3, de hoogst mogelijke internationale standaard voor datacentra.

ProRail wilde afgelopen weekend de stroomvoorziening voor zijn systemen uitbreiden en nam daarvoor in overleg met British Telecom de voorziening van het rekencentrum onder de loep. Het bedrijf, dat de enige gebruiker van de stroomvoeding is, nam daarvoor naar eigen zeggen voorzorgsmaatregelen. Op een korte storing na zouden er daardoor geen gevolgen zijn ontstaan.

Alles leek dus goed te gaan, tot er maandagochtend 'onverwacht' een van de computersystemen van de verkeersleidingpost Utrecht uitviel. Het ging volgens ProRail om een computer die was verbonden met het systeem dat afgelopen weekend kort uitviel in Nieuwegein. Hierop schakelde het systeem over op een backupsysteem, dat het werk overnam, maar de dataserver kon de belasting niet aan.

ProRail zegt dat er door de storing defecten ontstonden in de hardware van zowel de dataserver als de redundante computers. Meer weet het bedrijf nog niet. ProRail laat dan ook naar eigen zeggen een onafhankelijke partij onderzoek doen naar de storing, om 'te leren van deze storing en in de toekomst deze te kunnen voorkomen'.

"De eerste conclusie is dat het totale systeem inclusief de redundantie in het weekend een ‘tik’ hebben gekregen vanwege de kortstondige uitval die zeer waarschijnlijk ontstond door een verstoring in de stroomvoorziening. Duidelijk is ook dat de ProRail-systemen over voorzieningen beschikken die impact van stroomwisselingen moeten voorkomen, maar het lijkt erop dat dit onvoldoende heeft gefunctioneerd. Onderzoek moet dat nog bevestigen", verklaart ProRail. Alle schade is inmiddels gerepareerd.

ProRail zegt ondanks een forse investering ict-storingen nooit helemaal te kunnen voorkomen. Het bedrijf heeft sinds 2007 ruim 100 miljoen euro geïnvesteerd in verbeteringen aan de verkeersleidingsystemen. Het gaat daarbij onder andere om het upgraden van rekencentra en dubbele computersystemen en netwerken. Volgens het bedrijf zouden daardoor in ieder geval tachtig procent minder storingen zijn geweest. "Deze storingen variëren van een kapot computerscherm op de post met één vertraagde trein tot gevolg tot een grote storing in de systemen met veel hinder voor reizigers."

Update, woensdag 12:00: ProRail benadrukt dat de stroomstoring niet de schuld is van British Telecom. Die schuld werd aanvankelijk wel in dit stuk gewekt.

Reacties (141)

Maar de schuld ligt niet bij BT volgens ProRail:

"Volgens Prorail lag de oorzaak van de storing in het eigen systeem en was die niet te wijten aan BT." Bron: http://www.nu.nl/binnenla...ht-lag-in-nieuwegein.html

Welke van de twee berichten ook blijkt te kloppen: er zit intern bij ProRail iets niet helemaal lekker als ze op één dag twee tegenstrijdige berichten uitdoen...

Welke van de twee berichten ook blijkt te kloppen: er zit intern bij ProRail iets niet helemaal lekker als ze op één dag twee tegenstrijdige berichten uitdoen...

De kop kan enigszins misleidend zijn, want nu lijkt het alsof ProRail met de vinger wijst. Als je het oorspronkelijke blog leest (en zeker als je dat met enige enterprise-ICT kennis kunt doen) dan zie je dat er geen sprake van vingerwijzen is.

Dit is de verwarring:
Fysiek ligt het probleem in een locatie die van British Telecom is.
Intrinsiek (de kern) ligt het probleem in de eigen systemen van ProRail.

Op zijn hoogst wordt er een relatie gelegd met het onderhoud aan de stroomvoorziening door BT, maar daarvan zegt ProRail expliciet dat dat in goed overleg is gebeurd en de risico's daarvan aanvaard zijn.

Dat is ook geen vingerwijzen, maar wel belangrijk als achtergrond bij een Root Cause Analysis.

Het is op zich best bijzonder dat een grote organisatie zo gedetailleerd uitlegt wat er gebeurt is.
Voor mensen die zich erin verdiepen interessant om te lezen, maar het kan onbevredigend blijven. Aan de andere kant ondanks dat ze simpele taal proberen te gebruiken, kan het voor de leek abracadabra blijven en dan krijg je al snel een misvatting als dat ProRail zou zeggen dat het de schuld van BT is.

Kortom, ProRail steekt hier zijn nek uit. Dat vind ik lovenswaardig. Nu nog zorgen dat dit minstens 1 jaar niet meer voorkomt. En als het wel gebeurd, dat het sneller wordt hersteld.

[Reactie gewijzigd door Keypunchie op 3 februari 2015 22:45]

Dankjewel voor deze verheldering.
Dan vind ik de kop van het artikel inderdaad wat misleidend.
Maar ik steek de hand ook in eigen boezem: ik stond even niet stil bij het verschil tussen oorzaak en schuld.

Tier 4 is hoger dan tier 3 in mijn boekje dus waar het "hoogste internationale niveau" vandaan komt is mij een raadsel.

Je hebt deels gelijk. Bij tier 4 is het ook noodzakelijk dat de servers redundantie hebben. dan is dus niet alleen het datacenter dat de bepalende factor vormt.

Zie : http://www.ovh.nl/dedicated_servers/uitleg-t3-t4.xml

Ik heb wel eens gezien hoe een duur SAN verlamd werd doordat een stroomstoring de cache-controllers had gesloopt. Die controllers hadden ingebouwde batterijen en bijhorende beveiligingen maar zijn toch stuk gegaan. Zonder die controllers heb je een stuk minder performance.

Ik heb de afgelopen 10 jaar een paar keer een stroomstoring gehad in datacenters en dat kan inderdaad e.e.a. slopen. In mijn geval betrof dat meestal disken of raidsystemen die een tik hadden gehad.

Wat is het nou eigenlijk??

'het' is een lidwoord.

https://onzetaal.nl/taaladvies/advies/de-het-algemene-regels

Ik ken het genoemde datacenter. En die hebben de stroomvoorziening in het verleden al totaal aan een controle onderworpen. Wij hebben toen als bedrijf de nodige maatregelen getroffen in overleg met BT om eea beter op orde te brengen. Dit ging allemaal zonder problemen. Zelfs het overschakelen van de ene naar de andere feed ging zonder problemen. Ik zou bijna denken dat ProRail in het datacentrum geen gescheiden circuits heeft lopen op de voedingen van servers. Iets wat wel vaker voorkomt. Dubbel voeding in 1 server op eenzelfde feed. Gaat door werkzaamheden of omstandigheden een feed plat dan hop server plat.

ProRail zal er alles aan doen om geen gezichtsverlies te lijden, hebben ze laatste tijd al te vaak gedaan. Dus is het afschuifspelletje begonnen.

Een beetje bedrijf voert meerdere malen per jaar business continuity exercises uit om dit soort zaken te testen, kan me niet voorstellen dat dat hier ook niet het geval is, bedrijven voeren audits uit en zetten bepaalde targets die gehaald moeten worden.

Dat zijn in de meeste gevallen simulaties, oefeningen met 'near production-like' systemen. De meeste grotere bedrijven opereren 24/7, en die kunnen dus domweg niet oefenen met de productie systemen. Of we zouden als klanten moeten accepteren dat we af en toe een middagje niet kunnen treinen of pinnen of zo, omdat er een DR oefening aan de gang is. Dat zie ik nog niet zo gauw gebeuren.

Of we zouden als klanten moeten accepteren dat we af en toe een middagje niet kunnen treinen of pinnen of zo, omdat er een DR oefening aan de gang is. Dat zie ik nog niet zo gauw gebeuren.

Daarom doe je zo'n test ook 's nachts en kortstondig.

En dan weet je nog steeds niet wat er gebeurt als het systeem daadwerkelijk belast is

Tuurlijk wel, waarom niet?
Wissels/seinen aansturen kan ook zonder dat er werkelijk een trein rondkart op de rails; en als het treinverkeer wel van invloed is kan je natuurlijk onder normale omstandigheden data verzamelen die je tijdens de test weer naar de backup systemen voert zodat ze een realistische belasting hebben. Het liefst neem je zo'n sample tijdens zware piektijden natuurlijk.

Ik zie niet in waarom je dat niet zou kunnen testen...

Omdat je dan oa voorzieningen moet treffen om fake data te kunnen voeren aan systemen wat weer bewaakt moet worden waardoor je meer en meer van productie omstandigheden gaat afwijken en je test dus steeds minder realistisch wordt.

Welnee, het is gewoon de feed van een normaal gesproken live systeem te vervangen door een feed van een systeem dat dezelfde informatie, maar dan niet real-time, aan het systeem voert.
Het systeem krijgt nog steeds exact dezelfde data te verwerken, maar dan van een eerder moment.

In de IT werkt het vaak niet anders met stress- en capaciteit-tests...

Het systeem wat die niet realtime feed gaat voeren is een voorziening die afwijkt van de standaard productie. Daarnaast kun je niet willekeurig wissels/seinen gaan aansturen met zomaar een feed van een totaal ander moment zonder gedegen controle dat er tijdens die test helemaal niets op het spoor aanwezig is. Beetje lullig om met wissels te spelen in de nachtelijke uren als we ook gewoon een nachtnet hebben en het spoor dus gewoon gebruikt wordt in de nachtelijke uren.
Daarnaast moet je ook nog rekening houden met een daadwerkelijke calamiteit tijdens je test met fake data en moet je voorzieningen treffen om asap terug te gaan naar de normale productie situatie.
Al met al iets wat je niet zomaar even doet.

Ik zeg natuurlijk niet dat je het zomaar moet doen, dat zou belachelijk zijn. Maar als jij bij de planning voor vervoer er rekening mee houdt dat men op 15 Juni 2015 van 3AM tot 3.30AM een test wil houden: dan zorg je er voor dat er dan geen treinverkeer wordt toegestaan...
Verschuilen achter het excuus "maar er kan verkeer rijden" is natuurlijk onzin, dan moet je maar zorgen dat het goed ingeplanned is. Zo'n test is absoluut mogelijk.

En nee natuurlijk is het niet iets dat je zomaar doet, maar wel iets dat je MOET doen. Anders weet je nooit of je plan werkt. Die manier van denken zorgt dus voor de grote problemen die we nu zien.

Ik hoor hier enkel excuses, geen praktische oplossingen.
Dat is nou net het probleem dat veel van die bedrijven hebben; enkel denken in "we kunnen het niet zomaar doen" of "het kan ons een probleem opleveren", en er dus totaal geen vertrouwen in hebben of het dan maar links laten liggen.

Ja, dan moet je niet raar opkijken als je backup plan opeens belachelijk slecht lijkt te zijn als er opeens wel iets gebeurt.
Dus: geen excuses, gewoon degelijk testen!

' s nachts schakelen; zou kunnen, maar dat hangt helemaal van het soort bedrijf af. Je probeert je schakelmoment voor productie op een relatief stil tijdstip te plannen.

Kortstondig lijkt me juist niet. Als je het goed doet draai je minimaal toch een week op je uitwijksysteem. Juist om te testen/bewijzen dat je uitwijksysteem het echt aankan.

Een full-stop tijdens piek probeer je hooguit op je near-productie systemen uit. Om te testen of je inderdaad de juiste methodiek en procedures hebt.

Als je niet de stekker uit je systeem durft te trekken om de backup/failover te testen heb je geen vertrouwen in je system, dus je hebt een probleem.

Nou, niet om het een of ander, maar als je er pas achterkomt dat je backup systemen niet voldoende capaciteit hebben op het moment dat er iets gebeurt; dan lijkt dat er toch op te duiden dat er geen goede tests zijn uitgevoerd, of niet met alle scenarios rekening gehouden is/afgeschoven is op "slechts 1% kans, dus laat maar zitten; zien we dan wel weer".

Het probleem met testen is dat je sommige situaties niet kunt verzinnen cq. voorspellen. Als je dat wel zou kunnen zou er nooit iets fout gaan.

"geen stroom" lijkt me een redelijk voorspelbare situatie.

Voor een bedrijf wat zulke belangrijke apparatuur in zo'n datacenter plaatst zou het werkelijk godsgeklaagd zijn als ze geen A + B feed hebben, maar A of A + A.
En ook zo te zien geen eigen backups in het rack/voor hun apparatuur hebben hangen. Als de machine meteen plat gaat zodra de stroom weggaat is het met de redundantie nogal brak gesteld.

Het zou me ook erg stug lijken als ze geen aparte feeds hebben, maar eerlijk is eerlijk... Niets verbaast me werkelijk nog als ik kijk naar hoe sommige bedrijven, zeker die vanuit de overheid opereren, de boel op orde hebben. Of beter gezegd: niet op orde hebben.

[Reactie gewijzigd door WhatsappHack op 3 februari 2015 20:33]

Dus een bedrijf dat uitlegt wat er gebeurt is is bezig met een afschuifspelletje?

Als ik het originele blog lees zou ik eerder de schuld bij Tweakers leggen. Sensatiezoekende kop.

Ik ben geen kenner maar dit zou denk ik niet bij Schiphol gebeuren

Er zijn een aantal keer storingen in de computersystemen van Schiphol... Het gebeurt dus zeker wel.

Inderdaad, maar een storing zo groot dat er 4 uur lang geen enkel vliegtuig meer kan opstijgen en landen is er naar mijn weten nog nooit gebeurd.

Jawel;
http://www.nu.nl/internet...schiphol-storing-klm.html
En door korte onmogelijkheid hiervan het flink moeten reduceren van vluchten:
http://www.luchtvaartnieu...ort-vliegverkeer-schiphol
http://www.rtlnieuws.nl/n...r-vertraging-door-storing

Het is alleen wat makkelijker op te lossen bij Schiphol dan bij treinverkeer.

Laten we er wel bij opmerken dat er *veel* minder vaak storingen zijn bij Schiphol, met een enorme factor minder. De meeste storingen en vertragingen bij Schiphol zijn ironisch genoeg veroorzaakt door de NS.

Nog een interessant verschil om te noemen is de complexiteit met personeel materieel. In de luchtvaartwereld is het gebruikelijk om de crew te pairen met een vliegtuig, zodat heen- en terugreis door hetzelfde personeel (en vaak ook zelfde vliegtuig) wordt uitgevoerd. Het spoornetwerk zit logistiek heel anders in elkaar, waardoor een (flink) vertraagde trein effect kan hebben op meerdere andere verbindingen. Dat is in de luchtvaart veel minder het geval.

Al moet je ook bedenken dat er minder mensen voor het vliegtuig springen dan voor de trein (wat weer vaak rondom Schiphol gebeurt) .

En waarom zou dit niet in schiphol kunnen gebeuren? Dat kan daar evengoed. Bijkomend is een luchthaven of luchtverkeersleiding nog altijd iets eenvoudiger dan een netwerk te onderhouden dat zich uitstrekt over het hele land.

Mhwa....... over het eenvoudiger zijn van het Schiphol systeem daar ben ik het niet mee eens. 55.000.000 passagiers per jaar (met de daarbij behorend bagagestromen) en drie vliegbewegingen per minuut........ ik moet er niet aan denken als daar verkeerssystemen uitvallen....... en dan hebben we het nog niet eens over veiligheid.

Wat een groot probleem is bij de spoorwegen is dat er nog steeds met ouderwetse relais systemen gewerkt wordt (meer dan 50 jaar oude techniek) in het seinwezen. De koppeling en de vertaling van signalen voor hedendaagse techniek is behoorlijk complex. En deze relais systemen worden nog steeds gebouwd, ik heb twee jaar geleden voor een nieuw aan te leggen spoorcomplex de relaiskasten nog gebouwd!!

Vergis je niet, het spoor is veel lastiger. Het volume van de te behandelen acties is heus niet het probleem hoor, 3 treinen per minuut of 30 per minuut gaat weinig uitmaken, zo ook bij de vliegtuigen. Wat verkeersleiding lastig maakt voor vliegtuigen zijn diverse landingsbanene en vluchtroutes, voor treinen zijn dat naast de overeenkomstige gegevens ook nog eens dat de infra zelf (voor vliegtuigen: lucht) gebrekkig kan zijn of kapot kan raken. Daarnaast zijn vrachtreinen compleet andere dingen, andere routes, en significant langer (cargo vliegtuigen zijn verschillend, maar verschillen niet bijster veel van passagiervluchten - die toch al deels cargo doen)... Treinen bestaan daarnaast uit stellen - vliegtuigen niet (dit is belangrijker dan je denkt), en personeel is moeilijker te managen.

Je zou het misschien niet denken, maar de systemen voor treinverkeersleiding hebben een hogere complexiteit dan die van luchtverkeersleiding.

[Reactie gewijzigd door CakeSpork op 3 februari 2015 20:53]

En jij denkt dat er alleen luchtverkeersleiding nodig is om vliegtuigen te laten vliegen? Wat dacht je van alle logistiek er omheen en al die externe partijen die aangesloten zijn.

Dat is waar, maar de luchtverkeersleiding hoeft niet de vliegtuigen te besturen. De verkeersleiding bij Prorail moet niet alleen het verkeer leiden, maar ook de seinen en wissels besturen, en daar ging het nou net fout. Cake heeft een punt.

Als het goed is is veel voor geprogrammeerd, het systeem weet welke trein waar rijdt, waar die heen moet en waar andere treinen bevinden. Die rekent paar stappen vooruit in de tijd.

Pro-rail reageer alleen op melding van het systeem als iets (bv trein rijdt door rood sein, trein rijdt langzamer.... enz).

In Utrecht zit een belangrijk gedeelte van alle spoorbeveiliging EBS, (wissels seinen) als daar iets uitvalt, voldoet het systeem niet meer aan de daarvoor ontworpen veiligheid (failsafe) en schakelt het vanzelf alles uit (er rijden geen treinen meer).
Wat vooheen met ouderwetse relais gedaan werd, wordt nu door 2 computers gedaan, die voeren dezelfde bewerking uit en als er een verschil bestaat tussen de uitkomsten schakeld het systeem af (das het idee van de failsafe bij het gebruik van computers i.p.v. relais dus).

edit: in werkelijkheid zijn het wel meer dan 2 pctjes natuurlijk

Offtopic: EBS staat voor Electronische beveiliging siemens.... was stuknet virus niet iets dat specifiek op siemens systemen nogal destructief was?

Het zou me niets verbazen als door het schakelen naar een backup systeem, er hier en daar een bitje teveel en of te weinig door kwam waardoor het systeem zelf een gedeelte afschakelde ter voorkoming van erger. Als er door het schakelen naar een andere computer (backup) die normaal nooit op vollast draait, ineens dit wel doet, kan ik mij zo voorstellen dat er ergens een voedings blok ook ineens erg op zijn donder krijgt, met soms desastreuze gevolgen blijkt..

[Reactie gewijzigd door BenGenaaid op 4 februari 2015 14:38]

...wordt nu door 2 computers gedaan, die voeren dezelfde bewerking uit en als er een verschil bestaat tussen de uitkomsten schakeld het systeem af ,,,

Da's dus echt een slecht plan. Als een van de systemen een probleem heeft, valt meteen het geheel uit. In feite heb je zelfs je faalkans verdubbeld.
De truuk is dat je drie computers gebruikt, en de meeste stemmen laat gelden. Zo bescherm je je tenminste tegen slechte data uit een systeem.

De truuk is dat je drie computers gebruikt, en de meeste stemmen laat gelden. Zo bescherm je je tenminste tegen slechte data uit een systeem.

Dat mag dus niet, als er namelijk en uitkomst verschil is is er ergens een fout, dan mag zelft bij 3 systemen volgens de Failsafe norm er geen doorgang plaatsvinden (2 computers zeggen sein is op groen en 1 zegt op rood, is het dan rood of groen?, 2 computers zeggen er is geen trein op dat traject maar 1 zegt van wel, dus is ie er dan wel, of niet. Het systeem besluit in zo'n geval altijd om alles te stoppen (op het betreffende traject). Dat is juist de veiligheids norm die we Failsafe noemen.

Wat jij dus Faalkans noemt, noemt het systeem een geregistreerde fout die niet mag voorkomen. Kwestie van afspraken door de techneuten en Veiligheids controlleurs en Normering instituten en Ministerie van Verkeer en Waterstaat.

Lijkt me trouwens dat Siemens hier wel over heeft nagedacht voordat dit de oorspronkelijke ouderwetse relais schakelkasten heeft vervangen (welke overigens nog in 1997 en verder werden ontworpen voor bijv. Project IJzeren rijn).

Het voordeel van die constructie is dat je 100% van de incidenten detecteert. Maar als een enkel systeem een kans n heeft op een incident, heeft een tandem 2n+y kans (de y is de kans die de toegevoegde complexiteit oplevert).

In omgevingen waar continuïteit de belangrijkste eis is ligt stemmen meer voor de hand. Als je de kans op een synchrone fout op meerdere systemen te groot vindt kans je simpelweg opschalen, 10 systemen met een 80% quorum bij voorbeeld. Dat getal drie kwam uit een F16, trouwens, in de luchtvaart zie je het veel, of meer op mijn terrein clustered databases.

Het lijkt me een keuze tussen 'zeker weten' dat er geen ongemerkte fouten in je systeem sluipen, tot 'zeker weten' dat de boel blijft draaien. Het blijkt allebei onwaar in de praktijk.

In omgevingen waar continuïteit de belangrijkste eis is ligt stemmen meer voor de hand.

Daarin heb je gelijk, echter bij treinen is continuiteit niet de belangrijkste eis, veiligheid is de belangrijkste eis en kosten de 2de , vandaar deze contructie...

PS beetje later reactie (tijdje AFK) maar moest het toch nog even melden.

En jij denkt dat er alleen luchtverkeersleiding nodig is om vliegtuigen te laten vliegen? Wat dacht je van alle logistiek er omheen en al die externe partijen die aangesloten zijn.

Je kan inderdaad dan beter de treinen stoppen, om erger te voorkomen, maar een vliegtuig zal toch ergens ( rustig ) de grond moeten raken ...
een enkele vlucht kan nog wel uitwijken naar andere Europese luchthavens, maar die passagiers moeten toch op de eindbestemming komen.
Je rijdt niet zomaar een busje van Frankfurt of Parijs naar Amsterdam terug

Vergeet de overstappende transfers niet, een trein is dan 'makkelijker' op te vangen, dan die logistieke nachtmerrie op luchthavens

Beste CakeSpork,
Blijkbaar heb je heel veel verstand van treintjes, maar niet van luchtverkeersleidingssystemen.
Ik ga niet in discussie wat complexer is maar heb je hier al eens aan gedacht.
Viegtuigen moeten in hoogte, in afstand en lateraal uit elkaar gehouden worden. Er is niet een soort kist die allemaal net zo hard vliegt, stijgt en daalt. Nee ieder liegtuig heeft een andere performance. Dan komen er vliegtuigen, vertrekken er vliegtuigen en ze vliegen over nederland heen, dit gebeurt allemaal tegelijk in ons luchtruim. En in ons kleine land hebben we nog EHBK, EHRD, EHGG en EHEH waar burger verkeer wordt afgehandeld. Die drie minuten is per baan, er zijn vaak drie banen tegelijk op SPL in gebruik

Alle data van vluchten, ook van alle buitenlandse velden die informatie voor ons hebben, komen bij ons uit. Dan moeten al die verschillende systemen ook nog eens met elkaar kunnen communiceren in real-time

Misschien denk je er nu anders over.

Je hebt er kennelijk verstand van. Weet je ook wat er gebeurt als de computers bij LVNL op zwart gaan? Ik weet niet of zoiets wel eens gebeurt, maar kan me voorstellen dat ook daar zulke problemen wel eens optreden.
Ik heb wat minder verstand van de luchtvaart, maar denk wel dat de luchtvaart iets stabieler is. Vliegtuigen lijken mij nog redelijk autonoom op het moment dat de verkeersleiding uitvalt, omdat elke kist een eigen radar etc. heeft. Het spoornetwerk kent intens veel fail-safes, waardoor alle seinen op rood gaan op het moment dat ze door een dergelijke storing niet bediend worden.

Om even in te gaan op de complexiteit van het schedulen ofwel inplannen van treinen of vliegtuigen. Dit gebeurt middels geavanceerde wiskundige modellen. Zowel voor treinen als voor vliegtuigen zijn die modellen vergelijkbaar complex. Alleen het herplannen van personeel is bij treinen lastiger dan bij vliegtuigen, vooral omdat de personeelsplanning bij vliegtuigen door de maatschappij wordt afgehandeld, bij NS plannen ze beide. ProRail doet niets anders dan het monitoren van het spoor en goederentreinen tussen de dienstregeling door plannen. En als daar het systeem plat gaat gaat het evengoed fout als dat bij de luchtverkeersleiding de boel plat gaat.

Voor zover ik weet ( outdated info ) was op vliegbasis Gilze-Rijen de systemen dubbel ingericht.
Er draaien 2 losse systemen naast elkaar die beiden hetzelfde doen.
een controlling systeem monitorde beide systemen, en pakte de info willekeurig daarvan op.
Zou er één uitvallen, sloeg de backup-backend aan, en werd die data ververst op de achtergrond, tot het weer up2date was ( seconden werk )

In de tussentijd begon het herstel van de uitgevallen backend / frontend door het technisch personeel.

Schiphol is wat groter natuurlijk, maar kan me indenken dat de systemen in basis hetzelfde zijn opgezet.

We hebben hiervoor nog 2 systemen
Als ons main systeem uit valt dan kunnen we overschakelen naar een back-up die op achtergrond mee draait.
Als er een brand is of iemand graaft alle kabels stuk, wat in de praktijk niet kan, dat hebben we nog een systeem op een andere locatie die ook altijd stand-by is. Deze laatste stap is natuurlijk niet in een paar minuten geregeld.

Juist omdat de vliegtuigen niet vast aan een spoor zitten heeft elk vliegtuig een piloot met een veel hogere mate van zelfstandigheid dan de machinist van een trein. De beveiliging is dan ook minder strikt geautomatiseerd en er zal geen enkel vliegtuig onmiddellijk stilvallen als er een computer in een datacenter uitvalt.

Maar dan vliegen ze toch tegen elkaar als een systeem uitvalt.
Het Nederlands luchtruim is zo ongelooflijk druk, dat kan een piloot niet zelf regelen.
Een piloot moet vliegen wat een verkeersleider hem vertelt, hij kan niet zo maar zelf iets gaan bedenken. De verkeersleider is als het waren het oog van de piloot.
Als een verkeersleider niets meer kan met zijn systemen gaat het goed fout als er niet snel wordt ingegrepen.

"Maar dan vliegen ze toch tegen elkaar als een systeem uitvalt."
Nee, en zeker niet onmiddellijk de instructies zijn nog wel even geldig.

Treinen vallen wel vrijwel onmiddellijk stil zodra niet zeker is dat het baanvlak vrij is. Dat is niet te voorkomen door de machinist of de verkeersleider.
Voor vliegvelden kan de storing wat langer duren en kan er enigszins om de storing heen gewerkt worden. En vliegtuigen kunnen uitwijken naar een ander vliegveld als het moet.

Er zijn zelfs nog baanvakken in Nederland waar de B-relais nog nooit zijn vervangen sinds de aanleg zo betrouwbaar zijn ze. Zelfs de opvolger van de B-relais; VPi is extreem betrouwbaar.
Kwa trein beveiliging geloof ik het wel in Nederland, op het probleempje in het ATB-EG systeem na dan, die nu aangevuld is door ATB-Vv (die binnenkort weer verbeterd wordt )

Nee ProRail loopt al jaren te worstelen met het ICT beleid, ze zijn afgelopen jaar pas begonnen met de SAP systemen (goed) te automatiseren. Het grootste gedeelte van het archief zijn nog scans uit het NS tijdperk die nog niet verwerkt zijn in een CAD pakket... :-)

Prorail worstel omdat ze uiteindelijk niet de regie hebben. Onderaannemers zijn het werk aan het doen met een heel ander doel dan prorail heeft. Zolang de onderaannemer zich contractueel goed heeft afgedekt, zal die geen enkele pijn voelen bij storingen. Daar zit bij dit soort constructies in mijn optiek de miskleun.

En dit geld dus eigenlijk voor de gehele keten zoals deze ontstaan is in semi/overheids organen de afgelopen 10 jaar.

@pe1pme: Het grappige van dat verhaal is dat juist die dingen niet zo makkelijk stuk gaan en dat je die bovendien ook niet zomaar door software of firmware kunt vervangen en dan nog dezelfde betrouwbaarheid halen. De storing heeft mijnsinziens ook niet te maken met de zogenaamd moeizame koppeling tussen oude (niet ouderwetse) en nieuwe systemen, maar met de zogenaamd probleemloze koppeling tussen nieuwe systemen onderling.

[Reactie gewijzigd door mae-t.net op 3 februari 2015 21:43]

Beste Blokker_1999,
Onze apparatuur staat door het hele land. Zelf tot ver op de Noordzee staat apparatuur die operationeel is. Denk eens aan bakens, zendapparatuur, ontvangers en radarsystemen. Dan heb je in Nederland niet alleen Schiphol maar ook andere velden die allemaal met elkaar verbonden zijn. Ik kan nog even door gaan maar dan geef ik te veel details.

Een vliegtuig kan prima veilig vliegen zonder al die computers, dat is bij een trein wezenlijk anders. Zolang de baan te zien in kun je met relatief eenvoudige middelen een hele hoop vliegtuigen verwerken.

Alleen kunnen de mensen er niet in en kunnen ze niet controleren of er niet toevallig iemand gaat landen als jij net wilt vertrekken. Niet dus.

Dat valt best te controleren, daar heb je radio voor. Computers zorgen voor een verhoging van de capaciteit, ja, maar de luchtverkeersleiding moet toestemming via de radio geven voor zowel vertrek als landing.

Jup, het vliegen is dan ook het probleem niet, het landen en elkaar niet in de weg zitten is het probleem.
Treinen kun je stilzetten in het geval van een storing, vliegtuigen niet.

sterker nog... een trein zet zichzelf stil bij een storing

Anderhalf jaar geleden was er een grote computer storing in Groot Britannie waardoor al het vliegverkeer dat ook maar in de buurt van Londen kwam last had van ernstige vertragingen. Zelf ging ik toen van Schiphol naar Belfast en ook ik heb 3 uur vertraging gehad. Dus ja dit kan ook zeker voorkomen in de luchtvaart.

Hoe moet ik dit zien?
'ProRail zegt dat er door de storing defecten ontstonden in de hardware van zowel de dataserver als de redundante computers'
Dus er gaat hardware kapot omdat er te veel data doorheen gaat? Ik weet niet veel van server aplicaties laat ik dat voorop stellen. Maar ik dacht niet dat computers dingen waren zoals pijpleidingen. Als je er te veel flow over zet barsen ze niet right? De hardware was dus op voorhand niet goed?
Dit wil niet zeggem dat dat niet overal zou kunnen gebeuren. Ik heb ooit een regelcentrum van prorail gezien. Dat is inmiddels als weer wat jaren geleden. Maar dat geeft je wel een heel ander beeld van hoe complex die systemen zijn.

Maar ik dacht niet dat computers dingen waren zoals pijpleidingen. Als je er te veel flow over zet barsen ze niet right?

Wel eens gehad dat je harde schijf heel druk bezig was en daardoor je computer langzamer?

In zo'n omgevingen gebruiken de servers geen eigen schijven (heel soms om van te booten), maar een SAN (storage area netwerk). Dit is eigenlijk niks anders dan een hele grote verzameling disks, die door middel van snelle verbindingen gecentraliseerd storage aanbieden.

Maar als de i/o te hoog wordt (misschien wel vanwege enkele (deels) kapotte schijven door eerdere stroomstoring), dan treedt daar hetzelfde fenomeen op. Daarom zijn ze ook servers gaan uitschakelen, met de hoop dat de belasting van het SAN minder werd.

Dat is het nadeel van hoog gevirtualiseerde/complexe omgevingen, wanneer een van je onderste 'lagen" (in dit geval storagelaag) in de problemen komt, dan blijft het probleem niet geisoleerd.

[Reactie gewijzigd door Keypunchie op 3 februari 2015 20:45]

Er zijn applicaties gestopt om de load op het SAN te verminderen, geen clusternodes.

De uitval van de betreffende node had failovers van applicaties tot gevolg en dat heeft het beschadigde SAN onder te grote druk gezet. Daardoor werd het systeem stroperig en is de treindienstleiding gestaakt.

Ik vond dat ook een vage uitleg hebben, maar ik DENK dat ze bedoelen dat de hardware beschadigd raakte door de stroomuitval... Ook dat is te wijten aan slecht opgezette infrastructuur hoor, daar niet van... En klinkt ook niet als enterprise grade hardware maar zowaar als gewone desktop apparatuur.

Maar van wat hevige I/O overbelasting gaat een machine inderdaad niet kapot, hij kan "stikken" (choke) en bijvoorbeeld zo zwaar belast raken dat hij het gewoon opgeeft totdat een engineer ingrijpt (soms kan enkel een reboot nog helpen als het echt *te* erg is geworden en zo'n beetje alle processen op de io resources van een ander zitten te wachten of daardoor zelf in de wacht gezet worden), maar de hardware kapot gaan...? Nah uh.
Zoals ik eerder vermelde zou het natuurlijk kunnen dat er EEN harde schijf bijvoorbeeld kapot gaat omdat de stroom uitviel, of dat deze reeds al zwak was en door de zware i/o operaties nu besloot de geest te geven, maar ze hebben het over "meerdere apparaten zijn kapot", en dat *kan* gewoon haast niet met goede enterprise grade apparatuur; en al helemaal niet met een goede infra om dit soort dingen te voorkomen.

Het kan natuurlijk wel. Extreme uitval wordt vaak veroorzaakt door een samenloop van omstandigheden. Als je N+1 redundantie hebt bestaat altijd het risico dat er 2 componenten uitvallen. En als je N+4 doet kunnen het er in extreme gevallen 5 zijn.

Wat ik dan wel altijd frappant vind is dat files op de snelweg allemaal voor lief genomen worden en dan als er bij het spoor eens wat fout gaat het meteen zeuren is van hier tot Tokio. Nederland is het op twee na drukste spoorwegen netwerk van de wereld, dan kan er wel eens iets fout gaan...

Ik heb zelf ruim 5 jaar met de trein gereisd voor mijn studie 5 dagen in de week, ik heb maar twee keer niet thuis kunnen komen...

Ik heb zelf ruim 5 jaar met de trein gereisd voor mijn studie 5 dagen in de week, ik heb maar twee keer niet thuis kunnen komen..

Maar hoe vaak ben je pas uuuuuuren later thuisgekomen?
Ik reis niet vaak meer met de trein, en zelfs nu heb ik nog heel vaak verstoringen.
(Granted: op lange trajecten is dat in de winter niet altijd de schuld van de NS, maar ook van die mensen die voor de trein springen; ook altijd een feest... Ben je ook zo 2 uur verder.)

Enfin, ik heb vaak zat 2 tot 6 uur vertraging gehad door enorme fails bij de NS/ProRail.
Ik weet niet wat voor traject jij reist, maar zo te zien heb je heel erg veel mazzel gehad.
Toen ik op en neer moest voor studie had ik minstens 2x per week vertraging.

Uiteindelijk thuiskomen is geen probleem; of dat nou met de trein of vervangende bus is, maar extreme vertragingen wel: en die komen veels te vaak voor.

Rhenen - Utrecht en andersom, dus eigenlijk best wel veel omdat je afhankelijk bent van Utrecht - Arnhem en andersom want die heeft altijd voorrang.

Maar de keren dat ik meer dan twee uur vertraging heb gehad met uiteindelijk wel de trein zal nooit meer dan 20 keer zijn voorgekomen.

Ook al heb ik met grote regelmaat last van files, heb ik nog nooit meer dan 2 uur vertraging gehad. Zelfs meer dan 2 uur reistijd is met de auto binnen Nederland gelukkig nog steeds een uitzondering als je enigszins centraal woont.
(Dit op basis van dagelijks woon-werk naar klanten door het hele land heen tijdens ochtend- en avondspits)

Meer on-topic:
Wat vervelend is, is dat vrijwel alle spoorbewegingen compleet afhankelijk lijken te zijn van één locatie. (Utrecht)
Het zou mooi zijn als de individuele trajecten (of zelfs individuele treinen?) ook een vorm van zelfstandig beheer zouden kennen als fall-back als het geautomatiseerde centrale systeem niet meer werkt.

Ik werk wel niet voor prorail, maar bij een spoorweginfrastructuurbeheerder in een ander Europees land. Nu heb ik reeds verscheidene seinhuizen van pro-rail bezocht, en we werken ook elke dag samen wegens gemeenschappelijke belangen bij de grens. Waar de bazen van ons zo jaloers op zijn, is het volledig geautomatiseerde systeem bij jullie (minder werkvolk dus minder loonkost). Terwijl ik dit systeem totaal verfoei. Doordat bij ons niet alles door geautomatiseerd is, zit het "seingeven" bij ons nog in de vingers en zoeken we alternatieven. Bij jullie is het meer "the computer says no" 😉, en bollen ze niet meer.
Bij ons is het ook wel niet rozegeur en maneschijn, en in het verleden is er een slimme ingenieur geweest die vond dat het land in een stervorm vanuit onze hoofdstad per spoor bediend moest worden. Rara wat ons Utrecht mag wezen.
Het uitbranden van (oudere) seinhuizen heeft dikwijls, althans bij ons, te maken met koperdiefstal. Men knipt de terugstroomkringen stuk, aangezien die niet gemonitord worden. Kheb weet van dat er zo bij ons ooit 3Kv van de bovenleiding op de kabels van seinen en wissels is terecht gekomen. Seinhuis uitgebrand, 's avonds waren we alweer goederentreinen aan het rangeren.

Maar 2 keer niet thuis kunnen komen? Dat is volgens mij toch echt 2 keer te veel.

Er is alleen wel een verschil tussen een file van tientallen minuten op 1 bepaalde snelweg, of een complete uitval van al het treinverkeer op een druk kruispunt wat er voor zorgt dat een heleboel treinen niet kunnen rijden me dunkt.

Een vertraging is tot daar aan toe, maar dit is toch echt wel even heel anders. Het ergste is gewoon vooral dat het door een computersysteem komt. Als er voldoende tegenmaatregelen zouden zijn gemaakt had dit waarschijnlijk niet kunnen gebeuren, of een was de impact (veel) kleiner.

[Reactie gewijzigd door Bose321 op 3 februari 2015 20:30]

Als we het hebben over 261 school dagen dan is dat 522 ritjes per jaar. Dat is 2610 ritjes in die 5 jaar. 2 ritjes die mis gaan is dus 0,076628352%. Dat is dus een 'uptime' van 99,923371648%. Er zijn systemen die het minder goed doen. Dus ja ook al is het 2x te veel het is niet slecht.

Ik ben het wat dat betreft met Marc_87 eens. Er is vorige week een verkeersinfarct geweest in en rondom Arnhem. De zoveelste in een aantal jaren. Maar daar hoor je niemand meer over. Hetzelfde gebeurt vaker rondom Rotterdam. Maar daar hoor je een stuk minder over.

Het probleem is dat bij treinverkeer dat stil ligt je niet veel andere opties hebt. Het is niet dat je ineens je auto pakt als je midden in het land staat met je koffertje. Met een auto zou je nog kunnen overwegen om een andere afslag te pakken en terug te keren.

Wat ik niet begrijp aan ons trein systeem, is dat we schijnbaar besloten hebben dat er één punt is waar alles samen komt. Dat is volgens mij toch zo onderhand een stuk erger dan het computer systeem dat er achter hangt en iets verkeerd doet lijkt mij.

[Reactie gewijzigd door Webgnome op 3 februari 2015 21:53]

522 per jaar neem ik aan

Het probleem van het spoor netwerk in Nederland is dat het te complex is.
Er is blijkbaar ooit bedacht dat het een goed idee is dat een trein die Utrecht Centraal als bestemming heeft op ELK spoor moet kunnen aankomen. Dat maakt het geheel een gigantisch complex systeem waarin van alles fout kan gaan, en gaat.
Het erge is dat van die mogelijkheid vrijwel nooit gebruik gemaakt wordt omdat het de planning nog verder in de war schopt.

We hebben dus een systeem wat flexibel zou moeten zijn maar daardoor foutgevoelig is, en de flexibiliteit in het geval van fouten wordt niet benut.

Ik heb 7 jaar 5 dagen in de week met de trein gereisd en de NS heeft er altijd voor gezorgd dat ik thuis kwam.
Er is zelfs een taxi vergoed van Gouda naar Rotterdam omdat ik de laatste bus had gemist.

Dat is NS en niet ProRail.

Het spoor in Nederland is druk bereden en dit heeft concequencies op het onderhoud. Wil je tijdens de dag in het spoor, dan kan een trein vertraging oplopen.
Met de huidige snelheid van de treinen kan je op de veilige zones de trein afwachten maar bij HSL mag er niemand in het spoor zijn als dit bereden wordt omdat je wordt meegezogen.

Hoe sneller de trein kan gaan des te verder je veilige zone is vanaf het spoor.

Wil je een spoorbaan aanleggen, dan ga je een lang traject in waar onteigenen een onontkoombaar feit is. Je hebt het in de meeste gevallen maar te doen met het spoor dat beschikbaar is.

Kijk eens naar hoeveel de HSL en de Betuweroute hebben gekost.

ProRail heeft dan wel een monopoly positie wat betreft het beheer maar ze zijn afhankelijk van derden. Als je dit allemaal in huis kan houden dan heb je veel meer controle.

De keren dat ik met BT te maken heb gehad heb ik echt geen hoge pet op van die organisatie.

Eén keer was het 15-20cm sneeuw, toen was het ook op de weg lettelijk geen doen. Op school gewacht tot 21:00 uur en toen met een vader van een klasgenoot naar huis gereden.

De andere keer was nog triester, aanrijding met een auto op het stuk Utrecht - Nijmegen.

Verder ook wel eens vertraging meegemaakt die lang duurde maar dat kan gewoon wel eens proberen.

Dat zeg ik niet. Ik zeg alleen dat zo een fout als deze niet zou mogen gebeuren. Waar ging het lezen mis bij jou?

In je eerste zin zeg je het letterlijk: 2 vertragingen = 2 keer teveel. Tolerantie in techniek en dienstregeling is derhalve 0.

En dat dit niet mag gebeuren benadrukt die tolerantie nog maar eens. Het is een eigenschap van fouten dat je niet wilt dat ze gebeuren, maar shit happens. En dus ook bij de NS en ongetwijfeld ook bij jou.

Er is een verschil tussen iets als een vertraging en iets als niet thuis kunnen komen doordat treinen niet rijden.

Niet thuis kunnen komen is een breed begrip.

Was er een overnachting op het station ?
Waren er andere regelingen mogelijk ( bus / taxi )

Hoe was het tussen de stations geregeld, kon er wel naar het eindstation door alternatief, want NS is natuurlik niet verantwoordelijk om iemand thuis af te zetten.

Mensen roepen snel "ik kan niet thuis komen" terwijl eigenlijk alleen men niet via de gewenste route op het volgende station terecht kon komen.

Ik heb ook een dikke 10 jaar met de trein gereist en heb ontzettend veel vertragingen en teleurstellingen meegemaakt met de NS. Soms gewoon voor de gek gehouden door die club en met 1000 man uit de trein gezet (want de vertraging was dusdanig dat ze de trein er gewoon uit de dienstregeling hebben gehaald en dan telt deze doodleuk niet meer mee voor de jaarcijfers.) Daarna een auto gekocht en ik zeg, nooit, maar dan ook nooit meer NS. Ik bespaar me nu honderden uren reistijd per jaar (!) en nooit meer gefrustreerd op reis. Tuurlijk sta ik ook wel eens in een file.. Nou, ben ik hooguit een kwartiertje later thuis een paar keer per jaar. Met de trein was ik 1 op 2 reizen later thuis en dat was dan minimaal een half uur.
Desondanks, als je NS goed vindt dan verdien je het ook. Iemand moet die mythe toch in stand houden.

[Reactie gewijzigd door cbr600f4i op 3 februari 2015 21:53]

Dat kun je ook omdraaien... Jaren vanuit omgeving Rotterdam naar Den Haag gereisd met de auto.. De keren dat je op de filemeldingen op de radio hoort dat de vertraging 15 minuten is en je 1,5 uur later slechts 100 meter bent opgeschoven, zijn ook niet op 1 hand te tellen. Dus de VID kan net zo goed 'liegen' als prorail/ns. Laat staan de dagelijkse files..

Nu bijna iedere dag slechts 40 minuten in de trein (enkele reis) tegen 1 uur met de auto. Daarbij lekker tukkie doen s'ochtends. En die ene keer in de week dat ze vertraging hebben, weegt niet op tegen die 5 keer vertraging met de auto door files.
Het is maar net vanaf welke kant je het bekijkt..

Elke vertraging is vervelend. Maar deze keer in ieder geval een duidelijke uitleg wat er mis is gegaan.

Daar noem je ook een traject/route Ik werk in Den Haag en mijn collega's uit Rotterdam komen tegenwoordig al op de scooter omdat zowel de trein als de auto een ramp is

Overdrijven is ook een vak

Misschien, toen ik nog naar school ging hoefde ik maar 1 traject, simpelweg A naar B en daar had ik eigenlijk zelden problemen, want 5 minuten vertraging..soit. Die kwamen echter wel toen ik ging werken en ik 1,2,3 keer moest overstappen. Als je dan 5 minuten vertraging hebt wacht de ene trein niet meer op de ander, dat was 20 jaar geleden nog wel het geval. Smeer dat gegeven uit over 2 keer overstappen en je 5 minuten wordt een half uur of langer. Daarom vind ik ook dat de vertragingen niet per trein maar per persoon moeten worden gemeten. Wordt het beeld toch even anders en blijkt dat ik niet overdrijf.

Om dan nog niet te spreken over een kort traject waar een springer( ) is.
Dan is de vertraging soms uren en gratis bussen ter vervanging laten dan minstens een uur op zich wachten.

Niet de schuld van NS of ProRail, maar wel vervelend.

[Reactie gewijzigd door SirJMO op 4 februari 2015 09:21]

Dat is helemaal waar natuurlijk, even niet over nagedacht. Ikzelf heb eigenlijk nog nooit echt problemen gehad (5dagen per week van sneek naar leeuwarden). En ook de keren dat ik verder met de trein moest en ook minimaal 2x over moest stappen heb ik geen vertraging ondervonden. Maar ik kan mij voorstellen dat mensen die vaker een lang traject reizen hier wel last van hebben.

Los het nou eens op! Vind ik veel belangrijker dan de schuldvraag.

Ben het hier wel mee eens, maar ik denk toch dat er eerste naar de schuldige/het precieze probleem gezocht moet worden voordat er aan een oplossing gedacht kan worden

Oplossingen zijn het probleem niet.

Maar oplossingen zijn dan een oplossing voor het probleem.

"Prima, teken hier bij het kruisje, dan worden de treinkaartjes met 300% verhoogd, zodat u storingsloos kunt reizen!"

Nee, het moet allemaal gratis. Management verschilt niet zoveel van de gemiddelde burger.

Volgens mij is tier 4 het hoogste, waar wiki het ook mee eens is.
http://en.wikipedia.org/wiki/Data_center#Data_center_tiers

Tier 4 is niet mogelijk in NL. Je hebt hier een dubbele infrastructurele leverancier voor stroom voor nodig. En die hebben we niet in NL.

http://www.previder.nl/Ov...center-tier-classificatie

Op zich mee eens, echter lijkt mij een eigen generator (wat een ziekenhuis ook heeft) een vorm van een dubbele infrastructurele leverancier voor stroom.

Dat is een toer 3 datacenter. Sterker nog dat zijn er meestal twee dieselgeneratoren.

Niet dat het heel veel uitmaakt. Als ons enige hoogspanningsnet plat ligt, dan rijden er sowieso geen treinen meer.

Interessant dat er zoveel informatie over gegeven wordt, bij een volledig private partij met meer concurrentie dan ProRail zie ik het niet zo snel gebeuren!

Tier 3, redundant uitgevoerd... Dat klonk op papier voor de CIO vast allemaal heel goed totdat het daadwerkelijk uitviel. Ik waag te betwijfelen dat de betrokken ontwikkelaars en beheerders net zo zeker waren van de fallbackmogelijkheid als de directie. Dit soort systemen zijn natuurlijk nooit echt helemaal te testen in zo'n extreem scenario als hier - maar de pijnpunten moeten toch vantevoren te lokaliseren zijn.

Tegenwoordig is het niet meer mogelijk terug te vallen op een systeem volledig zonder computers - dat is te begrijpen. Wat niet is te begrijpen is dat er 'redundante' oplossingen zijn die gebruik maken van dezelfde dataservers. Wat wellicht handig zou zijn is in dit soort kritieke rollen systemen niet dubbel uit te voeren - maar daadwerkelijk redundant, bijvoorbeeld door een werkbare/goedkopere backup te hebben. Stel je PC van $3000 is kapot, dan heb je nog die oude $400 versie. Ja, er zit geen SSD in, maar je kunt wel bij je email.

Stel je PC van $3000 is kapot, dan heb je nog die oude $400 versie. Ja, er zit geen SSD in, maar je kunt wel bij je email.

Die vlieger gaat alleen niet op als die PC verantwoordelijk is voor het in banen lijden van al het treinverkeer rond Utrecht. Dan is die $400 versie leuk om nog 1 spoor aan te sturen, maar alle tig sporen gaat dan niet werken; en aan slechts 1 spoor heb je he-le-maal niets. Kan je misschien 1 route weer werkbaar maken, en daar blijft het bij. (En let's face it: ALS dat kan, dan krijgt eerder het zakelijke goederen vervoer voorang, niet het personen vervoer )
Net als dat jou $400 pctje misschien nog leuk is om je mail te lezen/tekst te verwerken, maar een film kijken of een game spelen: ho maar.

Je kan wel *noodvoorzieningen* inrichten, uiteraard; maar dat zou impliceren dat het normale systeem extra/niet werkelijk noodzakelijke luxe heeft ingebouwd zitten, en dat lijkt me eigenlijk stug... Een wissel/sein aansturen gaat niet beter werken door overbodige luxe in te zetten; het is namelijk pure noodzaak dat dit uberhaupt werkt.

Het gaat hier tevens om redundantie, en niet per definitie om een fallback; waar jij het meer over hebt. De infrastructuur moet te allen tijden de mogelijkheid hebben om de wissels/seinen aan te sturen. Als dat 2 systemen zijn die apart van elkaar werken, heb je het eigenlijk over een redundant uitgevoerde infrastructuur. Als beide systemen falen en er is nog een noodvoorziening, dan is *dat* je fallback; maar die moet dan wel voldoende capaciteit hebben om tenminste nog treinverkeer mogelijk te houden (bijvoorbeeld: geen info borden, niet bijhouden van vertragingen: maar wel treinverkeer.): anders is je fallback compleet waardeloos.

Hier lijkt zowel de redundantie als de fallback gewoon volslagen brak in elkaar te zitten: het werkt namelijk niet/is totaal niet berekend op het nog mogelijk maken van treinverkeer.

[Reactie gewijzigd door WhatsappHack op 3 februari 2015 20:31]

Ik ben het met je eindanalyse wel eens hoor: er was niet daadwerkelijke redundantie.

Het punt van 400/3000 is de fractie. Een redundant systeem kost vaak 1/1 van het systeem zelf, soms zelfs *meer* dan 100% van het initiele systeem (.. I know). In goede gevallen is het 30% van het systeem zelf... Ik vraag me af of een brakke oplossing niet voor dat geld gemaakt kan worden die toch werkbaar is voor 1 dag. Bijvoorbeeld: het systeem kan alleen treindiensten aan op centrale trajecten. Of, alleen diensten tot een andere regio. Of, alleen diensten van sprinters. Of, alleen diensten ....

Nou ja, je snapt hem wel. Het gaat niet om super-cheap, maar om de fractie ten opzichte van daadwerkelijke redundantie - die hier met een hoog prijskaartje toch niet bleek te doen waaar hij voor was.

Ben ik de enige die zich afvraagt waarom een overheidsbedrijf als Prorail in een datacenter van British Telecom zit en niet in een Nederlands datacenter?

En waarom zou dat niet kunnen? Ben benieuwd wat je beweegredenen kunnen zijn. Het DC staat op Nederlands grondgebied is waarschijnlijk via een Europese aanbesteding gegund en voldoet dus aan de eisen die Prorail heeft gesteld.

Ik zie liever dat data over Nederlandse infrastructuur bij een Nederlands bedrijf staat.
In België waren ze een tijdje terug ook minder blij met de Britse geheime dienst.

Daarnaast zie ik liever dat de overheid zijn geld binnen Nederland besteed. Dat lijkt me beter voor Nederlandse bedrijven en de hele economie hier.

Maar misschien moet ik wat meer in 1 Europa gaan denken.

Dit datacenter valt gewoon onder het bedrijf "BT Nederland", een dochter van het britse BT. Dit soort dochters worden *juist* opgericht ten behoeve van sentimenten zoals deze.

De data gaat juist over NL infrastructuur daarom dat de dienst ook draait in een NL datacenter. Daarnaast heeft BT een entiteit in NL dus geld blijft binnen de Nederlandse BV. BT is een bedrijf wat global opereert zo hebben ze waarschijnlijk vele datacenters in de wereld staan.
Neem KPN als voorbeeld: hoe NL is dat eigenlijk nog...

Prijs/kwaliteitverhouding waarschijnlijk. Het maakt weinig verschil voor dit soort systemen, tenzij er oorlog uitbreekt (maar daar is de backup voor! ); maar als je daar de hele tijd bang voor moet zijn kan je als land met helemaal niemand zaken meer doen, moet je alles intern houden en alles in het beheer van de overheid houden; totaal geen privatiseringen doorvoeren...

Goed idee: goed voor werkgelegenheid lokaal, goed voor onze eigen economie, goed voor onze infrastructuur. Welke politieke partij is het met me eens? Geen een.

Leuk zo, dat stemrecht en die democratie.

(niets ten nadele van jou hoor)

De SP is het met je eens, die hebben immers communistische roots.

het is toch een nederlands datacenter, in nieuwegein!?
Britisch Telecom zit gewoon in nederlands, zoals een andere nederlands bedrijf!

Volgens mij is Prorail zelf niet direct een overheidsbedrijf, maar is Prorail een dochteronderneming van Railinfratrust BV.

Oké, lees net dat Railinfratrust BV wel in handen is van de overheid, wat dus inhoudt dat Prorail ook gewoon eigendom is, weleens waar indirect, van de overheid.

Dus niet, dat is gewoon van Prorail. Alleen daar waar niks van Prorail ligt word gehuurd bij andere partijen.
(tenminste dat heb ik me laten vertellen).

Volgens mij hebben ze gewoon gelijkstroom op een wissel gezet. En ja, daar had natuurlijk wisselspanning op gemoeten

[Reactie gewijzigd door Thasaidon op 4 februari 2015 11:16]

Hmmm, idd

BT is in 1997 samen met de NS de joint venture telfort begonnen.
De NS had amper gebruikt glasvezel in de grond langs het spoor en daar kon BT mooi gebruik van maken.
Bij ons in Deventer op het station stond jaren zo'n mooie Telfort telefooncel.

ProRail zegt ondanks een forse investering ict-storingen nooit helemaal te kunnen voorkomen. Het bedrijf heeft sinds 2007 ruim 100 miljoen euro geïnvesteerd in verbeteringen aan de verkeersleidingsystemen. Het gaat daarbij onder andere om het upgraden van rekencentra en dubbele computersystemen en netwerken.
Voor een vermogen geïnvesteerd, nul rendement!

Ach, de laatste keer dat een trafo-huisje uitbrandde lag Utrecht 5 dagen plat... Dus an sich is dit al een verbetering Dat ik nooit geloof dat die 100 miljoen goed besteed zijn is wat anders, ik denk dat vele bedrijven daar een beter systeem voor kunnen leveren. Echter kunnen die niet de vereiste bullshit-papieren (certificeringen, EU-opdrachten en andere rotzooi) laten zien, dus die krijgen de job niet. Overhead overhead, all in over your head.

had je anders verwacht?