ING draait drie miljoen dubbele afboekingen terug - update

ING gaat dubbele afboekingen waarmee klanten onlangs te maken hebben gekregen, terugdraaien. In totaal gaat het om drie miljoen transacties. Die zijn het gevolg van een storing, waardoor een batch aan betalingen twee keer is uitgevoerd.

Een woordvoerder van de bank zegt tegen de NOS dat niet duidelijk is wanneer alle overtollige betalingen zullen zijn teruggedraaid. ING maakt via Twitter bekend dat het bij de transacties om pinbetalingen gaat die op 19 maart zijn gedaan.

Op het ING-forum melden veel klanten dat ze met het verschijnsel te maken hebben gekregen. Daar zeggen sommigen bij verschillende betalingen met dubbele afschrijvingen te maken te hebben gekregen en claimen anderen dat ze door de storing een negatief saldo hebben.

Update, 16:26: ING meldt dat alle dubbele transacties zijn teruggedraaid en dat het saldo van klanten weer correct zou moeten zijn.

Reacties (223)

[wimdebok]

Het gebeurt nogals eens storingen. Wat volgens mij toch een van de oorzaken is de moderne procesbenadering in het ICT vak en zeker bij de ING. Het procesdenken (scrum, lean) in combinatie met technieken als Continuous delivery/integration. Kort cyclisch, te veel releases, de vlug vlug snel snel automatisering. Vandaag af, gisteren in productie bij wijze van spreken. Ik denk dat het een hoop zou helpen als de ICT systemen veel conservatiever en terughoudender benaderd worden. NIet te vaak wijzigingn doorvoeren bijvoorbeeld. Paar keer paar jaar, hoogop, behoudens bugfixes. Betrouwbaarheid lijkt me veel belangrijker als weer die nieuwe feature. En, iedere wijzing die je maakt is een risco en kan het mislopen.

[ByteDelight]

Conservatiever? Denk je echt dat anno 2018 ICT systemen op een 'ouderwetse' manier opgepakt kunnen worden?
De complexiteit is ZO hoog met alle aan elkaar gerelateerde systemen, dat het onmogelijk is om er met een waterval-aanpak mee aan de slag te gaan.

Agile werken betekent niet 'vlug vlug' zoals jij omschrijft, maar juist kwaliteit is (hoort) één van de vastgestelde pilaren te zijn.
Kijk eens naar dit plaatje: https://agileexecutive.fi.../07/devops_triangle_2.jpg

Het is niet de Way Of Working die fouten veroorzaakt, maar de complexiteit.
Agile werken is IMHO de enige oplossing daarvoor.

Helaas hebben ze het bij ons (Enexis) ook nog niet begrepen, en roepen veel managers (ja, managers natuurlijk) dat projectmatig werken en waterval nog prima kunnen, en tenminste geen ophef bij de business oplevert... Zucht.

[Edgarz]

Er is niets mis met waterfall werken hoor. Juist in complexe en/of kritische omgevingen kan dit bepaalde zekerheden opleveren. Het is prima om van geval tot geval te bekijken welke methodiek best fit is.

Zoals iedere development methodiek kun je deze goed en slecht uitvoeren. Agile zelf is geen wondermiddel.

[wimdebok]

Ik bedoel conservatiever in de benadering. Ik denk dat belangrijk is om te zeggen, rustig aan, wat vandaag niet hoeft kan morgen wel, ruim de tijd nemen, komt tijd komt raad, pom pom de dag komt wel om. Dat heeft volgens mij goede invloed op de kwaliteit naast natuurlijk de mensen die er aan werken. Ik denk bijvoorbeeld dat continuit van personeel een hoop helpt. Niet denken dat het ook wel in een ander land kan of door een ander bedrijf (outsourcing). Dat kwaliteit een van de sterke punten is van Agile, dat zegt mij niet zoveel, er wordt veel aan agile toegschreven waarbij de vraag is: wat is agile? Een synoniem voor scrum denk ik wel eens. Of dat ongelukkig manifesto? Want ik denk bijvoorbeeld dat het niet goed is dat 'opdrachtgever' door middel van de product owner leidend is geworden. Dat kan niet anders dan slecht voor de kwaliteit zijn, prioriteiten die meer op het functionele liggen in plaats van op de software.

Wel denk ik, ik had beter een drie daagse scrum cursus kunnen doen dan een studie wiskunde/informatica.

[Cronax]

Als je je niet wil inlezen is het makkelijk om een boel vage statements bij elkaar te graaien maar je zegt niet zo veel.

Kort door de bocht is Scrum simpelweg een manier om een softwareproduct stukje bij beetje te bouwen. In plaats van grote langdurige trajecten zoals bij klassieke vormen, concentreer je je er als team er op om een beperkte set aan functionaliteit tegelijk te maken en die helemaal af te maken, klaar voor gebruik door de eindgebruiker. Dat wil zeggen dat je het ook gaat testen en gaat uitrollen naar een omgeving die ofwel productie is, ofwel goed genoeg op de productieomgeving lijkt. Verder ga je ook actief de functionaliteit met de eindgebruiker delen en bespreken zodat je eventuele feedback direct kan verwerken. Dat is de reden achter de bewering dat kwaliteit bij Agile ingebouwd is: het is onderdeel van het proces, want je gaat al in vroeg stadium dingen afmaken, integreren, testen en er gebruikersfeedback over verzamelen.

Het feit dat alles zo snel moet bewegen heeft ook bepaalde gevolgen, bijvoorbeeld dat je snel een nieuwe versie ergens moet kunnen neerzetten (zodat je die kan testen en eventuele problemen gelijk kan fixen) en je zal iets moeten bedenken om te zorgen dat de functionaliteit die eerder gebouwd is, niet is omgevallen. Dit gedeelte wordt echter vaak achterwege gelaten (omdat men niet wil investeren in testautomatisering, of een willekeurige andere onzinreden...) en dan begint het gedoe.

Dit alles om duidelijk te maken dat deze vage 'vlug vlug' sfeer die je toeschrijft aan Agile daar juist niet thuis hoort. Als je het Agile Manifesto leest en gelijk de Scrum Guide eens doorneemt dan zal het je hopelijk vrij snel duidelijk worden dat dat juist niet de bedoeling is. Dat neemt niet weg dat er een hoop bedrijven zijn die het verkeerd inzetten, of maar half inzetten en dan beslissen dat het dus nooit kan werken. Agile werken vereist een verandering van bedrijfscultuur en een verschuiving naar langetermijndenken, maar daar zijn veel bedrijven eigenlijk niet toe bereidt.

[wimdebok]

Dat is wat ik ook veel lees, het niet goed slagen van de scrum etc dat veel bedrijven het verkeerd inzetten, dus niet de ware agile beoefenen uitoefenen.

Stapsgewijs is niet zo gek, dat is wat je als softwareontwikkelaar al deed voordat scrum of agile nog maar bestonden. Je weet ongeveer waar het heen moet, je weet een beetje hoe dat moet gebeuren en al doende wordt het plaatje duidelijker. Je gooit wat weg, je herschrijft brokken en zo bouwt de software zich op. Ik denk dat het aan de functionele kant ongeveer hetzelfde gaat; het voortschrijdend inzicht moet het doen. Uiteindelijk moet je keuzes maken en sluit je sommige wegen af.

Wat ik zie, en ook in jouw antwoord lees, gaat het om kortcyclische release, waarin steeds functionaliteiten aangegeven door product owners worden opgeleverd. Maar hoe zit het met eens niet leveren en de software herschrijven? Je kan nooit van meet af aan leveren, het kan, maar ik denk dat je dan inlevert op de kwaliteit van de sofware. Vanaf het begin focussen op de te levere functionaliteit en dat als doel stellen, ik vraag me af of het handig is, en dat zit toch in dat hele gescrum ingebakken.

Denk dat agile dus ook gaat over het ruimte geven aan voortschrijdend inzicht. Maar ook, de opdrachtgever/bussiness verwacht rek in de functionaliteit, die rek is een eis aan de software. Dus het is ook de kunst je software zo te maken dat je verwachte wijzingen in de functionaliteit zich gemakkelijk laten doorvoeren. Ben dus van mening dat agile meer is dan alleen het proces waar het nu naar mijn mening teveel over gaat.

Ik weet in ieder geval wel dat de ontwikkelaars en techneuten (wat ouder) die ik ken hier allergisch voor zijn. De rituelen, de terminologie, de veelheid aan rollen die wel meepraten en zelfs bepalen maar geen verantwoordelijkheid met zich meedragen. Het is inmiddels een hele industrie geworden.

[Cronax]

Ik blijf overtuigd dat je een totaal verkeerd beeld hebt gekregen van wat agile betekend, waarschijnlijk doordat de enige ervaringen die je er mee hebt, komt uit plekken waar er maar wat gedaan werd met het labeltje 'agile' erop want dan hoef je lekker niets te documenteren (of een willekeurige andere onzinreden).

Alles wat jij beschrijft als eigenschap van agile die slecht is, is juist wat agile/scrum ontworpen is om te voorkomen. Ik hoop van harte dat je je er wat meer over wil inlezen.

