Dankort-systemet fejlede i timevis efter opdatering

Jeg har aldrig helt forstået hvorfor dem, der ruller ny software på ikke lige kigger i loggen, og ser om der er normalt drift efter opdateringen er gennemført.

Men det er måske ikke oplagt, der klokken lort om natten, efter en dag med change boards, ITIL-processer og hvad ved jeg. Og man skal jo nok få at vide hvis det ikke gik godt (når kundeservice har modtaget ca. 100.000 telefonopkald og man kan læse det på eb.dk).

Jeg har aldrig helt forstået hvorfor dem, der ruller ny software på ikke lige kigger i loggen, og ser om der er normalt drift efter opdateringen er gennemført.

Hvor i alverden ved du dog det fra? Altså at der blev testet, efter implementering.

I det mindste lykkedes det da faktisk for dem at markere driftsstatus på nets.eu med en rød prik.. Det er ikke tit det lykkedes, selv ikke under timelange nedbrud..

"Fejlen blev dog opdaget efter cirka fem timers nedbrud, oplyser pressevagt i Nets Ulrik Marschall."

http://politiken.dk/tjek/penge/dinepenge/ECE2014001/dankort-systemet-er-...

Hvis man laver en opdatering, der slukker hele Danmarks betalingsinfrastruktur, så kan man altså se det med det samme - hvis man gider at kigge efter.

Eller en systemvagt, der har sovet/overhørt en fejlalarm. Fik selv den første fejlmeddelelse om manglende kontakt til Nets fra min betalingsudbyder kl. 3:35. Så enten har de et mangelfuldt system til fejlalarmer, eller også har en eller anden sovet i timen.

Det er et klassisk eksempel på fejlende Change og Release Mgmt.

Man overlader til Incident processen at sørge for at servicen kommer op. I sidste ende peger de bare på deres leverandør, i stedet for at tage ansvar for slutbrugerens oplevelse af servicen. Det er desværre et ret normalt billede af manglende kommunikation og koordination mellem en serviceprovider og de aftaler de måtte have i under-pinning contracts. Problemet for NETS er bare, at det for slutbrugeren er komplet ligemeget hvad årsagen er, dankortet skal bare virke. At nedbrudsperioden kunne have været forkortet med transaktions/systemovervågning, verifikation, loganalyse mv. er en helt anden og fornuftig tankegang, men når dagen er slut er root cause til "nedbruddet" manglende validering og ufuldstændig Change og Release.

Det ville ikke undre mig om den del af servicen der var påvirket afhænger af viden på en eller meget få personer.

Situationen viser meget godt, hvor sårbare de fællesservices vi har i Danmark, er.

Lige så nemt som det tilsyneladende har været at åbne i den accessliste, eller hvad der nu var konfigureret forkert i den centrale dims, lige så nemt havde det været at undgå eller opdage det i tide.

Kan det ikke tænkes, at det har virket hele tiden, men ikke kunne klare "normal" belastning?

De mangler et bot-net til at teste performance :-)

Usandsynligt. Vi havde første afviste betaling 3:35 i nat, hvilket vist ikke kan gå under betegnelsen "normal belastning"...

Jeg forstår ikke, hvorfor et sådant system ikke er delt i 2 eller flere parallelle systemer. Således at man kan opdatere forskudt med f.eks. 24 timer, og dermed altid køre med halv kapacitet, hvis noget går galt.

Jeg forstår ikke, hvorfor et sådant system ikke er delt i 2 eller flere parallelle systemer. Således at man kan opdatere forskudt med f.eks. 24 timer, og dermed altid køre med halv kapacitet, hvis noget går galt.

Et spørgsmål om penge sikkert..

Systemet blev jo hacket. Måske er det stadigvæk hacket?

Typisk sårbarhed i et centraliseret system. Hvis man i stedet brugte et distribueret kryptografisk valuta system modelleret efter fx Bitcoin ville redundansen være så stor at det aldrig ville gå ned. Og som bonus behøvede vi ikke at stole på firmaer som Nets, hvis forretningsmodel går ud på at yde den absolut ringeste (billigste) betalingsservice danskerne vil acceptere.