Nets senket Vipps

[Redaksjonen.]

Meldte ikke ifra om programvareendring.

Nets senket Vipps

[Polle_2]

Hmm, hele vipps nede pga en endring i kontrakten når en legger inn "nye kortopplysninger", det høres for meg veldig merkelig ut at det skal ta ned alt av vipps.

 

Videre er det merkelig at det tar 3 dager å finne ut en webservice og hvilken som feiler, det burde vært feilsøkt og løst på maks noen timer.

[_dundun_]

At alt går ned når et API endres er ikke egentlig så veldig uvanlig, selv om det er litt udugelig. Tipper det har med sikkehet og signaturer å gjøre.

 

At det tok så lang tid å finne ut av det er intet mindre enn fantastisk.

[Øystein Jakobsen]

Er nok noen som trenger et ITIL-kurs og en fungerende CMDB. De må se avhengigheter, så de ikke igjen oppdager plutselig at en endring her får konsekvenser der.

 

Artikkel om CMDB: https://en.wikipedia.org/wiki/Configuration_management_database

Eksempel på CMDB: http://www.bmc.com/it-solutions/atrium-cmdb.html

Endret 20. juni 2016 av Øystein Jakobsen

[Polle_2]

At alt går ned når et API endres er ikke egentlig så veldig uvanlig, selv om det er litt udugelig. Tipper det har med sikkehet og signaturer å gjøre.

 

At det tok så lang tid å finne ut av det er intet mindre enn fantastisk.

 

Det er ikke vanlig, og det skal hvertfall ikke være vanlig i en bedrift som DnB. At en kontrakt på en liten del av funksjonaliteten endres skal ikke påvirke alle deler av et system, det er udugelighet.

[Nils Fredrik Gjerull]

Dette er nok bare en del av forklaringen og antagelig ikke hovedårsaken. Sikkert fint for DNB å kunne skylde på andre, men synes ikke forklaringen er troverdig. Er dette forklaringen DNB har fått av selskapet de outsource'er til?

 

Vil gjette på at det er flere årsaker til problemene som har vært. DNB må være mer åpne om hva som faktisk har skjedd enn dette. Etter Panama Papers avsløringene hadde jeg håpet å se litt mer åpenhet. Gode detaljerte forklaringer styrker tilliten, dette gjør det ikke.

[_dundun_]

Det er ikke vanlig, og det skal hvertfall ikke være vanlig i en bedrift som DnB. At en kontrakt på en liten del av funksjonaliteten endres skal ikke påvirke alle deler av et system, det er udugelighet.

Har du sett APIene bankene bruker? Det er ikke akkurat REST

[Polle_2]

 

Det er ikke vanlig, og det skal hvertfall ikke være vanlig i en bedrift som DnB. At en kontrakt på en liten del av funksjonaliteten endres skal ikke påvirke alle deler av et system, det er udugelighet.

Har du sett APIene bankene bruker? Det er ikke akkurat REST

Ja, jeg sitter i en bank akkurat nå og jobber mot API'ene til Evry gjennom SOAP. Alt går ikke ned om Evry skulle tulle med noen av kontraktene sine her hos oss.

[_dundun_]

Normalt skal det ikke gjøre det nei, så at dette er udugelighet er det ikke tvil om. Men det er jo også mer kompliserte greier enn hva folk normalt forbinder med APIer.

[tHz]

Det virker fantastisk amatørmessig. Typisk tegn på outsourcing hvor ingen gidder å ta ansvar.

 

En slik app bør ha telemtri og logging nok til å finne slike problemer umiddelbart. 

[Sokkalf™]

Integrasjonstester er jo ikke så dumt å ha..

[_dundun_]

De har nok det. Greia her var jo at ingen trodde det var gjort noen endring.

[siDDis]

Integrasjonstest vil jo gi beskjed med ein gong og nøyaktig kva som feiler. Men som sagt, sjølv med massevis av tester så er det sjeldan dei dekker corner cases fordi ingen visste om det før det faktisk skjedde. Testing førebygger at kjente feil ikkje skal skje igjen.

[tHz]

Log fra en klient ville gitt de svaret på hva som feilet.