Misschien kom ik wat over als een religieus fanaticus, misschien is dat ergens ook wel waar. Ik ben er echt heilig ( ) van overtuigd dat goed geïmplenteerd agile/scrum de beste manier is om fatsoenlijk software te ontwikkelen. Iedereen mag zijn mening hebben, maar dan wel gebaseerd op de feiten en niet op misinformatie.

[Reactie gewijzigd door Cronax op 24 juli 2024 22:50]

[wimdebok]

Dat beloof ik, ik ga het nog een keer proberen! Maar dat van die documentatie, och jee, die discussie ben ik ook zoveel tegengekomen, werd er wat somber van. Maar het manifesto gaf er ook wel aanleiding toe.

[nobraininvolved]

Ik de praktijk hangt het enorm af van het soort project of je voor de scrum manier of de waterval manier gaat.
Niet alle projecten zijn helemaal geschikt voor scrum en niet alle projecten zijn helemaal geschikt voor waterval.
Het grote voordeel aan scrum is dat je een enorme betrokkenheid hebt, door het hele proces heen, van de klant. De klant kan op ieder gewenst moment bijsturen (c.q. andere criteria doorgeven), die dan alsnog meegenomen kunnen worden.
Bij Waterval staat van tevoren (voor de bouw), eigenlijk al vast wat je gaat maken. Omdat projecten vaak een lange looptijd hebben (b.v. een applicatie maken kan maanden, zelfs jaren duren), is dit ivm voortschrijdend inzicht, niet altijd even handig.

Neem b.v. een afdeling marketing die een wijziging wil op een website.
Dat is nou typisch iets wat heel goed op de scrum manier kan gebeuren. De wijziging wordt gemaakt, de klant bekijkt het, kan het finetunen, uitbreiden, uitkleden (wat hij/zij maar wil) enz enz.
Hiervoor zou waterval veel te stroperig en langdradig zijn.

