digi.no meldte denne uken at tekniske problemer hos Evry fikk store konsekvenser. Minst én million norske bankkunder var uten nettbank store deler av tirsdagen. For flere av landets største banker fungerte verken mobilbank eller minibank.

Evrys stormaskin stoppet opp cirka 13.30 tirsdag ettermiddag. Først klokken 21 om kvelden begynte ting å ta seg opp. Fra midnatt ble det også en halvtime nedetid for de berørte bankene, før alt gikk som normalt fra 00:30.

digi.no har sett en logg fra hendelsesforløpet. Evry bekrefter at denne er korrekt (se nederst i denne saken)

Det viser seg at årsaken var at en kommentarlinje i et skript for rutinemessig vedlikehold feilaktig var opphevet som kommentar, slik at kommandoen i stedet ble eksekvert.

Tirsdag kveld hevdet Evry at det var en «sentral komponent i IBM stormaskin» som forårsaket at flere banker ble berørt av driftsproblemene.

Det som egentlig skjedde fremstår som en banal tastefeil i skript.

Den aktuelle kommentarlinja beskrev kode som måtte kjøres på databaseserveren for å kopiere en database i Evrys testmiljø, men i den aktuelle prosedyren gjorde den samme kommandoen at hele stormaskinens operativsystem ble stoppet. Dermed ble jobben lagt til i en automatisk omstartskø, og så feilet omstart gang på gang. Siden dette var såpass tidlig i oppstartsekvensen ble det heller ikke produsert loggmateriale som gjorde det lett å avdekke feilen.

For – denne feilen ble, ifølge vår kilde, ikke oppdaget før ni timer etter at systemet gikk ned, altså rundt halv elleve på kvelden. Evry fikk, etter flere forsøk, ut en systemlogg som ble sendt til IBM i USA for analyse, som igjen fant ut hvilken jobb som feilet slik at Evry til slutt kunne fjerne denne fra oppstartsprosedyren og isolere feilen.

I mellomtiden var systemene for kort, betaling og minibank flyttet over på en annen maskin, som gjorde at disse tjenestene var operative fra klokka ni på kvelden. Da feilen så ble luket bort, ble det besluttet at systemene skulle flyttes tilbake på den opprinnelige maskinen, for å minimere risikoen for ikke å rekke morgenoppgjøret som går 05:35. Det var altså årsaken til nedetiden mellom midnatt og 00:30.

Evry har som strakstiltak endret tilgangsnivåer slik at denne type kommandoer ikke lenger tillates å bli eksekvert i batch-jobber.

En kilde digi.no har vært i kontakt med mener at bankhavariet denne uken har skremmende likheter med et tilfelle fra 2001, da ansatte i daværende Fellesdata klarte å stoppe halvparten av Norges banker med et tastetrykk.

Kritisk feil
Vi har fått hendelsesloggen bekreftet av Evry. Våre opplysninger stemmer helt overens med et overordnet sammendrag selskapet nå legger frem overfor digi.no:

• 13:27: Det oppstår stopp i CPU2 på mainframe/stormaskin. Dette medfører at alle online og batch systemer stopper.
• Online produksjon ble reetablert igjen klokken 21.00
• 00:00-00:30 Det ble sendt ut varsling og kundeinformasjon i forkant på av at online produksjonen ble tatt kontrollert ned og opp, og flyttet tilbake til original konfigurasjon for å gjennomføre en normal eksekvering av batch med lavest mulig risiko.

I forbindelse med ordinært arbeid i akseptanse-test miljøet, oppstår en kritisk feil:

• En rutinejobb for å kopiere en database i testmiljø (image copy) inneholder en kommentar som angir en kommando som skal eksekveres i DB2.
• Ved en feil er tegnet som maskerer ut denne linjen som kommentartekst fjernet. (uthevet av digi.no)
• Kommandoen blir dermed eksekvert. IBM operativsystemet (JCL) har en likelydende kommando med en helt annen konsekvens, at hele operativsystemet på CPU2 stoppes. Dermed stopper både test og produksjon på CPU2. DB2 operatøren har ikke forutsetninger for å vite dette.
• Når denne kommandoen blir feilaktig eksekvert legger den seg også i en automatisk restart kø. Restart (IP/L) feilet derfor gjentatte ganger på samme punkt, men systemet ga ingen indikasjon på hva som feilet, da dette skjer så tidlig stadium i oppstartsekvensen at det ikke var produsert en logg som viste hvor eksakt oppstart feilet.
• Videre arbeid for å identifisere hvor problemet lå var da å sende en systemdump til analyse hos IBM. Det ble gjort 3 forsøk før det lyktes å få en fullstendig dump.
• Denne systemdumpen ble analysert på IBM lab i USA. IBM identifiserte i hvilken jobb feilen lå, og EVRY eliminerte deretter denne jobben i oppstartsprosessen. Det ble deretter verifisert at CPU2 startet normalt.

«Logisk sikkerhetshull»
Evrys kommunikasjonsdirektør Geir Remman bedyrer at stormaskinmiljøet deres er konfigurert i henhold til anbefalt industristandard fra IBM.

Han unngår å svare på spørsmål fra digi.no om endringene i skript er blitt utført av folk uten tilstrekkelig kompetanse på IBMs skriptspråk JCL (Job Control Language).

I stedet viser han til en ferdigskrevet kommentar vi mottar på e-post:

– Analyse av rotårsaken avdekket et logisk sikkerhetshull mellom test og produksjonssystemene som ikke har vært kjent hverken for EVRY eller andre som bruker samme teknologi. Periodiske systemkontroller er utført som planlagt men nevnte feil er ikke blitt avdekket gjennom dette arbeidet, sier Remman.

Arbeidet på testsystemet, som utløste hendelsen, er ifølge Evry gjort i henhold til fastlagte prosedyrer.

– Evry har endret kommando autorisasjonene slik at gjeldende og eventuelt tilsvarende alvorlige kommandoer ikke tillates eksekvert i batch, for å forhindre tilsvarende konsekvens.

Geir Remman avslutter med å si at de har beklaget hendelsen, og at Evry har vært åpen om hele årsaksforholdet overfor kundene sine.