Undren blandt it-professionelle over ny fejl ved rejsekortet

Fejlen, hvor nogle kunders betalingsaftaler har været knyttet til andre kunders rejsekort, vækker undren hos Version2-læsere og lektor på DIKU. Rejsekort A/S har endnu ikke noget bud på en teknisk forklaring.

Forleden udsendte Rejsekort A/S en meddelelse om, at kunder i 16 tilfælde fejlagtigt har fået tanket deres kort op via andre kunders betalingsaftale. Fejlen skulle være blevet introduceret i forlængelse af en opdatering af systemet.

Men at sådan en fejl, hvor kort og betalingsaftaler tilsyneladende bliver koblet på kryds og tværs, kan opstå i første omgang, vækker undren flere steder. Blandt andet hos lektor på Datalogisk Institut på Københavns Universitet Erik Frøkjær.

Læs også: Ny fejl: Rejsekort-kunder har fået tanket op fra andre kunders betalingsaftaler

Han undrer sig ikke så meget over selve fejlen som over, at den har fundet vej ind i produktionssystemet i stedet for at være blevet fanget under test.

»It-fejl forekommer tit mærkelige, men det er ikke det, der undrer mig. Det undrer mig, at man ikke har fanget det inden ved at have et tilstrækkeligt finmasket sæt af testcases, som kan sættes i sving i forhold til enhver opdatering. Det burde man have,« siger Erik Frøkjær.

Flere Version2-læsere undrer sig dog også over selve fejlen. Altså hvordan bruger x's betalingsaftale pludselig kan være blevet knyttet til bruger y's kort.

Henrik Pedersen skriver blandt andet:

»Hvordan opstår sådan en fejl rent teknisk?

Gemmer de deres betalingsinformationer i tekstfiler som er hashet med rot13, som så er blevet kortet ned til 6 tegn, eller hvad?«

Dan Villiom Podlaski Christiansen undrer sig også:

»Ja, hvordan i alverden kan det overhovedet lade sig gøre? Koblingen mellem betaling og kunde virker rimeligt grundlæggende. Den mest umiddelbare forklaring er, at systemet er så ufatteligt komplekst, at ingen har styr på, hvad der egentligt foregår hvor. Og det er ikke ligefrem betryggende!«

En anden læser, Anton Stonor, spekulerer på, om den tidligere fejl, hvor brugere fik adgang til hinandens selvbetjeningssider, fordi der ikke blev skelnet mellem store og små bogstaver, kan være på spil.

»Mon vi igen er ude i, at dele af systemet skelner mellem store og små bogstaver, mens andre ikke gør?«

Adm. direktør i Rejsekort A/S Bjørn Wahlsten har endnu ikke noget endeligt bud på, hvad fejlen kan skyldes.

Han nævner dog, da Version2 kontakter ham i forbindelse med en nærmere forklaring på fejlen, at der er en facilitet i rejsekort-systemet, der netop gør det muligt at knytte flere kort til en betalingsaftale.

»Det er en facilitet, som har været brugt af forældre og børn,« siger Bjørn Wahlsten.

Men i hvor høj grad faciliteten har noget at gøre med den senest udmeldte fejl fra Rejsekort A/S, er det for tidligt at sige noget om, påpeger Bjørn Wahlsten og henviser til, at han afventer en nærmere teknisk redegørelse fra leverandøren af systemet.

Desuden er Rejsekort A/S ved at lave en nærmere gennemgang af de 16 tilfælde, hvor der skulle være et mismatch mellem kunder og betalingsaftaler.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan S. Hansen

Fra et it site og community perspektiv - så er it problemer nu noget af det vigtige.
Især når det er noget der ofte giver problemer, har været meget dyrt, berører mange mennesker og indeholder masser af eksempler på et projekt der kunne have været håndteret anderledes.

  • 26
  • 0
Palle Simonsen

Sarkasme ?

Jeg synes det vil være meget interessant for v2's læserskare at få at vide hvad årsagen eller årsagerne til miseren er, så vi kan lære af fejltagelserne:

  • Design ?
  • Styring af vedligehold ?
  • Styring af idriftsættelse ?
  • Eller en kombination eller noget helt fjerde ?
  • 18
  • 0
Svend Nielsen