Maar neem nou een bestandsuitwisseling met b.v. een overheidsdienst.
Dat is vaak iets wat al aan de kant van de overheidsdienst helemaal vaststaat en waar bedrijven zich dan b.v. op aan moeten sluiten.
Omdat alles feitelijk al vaststaat (mapping is gedaan, analyse is gedaan), kan een klant niet zomaar zeggen; ik wil dat veldje niet in de XML, dus de klant staat van dit soort projecten een stuk verder weg.
In deze gevallen kan het handiger/efficienter zijn om eea via waterval op te pakken (kostentechnisch, want bij scrum staat er van begin tot eind een heel team klaar van ontwikkelaars, testers, Functioneel ontwerpers, klant, etc, terwijl het bij de waterval methode steeds van schutting naar schutting gegooid wordt, dus tester hoeft pas ingezet te worden als ontwikkelaar klaar is, etc.

Wat jou vraag betreft over leveren:
Bij scrum maak je gebruik van kleine, overzichtelijke userstories. Dus: een klantvraag wordt opgeknipt in zo klein mogelijke eenheden die los ontwikkeld kunnen worden (en waar de klant ook nog iets mee kan).
Aan het begin van een ontwikkelperiode (sprint), komt het hele team bij elkaar en worden de userstories besproken en ingeschat.
Die inschatting wordt tegenover de userstories gezet en er wordt simpelweg ergens een streep getrokken (dit kunnen we volgens onze inschatting binnen deze sprint afkrijgen, de rest komt in de volgende sprint).
In feite is iedere wijziging die de klant aangeeft, een nieuwe userstory.
Zo kan het zijn dat userstory 1 is: ik wil wielen met spaken, waarna de klant zich bedenkt en dan als userstory 2 verzint dat ie toch sterwielen wil.
Dat kan natuurlijk, maar dan wordt OF userstory 1 eerst gebouwd en daarna herbouwd naar userstory 2, OF userstory 1 vervalt, userstory 2 wordt door het team ingeschat en opnieuw geprioriteerd en dan past het wel/niet in de sprint (of er wordt binnen de sprint iets verschoven, waardoor een andere userstory met lagere prio naar de volgende sprint gaat).

De kwaliteitseisen worden bij de userstory ingeschat en moet door de professionals (b.v. ontwikkelaars) in de gaten gehouden worden. Als b.v. een userstory inhoudt dat er een stuk software herschreven moet worden om het totaal aan de ontwikkelstandaarden te laten voldoen, dan hoort dat simpelweg bij die userstory en bij de inschatting. Als dat niet gebeurd, dan is de professional gewoonweg niet goed bezig.
De kwaliteit zou dus, met een goed team, zeker gegarandeerd moeten zijn.

[wimdebok]

Mooie reactie, het klopt, het is niet overal geschikt voor. Ik denk ook, al iedereen hetzelfde erover denkt en tevreden over is, dan moet je vooral gaan scrummen. Websites, ja daar kan wat bij voorstellen. Het is altijd handig als je als ontwikkelaar kort op de gebruiker kan (mag!) zitten, hetzelfde geldt voor iedereen die technisch/inhoudelijk met elkaar te maken hebben op elkaar af kunnen stappen. Maar dat klinkt al meer als waar devops vandaan komt. Ken het hoor, heb je iemand nodig moet het via servicedesk en dan: heb je daar een ticket voor?

[nobraininvolved]

Ja idd, maar scrum heeft ook zijn valkuilen.
Wat ik vaak zie gebeuren is dat er aan al ingeschatte en al bijna afgebouwde userstories gezeten wordt en er zelfs tijdens het testen van de userstories nog wijzigingen komen in de acceptatiecriteria van de klant.
Eigenlijk zou dat niet mogelijk mogen zijn, want zoals aangegeven, zouden userstories, zodra ze zijn ingeschat en op de backlog staan, statisch moeten zijn (wijzigingen worden dan nieuwe userstories).
Maar goed, kleinigheden daargelaten is het een heel fijne methode om mee te werken en kun je er heel efficiënt en klantvriendelijk software mee opleveren waar de klant ook 100 % achterstaat.

[db_killer]

Toevallig werkzaam bij de belastingdienst als ICT'er? . Iets met...pom pom de dag komt wel om Maar even serieus. Het lijkt me alles behalve wenselijk om 2x per jaar een grote update van functionaliteit te doen op een zeer complex systeem. Het risico op fouten wordt alleen maar groter en de kans dat deze relatief eenvoudig op te lossen zijn kleiner.

[Reactie gewijzigd door db_killer op 24 juli 2024 22:50]

[wimdebok]

Nee, joh, bij de ING gewerkt. En de ene dag weet je het, de andere dag wat minder. Soms moet je even denken, dat bedoel ik. Het enige wat ik zeg, is het wijs aan systemen die zo cruciaal zijn en die 24/7 foutloos moeten werken in korte cycli wijzigingen door te voeren. Iedere wijziging is een risico. De betrouwbaarheid en uptime horen ten allen tijde op 1 te staan. Niet de wens het proces naar de letter uit te voeren.

[db_killer]

Het proces is inderdaad geen doel. Het doel is om functionaliteit toe te voegen om zo aan de wens van de klant te kunnen blijven voldoen en als bedrijf je marktpositie te handhaven. Software iedere twee weken of ieder half jaar opleveren zal geen invloed hebben op de hoeveelheid gewenste functionaliteit in bv. 1 jaar. Echter in een oplevering van twee weken zit minder functionaliteit verwerkt en als hier wat fout gaat is het eenvoudiger te repareren. Een oplevering die in een half jaar ontwikkeld is zal veel meer functionaliteit bevatten en daarom ook risicovoller zijn. De kans dat er iets mis gaat is aannemelijk en het corrigeren van fouten is lastig omdat er zoveel extra functionaliteit toegevoegd is. Als je vervolgens dus moet besluiten om de oplevering van een half jaar daarvoor terug te zetten, dan ben je al je nieuwe functionaliteit kwijt, terwijl 99% waarschijnlijk correct werkt.

[wimdebok]

Kan een eind met je meegaan, je zou ook kunnen zeggen, kort opleveringen betekent ook minder tijd om uitgebreid te testen. Als het fout gaat, is het misschien makkelijker terug te draaien. Kom ik toch weer op de agile/scrum, in korte sprints steeds nieuwe functionaliteit opleveren. Wordt dan niet de korte tijdspanne het doel in plaats dan maar iets langer en kwalitatief goed? Het is hoge druk ICT.

Meer opleveringen kan ook meer verstoringen voor de gebruiker op leveren en dat is geen goede reclame. Lastig!

[db_killer]

De ervaring leert dat je door in kleinere opleveringen te werken je effectief meer tijd hebt om te testen, hoe gek dat ook klinkt. Je hebt een tester die focus kan houden op de geleverde functionaliteit en die is redelijk beperkt in bv. 2 weken. De tester is onderdeel van het team en is daardoor bij alles betrokken. Bij een grotere opleveringen zie je vaak dat er een afzonderlijk testteam is die minder betrokken is bij de werkzaamheden, waardoor onderdelen gemist kunnen worden. Na een half jaar weet bijna niemand meer wat ze de eerste maand gebouwd/getest hebben en welke huidige wijzigingen hier nog een impact kunnen hebben. Door meerdere opleveringen is daarom jouw doel: iets langer en kwalitatief goed reëler dan bij heel weinig opleveringen. Down time en verstoringen voor de gebruiker zijn inderdaad een issue, waardoor je deze werkwijze ook alleen kan doen wanneer de infra en de overige processen hier op ingericht zijn/rekening mee houden. Uiteraard valt of staat alles met de juiste uitvoering en samenwerking, maar dat is zowel bij weinig en veel opleveringen het geval.

Overigens kun je zeggen wat je wil, ze hebben het weer snel gefixed bij de ING

[Reactie gewijzigd door db_killer op 24 juli 2024 22:50]

[nobraininvolved]

Het is ook altijd de taak van de tester om uit te vogelen (eventueel samen met het team) waar de risico's zitten en daar meer testnadruk op te leggen (Risk based testing).
Zo kan het bijvoorbeeld heel goed zijn dat als ik een oplevering test, dat ik maar 50 % daadwerkelijk bekijk en de andere 50 % niet, of nauwelijks bekijk. Als die 1e 50 % een hoop achterliggende functionaliteit raakt (of op een andere manier risico vormt, b.v. reputatieschade) en die 2e 50 % wat puntjes op de i zijn op b.v. een schermpje, dan wordt de nadruk echt op die 1e 50 % gelegd.

Daarnaast kun je er nog van alles omheen bouwen natuurlijk. Als ik naar onze toko kijk, wij draaien regelmatig regressietesten op alle applicaties, doen health checks wanneer iets naar productie gaat, testen per project de nieuwe functionaliteit door, al dan niet op basis van Risk based testing (soms testen we ook gewoon alles, ongeacht het risico wat ingeschat is, dat gebeurt b.v. in samenspraak met de klant).

Wat ook meespeelt, is hoe lang het (kan) duren voordat een bug gefixt is. Heb je maandelijkse opleveringen, dan kan een bug dus wat langer in de lucht zijn. Heb je een incidentenproces met eigen opleveringen, dan kan het mss binnen een dag of korter gefixt of in de lucht zijn. Ook dat hoort bij het risico-inschatten.

[Valkeyr]

Toevallig werkzaam bij een gemeente of de Belastingdienst? Iets met...pom pom de dag komt wel om .

2 releases per jaar lijkt mij nooit een wenselijke situatie en is denk ik toch wat kortzichtig. Anno 2018 kun je niet meer op deze manier denken, grote wijzigingen in 1x doorvoeren betekent vaak ook dat de impact enorm is en hoe kijk je tegen de mitigatie van kwetsbaarheden? Ik verwacht van mijn bank(toevallig ING) dat, zodra een kwetsbaarheid bekend is, dat er asap een mitigatie plaats zal vinden. Ik heb liever incidenteel een storing en een veilige omgeving, dan een infrastructuur vol met kwetsbaarheden met 2 releasemomenten (lees: 2 mogelijke verstoringen) in het jaar.

[wimdebok]

Zijn er kwetsbaarheden of bugs en er zijn fixes nodig dan voer je die zo snel mogelijk door. Dat is iets anders dan nieuwe of andere functionaliteiten. Wat ik probeer te zeggen, iedere wijziging is een risico. Downtime en verstoringen, dat is echt het allerlaatste wat je wil lijkt me.

[vectormatic]

Continous Delivery maakt het daarintegen ook mogelijk om bij een probleem, snel een fix uit te rollen, zonder dat je en masse je eigen regels hoeft te breken en al je regressie trajecten te shortcutten, en fouten gebeuren er hoe dan ook, of je nu een heel star 6 maandelijkse release cycle hebt, of elk uur kan gaan.

Overigens denk ik inderdaad niet dat het heel kort cyclische de handigste keus is voor de transactie systemen van een bank, maar daar zal dat ook minder worden ingezet gok ik zo (heb al een jaar of 7 niet meer bij een bank gezeten)

SCRUM/CI/CD zijn geen magic bullet, maar laten we vooral niet doen alsof old school monster waterval/releases lekker werkt, hoe vaak gaan dat soort projecten niet gruwelijk over hun budget/deadline heen, of worden ze helemaal opgegeven?

[Rob_03]

Inderdaad en daar komt bij dat het nog maar de vraag is of het een gevolg is van een nieuwe release. Ik heb er genoeg gezien waarbij processen stabiel draaien voor maanden en door een zeldzaam unieke combinatie van factoren in ene een ander resultaat geven zonder dat daar een new-release bug aan te pas kwam.

[Blaise]

Dat ING in bepaalde departementen agile werkt betekent niet dat ze dat ook doen voor de kernsystemen (transacties). Volgens mij werkt ING vooral agile in de afdelingen die de mobiele apps en Mijn ING ontwikkelen, en die systemen hebben niks te maken met een transactie-batch die dubbel is uitgevoerd.

Ik neem aan dat ING processen en checks heeft om de kwaliteit van het kernsysteem te waarborgen.

[Martao]

Ik zou niet weten waarom je voor zo'n kernsysteem niet agile zou werken. Er zijn hooguit zwaardere kwaliteits-eisen.

[Blaise]

Agile is (kort door de bocht) bedacht om een korte cyclus te hebben van samen bedenken wat je gaat doen, implementeren wat je bedacht hebt, feedback verzamelen van gebruikers.

Je kan zonder problemen agile toepassen op een kernsysteem, en misschien gebruikt ING dat ook in een bepaalde vorm. Het nut daarvan lijkt me beperkter omdat kernsystemen gelimiteerd zijn in functionaliteit, minder aan verandering onderhevig zijn, stabiliteit een essentieel onderdeel is, en gebruikers vooral interne computersystemen zijn.

[Martao]

Als er niks te ontwikkelen is, hoef je ook niet agile te ontwikkelen natuurlijk.

[mobrockers]

Je lijkt het idee van agile, CI/CD niet helemaal te snappen. Het idee is juist dat dit soort problemen eerder opgepakt worden. Stel dit is inderdaad door een nieuwe change geweest en ze hadden op de oude manier de software ontwikkeld. Dan hadden ze dit misschien wel een jaar geleden al geïntroduceerd en vandaag komen ze daar dan achter. Vervolgens moet het gehele release proces wat weken, maanden kan duren weer doorlopen worden om de fix hiervoor weer door te voeren. is het vervelend? Ja. Is het vervelender als je er een jaar na het doorvoeren van de change pas achter komt dat dit in productie voorkomt? Zeker.

Maar daarnaast, dit soort processen in de achtergrond, het doorlopen van transacties, die worden veelal nog in super oude systemen gedaan die nog vast zitten in kwart-jaarlijkse release schema's dus dit komt misschien wel helemaal niet door een change in software. Ik kan me zelfs voorstellen dat hier gewoon nog een handmatig proces aan te pas komt, en dat een mens per ongeluk dezelfde batch 2 keer gedraaid heeft.

[well0549]

Als testen zoals boven beschreven maanden werk is, veranderd de manier van werken dat helemaal niets aan.

Scrum, agile, waterval, allemaal loze kreten..... Die niets met het uitvoeren van tests te maken hebben......

Ik kan nu dan wel een fix maken maar die mag ook pas na test naar productie..... Ergo is over een paar maanden beschikbaar...

[BadpunK]

Heeft niets met agile te maken maar meer met de kwaliteit van ontwikkelen. Mogelijk dat testen een zeer groot aspect hiervan aan het worden is. Met name regressietesten. Ouderwetse manieren zoals waterval kan nog steeds bagger opleveren en verstoringen veroorzaken. Zie dat dus niet als een oplossing.

[well0549]

Klopt maak niet uit hoe ze de software maken....

Testen is een op zich staand proces waarbij de tester in principe de software namens de klant accepteerd....
En bij mijn weten laat ik nooit een slager zijn eigen vlees keuren.....

[GeoBeo]

Het gebeurt nogals eens storingen. Wat volgens mij toch een van de oorzaken is de moderne procesbenadering in het ICT vak en zeker bij de ING. Het procesdenken (scrum, lean) in combinatie met technieken als Continuous delivery/integration. Kort cyclisch, te veel releases, de vlug vlug snel snel automatisering. Vandaag af, gisteren in productie bij wijze van spreken. Ik denk dat het een hoop zou helpen als de ICT systemen veel conservatiever en terughoudender benaderd worden. NIet te vaak wijzigingn doorvoeren bijvoorbeeld. Paar keer paar jaar, hoogop, behoudens bugfixes. Betrouwbaarheid lijkt me veel belangrijker als weer die nieuwe feature. En, iedere wijzing die je maakt is een risco en kan het mislopen.

Ik zou het er bijna mee eens zijn, maar... Ik gebruik Bunq. De bank die veruit de meeste ICT features heeft en altijd als eerste die features heeft. Heel veel updates (sommigen vinden zelfs te veel).

Ik weet niet wat voor ontwikkel proces ze hanteren, maar blijkbaar werkt het aardig goed. De enige momenten dat ze down gingen, waarvan ik het weet, werden veroorzaakt door DDOS aanvallen.

Het ING probleem ruikt eerder naar een gevalletje vastgeroeste verkeerde mensen op de verkeerde plekken en juist een veel te ouderwetse vastgeroeste onefficiente ICT aanpak. Verder ook erg vreemd dat er geen alarm belletje gaat rinkelen als je als eeuwen oude mega grote bank 3 miljoen dubbele transacties uitvoert. Sterker nog: vreemd dat dat überhaupt mogelijk is.

Een typische situatie die ik al te vaak gezien heb in mijn loopbaan is dat frisse nieuwe werknemers onderaan de keten allerlei serieuze problemen signaleren die door het hogere meer ervaren management (maar ook devs) volledig genegeerd worden. Want; "nieuwe werknemers hebben nog niet zo veel ervaring", kost extra werk en geen tijd/budget voor en geen zin in. "We nemen het risico wel" (lees: negeren het risico). "Komt later wel". "Valt vast wel mee." En dan krijg je precies dit soort blunders.

ING heeft verder ook geen enkel excuus, geld zat...

[Reactie gewijzigd door GeoBeo op 24 juli 2024 22:50]

[ByteDelight]

Ik ben in juli 2016 bij ING op bezoek geweest, en daar hebben ze een enorme verandering doorgemaakt (die nog niet voltooid is) richting agile approach.
Ik was extreem onder de indruk wat ik daar zag, zeker wat de welwillendheid van de medewerkers betreft. Believe me: er zijn weinig organisaties die het roer zo drastich in de goede richting hebben omgegooid.
Wat ben jij onredelijk negatief tegen die mensen.

[Reactie gewijzigd door ByteDelight op 24 juli 2024 22:50]

[wimdebok]

Ik ben niet negatief tegenover de mensen, wel heel kritisch op de procesbenadering die zo belangrijk is geworden in het vak. Het had t welhaast iets religieus, bij de ING was dat zeker zo. Geeft toe misschien niet eerlijk, ik wordt er kriegel van als vrije jongen.

[mae-t.net]

Waar bij de ING ben je geweest? Voor zover ik weet zijn er meerdere softwareafdelingen.

[ByteDelight]

Hoofdkantoor Amsterdam.

[wimdebok]

Is ook niet helemaal eerlijk, Bunq vergelijken met de ING, Bunq is nieuw en vanaf 0 alles opzetten is toch iets anders. En de ING biedt veel meer diensten. Maar dat het daar wel lukt? Ik denk dat het eerder met de mensen te maken heeft dan met de methode, dat geldt wat mij betreft of het nu agile of waterfall is. Al moet ik heel eerlijk zeggen dat ik dat in mijn leven als ict'er dat nooit gerealiseerd heb. Ik doe maar wat . Wat ik wel weet, voortschrijdend iinzicht s belangrijk, en je moet bereid zijn om je ideeen bij te stellen ook. Is dat Agile?

Ook reactie op de anderen, toch mooi om te weten dat sommigen dingen niet veranderen. Nog steeds de batches die in de nacht draaien voor het bijwerken van je rekening, je echte rekening zeg maar. Ik weet niet helemaal zeker, maar volgens mij wat je op de site ziet is niet dat 'echte' systeem maar een schaduw daarvan.

Ja, en dan mijn gezeur over agile en scrum en zo. Ik ben denk ik een ouwe lul uit een tijd dat je als ict'er nog betrekkelijke vrijheid had en grote eigen verantwoordelijkheid. Het is ook een teken van de tijd, deze procesbegeleidingsmethoden zijn zo ingeburgerd maar buiten dat Scrum bijvoorbeeld ICT inhoudelijk niets te melden heeft gaat het over micromanagement en controle. Ben er allergisch voor, dit soort zaken en dan ook nog iedere ochtend als een klein kind staande moet zeggen wat je nu weer gaat doen. Maar ik weet ook, scrum wordt zelfs op scholen onderwezen. Het kan niet waar zijn. Heb zelf van nabij hoe karrevrachten van dit soort mensen binnengereden werd. Niet scrum masters en product owners maar ook verandermanagers of wat te denken continu verbetercoach. Maar het past in de tijd waarin de ene helft van de mensen de andere helft coached, stuurt en controleert. Uiteindelijk denk ik hangt het op net de juiste mensen bij elkaar, niet teveel en men begrijpt elkaar. Lastig zat.

[Reactie gewijzigd door wimdebok op 24 juli 2024 22:50]

[Martao]

Ik werk bij een software bedrijf met veel (scrum teams) en we hebben in principe elke dag een release. Mochten er bijvoorbeeld problemen zijn met de regressie test, dan kan dit weleens een paar dagen duren. Stel dat je pas na een week een nieuwe deployment hebt, dan zien we juist vaker dat er problemen ontstaan op de productie omgeving. Je kunt beter in kleine iteraties opleveren, dan grote batches van wijzigingen. Uiteraard moet je wel de kwaliteit van je kleine iteraties waarborgen.

[totaalgeenhard]

Weet jij wat er fout is gegaan?

[mjz2cool]

het idee van agile is juist dat je door sprints betere kwaliteit kunt leveren, omdat je steeds een klein stukje aanpakt. als het dan eenmaal af is kun je op deze manier ook de boel up-to-date houden. het is alles behalve vlug vlug snel snel. ook met agile kun je kiezen om een paar updates per jaar te doen. maar hoe verder we zijn hoe complexer alles wordt, ook qua veiligheid. dan kun je niet op de "ouderwetse manier" door blijven gaan maar moet je flexibel worden. dat er dan dit soort fouten optreden blijf je toch houden.

[Verwijderd]

Het is eerder zo dat de ING oude systemen juist niet durft aan te raken.

[ikke_]

Waar staat dat het twee keer aanbieden van de batch door een software update komt?

Volgens mij is het idempotent verwerken van gegevens niet geïmplementeerd, zodat twee keer dezelfde gegrvens aanbieden hetzelfde resultaat heeft en geen dubbele afboekingen.

[honey]

Hun berichtgeving klopt niet. Ik heb een dubbele boeking betaald op 20 maart en op 21 maart exact weer hetzelfde bij dezelfde Shell tankstation.

[faim]

'Afgeschreven op 20 maart, maar betalingen gedaan op 19 maart'.

Overigens zijn dubbele betalingen bij mij nu teruggeboekt, maar dit had geen invloed op mijn totaalsaldo, want dat is nog steeds hetzelfde als vanochtend.

[Countess]

Pin betalingen worden vaker een dag later afgeschreven.

wij hebben er ook 2 van de AH, de 19de gemaakt, maar de 20ste en 21ste afgeschreven.

[mjz2cool]

normaal is dit wel meteen te zien. naar een rekening van een andere bank overschrijven duurt vaak wel iets langer

[Verwijderd]

Verbazingwekkend dat dit zomaar kan gebeuren.
Hetzelfde transactienummer, hetzelfde bedrag, twee keer afschrijven... en dan treed er nergens een melding op en wordt de tweede _identieke_ afschrijving gewoon doorgevoerd van de rekening. Ik zag het gister al bij een redelijk grote betaling (300 euro) die we hadden gedaan op 19 maart die gister ook weer op de rekening was afgeschreven.
Omdat het exact hetzelfde transactienummer was heb ik eerst ING gebeld, en die zeiden doodleuk dat het het probleem lag bij de winkel waar ik gepinned had. Zelfs dan gaat er dus geen lichtje branden.
Shocking dat blijkbaar zoiets basics zo slecht geregeld is dat je gewoon twee keer dezelfde batch kunt gaan verwerken.

[iAR]

Niet om voor ING op te komen, maar het duurt natuurlijk wel even voordat de grootschaligheid van een probleem boven tafel komt. Als je een heel callcenter hebt dan duurt het even voordat je door hebt dat er vaak over hetzelfde wordt gebeld. En dan meer van horen-zeggen op de werkvloer dan via het systeem waar de tickets in verwerkt worden.
Dan hangt het af van een manager die het wel of niet adequaat escaleert.

ING heeft dit wel eens vaker gehad. Toen werkte ik er nog. Uiteindelijk, gek genoeg, is het allemaal netjes gecorrigeerd.

[koelpasta]

Als je een heel callcenter hebt dan duurt het even voordat je door hebt dat er vaak over hetzelfde wordt gebeld.

Punt is, geloof ik, dat het systeem er zelf achter zou moeten komen en dat de klanten (en de callcenters) helemaal niet in dit verhaal zouden moeten voorkomen.

[Verwijderd]

mensen bij een klantenservice weten vaak niet waar ze het over hebben. die hebben gewoon een aantal standaard antwoorden en scenario's die ze doorlopen

[Bensimpel]

Niet meteen inderdaad, maar op den duur (bij een goede klantenservice) gaat er na mate van een flink aantal tickets toch wel ergens een lampje branden en wordt er verder onderzoek uitgevoerd. En namate van de impact wordt ook meteen de prioriteit verhoogd.

Die informatie wordt ook weer gedeeld op de klantenservice, En op den duur weten ze wel wat er aan de hand is.

[Verwijderd]

Het gaat hier om een banksysteem, het is niet alsof iemand zomaar op een knopje kan drukken om alles om te draaien, ook al hebben ze een miljoen miljard tickets. Persoonlijk zou ik zelfs per direct bij een bank weggaan als een werknemer zomaar zoiets zou kunnen doen.

Ergens in de keten van aanbieders en verwerkers is het misgegaan en dan zullen ze eerst eens goed moeten kijken naar wat exact het probleem is en hoe ze met de juiste oplossing kunnen komen.

Zomaar transacties omdraaien kunnen ze ook niet omdat ze vast zitten aan een hoop regeltjes.

Wat je zegt is leuk, maar in een zwaarbeveiligd systeem kan dat gewoon niet.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:50]

