De uitval van een computer bij Prorail en het falen van redundantie leidde tot ernstige vertraging voor reizigers. VVD-Kamerlid Fahid Minhas vraagt staatssecretaris Vivianne Heijnen (Infrastructuur en Waterstaat) hoe het kan dat in twee jaar tijd drie storingen in digitale systemen het spoorverkeer in de soep laten lopen.
Rikus Spithorst, voorzitter van de Maatschappij voor Beter OV, in een recente column: ‘Maar goed, ik leg het nog één keer uit. Jongens en meisjes van Prorail: de bedoeling van een redundant systeem (dat door de belastingbetaler en de reiziger voor jullie is betaald) is dat dat in werking treedt als het primaire systeem het begeeft. Ingewikkelder is het niet.’
Wat was er gebeurd? In een verkeersleidingpost van de spoorbeheerder begaf een computer het; vervolgens weigerde het vervangende systeem dienst, waardoor in grote delen van het land treinen stil kwamen te staan. Vervolgens lichtte de NS de reizigers onvoldoende in over de ontstane situatie; raadde hen zelfs aan zelf transport te regelen. Chaos na computerblunder heette het in de termen van Maatschappij voor Beter OV.
Stresstest
Kamerlid Fahid Minhas (VVD) vraagt de staatssecretaris of zij bekend is met het feit dat in 2015 een stresstest is uitgevoerd naar de ict-systemen van Prorail. ‘Welke lessen zijn daaruit geleerd? En hadden de verstoringen van 2021 en 2022 in dat licht voorkomen kunnen worden?’, aldus Minhas.
‘Ik maak mij hard voor het op duurzame wijze verkleinen van de reistijden, met daarbij oog voor de grensregio’s, steden en onze buurlanden’, meldt de staatssecretaris op de website Rijksoverheid.nl. Het kan nog wel even duren voordat zij antwoord geeft op de vragen van Minhas, omdat de regering op reces is tot 5 september.
Minhas wil weten of de bewindsvrouw een nieuwe stresstest bij de ict-systemen van de spoorbeheerder wil laten uitvoeren.
In het AD reageerde een woordvoerder van Prorail op het falen van het backup-systeem. ‘Er wordt uitgebreid onderzoek gedaan naar de oorzaak, maar het lijkt dat dit komt vanwege een fout in de software. Meerdere systemen werkten hierdoor niet meer.’
Een redundant systeem biedt geen 100% zekerheid als we kijken naar software fouten, een dual systeem welke onafhankelijk is lijkt me dan een betere optie maar de vraag is of we wel dat soort systemen willen hebben als dit betekent dat we dan dubbel zoveel energie nodig hebben.
Wie zelf op een IT afdeling heeft gewerkt weet dat buitenstaanders vaak verwachten dat IT-ers tovenaars zijn en alles moeiteloos kunnen oplossen. De praktijk is helaas anders. Redundante systemen moeten regelmatig getest worden. Daarvoor is een testplan nodig en een moment in de tijd waarop alle belanghebbenden het eens zijn dat die test mag plaatsvinden (niet bij de maandafsluiting bijvoorbeeld!). Het plan moet door changeboards worden goedgekeurd en alleen de goedkeuring ervan mag soms bij zeer kritische systemen al een wonder heten. Dan moeten er nog mensen worden gevonden in de sowieso al zwaar overbelaste IT afdeling die het kunnen uitvoeren en de hele test moet minitieus worden gerapporteerd, ook daar heb je weer kennis en mensen voor nodig. Die kennis ontbreekt vaak uberhaupt al, want IT-ers zijn dun gezaaid en tegenwoordig zijn de meeste systemen zo ingewikkeld geworden dat je al met een team van 10 man bij elkaar moet komen om zelfs de eenvoudigste problemen opgelost te krijgen. Bovendien zijn vaak componenten uitbesteed aan derden, die je dan ook maar gecharterd moet zien te krijgen, ook voor de test. Verder gaf de vorige reageerder al aan dat geen enkel redundant systeem 100% betrouwbaar is en zelfs de test kan er toe leiden dat de hele redundante setup uitvalt. Daarvoor moet dan weer een disaster-recoveryplan klaarstaan, dat ook getest moet zijn enz.
Bij de afdeling waar ik zelf als architect heb gewerkt werd er soms wel gegrapt dat de eenvoudigste test bestond uit het ‘per ongeluk’ laten omvallen van een kopje koffie over het systeem. Een uitval daardoor vereist tenslotte geen goedgekeurd plan en er is meteen ook een noodsituatie waardoor alle partijen wel móeten opdraaien, alle agenda’s ten spijt.
Zo ziet onze infrastructuur er heden ten dage uit en niet alleen bij Prorail. Vrijwel elk systeem dat ik ken is zo zwak dat er maar iets hoeft te gebeuren en er is paniek. Bij het MKB is het vaak nog erger want die hebben al helemaal geen mensen hiervoor.
Toch blijven we met z’n allen maar doorbouwen op deze gammele fundamenten onder druk van managers en politici die bang zijn dat we ‘achterop’ raken als we niet voortdurend innoveren. Tel er de almaar toenemende cyberdreigingen bij op en het is slechts een kwestie van tijd voordat de hele boel eens echt finaal instort. Ik krijg visioenen van flatgebouwen in Cairo waar ook elke keer maar weer een nieuwe verdieping op wordt gezet, ondanks tegenwerpingen van de architecten.
Het komt allemaal door “een fout in de software”
eerst alles as a service as code en dan gaat het daarin weer mis..
voor zichzelf heeft regering blijkbaar minder behoefte aan continuiteit en redundantie, ze gaan gewoon tot 5 sept met reces.
wat betreft de conclusies van 2015.
ik dacht ik kijk ff voor de grap op die link naar Externe partij onderzoekt storing Prorail..
“Pas toen we werkplekken hebben uitgezet en het systeem lucht hebben gegeven, kon de treindienst opgestart worden.”
Meer lucht geven dus.. hoe zou dat moeten.. Misschien met het uitzetten van de werkplekken ?
Dus niet mee bemoeien, kan je het ook niet kapot maken en met beetje geluk lost het zichzelf op.
Dacht Trump ook, met die Coronacrisis.
Maar goed. de conclusie dus : Om u nog beter van dienst te kunnen zijn zetten we de werkplekken uit en gaan we naar huis.
Klinkt inderdaad als een plan, zeker vrijdagmiddag.
Fijn weekend
Naast anonieme reacties moeten we vooral af van systemen en het bijbehorende systeemdenken.
@Rob van Linden, er zijn genoeg bestaande en denkbare architecturen waarbij van die geschetste problematiek helemaal niets meer overblijft. Hoe zou fail-save karakter en de testbaarheid daarvan zich geheel kunnen onttrekken aan iedere vorm van innovatie en voortschrijdend inzicht? Ik ben wel met je eens dat het overal een ondergeschoven kindje is en dat we ons op dat vlak nog maatschappijbreed in de tachtiger jaren bevinden. Maar technisch is daar geen enkele reden voor aan te wijzen. Kwestie van architectonisch onderhoud, prioriteiten en schaarste zoals jij ook al beschrijft.
Oh ja, en een kwestie van weerbarstigheid door gevestigde belangen in de bestaande situatie. Dat is waarschijnlijk meestal de belangrijkste oorzaak.
Wat betreft de gebruikelijke zure reacties van Dino, de fouttolerantie van een systeem omvat meer dan software/hardware als we kijken naar de som der delen van het systeem. En het is niet altijd de techniek die faalt als we kijken naar het organiseren van het beheer. Link naar 2015 lijkt me om het configuratiemanagement te gaan:
“…een te zware belasting op het systeem waar de data wordt opgeslagen…”
Service-as-code klinkt als fouttolerantie omdat de portabiliteit van de workload vergroot wordt, ik verplaats deze binnen enkele seconden. Een bewezen strategie zoals referenties kunnen bevestigen hoewel er wel eisen zijn aan de service zelf, de kwaliteit van de data aangaande de status van seinen moet correct blijven. Ik denk dat Dino het verschil wel weet tussen schrijven/wijzigen en lezen want redundantie op data niveau betekent schrijven met een vork. Monoliet van een database vormt vaak het gammele fundament waar met het idee van een Service Oriented Architecture vele verdiepingen bovenop zijn gezet. De data architectuur hierin gaat om een circus aan olifanten en service-as-code om het publiek naar het circus te brengen.
“Meer lucht geven dus.. hoe zou dat moeten..”
Configuratiemanagement is een proces in de ‘systeemkunde’ voor het vaststellen en onderhouden van een product of object waarbij men functionele en fysieke kenmerken kan aangeven met daarin de vereisten en operationele informatie gedurende de levenscyclus. Leerde ooit eens dat onderdeel van het configuratiemanagement de beoordeling van de bezettingsgraad omvat want het opschalen is makkelijk als je voldoende reserve capaciteit hebt. Gezien de wens om het allemaal efficiënter te willen doen ben ik benieuwd hoe goed dit proces ingevuld is.
Misschien dat Rob als architect hier wat over kan zeggen want gebruikelijke CMDB kijkt niet meer
naar de infrastructuur, de ontkoppeling van functionele en fysieke kenmerken gaat niet om een flat in Caïro maar een luchtkasteel in Den Haag. Architecten zijn in het circus van modellen de clowns die nu pas tot het besef komen dat er geen draadloos stroom is, fysieke realiteit van de infrastructuur gaat om wetmatigheden die met een zekere foutmarge redelijk voorspelbaar zijn als we kijken naar de wet van Murphy. Een gek kan meer vragen dan 10 wijzen kunnen beantwoorden, Fahid Minhas stelt namelijk retorische vragen wat leuk is voor de bühne maar zonde van de tijd.
Voor Jack, het filosoferen zonder rekenschap te geven aan de onderlinge afhankelijkheden leert dat je gedoemd bent de geschiedenis te herhalen. Aangaande de bestemming, de ordening en de relatie rijden treinen al eeuwen niet op tijd maar op rails en die zijn essentiëler dan de locomotief die van stoom naar stroom is gegaan.
De ‘systeemkunde’ gaat tegenwoordig om een verzameling systemen met het loketdenken zonder enige samenhang, neem de bestemming, de ordening en de relatie in het OV. Grote kans dat je met de bus naar de trein moet en vervolgens weer de bus moet nemen om je bestemming te bereiken. Ik kan me voorstellen dat je hiervoor een beslissingsmodel hebt voor de planning of filosofeer je maar op goed geluk?
Wel bij de les blijven Jack want van A naar Beter is het de vraag of we nog moeten investeren in een vervoerssysteem uit 1800 en een beetje, duur en onbetrouwbaar als we kijken naar Uber…..
@Oudlid, bedoel je Rob van Linden? Ik ben geen architect. Sinds ik de laatste weken 25 keer langer bezig ben testen en foutzoeken dan met de code schrijven, heb ik ook geen tijd meer voor gratis consult :-). Vervangende systemen weigeren niet vervolgens dienst. Dat kan ik je er nog wel over vertellen. Sinds 2006 of zo geeft iedere gratis hypervisor je de mogelijkheid om meerdere versies van je productieserver met een minuutje achterstand of zo permanent mee te laten draaien. Zoals gewoonlijk lijkt ook dit overheids- of semi-overheidsgeval weer een volslagen belachelijk verhaal. Ik ken de details niet maar ik durf te wedden dat de Rekenkamer weer à la politie over één groot tranendal gerept zou hebben. Schouders ophalen en zo weinig mogelijk mee bemoeien is al een jaar of 12 mijn devies. Er vallen geen dooien en je maakt er bovendien alleen maar vijanden mee.
Hoe ‘begeeft’ een computer het, bovendien? Als sinds 2012 kun je voor iedere server-licentie kiezen of je 1 fyiek, 1 virtueel of 2x virtueel wilt draaien. Dat betekent dus dat je met 5 of 6 enerprise licenties een cluster kunt draaien waarbij een applicatie virtual op vijf verschillende nodes kan draaien en er drie of meer nodes uit moeten vallen voordat er storage partities sneuvelen. Dit is dus niet iets bijzonders. Dit is waar ieder slagerij-op-de-hoek clubje zoals wij standaard mee draaien. En – als dat allemaal te moeilijk is – waarom gaan ze dan niet gewoon naar Azure of AWS? Toch weer een gratis consult.
t