En varslet katastrofe

Midt i mars klarte Teknisk Ukeblad å få tak en hemmeligstemplet rapport. De meldte at Altinn hadde store potensielle problemer. Knapt var artikkelen publisert før det smalt. Smellet har fått betegnelsen Kenneth.

Alle som prøvde å sjekke inn for å se på sin skatteavregning fikk dataene til Kenneth i 17 minutter før Altinn ble stengt tirsdag 20. mars klokken 18.34.

Hemmelig et halvt år

Da hadde Nærings og Handelsdepartementet (NHD) sittet på rapporten fra Det Norske Veritas (DNV) siden begynnelsen av oktober 2011. Rapporten var umiddelbart blitt hemmeligstemplet.

Etter problemene gikk det bare noen dager før NHD friga rapporten fra DNV.

- Vi visste om rapporten, men hadde ikke sett den, sier Bjart Kvarme, administrerende direktør i Basefarm Norge.

- Vi hadde ikke fått tilgang til rapporten før denne uken, sier Georg Andreas Huus, informasjonssjef i Accenture.

Jobbet på spreng

I mellomtiden jobbet de involverte partene med å løse problemet. Alle stilte opp. Accenture, Altinn, Basefarm, Brønnøysundregistrene og F5. De var optimistiske. De klarte raskt å finne den sannsynlige årsaken. Utfordringen var å klare å gjenta feilen for å bevise antagelsen. Det klarte de og beviste sin antagelse. På fredag 23. klokken elleve var Altinn oppe igjen.

Feilen lå i forbehandlingssystemet. Det var effektiviseringsmekanismen som sviktet. Dataene ble lagt inn i en buffer (cache) for å unngå å hente dem på nytt. Denne bufferen ble overbelastet og hang seg opp slik at data om Kenneth var det eneste personer som skulle se sin egen skatteavregning fikk se.

Konsekvensen er at Basefarm har måttet slå av effektiviseringsfunksjonen. Nå er det derfor opp til leverandøren å fikse den programvaresvakheten som ble avslørt, før optimaliseringsmekanismen blir slått på igjen.

Bør være pessimistiske

De fant og isolerte en svakhet, men de bør være pessimistiske, for Altinn har store grunnleggende problemer, ikke for generelle tjenester, men for rapportering av selvangivelsen for personer og næringsdrivende.

Satt på spissen har ikke løsningen kapasitet nok for det volumet som oppstår når Skattedirektoratet (SKD) frigir dataene. Det står tydelig i rapporten til DNV, men Veritas er forsiktige i sine formuleringer.

«Systemet synes ikke designet for å håndtere store datamengder da batchkjøringer reduserer responstid blant annet ved bruk av basen, og det er ikke mulig å kjøre parallelt slik det er i Altinn 1». Slik formulerer DNV seg.

Det var 8,8 TB med data Altinn måtte ta seg av. Sikringen av disse tok tolv timer og datamengdene øker med 3 TB i året.

Gjøre en studie

Videre skriver DNV; «Arkitekturen er databasesentrisk der det ved skalering vil være flere prosesser som konkurrerer om bruk av samme database. Vi anbefaler at det gjøres en studie for å vurdere hvordan arkitekturen kan justeres for å gjøre den mindre databasesentrisk».

Varianter av disse utsagnene gjentas en rekke ganger. Forslaget om egne databaser for lesetransaksjoner for å avlaste databaser det skrives til, er et typisk krisetiltak. I utgangspunktet skal dokumenter kunne endres av brukerne, eksempelvis selvangivelsen.

Hvordan arkitekturen virkelig ser ut, vet bare noen få. Den skissen som står i rapporten til Veritas sier veldig lite. De skissene som angis i rapport 2010-17 «Nasjonale felleskomponenter i offentlig sektor» og i omtalen av Altinn 2 foredrag holdt av Hallstein Husand bidrar til å forvirre. De ser på Altinn fra forskjellige utgangspunkt.

Skriver om det de kan

Derfor skriver Veritas om noe de kan; testing. Kontrollregimet med hensyn godkjenning av komponenter i systemet har ikke vært tilfredsstillende.

«Prosjektstyringen i forhold til test og akseptanse har vært preget av tidspresset i prosjektet og kontraktstruktur, der man har akseptert produksjonssetting av løsning med et stort antall kjente feil.»

Skal man tro Veritas har kvaliteten på testingen vært for dårlig i alle faser, fra modultest, via enhetstest til akseptansetest. Konsekvensen er at Altinn 2 er i produksjon med mange kjente og ukjente feil.

Kjente feil kan man fjerne over tid. Ukjente feil oppdages på samme måte som sammenbruddet på tirsdag.

«Dagens praksis med sen involvering av driftskompetanse i design og arkitekturvurderinger kan redusere løsningens driftbarehet og ytelse, noe som kan være kostnadsdrivende», skriver DNV.

Overgangen fra programvareutvikling til produksjon er et område konsulentselskapet Bekk har jobbet mye med i sitt program Devop.

-- En veldig viktig funksjon er produksjonssetting av applikasjoner. Det jobber vi veldig mye med, sier Olav Folkestad, administrerende direktør i Bekk.

Bekk er veldig bevisst at produksjonssetting tar tid og forbindes med betydelige kostnader om ikke testregimet og produksjonsfolk har vært involvert i tilretteleggingen.

«Ytelsestest har ikke vært tilstrekkelig. Det har vært manglende kvantiserbare krav til ytelse, manglende krav til ytelsestesten (bakgrunnslast og datamengder når ytelsestest gjennomføres), for dårlig testmiljø, for få typer script, for kort tidsperiode, ikke varierende brukerprofiler. Resultatet av dette er at alvorlige ytelsesproblemer ikke avdekkes før løsningen ser satt i produksjon». Deretter henviser DNV til problemene 22. mars 2011.

Lite testet for katastrofe

Ifølge DNV er det etablert en katastrofeløsning, men den er bare delvis testet. Det gjenstår redundanstest av SAN-failover (SAN, det vil si lagringsnett) og databaseklynger samt en totalgjennomgang av hele katastrofeløsningen og nødvendige rutiner.

Videre er Veritas opptatt av at den organisatoriske kompleksiteten med et stort antall interessenter og parter i Altinn-samarbeidet.

«Risikoen for suboptimalisering og feil bruk av begrensede ressurser blir stor. Dermed blir det vanskelig å gjennomføre velfunderte prioriteringer i forvaltning og videreutvikling av Altinn-plattformen.» skriver DNV.

Gikk gjennom koden

På oppdrag fra Brønnøysundregistrerene gjorde Capgemini en kodegjennomgang av programmene. Der fremkommer det at det fortsatt er mye å gjøre med mange «TO DO» og deler av koden som er gjort om til kommentarer (utkommentert kode).

Det vitner enten om begynnelsen på fremtidige forbedringer eller midlertidig kode for et eller annet formål.

Produksjonsversjoner av applikasjoner bør ikke inneholde kode som er gjort om til kommentarer fordi det er så lett å overse at den ikke er aktiv. Kode som er blitt kommentarer, gjør det vanskeligere å forvalte applikasjonen ved behov for endringer, forbedringer og nye krav.

På begynnerstadiet

Av den grunn er Altinn 2 bare på begynnerstadiet. Kompleks samhandling er ikke prøvd gjennomført. Det inneholder tekniske, juridiske og organisatoriske utfordringer.

Det betyr at en bedrift foreløpig ikke kan rapportere data i et skjema hvor dataene overføres til flere forskjellige offentlige etater.