[Bensimpel]

Ik heb zelf op een technische klantenservice voor een grote Nederlandse bank gewerkt, (op de achtergrond van de bank dus). Voor dit soort zaken worden gewoon grote conference calls opgezet met verschillende teams. Wintel, Ops, servicedesk, Oa ander server teams, zoals Back up, tape etc.

Dan moet er een lijstje afgewerkt worden met mogelijke oplossingen, heb welleens in de conference calls uren aan de telefoon gezeten omdat er bijvoorbeeld door iemand een back up was terugzet in de productie omgeving van Oracle. Doel is om eerst alles natuurlijk zo snel mogelijk weer draaiend te krijgen, (volgens de procedures, lijstje afwerken en eerst testen in test omgeving).

Vervolgens word er een onderzoek gestart naar hoe het heeft kunnen gebeuren en worden verbeteringen ingedient door verschillende teams.

[Gomez12]

Je beschrijft het zelf al, er gaan makkelijk uren/dagen overheen voordat er iets duidelijk is en gecommuniceerd kan worden naar de klantenservice. Oftewel het is maar net wanneer je belt naar de klantenservice.

En veelal gaat er ongeveer 15 minuten nadat de klantenservice ingelicht is (dan moet het daar nog wel intern verspreid worden) een persbericht de deur uit die overal komt te staan etc.
Oftewel grote kans dat klantenservice het pas een uur geleden doorgekregen heeft en dus gisteren totaal van niets wist.

