De technische storing in het IBM-mainframe, die op zondag 27 oktober 2013 diverse systemen bij de Dienst Uitvoering Onderwijs (DUO) platlegde, heeft verschillende soorten schades veroorzaakt. Pas na afronding van de inventarisatie van de aard en de hoogte van de totale schade zal DUO bij ict-infrastructuurbeheerder KPN een mogelijke schadeclaim neerleggen. Ook vindt er nog een evaluatieonderzoek plaats naar de storing.
Dit blijkt uit de beschikking die het ministerie van Onderwijs, Cultuur en Wetenschap (OC&W) opstuurde, naar aanleiding van het door Computable opvragen van documenten over de storing op basis van de Wet Openbaarheid van Bestuur (WOB). Daarin wordt gesproken over een complicerende factor bij het bepalen van de aard en hoogte van de schade, namelijk dat er sprake is van ‘verschillende soorten schades met elk hun eigen kenmerken’.
Extra handmatig werk
De storing in het mainframe legde vanaf eind oktober 2013 tot 4 november het studiefinancieringssysteem en het portaal Mijn DUO plat. Ook het personeelszakensysteem van Raet zou er uit hebben gelegen. Studenten konden door de storing niet inloggen op Mijn DUO. Medewerkers van de uitvoeringsorganisatie van OC&W waren niet in staat het studiefinancieringssysteem te raadplegen als studenten belden, mailden of langskwamen. Wel konden studenten via de website van DUO een aantal formulieren downloaden om bijvoorbeeld wijzigingen in de studiefinanciering door te geven.
De storing leidde tot veel extra werk in de uitvoering bij DUO, omdat medewerkers wijzigingen van klanten handmatig moesten noteren en, nadat de storing was opgelost, in het systeem moesten invoeren. DUO laat, sinds de systemen weer in de lucht zijn, het portaal Mijn DUO zwaar monitoren.
Catalog-fout
Volgens KPN is de storing veroorzaakt door een samenloop van twee omstandigheden: een fout in de replicatie van data tussen twee datacenters in combinatie met een geplande uitwijktest. De storing zorgde ervoor dat systemen niet benaderbaar waren en applicaties op die systemen niet gebruikt konden worden.
Uit een vrijgegeven WOB-document blijkt dat na het opstarten van het mainframe op de uitwijklocatie er een verstoring in het opslagsysteem plaatsvond. Daardoor ontstond er een inconsistentie in de z/OS Catalogs. Deze catalogs, die aangeven waar op welk volume een dataset is opgeslagen, verwezen in een aantal gevallen naar verkeerde locaties. Vervolgens werd het ‘shared mainframe platform’ onbruikbaar en konden de klantapplicaties niet meer beschikbaar worden gesteld (zie afbeelding).
Complex
Maar wat precies de oorzaak is geweest, wil DUO noch KPN aangeven. KPN, die als ict-infrastructuurbeheerder optreedt voor DUO, spreekt van een complexe storing. Een woordvoerder van het DUO stelt: ‘De oorzaak was een fout bij KPN waarvan niet aannemelijk is dat die zich zal herhalen.’
Computable deed vervolgens een beroep op de WOB en vroeg de documenten op die te maken hebben met de storing. Het ministerie van OC&W, waar het DUO onder valt, wees het verzoek grotendeels af. Slechts drie van de 34 geïnventariseerde documenten zijn openbaar gemaakt, waaronder een persbericht en de pdf’s ‘DUO event map Mainframe verstoring’ (zie afbeelding hierboven) en ‘DUO proces uitwijktest Mainframe’ (zie afbeelding hiernaast).
Afwijzen
Het ministerie staat op het standpunt dat openbaarmaking van de andere 31 documenten ‘de positie van DUO bij de contractuele afhandeling van de storing en de bepaling van (de hoogte van) een mogelijke schadevergoeding zou kunnen verstoren.’ De juridische dienst van OC&W voert ook nog aan dat openbaarmaking van de betreffende documenten DUO onevenredig zou benadelen, omdat de uitvoeringsorganisatie met KPN afspraken heeft gemaakt over de woordvoering omtrent de storing. ‘Openbaarmaking zou ingaan tegen de afspraken rond de woordvoering en tevens de onderhandelingspositie van DUO kunnen verstoren en zo onevenredig kunnen benadelen’, schrijft de dienstdoende jurist.
Wat OC&W met dit laatste punt bedoelt, wordt verder niet duidelijk gemaakt. Computable tekent bezwaar aan tegen deze beschikking.
Worden hier IBM en z/OS niet onnodig te kakken gezet? Een mainframe van een andere leverancier en een besturingssysteem van een andere leverancier hadden het probleem voorkomen?
In mijn begintijd (1979), werd altijd de uiterste consequentie van Murphy’s law getoetst en werd alles voorbereid ter voorkoming van problemen bij een bank. Ik heb het gevoel dat men tegenwoordig in algemene zin aanzienlijk minder voorzichtig is geworden.
Misschien dat de redactie een fantastische grap van vroeger hier opnieuw kan plaatsen. De tekst was een inzending ihkv een wedstrijd en ging over het veiligstellen van een backup.
Is 1x per jaar testen in zo’n omgeving niet een beetje aan de lage kant?
IBM mainframe en z/OS treft m.i. geen blaam, het lijkt mij eeder een kwestie van verwaarloosd beheer. Als jullie bij Computable geïnteresseerd zijn in de achterliggende oorzaken kijk dan eens naar de voorwaarden waaronder de outsourcing naar KPN tot stand is gekomen. Kan, cq. wil KPN wel de benodigde (beheer)kwaliteit leveren voor de prijs die is afgesproken?
Henk,
Goede toevoeging. De gemaakte afspraken verschillen nog wel eens in de praktijk met de verwachtingen. Wie weet is dit helemaal niet genomen in de contracten/SLA’s.
Ik ben benieuwd of hier wat meer informatie over gedeeld kan worden zodat er een eerlijk beeld geschapen kan worden.
En dan gaat dit fout tijdens een gecontroleerde uitwijktest (Failover test). Moet er niet aan denken als dit een keer ongecontroleerd gebeurt (bijv. explosie of brand in primaire locatie). In dat geval is het ook niet zeker of de data wel helemaal consistent is. Als daarop de hele applicatie omvalt is er toch een serieus probleem.
@Erwin
Je haalt aan wat ik dacht, als de oorzaak ligt in replicatie van data tussen twee datacentra dan is het maar de vraag of je werkelijk een uitwijk hebt. Misschien een ongelukkige samenloop van omstandigheden maar consistentie van de data wordt op deze manier wel heel onzeker.
Zonder direct in conclusies te springen lijkt storage als gebruikelijke abstractie neergezet, richting van de pijltjes is trouwens opmerkelijk in het plaatje.
@ Erwin en Ewout,
Zonder consistente data ben je nergens. Dat ben ik helemaal met jullie eens.
Door geregeld de gerepliceerde data te testen voorkom je dit soort uitdagingen.