Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 8. december 2006.
PBS Efterårets store dankortnedbrud skyldtes en række ukomplekse fejl.Tilsammen lagde de systemet stille.
Mandag 2. oktober vågnede Danmark op til en morgen uden dankort. Først klokken 11 kunne det igen lade sig gøre at hæve penge og betale med landets mest udbredte betalingskort. Årsagen var en serie af usædvanlige fejl, der opstod i forbindelse med en planlagt opdatering af systemet.
- De alvorlige problemer opstår altid ved de uforudsete fejl. Hvis man kan forudse en fejl, kan man også forberede sig på at behandle den. I dag er maskinerne så driftsikre, at spidsbelastninger ikke er noget problem. Det er ændringer til gengæld, siger Dainis Krastins, direktør med ansvar for it-drift og -udvikling.
Computerworld CTO har opsøgt ham hos PBS i Ballerup for at få afklaret, hvad der egentlig gik galt 2. oktober. Det viser sig, at historien begynder længe før: Nemlig 17. januar.
- På det tidspunkt er nogle af vores folk inde og rode med et kontroldatasæt. Det er en samling data, der fortæller, hvordan IMS-databasen har det. De efterlader systemet i en tilstand, hvor der står, at en log er aktiv, skønt den ikke er det, fortæller Dainis Krastins.
Hjertet i systemet
IMS er den IBM-database, der udgør hjertet i dankortsystemet. Det har den været siden 1995, da systemet blev flyttet fra en danskudviklet CR80-platform til en IBM-mainframe.
Alt i dankortsystemet er dubleret. Softwaren kører på to mainframes, hvor den ene er et spejl af den anden. Alle netværksforbindelser, diske og båndsystemer er også dublerede. Hardwaremæssigt er der dermed taget højde for alle tænkelige problemer.
Hver måned vedligeholder PBS dankortsystemet. Det sker som regel mellem klokken 2 og 5 natten til mandag. Her indføres der ændringer til systemets software: Rettelser fra IBM og andre softwareleverandører og ny funktionalitet fra PBS' egne udviklere.
Ved samme lejlighed udvider PBS ofte databasestørrelsen, fordi mængden af transaktioner er konstant stigende.
- Proceduren er, at vi tager hele systemet ud af drift. Så opdaterer vi det ene delsystem og verificerer, at det er lykkedes. Derefter gør vi det samme på det andet delsystem. Når begge systemer er verificeret, sætter vi dem i drift, forklarer Dainis Krastins.
2. oktober gik installationen af programændringer uden problemer. Det første delsystem fik også udvidet sin databasestørrelse. Men det andet delsystem meldte fejl: Databasen kunne ikke ændres, fordi der var noget aktivt på systemet.
- Vores folk prøver at finde ud af, hvad der er aktivt på systemet. Men de kan ikke finde noget. Tiden går, og da problemet ikke umiddelbart kan løses, vælger vi at lave såkaldt fallback. Det går godt på det ene system, men fallback-proceduren fejler på det andet system, fortæller Dainis Krastins.
Klokken er omkring 4:30. Der er endnu ikke panik på. Men da fallback ikke kan gennemføres, vælger man at lave en hel database-recovery. Det vil sige, at systemerne bringes tilbage til den status, de havde, før man begyndte på ændringerne.
- Men så kommer 17. januar efter os. Systemet vil ikke lave database- recovery, så længe en log er åben. Men den er ikke åben, den log eksisterer slet ikke mere, siger Dainis Krastins.
Falsk oplysning
Nu kommer der sved på panden hos de otte mand på vagt hos PBS. Der bliver indkaldt folk alle vegne fra - både kolleger og fra leverandører. Ved 7-tiden er 16 mand i gang med at løse problemet. En ekstern konsulent kommer omkring 8:15 med de forløsende ord: Han har set noget lignende hos en kunde i Norge.
Konsulenten finder ud af, at det en bestemt record i kontroldatasættet, der indeholder den falske oplysning om den åbne log. Den er identificeret med et tidsstempel. Nu skal man bare slette den record for at få lov til at lave database recovery.
Systemet oplyser, at recorden har tidsstemplet 2:17 den 17. januar.
- Så vi går ind og siger: Vi vil gerne ændre den record. Hertil svarer systemet: den record kender jeg ikke. Der er ingen record kl. 2:17, siger Dainis Krastins.
To records
Et kvikt hoved siger: Det kan være noget med UTC (Universal Time Coordinated). Ganske rigtigt: IMS-systemet viser klokkeslæt i dansk normaltid. Men internt opererer databasen med UTC, der er afløseren for gamle dages Greenwich Mean Time.
Nu korrigerer operatøren for UTC-afvigelsen og lægger en tom record ind for at få slettet den oprindelige. Men det sker ikke. I stedet optræder der nu to records med samme tidsstempel - hvilket ikke burde være muligt.
- Her klør folk sig i nakken. Vi har bedt om at få ændret en record, og i stedet er der pludselig to. Indtil en indser det: Vi har sommertid, det var det ikke i januar, fortæller Dainis Krastins.
Korrigeret for UTC og sommertid tager det ingen tid at få slettet den fejlagtige log-oplysning. Herefter kan databasen gendannes uden problemer. Klokken 11 er dankortsystemet atter i drift.
- Så det var ikke noget farligt, der var på færde. Det var tværtimod yderst banalt. Men kombinationen af flere fejl gav problemerne, konkluderer Dainis Krastins.
Handlingslammelse
Den første fejl betød, at databasen troede, noget var aktivt på systemet, skønt alt var lukket ned. Den har IBM set andre steder, og der er nu lavet en rettelse, der skulle fjerne den. Den blev lagt ind søndag den 12. november, hvor alle opdateringer blev gennemført uden problemer.
Den anden fejl var den fejlagtige log-oplysning 17. januar.
- Kunne vi have undgået problemer med test? Nej, vores testsystemer havde ikke den fejl, den fandtes kun i kontroldatasættet på produktionssystemet. Men vi har indført nogle yderligere procedurer, der kan hjælpe i lignende situationer i fremtiden, fortæller Dainis Krastins.
En ting overraskede ham ved forløbet: Da det begyndte at gå galt, blev folk først nærmest handlingslammede:
- Førhen var vi vant til, at der jævnligt var problemer. Vi forventede dem nærmest. I dag forventer vi, at systemerne virker. Og når de så ikke gør det, bliver vi lige handlingslammede et øjeblik, før vi kommer op i gear, siger han.
I øvrigt mener han, at der opstår lignende problemer i alle store, komplekse it-systemer. Forskellen på PBS og de andre er, at når dankortet er nede, mærker hele samfundet det.
Faktaboks:
PBS
PBS behandler 1,1 milliarder korttransaktioner om året.
Dankortet kører på et dubleret IBM zSeries-mainframesystem med zOS. Softwaren bygger på transaktionssystemet IMS med databasesystemet DL/1.
Kommunikationen til terminalerne foregår på et gammelt X.21-net, der er ved at bliver udfaset. Endvidere anvendes adsl, mpls og isdn. Systemet kører både SNA og TCP/IP.
OriginalModTime: 08-12-2006 12:13:06