3 dager er helt latterlig, uansett bortforklaringer.

[_dundun_]

Log fra en klient ville gitt de svaret på hva som feilet.

3 dager er helt latterlig, uansett bortforklaringer.

Neppe, da dette tydeligvis var en backendfeil helt uavhengig av appen.

 

Integrasjonstest vil jo gi beskjed med ein gong og nøyaktig kva som feiler. Men som sagt, sjølv med massevis av tester så er det sjeldan dei dekker corner cases fordi ingen visste om det før det faktisk skjedde. Testing førebygger at kjente feil ikkje skal skje igjen.

Tipper de får en test for dette caset nå

Endret 20. juni 2016 av Audun_K

[tHz]

 

Log fra en klient ville gitt de svaret på hva som feilet.

3 dager er helt latterlig, uansett bortforklaringer.

Neppe, da dette tydeligvis var en backendfeil helt uavhengig av appen.

 

En backendfeil er som resulterer i at klienten viser en feilmelding er aldri "helt uavhengig".

Klienten logger feil, som korreleres med log serverside.

 

Dette er elemtær logging som støttes i alle loggrammeverk og applikasjonsoveråkingsverktøy som finnes.

 

Hvis DNB for ramme alvor ikke kan se feilmeldinger som genereres i systemet sitt så blir jeg skremt.

[_dundun_]

Jeg tviler sterkt på om de videresender errorlogger fra backend til klientene, om det er det du mener. Men at de burde hatt dette i loggene sine? Helt klart.

 

Problemet er bare at ukjente feil ofte er vanskelige å lese ut fra logger selv om man har data. Feilen oppstår gjerne et annet sted enn der man venter, loggene har masse støy, etc. Særlig når man har et par millioner brukere som alle opplever feil samtidig. Da tar det tid å lete seg frem også om man har gode loggerutiner, og så skal man begynne å finne ut av det.

 

Tre dager er lenge, men det er faktisk ikke enkelt å finne ut av alle feil selv om man har aldri så gode logger, og særlig ikke når det er nye og ukjente feil man gjerne ikke har en spesifikk loggmelding for.

Endret 20. juni 2016 av Audun_K

[E32IF3SH]

Nyhet i neste uke "Vipps er nede igjen".

[tHz]

Jeg tviler sterkt på om de videresender errorlogger fra backend til klientene, om det er det du mener. Men at de burde hatt dette i loggene sine? Helt klart.

 

Problemet er bare at ukjente feil ofte er vanskelige å lese ut fra logger selv om man har data. Feilen oppstår gjerne et annet sted enn der man venter, loggene har masse støy, etc. Særlig når man har et par millioner brukere som alle opplever feil samtidig. Da tar det tid å lete seg frem også om man har gode loggerutiner, og så skal man begynne å finne ut av det.

 

Tre dager er lenge, men det er faktisk ikke enkelt å finne ut av alle feil selv om man har aldri så gode logger, og særlig ikke når det er nye og ukjente feil man gjerne ikke har en spesifikk loggmelding for.

 

Jeg mente ikke at backend sender feilmelding til klientene. Jeg mener at man har en id på klienten som sendes inn sammen med alle api kall, samt at feilmeldinger på klienten også blir sendt inn til backend. Da kan man spore en feil fra klienten og hele veien igjennom systemet.

 

En feil som gir samme feilmelding hver gang, feiler på samme sted og gjelder samtlige brukere bør være triviell å lokalisere. Det er sjelden man har en såpass lett reproduserbar feil på lista. De fleste språk gir i det minste en stacktrace, selv om feilen i seg selv er ukjent.

[quantum]

Det er ikke vanlig, og det skal hvertfall ikke være vanlig i en bedrift som DnB. At en kontrakt på en liten del av funksjonaliteten endres skal ikke påvirke alle deler av et system, det er udugelighet.

 

En ønsker generelt ikke å la systemet kjøre videre når det er innført uspesifiserte/ukjente endringer. Fail fast, better safe than sorry osv. Her ble penger trukket fra den ene kontoen og ikke satt inn på den andre. Hvor lenge tror du egentlig vipps-brukerne er interessert i at systemet kjører med den "funksjonaliteten"?