Op dinsdag 19 juni 2012 ging de upgrade mis van een batch scheduler bij Royal Bank of Scotland (RBS). Elke nacht worden de transacties verwerkt tussen miljoenen rekeningen. De rollback naar een oude, stabiele versie mislukte.
Bovendien was de transactiedata niet beschikbaar waardoor niemand precies wist welke transacties wel of niet verwerkt waren tot het moment van falen. Het gevolg was een aanzwellende backlog in de dagen erna: alle batches moesten eerst weer in sequentie worden geplaatst. Deze nachtmerrie leidde uiteindelijk tot de grootste digitale ramp die de UK (tot nu toe) heeft getroffen. Hoe kan een systeembank zo falen?
Wanneer je geen geld kunt ontvangen, pinnen of betalen wordt het dagelijks leven ernstig ontwricht. Bij RBS hielden de problemen bijna twee weken aan: salarissen stonden niet op rekeningen, vakantiegangers waren gestrand, uitkeringsgerechtigden kregen hun uitkering niet en belangrijke transacties zoals het passeren van onroerend goed gingen niet door. Er waren speculaties en RBS kwam meer niet met een heldere uitleg.
Volgende ramp
Hoe kan een ‘routine' incident tot een domino-effect leiden? Waarom die zo moeizame recovery? Is belangrijke kennis nog wel binnenshuis na de massale outsourcing van RBS? Het antwoord op deze vragen kwam maar niet. Dan is het niet vreemd dat mensen gaan denken dat een volgende ramp slechts een kwestie van tijd is.
Weten leden van de Raad van Bestuur bij banken het verschil tussen een rollback en recovery? En de commissarissen? Menig bestuurder of toezichthouder zal een vaag antwoord geven. Willem Duisenberg stelde al voor de opkomst van internet en mobieltjes vast dat 'een bank niets meer is dan een computer met een marmeren poort'. Als topmanager van een bank of toezichthouder kun je niet wijzen naar de cio, alias ‘de man die iets met computers doet', als eindverantwoordelijke voor de informatiehuishouding.
Grote discrepantie
Veel cio's staan onder druk: It is niet echt populair binnen hun bedrijven. Dat gebrek aan status zorgt ervoor dat er gemakkelijk bezuinigingen en grootschalige offshore worden opgelegd van hoger hand. Dat de reputatie van it belabberd is, hebben it-organisaties ook aan zichzelf te wijten. Dit neemt echter niet weg dat een situatie waarin it en de business in een loopgravenstrijd zijn verwikkeld, levensbedreigend is voor het voortbestaan van een bedrijf (ook wanneer je geen bank bent). Er is een grote discrepantie tussen het belang van it voor een moderne onderneming en de oprechte interesse van de top.
Topmanagers die it verwaarlozen spelen een gevaarlijk spel. Verouderde en complexe systemen waar je constant bezig bent met upgrades, patches en andere changes, is vragen om problemen. Waarom heeft bijna geen enkele Westerse bank tijdens de vette jaren geïnvesteerd in vernieuwing? Waarom zijn het juist nieuwe banken die zo sterk investeren in it?
Heksenjacht
Wie it als een kans ziet om te groeien en de klantervaring te verbeteren, acteert heel anders dan een topmanager die it nog steeds als een ver-van-m'n-bed-show ziet. Dan regeert de angst en niet de hoop. Wanneer catastrofes als bij RBS leiden tot een heksenjacht om schuldigen aan te wijzen, is voor topmanagers it vooral een carrière liability. Love IT, don't hate it!
“De rollback naar een oude, stabiele versie mislukte”
Tja, dat is dan, hoe je het ook bekijkt, niet goed voorbereid.
Bij zeer bedrijfkritische systemen, waar er eigenlijk geen ruimte is voor onderhoudsvensters, moet de hele stack in principe rolling upgrades ondersteunen. En zelfs dan moet je een fallback plan hebben waarvan je zeker weet dat die werkt. De kunst is die zekerheid te verkrijgen.
Marco,
Alleraardigst dat je het incident van RBS bespreekt maar ik ben benieuwd of de geschatte schade van £50 tot £100 miljoen overeenkomt met de besparing die de bank dacht te halen door een blijkbaar goedkoop change management proces.
“When they did the back-out, a major error was made. An inexperienced person cleared the whole queue … they erased all the scheduling.”
Deze zin is in meerdere opzichten interessant omdat niet alleen banken een IT architectuur hebbben van vele verschillende oplossingen, het gevolg van de vele overnames in vette tijden en reorganisaties in magere tijden, die met honderden verschillende koppelingen aan elkaar verbonden zijn. En hoewel deze middleware bepalend is voor de processen, informatiestromen en de service worden steeds vaker de afhankelijkheden hierin vergeten. Want RBS is niet een bijzonderheid en dezelfde fouten worden steeds vaker gemaakt hoewel ze gelukkig meestal niet zulke vergaande consequenties hebben.
Ergens heb ik namelijk het idee dat de ongelukkige die op de verkeerde knop drukte dit deed na ruggespraak met iemand anders in het Change proces. En dat die persoon zelf misschien ook wel advies gevraagd had in de lijn maar onder druk van tijd en kosten een besluit moest nemen. Want de rollback naar een oude en stabiele versie roept al vragen op of de noodzakelijke testen wel uitgevoerd zijn. Net als trouwens de uitvoer van de rollback die blijkbaar niet beschreven was maar wel gedaan moest worden door een onervaren, misschien zelfs tijdelijk ingehuurde kracht.
Stellen dat leden van de Raad van Bestuur het verschil moeten weten tussen een rollback en recovery lijkt me dan ook niet nodig en ook topmanagers hoeven echt niet alle details te weten van IT. Wat ze echter wel moeten weten is waar nu precies de waarde en het risico zit zodat in de toekomst dit soort veranderingen niet te lichtzinnig uitgevoerd worden.
Als ik zo de analyse van Ewout bekijkt hebben we het hier niet over falende IT, maar falende mensen …
Geeft ineens een heel andere kijk op de zaak, vindt je niet?
Je kunt processen maken en testen tot je een ons weegt, maar als de heer of mevrouw X op het verkeerde moment op het verkeerde knopje drukt, zal het toch mis gaan.
Hier kan zelfs een CIO of raad van bestuur niets meer aan doen; fouten maken is en blijft menselijk. Het enige wat je als organisatie kunt doen is je processen zo solide mogelijk maken, maar vooral zorgen dat de mensen weten wat ze doen. Het grote gevaar van uitgekauwde processen, werkinstructies en checklisten is dat mensen alleen nog maar de lijstjes volgen, maar geen idee hebben wat ze nu eigenlijk aan het doen.
In het (Engelstalige) artikel http://www.bobsguide.com/guide/news/2012/Jul/6/rbs-it-crash-age-will-soon-get-the-better-of-the-banks.html wordt inderdaad gewezen op de factor mens: gebrek aan ervaren ITers
Bij bedrijfskritische systemen en upgrade zijn er drie zaken heel belangrijk, testen, testen en testen, zowel naar voren als naar achteren. Dit onder strakke regie van een oppergod, die uiteindelijk na uitgebreide rapportages en verificaties op verschillende niveaus van verschillende mensen de opdracht GO geeft. Systemen falen niet, menselijke fouten hebben impact.
Dit is een cruciale fout, ik heb behoorlijk wat ervaring in kritische systemen en ik zou nooit gaan upgraden zonder 100% zekerheid. Ik neem aan dat er wat mensen bij RBS zich elders oriënteren, na deze mislukking.