Nets: Menneskelig fejl skyld i Dankort-nedbrud

21. januar 2014 kl. 12:5019
Det længste nedbrud i Dankortets historie skyldtes ifølge Nets en menneskelig fejl. Underleverandøren IBM beklager, men ønsker ikke at uddybe, hvordan fejlen opstod.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Efter det landsdækkende nedbrud på Dankort-systemet mandag, er firmaet bag løsningen blevet en smule klogere på, hvad der fik hele Danmarks foretrukne betalingskort til at gå ud af funktion i mere end ti timer.

»Vores foreløbige konklusion er, at der er opstået en fejl på en router i forbindelse med en planlagt systemopdatering hos IBM. Fejlen opstod i forbindelse med en vedligeholdelsesprocedure, og på den måde kan man sige, at der var tale om en procedurefejl,« siger Michael Juul Rugaard, kommunikationsrådgiver hos Nets, til Version2.

»En menneskelig fejl kunne man måske også kalde det, men altså ikke en systemfejl,« siger han.

Nedbruddet startede kort efter klokken fem mandag morgen, og først ud på eftermiddagen klokken fire kunne Nets oplyse, at systemet nu igen var på ret køl efter mere end ti timers nedetid, hvilket gør nedbruddet til det længste i kortets historie.

Artiklen fortsætter efter annoncen

Nets er officiel leverandør af Dankort-løsningen, men gør brug af underleverandøren IBM, som altså var arnestedet for fejlen.

Men IBM ønsker ikke at delagtiggøre Version2 i, hvordan fejlen opstod og de nærmere tekniske detaljer omkring nedbruddet. IBM har fremsendt følgende skriftlige udtalelse, som også har været sendt til andre medier:

»IBM er leverandør af de services til Nets der vedrører Dankortet. Vi har sidens problemets start haft vores lokale og internationale eksperter på opgaven i tæt samarbejde med Nets for at løse problemerne. Den normale service på Dankortet er nu genoprettet. Vi beklager dybt situationen og de gener det har medført i dagens løb,« skriver IBM’s pressekoordinator Karsten Stokking i en e-mail til Version2.

Grundige undersøgelser i gang

Hos Nets går en grundig analyse af fejlen nu i gang, og det arbejde vil ske i samarbejde med IBM.

Artiklen fortsætter efter annoncen

»Det, der skal ske nu, er, at vi går i gang med at analysere hele forløbet. Alt bliver endevendt og gennemgået med en tættekam, så vi kan være sikre på, at vi har gennemanalyseret alt og kan lære af det og undgå at lige præcis denne fejl skulle opstå en anden gang,« siger Michael Juul Rugaard til Version2.

Han fortæller, at forløbet kan vare op til et par uger, hvor Nets i den periode ikke kan melde flere detaljer ud, end der foreligger nu.

Kan du sige noget om, hvorfor det trak ud med at få rettet fejlen?

»Der var jo rigtig mange ting, der blev gennemgået i går, indtil man lokaliserede fejlen. Derefter har der været nogle efter-analyser og tests,« siger Michael Juul Rugaard, men kan ikke komme årsagen til nedbruddets længde meget nærmere.

Send os gerne et tip, hvis du ved noget om sagen.

19 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
17
22. januar 2014 kl. 11:41

Det kan være en lille ting som ingen har tænkt på som er skyld i en kæmpe fejl. En af mine venner arbejder med IT på serverniveau, fortalte at det havde taget 14 dage og finde et flueben som var sat forkert, i en fordeler. (den kasse som sørger for interface mellem servere SAN / NAS harddiske) Ved ikke lige hvad den hedder. Det var noget helt grundlæggende, som alle tænkte: Jammen det er ikke sådan noget der er galt. Men det var det. 14 dage uden adgang til diskene. mvh, Erik.

19
23. januar 2014 kl. 19:11

Erik - det kaldes såmænd bare en san-switch. Dem har man normalt 2 af for redundans så man kan have en nede og stadig være kørende. - Noget tyder på at det "professionelle" lige var købt en smule for billigt når man så går ned i 14 dage. Dermed er man så desværre også en smule selv ude om det. Det er lige præcis i de her tilfælde man har redundansen.

18
22. januar 2014 kl. 12:01

En af mine venner arbejder med IT på serverniveau, fortalte at det havde taget 14 dage og finde et flueben som var sat forkert, i en fordeler.

Jeg vil hermed gentage: Change Management - det er derfor så hamrende vigtig at registerere samtlige ændringer (selv tilsyneladende ubetydelige), så du kan se hvornår fejler er opstået og hvad var nu ændret omkring det tidspunkt.

Havde de brugt 5 minut på at registrere ændringer (i CMS), ville de ikke tabe 14-dages arbejde.

15
22. januar 2014 kl. 08:50

.. hvis det ikke er hardwarefejl må det vel være softwarefejl eller procedurefejl og så er det vel altid en menneskelig fejl... ?

11
22. januar 2014 kl. 01:20

Man må, som så ofte på det her forum, igen konstatere at bagklogskabens lys er meget klart og samtlige debattører er hævet over at lave fejl. Det er ligesom med nem id eller rejsekortet, folk laver ikke andet end at brokke sig i debatsektionen.

10
21. januar 2014 kl. 21:32

Hvis man kører forbi et firmas hovedkontor, og ser at gruset i indkørslen er overgroet med ukrudt og græs, hækken er forpjusket osv., så ville man næppe tænke at det er nok fordi de har en dårlig hækklipper, riven er til reparation, eller gartneren nok bare har en dårlig dag. Det er et valg fra firmaets side - et ledelsesproblem.