[WhizzKid-Eddy]

Ja, en blijkbaar hebben ze daar 2 dagen voor nodig aangezien er nu pas melding van wordt gemaakt...

[redfox314]

Er ging dus wel een lichtje branden. 3 miljoen transacties. Da's waarschijnlijk een uur voordat dit gedetecteerd werd. Bovendien hebben ze blijkbaar ook de mogelijkheid om die proper terug te draaien.

[Me_Giant]

Het gaat om 1 batch, het aantal heeft dus niets te maken met de tijd die het duurde om erachter te komen. Verder betreft het transacties van maandag waarvan dinsdag te zien was dat ze dubbel zijn uitgevoerd en waar ING vanmorgen pas zelf bericht over gaf. Dat is dus zeker geen reactietijd van 1 uur maar van 1 dag.
Overigens is er nog niks teruggedraaid, klanten wachten hier nog steeds op op dit moment. Ik ben student en in mijn omgeving ken ik mensen die vandaag geen geld kunnen uitgeven omdat ze geen banksaldo hebben door dit probleem.

Het is dus wel degelijk een probleem met veel impact waar zeker niet al te snel op gehandeld wordt. Los van het feit dat zoiets niet hoort te gebeuren.

[Reactie gewijzigd door Me_Giant op 24 juli 2024 22:50]

[WhizzKid-Eddy]

Ik vraag me eigenlijk af hoe ze dit terugdraaien. Via een interne tegenrekening van de bank zelf, of hoe werkt dit

[redfox314]

Heel het overschrijving systeem is een ingewikkelde constructie van boekingen naar interne rekeningen en verzamelrekeningen en wordt er een aantal keer per dag gesynced met andere banken +- inkomende overschrijvingen. Dat is tenminste wat ik begreep van een collega die als vorige baan bij ING BE daarop werkte.

[SuperDre]

Ben benieuwd of ze dan ook rente gaan trekken van die negatieve saldo's, want dat gebeurd gewoon allemaal automatisch. En die rente is zo'n 200% hoger dan dat jij uberhaupt aan spaarrente kunt krijgen, zelfs als je dus nog geen dag in het rood staat, te belachelijk voor woorden, zij gebruiken jouw geld en je krijg er niets voor terug (is niet eens de inflatiecorrectie tegenwoordig) maar zodra je ook maar per ongeluk even in de min staat is het kassa voor hun..

[Ynst2003]

ING komt klanten die rood zijn komen te staan, wel deels tegemoet. Zij betalen daarover geen rente.

bron: https://www.rtlnieuws.nl/...or-gedupeerde-ing-klanten

Ze rekenen geen rente over het negatieve saldo, volgens dit bericht. Echter weet ik niet of dit een echte quote is van ING, maar als het wel zo is.. Wat een arrogantie! Zij maken een fout en dan moeten wij dankbaar/blij zijn dat ze over die fout (die zij gemaakt hebben) geen extra kosten gaan rekenen. Bedankt ING!, wat een coulance

[maxkranendijk]

Ik blijf het apart vinden dat banken nooit compensatie geven bij dit soort fouten. Al is het maar een paar euro of 0.5% als gebaar.

Ze maken miljarden winst, dus een klein gebaar zou al mooi zijn. Op de 1 of andere manier blijven ze maar vasthouden aan hun negative imago.

[Verwijderd]

Aan een gebaar heb je ook geen reet, ik heb liever dat ze dat geld steken in het voorkomen van deze issues.
Ik ben best tolerant wat outages betreft, zeker omdat de ING in mijn ogen best veel doet aan hun user experience kan ik er best wel mee om gaan dat het er wel eens uit ligt, maar dit is ook niet de eerste keer dat ze van dubbele afschrijvingen last hebben en dat vind ik toch wel hele listige materie om mee te ouwehoeren. Dat moet je echt niet te vaak doen want daar gaat je betrouwbaarheid als bank gewoon aan onderdoor en als dat weg is kan je gewoon opdoeken.

Kan je 50 cent op je rekening gestort krijgen maar daar heb je dan gewoon veel meer dan 50 cent gezeik aan.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:50]

[Inktvisje]

ING doet dit juist wèl, ik heb afgelopen maand nog 1,50 van ze teruggekregen omdat de mobiel betalen app een tijdje niet goed gewerkt heeft op mijn oneplus. Ik had het zelf niet eens door dat de app niet gewerkt had want gebruik hem niet zo vaak, maar ING had dat volledig uit eigen initiatief teruggestort op mijn rekening.

[ajolla]

Heb je nu nog steeds niet door dat je de slááf bent, niet de meester?

[maxkranendijk]

Ik ben de meester, omdat ik niet bij ING zit

[ajolla]

Dat dàcht je. Niemand ontsnapt op den duur aan de macht van de bankiers.

[Radiant]

Ik zie de IT-infra van de ING voor me als een aantal enorme mainframes uit de jaren 60; sommige van de ING en anderen zitten nog wat vergeelde Postbank-stickers op. Op de achtergrond draait nog ergens de server voor Girotel maar het modem is inmiddels niet meer aangesloten. In de ochtend loopt er iemand wat heen en weer met stapels ponskaarten om de transacties tussen de verschillende systemen te laten verlopen (tevens de reden waarom geld overmaken bij de ING zo lang duurt), maar oeps! Vandaag heeft hij in zijn onoplettendheid 2x dezelfde stapel ponskaarten ingeladen. Dat wordt tapes terugspoelen..

[Verwijderd]

Interessante visie. Ik zie het helemaal voor me.

Wat echter niet klopt is deze stelling:

...(tevens de reden waarom geld overmaken bij de ING zo lang duurt)...

Geld overboeken binnen de ING is instantaan.

Wat me echter het meest bevreemd is hoe een batch-run met een ID, voorzien van 3 miljoen opdrachten, met elk hun eigen unieke ID, dubbel uitgevoerd kan worden, en dat er dus bij boekingen ook geen validatie plaatsvindt of een transactie met een ID niet al heeft plaatsgevonden.
Het lijkt er nu op dat dit pas ontdekt werd toen iemand die hierdoor geraakt werd het gemeld heeft.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:50]

[T-men]

Hierboven wordt (volgens mij niet onterecht) aangenomen dat er bij de ING nog de nodige mainframes (met Cobol programmatuur ?) draaien.

Ik werk zelf bij een ander bedrijf als Cobol programmeur, maar ik kan me iets van de situatie voorstellen.

Ook bij ons bedrijf loopt de batch-run wel eens stuk op een foutje in een bestand of een programma.

De beheerder mag dan zien dat dat foutje gefixed wordt. Nadat dat gebeurd is, dan is het niet ongebruikelijk dat een deel van de batch overgedraaid moet worden.

Dat overdraaien is mensenwerk. Oude uitvoerbestanden moeten geveegd worden, parameters (waaronder de generatiecontroles voor de bestanden) moeten terug gezet worden, databases gerestored.
Dat is een nauwgezet proces maar het blijft mensenwerk.

