Vipps ble slått ut av kodefeil

[Gjest Marius B. Jørgenrud]

Endringer i produksjon førte til kaos og 16 timers nedetid.

Vipps ble slått ut av kodefeil

[VLZELTYW]

Det som er ironisk er at teknikken som normalt benyttes for å unngå denne typen feil kalles transaksjoner. Man skulle jo tro at transaksjoner var en del av kjernevirksomheten til banken og noe de hadde kontroll på.

[Trond Remi]

Har hatt Swish i Sverige et par år nå helt uten trøbbel.

Bruker Norge ny utdannede IT amatører som kan og vet alt ! 

Endret 7. august 2017 av Trond Remi

[Benbjo]

Har hatt Swish i Sverige et par år nå helt uten trøbbel.

Bruker Norge ny utdannede IT amatører som kan og vet alt ! 

 

Og du vet ikke hva du snakker om ser jeg

[GOAXT8WU]

"Et stort antall teknikere jobbet ifølge ham på spreng med å avdekke feilen på fredag".

 

Hva med de som har utviklet det? Kunne kanskje vært litt mer effektivt. Men de sitter vel laaaangt unna, de som kan systemet. Genialt.

[Sokkalf™]

Det som er ironisk er at teknikken som normalt benyttes for å unngå denne typen feil kalles transaksjoner. Man skulle jo tro at transaksjoner var en del av kjernevirksomheten til banken og noe de hadde kontroll på.

Tja, de har kanskje fått litt skikk på det etter forrige runde, hvor de faktisk betalte ut mer penger enn det som var trukket.

https://www.digi.no/artikler/vipps-betalte-dobbelt-na-vil-de-ha-pengene-tilbake/395995

Denne gangen har jo ihvertfall de samme pengene som har gått ut gått inn et annet sted, selv om det skjedde flere ganger enn det burde.

 

Det de imidlertid viser denne gangen ved å gå ned av en endring i produksjon, er at de ikke har tilstrekkelig testregime.

[tHz]

Jeg lurer på om DNB fortsatt mener at IT er noe man kan outsource til der det er billigst.

IT er jo ikke viktig, ikke sant? Det er bare en utgiftspost. DNB sin kjernevirksomhet er jo bank, ikke IT. Da kan ikke IT være verdt å bruke penger på.

[henrikwl]

Det som er ironisk er at teknikken som normalt benyttes for å unngå denne typen feil kalles transaksjoner. Man skulle jo tro at transaksjoner var en del av kjernevirksomheten til banken og noe de hadde kontroll på.

 

Transaksjoner er ingen sølvkule; spesielt i store, komplekse distribuerte systemer så finnes det flust av steder hvor transaksjonshåndtering kan gå skeis. Heuristiske feil slik som den vi så her er på ingen måte uvanlige i utviklings- og test-fasen og kan være vriene å få has på. Her hadde tydeligvis en av dem sneket seg gjennom til produksjonsmiljøet.

[Gjest Slettet+987123849734]

 

Det som er ironisk er at teknikken som normalt benyttes for å unngå denne typen feil kalles transaksjoner. Man skulle jo tro at transaksjoner var en del av kjernevirksomheten til banken og noe de hadde kontroll på.

 

Transaksjoner er ingen sølvkule; spesielt i store, komplekse distribuerte systemer så finnes det flust av steder hvor transaksjonshåndtering kan gå skeis. Heuristiske feil slik som den vi så her er på ingen måte uvanlige i utviklings- og test-fasen og kan være vriene å få has på. Her hadde tydeligvis en av dem sneket seg gjennom til produksjonsmiljøet.

For å tippe hva en sånn feil som dette går ut på, så tror jeg det er en eller annen prosess som har ansvar for å gjennomføre vips transaksjoner mot bankens systemer.

 

Dvs vips sender en melding til denne "overfør xx kr til yy fra zz" Denne prosessen setter I gang med jobben og får den gjort også skal den oppdatere status på jobben (sikkert i en database) også feiler det her. Dermed så står jobben fortsatt som "ikke ferdig" og denne prosessen tar tak i jobben på nytt og dermed har du en løkke av transaksjoner.

 

Alternativt kan det jo også være flere av denne prosessen for last balansering/failover også tar flere av denne prosessen tak i jobben som skal gjøres, fordi det ikke er noen fungerende låsemekanismer for jobber som blir gjort, sånn at de kan utføres av flere prosesser samtidig og dermed får man utført samme oppgave flere ganger.

[lfa]

Er det ikke litt spesielt at det tok 16t før de rullet tilbake til forrige versjon? De må jo ha sett at problemene startet etter endringene som ble gjort.

[joppzter]

Noen som vet om Vipps blir utviklet i Norge eller er det stort sett outsourcet til India?

[Bolson]

Noen som vet om Vipps blir utviklet i Norge eller er det stort sett outsourcet til India?

 

Stor grad utviklet i Norge av indiske IT-arbeidere. Du husker sikkert balubaen knyttet til brudd på norsk arbeidsmiljølovgvning.

[Ove Gram Nipen]

Det som er ironisk er at teknikken som normalt benyttes for å unngå denne typen feil kalles transaksjoner. Man skulle jo tro at transaksjoner var en del av kjernevirksomheten til banken og noe de hadde kontroll på.

 

Nå må du ikke forveksle en databasetransaksjon og en finansiell transaksjon.

[Dr.B]

Det som er alarmerende med at DNB har gjentatte problemer med tjenestene sine, er at de har en testavdeling som burde fange opp store avvik som dette.

 

Er det DNB som mener test ikke er viktig og derfor ikke inkluderer dem, eller er det noe galt med hvordan de organiserer test?

 

At en oppdatering slipper gjennom test med en alvorlig feil kan skje både en og to ganger, men når det gjentar seg så ofte som det gjør hos DNB bør noen revurdere risikomatrisene og hvordan man utfører testing. DNB har nærmest blitt et skjellsord i Norge.

[Bernies]

SpareBank1s mCASH (norskutviklet) har fungert mer eller mindre smertefritt i 3 år. Merkelig at DNB ikke velger å benytte mCASH sin back-end nå som de skal slås sammen fremfor det rælet de sitter på nå.

[TG-]

Synes fortsatt de burde kalt det "Oopps" - alt tatt i betraktning, ville navnet beskrevet tjenesten bedre..

[ChrZZ]

SpareBank1s mCASH (norskutviklet) har fungert mer eller mindre smertefritt i 3 år. Merkelig at DNB ikke velger å benytte mCASH sin back-end nå som de skal slås sammen fremfor det rælet de sitter på nå.

 

Kan vel med trygghet si at lasten på mCASH ikke er helt den samme som hos VIPPS.

 

Samt, kompleksiteten. Kan ikke se at jeg kan betale med mCASH i nettbutikker?