Na de mislukte softwareupdate om de performance van het Mijn UWV-portal te verbeteren, proberen de betrokken leveranciers IBM en Unisys de oude situatie van medio december te herstellen. Is die weer in de lucht dan wordt gekeken hoe er alsnog een vernieuwde portal kan worden gebouwd. Intussen is het Uitvoeringsinstituut Werknemersverzekeringen (UWV) noodgedwongen overgegaan tot het printen en versturen van de betaalspecificaties van uitkeringsgerechtigden.
De website Mijn UWV ligt al een week plat. Via de site worden normaal gesproken betaalspecificaties digitaal verstuurd en kunnen mensen de status van hun ww-aanvraag bekijken, wijzigingen via e-formulieren doorgeven en een jaaropgave downloaden. Werknemers kunnen er met hun DigiD controleren of hun arbeidsverleden correct staat weergegeven.
Mijn UWV is ontwikkeld binnen een .Net-framework, werkt met een Oracle-database en draait op een Wintel-platform. Door het groeiend aantal werklozen kampte de site, die al een aantal jaren in de lucht is, afgelopen december met performanceproblemen. Om die op te lossen voerden de leveranciers IBM en Unisys samen met de ict-afdeling van het UWV een software-update door. ‘Die haalde echter het systeem onderuit’, vertelt Wessel Agterhof, woordvoeder van de uitvoeringsinstantie.
Dig-iD
De oorzaak van de crash is nog steeds onduidelijk, zegt Agterhof. Daarbij speelt mee dat testen lastig is omdat het achter een DigiD-omgeving plaatsvindt. ‘De softwareupdate is wel getest, maar eigenlijk beschikt het UWV over te weinig nep-inschrijvers – niet-bestaande DigiD’-inlogcodes en Burgerservicenummers – voor een soepel testtraject. Wij zijn benieuwd hoe andere instanties die met DigiD werken daarmee omgaan.’
Volgens Agterhof komt dit in de evaluatie met de leveranciers zeker op tafel, net als het achterhalen van de oorzaak. Maar eerst moet het portaal weer in de lucht. Er is daarom voor gekozen om de oude situatie van half december – en de performanceproblemen voor lief te nemen – weer te herstellen. De zegsman verwacht dat dit op zeer korte termijn is gerealiseerd, maar kan geen harde datum noemen. Wanneer de oude site weer draait, gaat het UWV met de leveranciers een planning maken voor een vernieuwd en wel beter presterend portaal.
Per post
Het UWV heeft inmiddels een telefonische helpdesk ingericht die ook in het weekeinde bereikbaar is voor het doorgeven van wijzigingen of andere vragen. Ook heeft het UWV besloten de betaalspecificaties tijdelijk weer te printen en per post te sturen. De uitkeringsinstantie heeft beloofd geen sancties te zullen opleggen wanneer een wijziging te laat binnenkomt. ‘Gelukkig hebben we nog veel ervaring met handmatige en papieren verwerking van dit soort processen. Daardoor konden we de gevolgen van de crash opvangen’, aldus Agterhof.
Afgelopen december kapte het UWV ook al met performanceproblemen rond de vacaturesite Werk.nl. Die problemen zouden na het doorvoeren van een aantal verbeteringen zijn opgelost. Woordvoerder Agterhof stelt dat deze website momenteel goed draait, net als de organisatiewebsite Uwv.nl.
Door het groeiend aantal werklozen kampte de site,…..Ja hoor geef de werkelozen maar weer de schuld, ze zijn de reden van jullie bestaan EN de banen bij UWV zelf;-)
Ik ken de details niet, maar wil wel een opmerking plaatsen.
Men roept wel eens dat cloud computing gevaarlijk is omdat je mogelijk ineens geen toegang meer hebt tot je data. In gevallen zoals deze zie je dat er veel meer mogelijkheden zijn om niet tot je data te komen. Het uitval risico is er dus altijd, cloud of geen cloud.
Voordeel van cloud computing is dat je relatief goedkoop een volledige productieomgeving kunt nabootsen waarop je dus de update op uit kunt proberen.
Een techniek die Windows Azure bijvoorbeeld gebruikt is dat je een Staging Area op kunt zetten welke een exactie kopie is van je productieomgeving. Pas als deze staging area getest en geaccepteerd hebt kun je de staging area swappen met de productie omgeving.
Geen downtime en geen verassingen.
Het product (UWV portal) is niet opgezet met een cloud-computing gedachte. Zo lijkt het (en tik op mijn vingers als ik het fout heb) alsof de software geschreven is naar DIGID toe. Dat is fundamenteel fout. Je software moet moet losstaan van je authenticatie en per definitie niet afhankelijk zijn van een derde partij. Deze moet plugbaar, vervangbaar zijn zonder dat je de software hoeft aan te passen (of down te brengen). Een fout die je bijvoorbeeld ook zag in de Diginotar zaak. Certificaten moeten plugbaar en vervangbaar zijn.
Net als dat IP adressen niet boeiend zouden moeten zijn en hot swappable.
Daarnaast constateer ik hierbij (aangezien het dagen duurt) dat er niet echt een voorbereiding was op dit scenario. Nu weet ik niet wat de impact is, maar kan me voorstellen dat deze toch wel aanzienlijk zijn.
Op z’n minst één van de genoemde partners zal nu ‘minder blij’ zijn om genoemd te worden.
Want wees eens eerlijk: ‘eigenlijk beschikt het UWV over te weinig nep-inschrijvers – niet-bestaande DigiD’-inlogcodes en Burgerservicenummers – voor een soepel testtraject’ is een wel héél erg mager excuus om geen geanonimiseerde testbestanden voorhanden te hebben. Zo’n zeperd zou ik ook niet graag in mijn bedrijfs-CV genoemd willen hebben.
Dit is te gek voor woorden. Dat ze nep inschrijvers nodig hebben betekent dat ze testen op de productie systemen OF dat de productie en (acc) test omgevingen niet voldoende van elkaar afgeschermd zijn!
In een moderne omgeving heb je je machines gevirtualiseerd. Voor de OTA omgevingen kan je dan gewoon een kopie maken van je productie systemen. Die stop je dan in een ander (sub-) netwerk zodat je zeker weet dat je niet op de prod omgeving zit. Voor de test omgeving kan je dan resources knijpen om overload te simuleren. Bovendien kan je echte geaninimiseerde data gebruiken. Er zijn mooie niet te dure tools om data te anonimiseren…
Voor het ontstaan van het UWV heb ik bij een van de toenmalige uitkeringsinstanties gewerkt, om een nieuw (want object-georiënteerd, met een relationele database eronder) systeem te testen.
Hierbij moesten we “verzekerden” opvoeren. Hun gegevens werden getoetst aan een landelijk systeem waar alle SOFI-nummers in zaten. Dit landelijke systeem had in 2001 geen testomgeving.
We konden dus alleen testen met sofinummers van echte mensen. Waar haalden we die vandaan? Gewoon aan de collega’s vragen wat hun sofinummer was. Het was natuurlijk onmogelijk om op deze manier een grote testset op te bouwen.
Sofinummer heet nu burgerservicenummer en we zijn bijna twaalf jaar verder.
Blijkbaar heeft de GBA-personen nog steeds geen testomgeving ten behoeve van andere partijen.
Wat een treurnis!
Tegelijk: wat een kans voor particulier initiatief. Bied een web-interface aan dat identiek is aan dat van de GBA-personen, alleen vol fictieve personen. De gebruikers van deze faciliteit betalen bijvoorbeeld een vast bedrag per aansluiting of abonnement en/of per raadpleging en ze kunnen hun eigen testsets uploaden.
Om zo’n zeperd als nu bij het UWV te voorkomen (slecht voor het imago van het UWV, vervelend voor de gebruikers en een dure grap voor het UWV) zou enkele tienduizenden Euro’s voor een abonnement op zo’n testomgeving de moeite waard zijn.
Behalve het UWV zijn er vast nog wel wat instanties die met hetzelfde probleem zitten, de KvK en de verzekeringsmaatschappijen om er een paar te noemen.
@Rob Jasper
De Digi-ID omgevingen zijn niet in beheer bij het UWV. Dat is een platform van de rijksoverheid.
UWV is daarbij vermoedelijk slechts een partner die maar een beperkt hoeveelheid test gegevens op die omgevingen kan/mag gebruiken.
Performance testen op de aceeptatie omgeving is dan bijvoorbeeld heel moeilijk.
@Henri
Je geeft een oplossing aan waarmee dit mogelijk voorkomen had kunnen worden.
Echter, kijk ik naar de omvang van het probleem, dan zou ik eerder een groot vraagteken zetten (ook ik ken de details niet) bij de hele acceptatietest vooraf.
Daar helpt ook jou oplossing volgens mij niet meer aan (alle goede bedoelingen ten spijt)
Beste Rik,
Nep inschrijvers, nep Digidcodes en BSN’s zullen het ook nooit doen, dat vraagt om problemen. Komt wat onprofessioneel over. Het gaat dus echt om test personen, test Digid codes en test BSN’s.
Waarschijnlijk geen marge meer over in de business case om een gedegen test traject op te zetten lijkt mij. Leve uitbestedingstrajecten !
Wat ik het voorgaande mis is, welke soort test uitgevoerd moest worden.
Was er sprake van een performancetest, dan zul je voldoende testers moeten hebben om de test uit te voeren (er zijn ook wel tools om dit te simuleren). Was er sprake van een dataload test, dan had men eenvoudig de testdatabase kunnen vullen met “real” data en deze met een simpel scriptje anonimiseren (bijv. achternaam vervangen door TEST+BSN, straatnaam door STRAAT+BSN etc.). Op basis van de testset van DigID kun je de database extra vullen met deze gegevens, en voila je hebt een goedgevulde database en de fake-records van DigID waarmee je kunt testen.
Wat mij vooral dwars zit is dat de manager willens en wetens het risico heeft genomen om (ondanks de beperkte testset) toch de update door te voeren. De risico-analyse is dus duidelijk tekort geschoten, in mijn ogen een reden om vriendelijk, doch dringend afscheid te nemen van deze manager.
Er zijn dus ook geen maatregelen genomen om een mislukte update terug te kunnen draaien, dit is “common practice” bij (gevoelige) updates.
Helaas….