Waar mensen werken worden fouten gemaakt en een computer heeft er geen enkele moeite mee om zo'n foutje 3 miljoen keer te reproduceren.

Wat de ING overkomen is, dat is niet meer dan een klein rot-foutje, helaas met grote gevolgen qua exposure.

Maar wees eens eerlijk: volgens mij weet elke Tweaker hier wel hoe snel een foutje in de ICT uit kan groeien tot een probleem.

Heb wat respect voor de mensen die dit werk doen hen bedenk eens hoe vaak het wél goed gaat !

[ToolkiT]

En waarschijnlijk zit er in die batch geen check of een transactieID al bestaat, want dat duurt te lang?

[T-men]

Bij ons zit op de meeste programma's een generatiecontrole van het bestand. (Denk in batch, niet in transacties)
Zo'n bestand heeft eerst een voorlooprecord met daarin de naam van het bestand en een (oplopend) generatienummer.
Daarna volgen de werkelijke data-records en eventueel een sluitrecord om er zeker van te zijn dat álle datarecords verwerkt zijn.

In een tabel wordt bijgehouden welk generatienummer van welk bestand aan de beurt is.

Wijkt het nummer in het voorlooprecord af van het verwachtte nummer in de tabel, dan stopt het proces en mag de beheerder kijken wat er aan de hand is.

Op die manier voorkom je dat batch-bestanden dubbel verwerkt worden.

Het is een algemeen in gebruik zijnd systeem. Ik kan me niet voorstellen dat dat bij de ING anders is.