Ja, det var også min første tanke. En race condition som opstår f.eks. under en opdatering, som foregår uden at de nødvendige spærringer i databasen er på plads. Mon ikke det er sandsynligt, at 16 personer kan nå et lave en opdatering, betaling eller lignende, mens opdateringen finder sted.
Hvis det så kombineres med, at kompleksiteten i systemet er så stor, at ingen (eller meget få) har et fuldstændigt overblik over hvad der foregår (og hvor det foregår), så opstår sådanne situationer.
Svære at spotte under test: Ja, i den grad. Faktisk umulige, fordi man - hvis man vidste at der kunne opstå et race problem, både kunne fordindre / fjerne og teste for det.

Undren blandt it-professionelle: Man kan selvfølgelig godt undre sig over den enkelte fejl, og dens til tider absurde virkninger. Det man måske bør undre sig mest over er, at der kan opstå fejl, som de ansvarlige IT folk ikke er i stand til at forklare, når virkningen af dem er fundet. Tyder på (meget) ringe dokumentation og dårlige grænsefladebeskrivelser. Jeg undrer mig f.eks. også over, at man kan sige, at det er præcis 16 kunder der er berørt. Er det de 16 der har klaget? Og er der 160, 1.600 eller 16.000 kunder mere som bare ikke har opdaget det endnu.

Og så længe man ikke ved hvad fejlen er, hvad gør man så for at forhindre at det sker igen?
Mon ikke man bør spærre sin betalingsaftale indtil en (forhåbentlig fornuftig) forklaring og meddelelse om at den er rettet, foreligger.

  • 14
  • 0
Martin Jünckow

Det interessante er at det kun er gået galt i 16 tilfælde og hvis vi antager de ikke er idioter, så tror jeg mest på det er en af følgende 2 scenarier:

1) Hash-clash som nævnes i artiklen, eks. er det typisk for den slags systemer kun at bruge en mindre del af kortnummeret til at hashe på, da det ikke må være muligt at omregne hashen tilbage til kortnummeret. En som ikke helt har forstået nok omkring konsekvenserne ved det kan have valgt at betragte resultatet som en unik nøgle man kan slå op på.

2) Som sagt race condition - det sker ofte at race conditions kun finder sted i eks. én ud af 1 mio. forespørgsler og kun under meget høj load på systemet. I et system med mange brugere vil man ramme ind i selv de mest sjældne race conditions fra tid til anden og det kan netop være en sådan sjælden race condition der kan forklare de 16 tilfælde.

Jeg hælder faktisk mest til race-condition fordi 1) kræver lidt at de groft sagt er "idioter" og lagring af kort-data kræver PCI-certificering som der stilles store krav til og en sådan amatør-fejl ville forhåbentlig være blevet spotted i Q&A.

Race-conditions derimod havde vi selv et nasty tilfælde af fornylig hvor vi var nød til at opsætte simuleringer til stress-test der kunne presse servicen op på 100% CPU forbrug før en race condition opstod i en lock-free kø-implementation i sjældne tilfælde. Inden denne stresstest, havde vi tested med 20 mio. successfulde forespørgsler og vi ville aldrig have opdaget den før produktion hvis ikke det var fordi vi havde valgt at udføre en simulering af at have 100.000 brugere forbundet samtidigt som pushede requests afsted.

  • 5
  • 0
Kaj Jensen

Medierne er vel de eneste som kan sætte en stopper for hele det cirkus. Hvad er din rolle i forhold til rejsekortet, siden du altid forsvarer det - og nu ligefrem mener at medierne spilder deres tid/plads på det?

Topic: Skræmmende fejl og jeg ville som ansvarlig være lidt nervøs når fejlen ikke kan identificerws.

  • 6
  • 0
Kim Jensen

Hejsa,

Det der undrer mig her, hvordan IT Professionelle kan undres! Har de personer der kommenterer på dette da ingen praktisk erfaring ?

At høre IT Lektor, Erik Frøkjær, udtale følgende: "Det undrer mig, at man ikke har fanget det inden ved at have et tilstrækkeligt finmasket sæt af testcases, som kan sættes i sving i forhold til enhver opdatering." Er faktisk skræmmende!

Når man snakker større systemer, som Rejsekortet må antages at være, så er der en skarp adskillelse mellem de forskellige led. Udviklerne har hverken adgang eller rettigheder til at lavet noget på produktions databaserne.

Så når udviklerne kommer med næste version af systemet, så er der ofte en DB opdatering, med tilhørende data aktualiseringer, med. Alt dette er grundigt testet, men mod et test system, der består af et subset af datamængden som det rigtige system har. Test data og test systemet er oftest noget man med tiden udvider til at inkludere fundne fejl og problemer, samt tilpasning af eksisterende og nye funktioner.