Når vi oplever at Dankort-systemet er nede i 9 (ni!) timer, og dermed lammer en stor del af vores handel og færden, så er problemet ikke en defekt router eller en medarbejder med en dårlig dag. Til opgaver med så stor betydning, har man altid en backup-plan, hvor man kan gå tilbage på få sekunder, hvis noget går galt. Nets demonstrerer blot en komplet ligegyldighed med opgaven. Igen og igen!

Når Nets nok engang demonstrerer at de ikke magter opgaven med at tage ansvaret for en så vigtig del af vores infrastruktur, så er det et ledelsesproblem hos Nets. Når vi som borgere lader et inkompetent firma som Nets have monopol på noget så vigtigt, så er det et politisk problem af skandaløse dimensioner!

12
22. januar 2014 kl. 04:49

Nets demonstrerer blot en komplet ligegyldighed med opgaven. Igen og igen!

Nets er udtænkt af, opbygget af, ejet af samt drevet af bean counter[1] sjæl. Der er sikkert fornuftige personer samt relevant it-uddannet personale, men hvad hjælper det hvis sjælen en bean counter.

Alle Nets tåbeligheder incl. SlemID peger i en og samme retning.

[1] Beans are a cheap commodity, so to count them is a rather silly thing to do. A "bean counter" is one who nitpicks over small things in order to save costs. It is a derogatory term for accountants, bankers, and anyone who holds a financial interest in an endeavor.

7
21. januar 2014 kl. 15:14

"Vi beklager dybt situationen og de gener det har medført i dagens løb"

Og så er det ellers bare ærgerligt for alle de forretningsdrivende der har mistet en stor del af dagens omsætning, eller de mennesker som har fået en parkeringsafgift fordi de ikke lige render rundt med med en mængde mønter til backup for at sikre sig mod at IBM fucker op.

"Vi beklager" er simpelthen ikke godt nok, og tragisk at et firma der på elegant vis giver underskud år efter år, og dermed ikke betaler skat, kan slippe så let.

Føj.

5
21. januar 2014 kl. 14:22

Kan v2 ikke grave lidt mere i det her. Det er ikke ok, at hemmeligholde den reelle grund til et it-nedbrud med samfundsøkonomiske konsekvenser som et mindre terror-angreb.

Og lad os så få den it-havarikommission.

4
21. januar 2014 kl. 14:14

...konfigurations/versionsstyring af deres konfigurationer af deres systemer. Så når det går i fisk i routeren, så kan de ikke abre smide den gamle konfiguration på, for den har de ikke, de skal manuelt til at lave den tilbage til det de kan huske den stod til.

Alt for mange driftsorganisationer kører på denne måde, med Word dokumenter der beskriver ændringer, og reverse-ændringer der skal foretages manuelt af personer, og når det går galt går det dobbelt galt fordi man ikke bare kan smide den sidst virkende konfiguration på. Altså den konfiguration af hele landskabet (routers, firewalls osv.) der virker.

Det er amatøragtigt.

2
21. januar 2014 kl. 13:38

Betyder det at en har glemt at tænde den igen :-P

14
22. januar 2014 kl. 07:25

man traceroute

3
21. januar 2014 kl. 13:58

Jeg gad godt have været en flue på vægen hos IBM, da det blev erkendt hvad fejlen skyldtes og alles ansigter drejer sig og kigger på router-fyren i hjørnet, og set hans ansigtsudtryk da han erkender at have været skyld i at ingen kunne bruge Dankort hele mandagen... priceless.

Helt seriøst er det utilgiveligt at lægge den slags ansvar på enkeltpersoner. Den slags skal automatiseres og der skal være fallback-systemer, så en enkelt person ikke skal stå med den slags ansvar. Jeg er i hvert fald glad for at det ikke er mig...

8
21. januar 2014 kl. 18:47

Nu kan man jo sige at alle fejl er menneskelige fejl, for om ikke andet kan manglende procedurer eller lign. også være menneskelige fejl.

Der står jo heller ikke det kun er 1 persons skyld. Den menneskelige fejl kan jo netop være en fejl i en procedure eller i en change som flere har været inde over, uden at have spottet fluen i suppen. Og om ikke andet kan den lange fejlsøgningstid næppe tilskrives et enkelt individs ansvar. Jeg synes netop denne lange tid er det største mysterium i sagen. Hvis det bare er en konfigurationsfejl på en router burde det jo ikke tage lang tid at lokalisere hvor "data" stopper.

9
21. januar 2014 kl. 19:21

Du har fuldkommen ret Morten. Taget i betragtning af at der nok er fuld overvågning på systemerne (må man i hvert fald antage. IBM har normalt en forholdsvis professionel tilgang til tingene og er altså vant til MEGET store kunder) Så burde det altså ikke tage lang tid at finde ud af i hvilken hat kaninen gemmer sig. Ydermere er det interessant at IBM dk ikke har kunnet løse problemet og at der har skullet eskaleres op på højere plan lyder godt nok underligt. Som Jeg skrev i første indlæg - tidspunktet taget i betragtning så virker det absolut meget underligt. Det tidspunkt er generelt i de fleste IT-afdelinger et absolut no-go for at lave "planlagte" opdateringer.

1
21. januar 2014 kl. 13:08

»Det, der skal ske nu, er, at vi går i gang med at analysere hele forløbet. Alt bliver endevendt og gennemgået med en tættekam, så vi kan være sikre på, at vi har gennemanalyseret alt og kan lære af det og undgå at <strong>lige præcis denne fejl</strong> skulle opstå en anden gang,« siger Michael Juul Rugaard til Version2.

Ja, fordi vi skulle jo nødigt få et stabilt gennemtestet system med redundante forbindelser og muligheder. Men nu skal vi sørge for at lige præcist denne (iføølge IBM) menneskelige fejl ikke kan gentages.