Maar stel je nu voor dat een proces stuk loopt. Dan moet er een probleem gefixed worden en een deel van de run (meerdere programma's en dus ook meerdere bestanden) moet over.

Dan moet de beheerder dus al die generatieparameters terug zetten zodat de bestanden opnieuw gedraaid kunnen worden. Ook moet de uitvoer van de eerdere, stukgelopen run, geveegd worden. En daar is het, vermoed ik, mis gegaan; Da's niet (goed) gebeurd.

Oude data is blijven bestaan en de nieuwe data is gewoon bijgeschreven.

Nogmaals... het is mensenwerk. En mensen maken fouten.

[beerendlauwers]

Maar stel je nu voor dat een proces stuk loopt. Dan moet er een probleem gefixed worden en een deel van de run (meerdere programma's en dus ook meerdere bestanden) moet over.

Is dit niet al lang geleden opgelost met (SQL) transactions?

[Reactie gewijzigd door beerendlauwers op 24 juli 2024 22:50]

[BiLLY_daKid]

Dit klinkt heel plausibel. Natuurlijk zit er controle op dubbele verwerking van batches (niet op transactieniveau, dat zit meer in de online verwerking). Soms zit er een foutje in een batchbestand wat zorgt voor een abend. Normaliter fix je dat en daarna opnieuw submitten. Blijkbaar is de hele batch toen opnieuw ingestuurd ter verwerking.

Gelukkig is er vanwege SEPA (PSD) voor banken een mogelijkheid om overboekingen te recallen: https://www.betaalverenig...ocedure-sct-recall-batch/

@coolkil natuurlijk draait er zelf geschreven software. Ieder bedrijf met enige historie heeft zelf moeten ontwikkelen. Overigens moet je bij 'zelfbouw' niet denken aan één enkele techneut, bij dit soort Cobol programmatuur zijn tientallen afdelingen en developpers betrokken.

[ToolkiT]

klinkt als een bekende procedure... PeopleSoft batches hebben soms ook vergelijkbare issues..
Pain in the @$$ om dat te fixen...
Row level checks zouden veel beter zijn.. maar gezien de volumes is dat qua timing niet haalbaar...
Kleinere batches minimaliseerd het probleem maar geeft meer overhead.. dus altijd schipperen tussen de lesser evil,.

[mphilipp]

Geld overboeken binnen de ING is instantaan.

Niet helemaal. Het lijkt instantaan, maar dat betreft alleen een reservering. Uiteindelijk komt er een definieve run die alle controles doet en het zou zomaar kunnen dat tijdens die run ontdekt wordt dat het toch niet goed zit en dan wordt ie terug gedraaid.

Een poos geleden is daar nog gedoe om geweest omdat je het niet zo snel ziet in Mijn ING. Een aantal oplichters heeft daar handig gebruik van gemaakt door spullen te 'betalen' met gestolen accounts e.d. Als je dat in het weekend doet, heb je kans dat ze pas maandag erachter komen dat het niet klopt. Er zijn gevallen op TV geweest (Kassa geloof ik) waarbij ING dat zei. Het werd altijd al aangegeven, maar niet heel duidelijk. Onder druk van consumentenorganisaties is dat toen verduidelijkt.
Dus als je je auto verkoopt en iemand maakt geld over en je ziet het in je app, is dat nog steeds niet definitief...

[Fab1Man]

Ik heb het idee dat het hele bankwezen in de IT qua systeeminrichting en processen gewoon een "kopie" is van het ouderwetse handmatige proces. Ik zal het niet exact weten, maar vroeger ging je bij de bank langs om geld op te nemen. Dit werd in een soort boekje bijgehouden (referentie) en 's avonds na 23:00 uur verwerkt.
Je hebt dus altijd bron- en referentiesystemen. Een aantal jaren geleden was dit ook al gebeurd. Het referentiesysteem had alle boekingen dubbel uitgevoerd. Had je die dag ervoor je huur betaald, had je opeens dubbel huur betaald. Kreeg je die dag je salaris, had je opeens dubbel salaris.
Ik snap wel waarom een referentiesysteem bestaat, het gaat alleen nogal vaak mis lijkt het.

[abort_]

Dat is ook zo bij de meeste banken die er al een tijdje zijn. De software is vaak 1 op 1 een automatisatie van het oude handmatige proces. Het aanpassingen maken aan het fundament is vrij complex omdat het honderden systemen zijn die samenwerken (cascade effecten etc) en idealiter de services 24/7 in de lucht moeten blijven. Daarnaast zorgen fusies en acquisities ook voor complexiteit (je haalt de architectuur/complexiteit van een ander bedrijf in huis). Zaken als Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law) spelen daarbij echt rol.

[Verwijderd]

Dan doen ze het bijvoorbeeld met hun app best goed...

[Franckey]

Dan doen ze het bijvoorbeeld met hun app best goed...

Gisteren nog het bericht dat ze stoppen met de app voor Windows 10 mobile. Dat noem ik niet goed.

[Verwijderd]

Tjah, ze hebben ook geen PalmOS app...
Windows 10 mobile wordt ook door Microsoft zelf verlaten dus ik snap ook niet echt wat je realistische verwachting is op dat vlak. Op den duur kost het gewoon meer dan het oplevert zo'n app op een bepaald platform in de lucht te houden.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:50]

[coolkil]

Toch nog even inlezen voor je dingen roept. ING wil al jaren van zijn mainframes af. Deze zouden namelijk niet passen in een agile werkomgeving... https://www.theregister.c...1/ing_mainframe_strategy/

Toch zou het mij niet verbazen als ze het mainframe in de laatste 2 jaar nog een keer vervangen hebben. Ofwel een mainframe uit 1960 is er niet bij vermoedelijk.. Dat er nog zelfgeschreven software op staat uit 1980 is overigens wel een mogelijkheid. Draait echter nog steeds maar kan inderdaad wel dit soort storingen tot gevolg hebben. Fun fact je kan tegenwoordig ook gewoon Linux op je mainframe draaien met generieke software als nodejs, kvm en veel meer. Of ze dat ook doen bij ING is me niet bekend.

[Reactie gewijzigd door coolkil op 24 juli 2024 22:50]

[iAR]

Zo overdreven is het niet maar je komt wel in de buurt... weet ik uit ervaring

[MrFax]

De app is iig best modern.

[mae-t.net]

Was het maar zo'n feest. In werkelijkheid gaan er op onze kosten (!) regelmatig hele datacenters vol met gloednieuwe bladeservers doorheen. Die dan voordat ze technisch afgeschreven zijn ook vernietigd worden, want wipen en voor goed geld verkopen is te lastig ofzo.

[paralyz3]

Toch apart hoe zo'n fout er tussendoor kan slippen in zo'n groot systeem. Ben benieuwd waar dit precies is fout gegaan.

[Apache]

Laten we zeggen dat ik praktijk ervaring heb met IT bij banken. En dat het woordje "idempotency" bij sommige IT'ers deze reactie uitlokt:
Dus hier schrik ik niet van.
Uit hun uitleg begrijp ik dat dezelfde batch twee keer is uitgevoerd. De vraag is, wat gebeurd er als een batch half verwerkt is en dan herstart wordt, welke gevolgen heeft dat. Waarom is er geen traceability tussen de transactie en de boeking ... Hier kan waarschijnlijk heel veel uit geleerd worden, en mee gedaan worden, als ze de juiste mensen hebben.

Een tijdje terug heb ik zelfs een korte talk gegeven met over dit als concreet voorbeeld: https://docs.google.com/p...e&loop=false&delayms=5000

[Reactie gewijzigd door Apache op 24 juli 2024 22:50]

[KopjeThee]

Ik hoop inderdaad dat ze hiervan leren en geschikte maatregelen nemen.

Ik zou bijna zeggen "You had one job...". Iemand maakt bedrag x over van rekening a naar b. Your job: Denk na wat er moet gebeuren, ook als iemand op een slecht moment een netwerkkabel doorknipt of een computer stuk maakt. En andere vervelende situaties.

Maar ja, misschien/hopelijk is er echt iets heel heel uitzonderlijks aan de hand geweest.

[SCiENTiST]

Ik denk dat je onderschat hoe complex systemen kunnen zijn bij een grote bank die de nodige fusies heeft ondergaan.

[beerendlauwers]

Zoals Apache had gezegd, zijn er reeds wiskundige concepten waarop gebouwd kan worden om dergelijke complexe systemen op een robuste manier te benaderen. Maar vaak wordt het systeem op een naïve (in de context van de computerwetenschap) manier geïmplementeerd, met hopen side-effects als gevolg.

[KopjeThee]

Je kunt systemen in theorie perfectie laten benaderen. De keerzijde is dat de kosten hard oplopen. Mijn beeld van banken is, sinds de crisis, niet al te rooskleurig. Waarom zou ik een systeem 99,99% betrouwbaar maken voor een vermogen? Met 98% kom ik toch ook weg? Ik roep af en toe sorry, en klanten vinden het toch te veel gedoe om over te stappen. Als ik er een keer echt een zootje van maak, dan springt de overheid wel bij.

[KopjeThee]

Ik kan me voorstellen dat er veel en complexe systemen zijn bij een bank. En hoe meer er in de loop der tijd aan verbouwd is, hoe ondoorzichtiger het misschien wordt.

Maar het uitvoeren van dit soort transacties raakt wel aan de absolute kern van wat een bank goed moet kunnen. Als consument wil ik er volledig op kunnen vertrouwen dat als ik bedrag x overmaak van rekening a naar rekening b dat het dan ook echt zo gebeurt, en niet anders. En uiteindelijk is dat hier ook wel het geval, hopelijk, na deze correctie.

Dit soort incidenten in de kern van de taak, levert echter wel een deukje op in mijn vertrouwen. Heeft de bank de primaire systemen nog wel goed onder controle?

[Apache]

Een van de problemen is dat er weinig autonomie ligt bij IT in europa. Je hebt business die vraagt, management die ja knikt, en IT moet het uitvoeren.

Een compleet foute hierarchische aanpak. IT zelf is ook stakeholder. Liefst van al heb je een IT afdeling die gewoon perfect je business requirements implement, en daar dan perfecte monitoring op heeft, test coverage, etc. Dat is een utopie in 99,9% van de gevallen.

Je IT moet mee een stakeholder zijn en kunnen beslissen om zaken te refactoren, aan te pakken, of zelfs te herschrijven, allemaal in overleg met de business. In plaats van legacy systemen over te nemen, integreren, en dan het te beschouwen als "af" en het daar maar rustig laten staan (tot het mis gaat). Zelfs in banken hebben ze de term "technical debt" niet door. Dit was voor ING een interest aflossing op hun technical debt.

Een leuke quote daar is: "It's always temporary, until it works". Laten we hopen dat hier met de wetgevingswijzingen die binnenkort in voegen gaan er wat fintech bedrijven opstaan die deze oude industrie en concepten snel van de kaart vegen, open financials kan heel wat impact en modernisatie teweeg brengen bij hoe we momenteel zaken doen. Een (realtime) bank api waarmee je kan integreren vanuit bvb een boekhoud pakket is momenteel een echte zeldzaamheid tenzij je echt al een grote firma bent.

[KopjeThee]

Mee eens. Ik zou niet graag IT directeur zijn bij ING. In principe zou "de business" moeten gaan over "wat", en IT over "hoe". In dat opzicht is het ontstaan van technische schuld (en de consequenties) altijd aan eerdere oplossingen van IT te wijten. Het zou beleid moeten zijn deze schuld niet op te bouwen voor je primaire systemen. Hier hangt natuurlijk wel een prijskaartje aan. Maar als IT directeur zal je die eis verkocht moeten krijgen, anders kan je eigenlijk geen verantwoordelijkheid nemen voor de systemen.

[Dets]

Daarom, als ik op mijn rekening kijk zie ik twee keer exact dezelfde gegevens: bedrag, datum/tijdstip, transactie en term. Je zou toch veronderstellen dat je een systeem zo bouwt dat een transactie niet twee keer wordt uitgevoerd of in ieder geval de tweede keer geen effect heeft.

Maar het zal wel een gevalletje zijn zoals ik wel vaker hoor bij testcases: "Dat komt in de praktijk niet voor."

[wica]

Maar elke transactie heeft toch een Transactie ID.
Als je een batch draait, controleer je toch of een bepaalde Transactie ID al bestaat, voor dat je een update uitvoert?

Dit had ik 18 jaar geleden al in mijn systeem, juist om te voorkomen dat bij het draaien van een import iets per ongelijk dubbel gebeurde. En dubbele werden in een log opgeslagen om door een persoon te laten controleren.

Maar ja, ik werkte toen voor een adult bedrijf en niet voor een bank.

[Carlos93]

Maar de vraag blijft natuurlijk, waarom is de tweede identieke overschrijving niet automatisch gestopt.

Hier bij HSBC krijg ik gelijk een melding bij de 2e overboeking of ik het wil verifiëren.

[Blaise]

Als je een overboeking doet wordt het niet gelijk overgeboekt, je doet een opdracht en die wordt later verwerkt met andere opdrachten van anderen klanten in grote batches. Als de ontvanger bij een andere bank zit zal de ontvanger pas dan de overboeking zien op haar rekening.

Een bank kan checken of je een identieke opdracht hebt gedaan en vervolgens een melding tonen dat deze dubbel is. Een bank kan ook opdrachten binnen de bank alvast virtueel toepassen op de rekeningen van de ontvanger en verzender als deze beiden bij dezelfde bank zitten. Maar later tijdens de échte verwerking kunnen er alsnog dingen misgaan, zoals blijkbaar een dubbele afboeking.

[Verwijderd]

Het lijkt me juist dat zo'n fout makkelijker gebeurt bij een groot systeem. Even de hele ING afzeik discussie daargelaten, het is bij een groot systeem gewoon makkelijker om fouten te krijgen dan bij een systeem waar 2 mensen mee pinnen.

[paralyz3]

Klopt, zeker waar. Maar de test procedures zijn bij zulke systemen vaak zo geautomatiseerd dat zulk soort impactvolle fouten hier wel uitgevist worden. Maar het is natuurlijk onmogelijk om alle edge cases te voorzien en voorkomen.

[Iblies]

Dat weten we simpelweg niet.

Er wordt melding gemaakt van 3mln boekingen, en dat dat een batch is, maar wordt verder niet gesproken over een tijdsframe.

Het lijkt me heel onlogisch dat een hele dag opnieuw is geboekt. Maar voor een dagdeel lijkt het me weer te kort.


Overigens ben ik wel van mening dat de politiek hier van op de hoogte moet worden gesteld. Is het een menselijke fout, software, of is er inbreuk gepleegd.

[Reactie gewijzigd door Iblies op 24 juli 2024 22:50]

[CyBeR]

"De politiek" hoeft niet van elke scheet bij een bedrijf op de hoogte te worden gesteld. Laat ze alsjeblieft gewoon ons land in goede banen leiden ipv zich bezig te houden met dit soort onzin, dat kost ze blijkbaar al genoeg moeite.

[koelpasta]

Grote fouten bij banken als ING kunnen absoluut grote impact hebben op ons land. Depolitiek mag zich wat mij betreft best wel bemoeien met zulke belangrijke infrastructuren.

[Iblies]

@CyBeR
Op dit moment is er zoiets niet op dergelijke schaal gebeurt. Ligt de fout überhaupt wel ING, is diegene die de pin verwerkingen doet.

De impact is niet goed te schalen.

Stel je voor dat het de volgende keer om twee of drie dagen gaat, vb tijdens Pasen waar niet alleen sprake is van gruwelijk grote omzetten,
maar waarbij banken ook even drie dagen stil staan.

Politiek moet het zeker volgen, daar waar nodig participeren.

[PetervdM]

je mag er vanuit gaan dat elke batch een uniek serienummer heeft, en dat het verwerkingsprogramma controleert of die batch al is geweest. zo ja, message naar de operator en verwerking parkeren.
zo ingewikkeld is dat niet. deden wij vroeger al zo met onze tapes .....

[SCiENTiST]

Het kan natuurlijk zo zijn dat er meerdere systemen zijn waar de batch op staat, waarvan maar 1 actief is en de anderen backup. Als dan om 1 of andere reden de backup ook actief wordt, dan kan de batch misschien 2x verwerkt worden.

[Sharkoon]

En als daar nou een bug is zit dan heb je dus dit soort issues..

[poehee]

Ik ben zo'n back-end man, maar als niet iemand de vraag gesteld heeft: "En wat als die file twee keer wordt ingelezen?" dan is dat ook een mate van incompetentie (en met alle offshoring en uitbesteding neemt het aantal kritische vragen en testgevallen niet toe kan ik zeggen).

[jerrycan92]

Waarschijnlijk was de batch eerder halverwege stuk gegaan na verwerken 3M transacties. Daarna een herstart zonder eerst te controleren dat inderdaad het eerste deel niet verwerkt was (of gehoopt dat verder gegaan zou worden waar eerder gestopt was).
Met realtime verwerking kun je zo’n fout moeilijk tegenhouden.
Lijkt op een keten incompetente mensen die bepalen wat gedaan moet worden in geval van problemen.

[themac1983]

Toch jammer dat je het hier moet zien en niet even een berichtje krijgt ofzo. (in de app overigens nu wel een bericht). Maar inderdaad, 2x betaald bij de appie, kijken of ze me nou gratis de winkel uit laten lopen straks

[Blokker_1999]

Deze tweet zal op het zelfde moment geplaatst zijn als dat de berichten naar de klanten verzonden zijn. Niets mis mee.

En neen, de betaling zal gewoon teruggedraaid worden, met andere woorden zal het zijn alsof deze nooit is uitgevoerd.

[themac1983]

Ik bedoel een meer actieve manier van benaderen van je klanten dat je een foutje hebt gemaakt. Ik krijg wel de ING spam in mijn mailbox, maar hiervoor moet ik in de app (waar ik toch echt niet dagelijks inzit) toevallig zelf zien dat er een berichtje staat voor me.

[e.dewaal]

Het is juist slim dat ze het op deze manier doen. Nu zien alleen mensen de berichtgeving die hun saldo checken. Zouden ze dit groot aan de bel gaan hangen krijgen ze extra telefoontjes waardoor medewerkers hun tijd daar aan kwijt zijn. Door het wat meer verborgen te houden is de kans dat klanten het merken ook kleiner als ze het spoedig oplossen.

[Dets]

De grootste fout is het niet melden. Transparantie is hier wel op zijn plaats. Dingen "onder de pet houden" is de grootste fout die je kunt maken als klanten het zelf kunnen waarnemen.

[gjmi]

Nou, als je net een dure uitgave gepunt hebt, die 2 keer word afgeboek, en daarna bijvoorbeeld andere automatische afboekingen niet meer goed gaan. Of als de de volgende dag in de winkel staat en je kunt niet pinnen vanwege ontoereikend saldo. Dat had je dan liever van te voren geweten.

[B64]

Het valt me sowieso op dat banken vooral heel goed zijn in berichten op Twitter, blijkbaar in de hoop dat die berichten dan worden opgepakt door de media. Of gaan ze er vanuit dat al hun klanten de hele dag op Twitter zitten te koekeloeren?

[bbob]

Helaas werkt het zo. Klantdienst bellen met een klacht, vaak niet serieus. dump je het op twitter of facebook worden ze ineens wakker.Triest eigenlijk hoe service steeds slechter wordt.

[Mektheb]

En toch belde ik vandaag om 08:10 en de dame wist gelijk waar het over ging en vertelde me dat het probleem bij de ING zat.

Duurde wel 20 min voor ik iemand aan de lijn had maar toch.

[renevanh]

Nee, want het is per abuis twee keer afgeschreven, maar niet bijgeschreven aan de andere kant.

[Gwaihir]

Vermoed je dat of weet je dat?

Als het echt eenzijdig is, kan ik me moeilijk voorstellen dat het onduidelijk is hoe lang herstel gaat duren.

[Reactie gewijzigd door Gwaihir op 24 juli 2024 22:50]

[ajolla]

Dat is waarschijnlijk onduidelijk omdat 't over 3 mio txns gaat en ze zoiets nog nooit aan de hand hebben gehad.

[Gwaihir]

Nee, de grootte van de batch maakt (als het eenzijdig is) niet echt veel uit. Ze gaan ze echt niet handmatig corrigeren.

[renevanh]

Het staat letterlijk in het gelinkte NOS artikel.

[Gwaihir]

Je bedoelt: "Het gaat alleen om afboekingen, niet om bijschrijvingen."? Hmm.. dat het dus eenzijdig is, maak ik daar eerlijk gezegd niet helemaal uit op. Uiteraard gaat het bij een batch pinbetalingen (voor de gedupeerden) alleen om afboekingen.. maar inderdaad zou dat normaal gesproken ook tot onjuiste bijschrijvingen elders leiden en dat lijkt wel ontkend te worden. Hmm.. blijft wat vaag.

[FreshMaker]

Toch jammer dat je het hier moet zien en niet even een berichtje krijgt ofzo. (in de app overigens nu wel een bericht). Maar inderdaad, 2x betaald bij de appie, kijken of ze me nou gratis de winkel uit laten lopen straks

Natuurlijk laten ze je gratis de winkel uitstappen

Alleen moet je wel de producten laten liggen

[Bart ®]

Toch lullig als je net een nieuwe auto gekocht heb van zeg 25.000 euro, en met pin hebt betaald .

[Edoras]

Wat er niet is kan je ook niet afboeken hè, dus alleen lullig voor de mensen die standaard 50k op hun betaalrekening laten staan 😉

[WebHawk]

Normaal wordt er voor een transactie gekeken of de rekening nog genoeg saldo heeft. Als dat zo is dan wordt de transactie goedgekeud en uitgevoerd. Dat goedkeuren is vermoedelijk de eerste keer al gebeurd, en niet opnieuw gecheckt bij de tweede verwerking van de transactie.

[lucatoni]

Nee, het zit iets anders. Goedkeuring vind plaats op het moment dat je met je pin pas de transactie uitvoert. Bij te weinig saldo vindt afkeuring plaats. Vervolgens wordt het bedrag gereserveerd. Pas in de nacht wordt deze verwerkt. Verwerking heeft dubbel plaatsgevonden. Tijdens de batch verwerking van transacties wordt geen saldocheck meer uitgevoerd.
In bepaalde situaties is het dus mogelijk om rood te staan, terwijl je dit niet mag, met name met audomatische incasso's.

[Reactie gewijzigd door lucatoni op 24 juli 2024 22:50]

[Sinus_rhythm]

Er zijn berichten dat rekeningen die niet rood kunnen staan door deze fout en dubbele boeking wel rood staan.

[ajolla]

Hoe is dàt in godsnaam nou weer mogelijk? Ze 'kunnen' niet rood staan, maar kunnen het tòch. Wat een puinhoop!

[Reactie gewijzigd door ajolla op 24 juli 2024 22:50]

[Gwaihir]

Lijkt mij vrij logisch. Of je mag betalen (qua rood staan) wordt bekeken op het moment dat je pint, niet later pas als de transactie verwerkt (of tenminste gereserveerd) wordt (en jij met je aankoop de winkel al uit bent). Zit normaal gesproken zo weinig tijd tussen dat het er extreem zelden toe doet. Maar ja.. nu wordt die ene goedkeuring per ongeluk voor meerdere afboekingen gebruikt..

[Reactie gewijzigd door Gwaihir op 24 juli 2024 22:50]

[mae-t.net]

Bij veel banken kan een rekening die niet rood mag (let wel: mag, niet kan) staan, wel degelijk onder nul zakken. Bijvoorbeeld door het afboeken van de maandelijkse bankkosten, door een creditcardafboeking of na een incasso.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 22:50]