Selv hvis man, som udvikler, har adgang til en kopi af produktions databasen, så er det gerne med anonymiserede data. Hvilket betyder at man kan teste og verificere opdateringen, men gør det på basis af en tilnærmet norm.

Min formodning er simpelt; et af de scripts der skulle køres var lavet med "løse antagelser"; "UPDATE ... WHERE bla like '...%'". En dum måde at lave opdateringer på, men desværre ikke ualmindelig. Dette vil kunne forklare hvorfor det ikke var fanget, eller kunne fanges, tidligere.

Skulle mine formodninger være forkerte, og udviklerne har haft direkte adgang til produktions systemer, eller ægte kopier af produktions dataene, så er det et sjusket amatør arbejde som de har lavet!

Mvh,
Kim Jensen

  • 5
  • 5
Peter Rosendahl

Jeg tænker, at de fleste der skriver i denne tråd har begået fejl (!), og alligevel betragter sig selv som professionelle. Det sker, og hvis man undres over det, har man næppe lang praktisk erfaring. Eller lægger så højt et kvalitetsniveau, at produktiviteten må være temmelig lav.

Fejlen er uheldig, men jeg har svært ved at blive forundret...

  • 10
  • 1
Ditlev Petersen

hvor man holder op med at undres, bliver livet meget kedeligt. Hvis det er rigtigt, at det kun er sket 16 gange, er det måske ikke så mystisk, at fejlen er sluppet igennem en aftestning. Jeg har set værre ting ryge gennem en test. Og den fejl fandt vi aldrig, vi var nødt til at kode programmet om med et ekstra fejltjek. Muligvis var det noget tredjeparts-software, der "engang imellem" returnerede en forkert værdi.

  • 3
  • 0
niels henrik højbjerg

jeg undrer mig til gengæld over at nogen kan undre sig over at der er fejl i rejsekort-systemet.

set udefra er det et meget dårligt, klodset og uhensigtsmæssigt system, som partout skal trækkes ned over hovedet på folk.

det tager ikke højde for ganske banale ting.

det er dyrt og dårligt.

og det kommer ALDRIG NOGENSINDE til at fungere ordentligt.

nh

  • 11
  • 3
Klavs Klavsen

Et seriøst miljø vil da vel altid have et staging/pre-produktion miljø - hvor man netop får en komplet kopi af produktion - og så tester opgraderingen på det, men har sikret at kommunikation udadtil (email f.ex.) - ikke ryger til kunderne men til et opsamlingssted.

Har selv lavet det samme - også til test miljøer, hvor man bare giver dem et snapshot (disk mæssigt) af de par TB data produktionen har - og så anonymiserer som relevant hvis det er til udviklere - men til pre-produktion/staging testen, skal det selvf. være 100% magen til prod - og så bare "vejene ud" der skal fanges.

Så kan man se præcis hvad en updatering vil gøre og hvordan det vil ende - på præcis de produktionsdata det skal foregå på bagefter.

Derudover så vil jeg håbe at rejsekortet falder ind under Brian Mikkelsens beskrivelse af hvad der burde høre under PHK's baby - en IT-havari kommission? - ellers er det ihvertfald utilstrækkeligt med det oplæg de kommer med.

  • 1
  • 0
Knud Jensen

I går skrev man:

Adm. direktør i Rejsekort A/S Bjørn Wahlsten fortæller, at fejlen blev opdaget i sidste uge, og at den blev rettet ved at rulle det, der i rejsekort-terminologi hedder en hotfix ud i systemet. Hotfix er en målrettet systemopdatering.

I dag skriver man så:

Adm. direktør i Rejsekort A/S Bjørn Wahlsten har endnu ikke noget endeligt bud på, hvad fejlen kan skyldes.

Hvis man ikke ved hvad fejlen skyldes, hvordan kan man så rulle en patch ud?

  • 13
  • 0
Ditlev Petersen

Det viser først og fremmest handlekraft at rette fejlen, før den er fundet. :-) I det tilfælde, jeg omtalte før, gjorde vi netop dette. Vi kunne fange fejlen, før der skete noget, men vi vidste ikke (og fandt aldrig ud af), hvorfor den opstod.

  • 1
  • 0
Rasmus Iversen

Lyder som om udviklerne ikke har taget højde for hashing collisions eller sådan noget. Man fanger jo ikke nødvendigvis den slags fejl, hvis man ikke tester op mod datasæt der er store nok, til at de opstår. Dog burde man vide den slags... hvis det altså er det som er tilfældet her.

  • 0
  • 0
Log ind eller Opret konto for at kommentere