Fejlramt slettejob lammede coronapasset i 9 timer
Inden raketterne bragede det nye år ind, og champagnen fyldte danskernes ganer, kunne medier i hele landet berette om bøvl med coronapasset, Sundhed.dk og appen MinSundhed.
Et databasenedbrud var skyld i, at folk ikke kunne få deres coronapas eller prøvesvar vist i godt og vel ni timer. Det fik så alvorlige konsekvenser på tværs af samfundet, at blandt andet DSB akut måtte droppe kravet om fremvisning af coronapas i offentlig transport, så længe fejlen stod på.
Version2 har fået aktindsigt i en rapport, som leverandøren Trifork har sendt til Sundhedsdatastyrelsen. Og selvom styrelsen har overstreget en række detaljer om specifikke systemer og komponenter, kan man læse, at et ‘slettejob’ var årsagen til problemet i første omgang.
Den efterfølgende fejlsøgning tog markant længere tid end forventet, og derfor endte fejlen med at være skyld i op imod 60.000 forgæves forsøg fra borgere på at hente coronapas.
Her er en gennemgang af forløbet.
Klokken 03:53
Natten til nytårsaftensdag sidste år tikker en alarm ind via SMS. Klokken er 03:53, modtageren er softwarevirksomheden Trifork, og alarmen meddeler, at der 49 minutter forinden har været et databasenedbrud på et essentielt it-system, der er med til at håndtere Det Fælles Medicinkort. Platformen, der håndterer medicin og vaccinationer på danske borgere.
En fejlsøgning igangsættes med det samme.
Klokken 04:00
Efter den indledende alarm ringer en vagt fra it-konsulentfirmaet Netic, der er ejet af Trifork, for at oplyse, at et system er nede, men at man er i gang med at re-synkronisere.
Netic forventer, at det kommer til at tage 45 minutter.
Det informerer Trifork videre til systemforvalteren. Præcis hvilket system og hvem systemforvalteren er, er blevet hemmeligholdt i aktindsigten.
Tallene er estimater, som Trifork har inkluderet i rapporten til Sundhedsdatastyrelsen. De er baseret på historiske data, der viser, at sundhedsfaglige kald den 31.12. svarer til antallet af kald, der sker i løbet af en weekend i samme periode. Derfor har man taget udgangspunkt i antallet af kald, der skete lørdag d. 25.12. Firmaet understreger, at der er betydelig usikkerhed i tallene, da man ikke kendte borgernes behov for at fremvise coronapas på nytårsaftensdag, og der ikke foreligger historiske data fra det foregående år.Så mange blev berørt af nedbruddet
Klokken 07:17
Re-synkroniseringen viser sig at tage meget længere tid end 45 minutter, og kl 07:17 – cirka 3 en halv time efter Trifork først er blevet informeret – oplyser Netic systemforvalteren, at en alternativ løsning er at gå online på 1 database serveren og genoptage re-synkroniseringen på et senere tidspunkt.
Det vælger systemforvalteren dog ikke at gøre, da man ønsker at køre replikeringen færdig.
Klokken 10:27
Nogle timer senere lykkedes det så at få Det Danske Vaccinationsregister (DDV) online igen.
»10:27 bliver der indlæst en kopi af admin databasen til [hemmeligholdt information] (som normalt bliver brugt til AuditLog og RequestResponse) – herefter bliver admin modulet genstartet, hvilket gør DDV tilgængelig igen kl 10:30,« står der i rapporten.
Klokken 10:48
Cirka et kvarter efter DDV igen er gjort tilgængelig, bliver problemet diskuteret af en bredere skare mellem Netic og Trifork. Her bliver konstateringen, at man ikke kan sige, hvornår re-synkroniseringen bliver færdig.
»Der drøftes en løsning, som går ud på at [hemmeligholdt information] kan re-synkroniseres uden nedetid på et senere tidspunkt, hvilket dog først skal testes i [hemmeligholdt information]. Løsningen virker forsvarligt, da der også er en [hemmeligholdt information] som fortsat kan holdes opdateret på trods af, at der kun er [hemmeligholdt information].«
Løsningen forelægges for systemforvalteren og sættes i værk.
Klokken 11:23
klokken 11:23 er FMK og FMK Online igen tilgængelige, en halv time senere deaktiveres slettejobbet og klokken 12:11 har Netic reetableret replikeringen til det centrale data warehouse.
Ny metode skal bruges ved fremtidige nedbrud
I rapporten kan man også læse, hvordan Trifork har tænkt sig at forbedre sikkerheden i tilfælde af fremtidige nedbrud. Igen er de specifikke systemer og forandringer overstreget.
For det første vil man ændre re-synkroniserings-metoden, da den tidligere version viste sig at være fejlbehæftet. Det er allerede sat i værk, så den nye metode bruges ved fremtidige nedbrud.
»Under fremtidige nedbrud vil der dermed kun være enkelte transaktioner, der vil blive afbrudt uden at have betydning for oppetiden,« står der i rapporten.
Et andet forslag til forbedringer er, at man bør overveje at fordele data på tværs af små databaser – f.eks. ved brug af containere. Havde man haft det tidligere, havde nedbruddet på nytårsaftensdag ikke haft betydning for Vaccineregisteret, der så havde kørt på sin egen database.
Det foreslås også, at slettejobs i FMK bliver gjort ensartede, så man nemmere kan overvåge og udføre sletninger på en standardiseret måde, der ikke kommer til at have betydning for databasens afvikling af trafik. En løsning, der ifølge rapporten er planlagt til at blive implementeret snarligt.
Endelig vil man også forsøge at genskabe nedbruddet med henblik på at analysere den nye måde at standardisere slettejobs.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