[ajolla]

Ik heb regelmatig (2x of zo) gehad dat een incasso dan geweigerd werd.

[0kk0]

sommige mensen staan hierdoor rood die normaal niet rood kunnen staan

[Nat-Water]

Volgens 't ING forum stonden er nu genoeg mensen rood door deze fout, dus dat klopt niet helemaal.

[Bas_f]

Dit gaat denk ik nog een staartje krijgen, want die mensen die nu een dagje rood staan, gaan waarschijnlijk debetrente afgeschreven zien worden aan het eind van de maand. Ben benieuwd hoe en/of ze dat opgelost gaat worden.

[renevanh]

Van die rente is al gezegd door de ING dat die niet in rekening wordt gebracht. Staat gewoon in hun persbericht en/of het meest recente artikel hierover op NOS.

[Nijl]

.. en daarna niet meer kunnen pinnen bij de Action..

[lighting_]

Ik kan niet geloven dat er geen controle zit op dubbele batchnummer.

[HollowGamer]

Precies, dat is toch het eerste wat je checkt? Wat als de batch halverwege stopt, de batch opnieuw moet worden uitgevoerd of zoals nu deze eerst moet worden teruggedraaid?

Ik neem toch aan dat elke transactie een uniek kenmerk heeft en gaat 'piepen' als die transactie al een keer is gedaan?

[lighting_]

Er is niet altijd een stringente business rule. De redenen heb je zelf gegeven. Je wordt er niet flexibeler op. Maar een melding dat dezelfde batch nummer is gelezen moet toch geen probleem zijn.

[HollowGamer]

Lijkt me toch voor de hand liggend dat ze werken met transacties? Gaat het fout dan kun je deze transactie terugdraaien. Daarom doe je het toch in batch-vorm?

Het klinkt inderdaad zo simpel gedacht, maar ik begrijp niet dat het bij een bank als de ING zo moeilijk kan zijn.