Belgische bank Argenta schakelt internetbankieren uit om problemen op te lossen

De Belgische bank Argenta denkt vandaag de problemen met internetbankieren en de app op te kunnen lossen. Momenteel toont de website enkel een pagina met een excuus en is er verder geen functionaliteit. De problemen ontstonden in het Paasweekend.

Bezoekers van argenta.be worden op dit moment automatisch doorgestuurd naar een ander domein, sorryarg.be, waar de bank een pagina met excuses en uitleg heeft geplaatst. De bank zegt de afgelopen nacht gewerkt te hebben om de problemen op te lossen, maar wil geen risico lopen en heeft daarom sinds woensdagochtend 8.30 uur internetbankieren uitgeschakeld. Dat doet de bank naar eigen zeggen 'om voorrang te geven aan transacties in kantoren en betalingsverkeer'.

Argenta zegt dat internetbankieren in de loop van de dag weer wordt opgestart, maar noemt geen tijd. Als laatste wordt weer de functionaliteit voor mobiel betalen via de app aangezet. De bank erkent de impact van de problemen onderschat te hebben. In een faq heeft de bank de gang van zaken opgeschreven.

De problemen bij internetbankieren ontstonden na gepland onderhoud. Van donderdag 20.00 uur tot zondag 20.00 uur was inloggen niet mogelijk door deze geplande werkzaamheden, maar daarna traden er problemen op bij het inwerking nemen van de nieuwe systemen. Volgens Spaargids.be zei de bank dat dat kwam door een grote hoeveelheid inlogpogingen. Na het weekend zou internetbankieren weer deels gewerkt hebben, maar dinsdag waren er problemen voor klanten en kantoren van de bank.

Een probleem dat zorgde voor een vertraging bij de verwerking van de saldi op de rekeningen van klanten is volgens Argenta inmiddels verholpen, net als een probleem met de vermelding van de naam bij gemeenschappelijke rekeningen. Verder benadrukt de bank dat klanten nog geld kunnen afhalen bij pinautomaten en in winkels met hun pinpas kunnen betalen. Dringende overschrijvingen kunnen via een kantoor geregeld worden.

Reacties (106)

[Admiral Freebee]

Voor alle duidelijkheid gaat het niet om eenvoudig onderhoud maar om de vervanging van de kern van het backend systeem. Vandaar dat internetbankieren, de website en de app al onbeschikbaar waren vanaf 20u vorige donderdag. Het plan was dat alles op 1 april om 20u weer beschikbaar zou zijn maar vele zaken werkten toen nog niet goed.

Ik was donderdag nog bij een kantoor van Argenta en de kantoorhouder noemde het een "open hart operatie".

[peverix]

Ze hebben dit weekend inderdaad een update naar de laatste versie van het sopra banking platform gemaakt.
Is een mooie vergelijking van de kantoorhouder.

Met deze stap zijn ze klaar om te voldoen aan de nieuwe eisen van europa in verband met betalingsverkeer.

[Apache]

Tof, alleen gaat die vergelijking compleet niet op en is dat een oversimplificatie van wat je in onze sector kan bereiken.

Het hoeft allemaal niet big bang, je kan perfect een 2e hart installeren, en pas als dat klopt het vorige hart eruit snijden en wegwerpen.

Dat er gekozen is voor een big bang die nu voor een grote knal gezorgd heeft moet men zelfs niet proberen recht praten.
Technieken als bvb een strangler pattern laten perfect toe om dit uit te voeren met een sterk gereduceerd risico doen dan waar nu voor gekozen is.

[Blokker_1999]

Wanneer je een migratie doet die one way is en daarna komt er ook maar 1 transactie door kan je niet zomaar terug naar de oude database.

Als jij je eerste hart uiteindelijk wegsnijdt en daarna blijkt dat tweede hart de kracht van alleen te werken niet aan te kunnen zal je alsnog een groot probleem hebben, ook al leek alles eerst goed te gaan.

[Apache]

Opnieuw, te simplisitisch. Niets houd tegen om stelling in plaats te brengen die je transacties naar het oude en het nieuwe systeem doorstuurt. Je data migraties kunnen incrementeel gebeuren, en checks om te zien welke data al gemigreerd zijn kunnen vrij triviaal gechecked worden, alles heeft een id veld.
Migraties kunnen afgestemd worden op basis van een cutoff date, die zelfs niet system wide hoeft te zijn maar per user.

Denk jij dat bvb gmail geen datamigraties heeft gedaan in het verleden? Tuurlijk wel, maar daar hoef je niets van te merken. Meerdere versies in de lucht houden, zero downtime deployments, het is allemaal geen black magic meer. Een datamigratie is perfect mogelijk in een draaiend operationeel systeem.

Tuurlijk, je moet er iets meer intellectuele arbeid tegenaan smijten, "stelling" in place brengen, maar strategisch breng je naar en positie waarin je niet vast zit, waarbij er opties zijn. Uiteraard komt daar data duplicatie bij kijken, en misschien zelfs heeldere applicaties die erna weggesmeten worden.

Je zou zelfs kunnen beslissen een subset van je users, eventueel eigen personeel al te migreren naar het systeem en vanaf dat wat gesettled is elke week 10% meer klanten over te zetten. Kan je zelfs een betere inschatting van de resources krijgen.

Meestal komt het hier op neer:
https://robinplacefabrics...ads/2018/01/image-300.png

[ppl]

Je stelt het inderdaad allemaal veel te simplistisch voor. We hebben het hier niet over een intern CRM pakketje wat je gaat vervangen en waar vrijwel geen wet- en regelgeving bij komt kijken! Banksystemen zijn vaak grote en complexe systemen omdat ze met allerlei andere componenten in verbinding moeten staan. In plaats van hooguit 10 aansluitingen verleggen zoals bij het overzetten naar een hartlong-machine gaat het al snel om een tienvoud daarvan. Uiteraard zal een bank hier geen publieke mededelingen over doen.

Je vergelijking met gmail gaat dan ook totaal niet op, temeer omdat dit een op zichzelf staand systeem is (lees: het is niet afhankelijk van allerlei andere systemen om zijn werking te kunnen doen danwel zijn andere systemen afhankelijk van gmail om hun werking te kunnen doen). Sterker nog, je gmail vergelijking is een heel mooi voorbeeld dat je het allemaal veel te simplistisch voorstelt en je vooral bedient van aannames.

Daarnaast is het ook onjuist om te denken dat alle migraties met zero downtime kunnen op technisch vlak. Je hebt hier te maken met verschillende soorten data die ieder weer een verschillend wijzigingspatroon heeft. Het een veranderd veel vaker dan het ander. NAW-gegevens zullen amper veranderen en kun je eenvoudig overzetten en syncen. Betalingsverkeer daarentegen niet. Daar zitten niet alleen veel wijzigingen bij maar ook wijzigingen die onderhevig zijn aan wet- en regelgeving. Daar zullen ongetwijfeld het nodige aan checks zitten. Juist dat soort zaken maakt een datamigratie nog complexer dan het is.

Je reacties lijken meer aaneengeregen aannames te zijn. Een voorbeeld daarvan is het roepen dat alles een id veld heeft. Ik heb nu diverse soorten systemen gezien en ik kan je uit ervaring vertellen dat dit een aanname is met hele grote gevolgen. De aanname die je hier doet is de hoofdreden waarom migraties stuk gaan. In de praktijk blijkt namelijk vaak dat wat jij dacht dat er zou zijn, er in het echt niet is.

Buiten dat ontbreekt hier ook een ander stukje besef: namelijk die van de natuurwetten. Je hebt beperkingen in hoeveelheid data die je over een lijntje naar elders kunt versturen. En daarmee heb je beperkingen op gebied van tijd.

Niet alleen het bouwen van de nieuwe software duurt jaren, de voorbereiding op de implementatie van die software duurt ook jaren. In die tijd worden er allerlei zaken in kaart gebracht zodat men weet welke beperkingen er zijn en wat ze o.a. aan datamigratie kunnen verwachten. Onderdeel daarvan is ook een risicoanalyse en een kosten-batenanalyse. Die twee bij elkaar opgeteld kunnen een directie doen besluiten dat het uiteindelijk goedkoper en makkelijker is om de boel gewoon dicht te gooien ipv open te houden. En nee, dit is niet een gevalletje van hardware (een term die van toepassing was in 1998 maar anno 2018 hebben we het over servers en services aangezien die net zo hard virtueel als bare metal kunnen zijn) maar een gevalletje van mankracht en de kosten die komen kijken wanneer dingen misgaan (en dan moet je ook denken aan zaken als boetes). Dan kun je idiote zaken krijgen als een systeem die 3 miljoen euro per dag kost als het offline is rustig een hele week offline mag zijn. Waarom? Omdat zo'n systeem niet zo mission-critical is als de overige systemen. Daar lijkt het in dit geval ook om te gaan aangezien ze iets uitschakelen om andere systemen voorrang te geven.

De stelligheid waarmee jij hier nu zegt dat ze het verkeerd doen is dan ook zeer misplaatst, respectloos en dom. Helaas vergeet je in het verhaal nog wel het meest belangrijke: al zou er een zilveren migratie methode zijn (ieder systeem vereist zo'n beetje zijn eigen aanpak) dan nog loop je kans dat de boel in de soep loopt. Hope for the best, plan for the worst is dan ook het devies. Laat dat nou net het hele punt in dit nieuwsartikel zijn: shit hit the fan en nu moeten ze het oplossen. Hierbij moet je er ook rekening mee houden dat de informatie van de kantoorhouder wellicht niet (helemaal) juist is (niet iedereen weet van de hoed en de rand). Het is in deze ook nog maar de vraag of de problemen met schaduw draaien te voorkomen zijn. Het officiële bericht meldt vertraging bij interne gegevensuitwisselingen. Dat kan van alles zijn, dus ook een networking issue die je nooit met schaduw draaien oplost.

Oftewel: je moet je reactie niet baseren op compleet drijfzand, hou het bij de gemelde feiten.

[Apache]

Mijn simplistisch slaat net op het feit dat er complexiteit is die getackled moet worden. Maar dat "gewoon" de data transformeren van oude naar nieuwe systeem de meest simplistische vorm is die je kan doen, die het meeste risico met zich meebrengt, want het is alles of niets, en je zit in een no way back constructie. Geen fallback, niets gradueel. Potentieel moet je systemen ontwerpen om dit mogelijk te maken, ik denk dan aan splitters, routers, duplicators, met soms een inzicht in de inhoud om te beslissen wat naar welk systeem gaat voor welke user of rekening.

Wet en regelgeving zijn van toepassing in de business logica, de outcome daarvan is persisted state. Die wil je omzetten naar een nieuwe structuur. Bij die transformatie wil je geen business logica, of herinterpretatie van de "waarheid" van het vorig systeem toepassen. Dan doe je 2 stappen in 1 keer. Een overschrijving als voorbeeld, als het oude systeem state produced, die gemigreerd kan worden naar het nieuwe systeem, zou als dat een geldige migratie is er geen verschil mogen zijn tussen het overschrijving naar het oude systeem + migratie en overschrijving meteen naar het nieuwe systeem te sturen. Er staat in beide systemen voor en na die transactie evenveel op de rekening.

Je NAW voorbeeld is ook mooi. IT'ers van de oude strekking die enkel een database kennen maken alles relationeel. Als we dan een klant -> factuur voorbeeld nemen waarbij de factuur een foreign key zou hebben naar klant komen we in allerlei problemen wanneer bvb een klant zou verhuizen. Je oude factuur mag namelijk niet wijzigen. Data duplicatie kan daar bijvoorbeeld helpen. Dat zorgt er dan sowieso ook voor dat klanten en facturen aparte systemen met minder koppeling kunnen worden.

Als er 80 integraties zijn, die ook meteen allemaal mee (moeten) veranderen bij de upgrade van 1 component hadden het misschien zelfs beter geen aparte componenten geweest. Dan zitten we al meer op het terrein van modulariteit en autonomie.

Het voorbeeld van een ID veld is evengoed iets waar scaffolding voor gebouwd kan worden. Stel nu dat er een tabel is zonder ID, dan genereer je juist in functie van je migratie een referentie id, een stelling is iets wat je er zet zodat je kan (ver)bouwen. Die id was niet nodig in het originele systeem, nu wel voor de migratie, je voorziet dat, een trigger die het vult, en je hebt een referentie waarde voor traceability van je migratie.

Ik sta nog volledig achter mijn oorspronkelijke uitspraak, zoals ik daar ook zeg, je moet er intellectuele arbeid tegenaan gooien, er is geen silver bullet, maar het is wel degelijk mogelijk om elk systeem in een staat te brengen, met behulp van allerlei patronen en technieken, kennis van bestaande systemen, en goeie software engineering om eender welke case te migreren, het kost werk en in ruil krijg je risico mitigatie en minder slapeloze nachten in return.

De vergelijking die ze bij argenta maken met de open hart operatie zou dus mijn inziens nooit mogen opgaan, alles van belangrijke systemen van onder je bank onderuit trekken en vervangen lijkt mij vanuit mijn ervaring absoluut geen slim idee. Mogelijk zijn er verzachtende omstandigheden en nuances die ik niet ken. Het feit dat het probleem zich op deze schaal heeft voorgedaan betekend dat er in het process serieuze zaken over het hoofd gezien zijn.

[ppl]

Wet en regelgeving zijn van toepassing in de business logica, de outcome daarvan is persisted state.

Wet- en regelgeving slaat op alles in de keten, niets staat er boven. Dat slaat op je software, hardware, beheer, enz. enz. enz. Er moet dus wel heel wat meer gebeuren. Let wel: wet- en regelgeving houdt niet op bij alleen de wet, ook bepaalde certificeringen die je moet hebben (om wat voor reden dan ook) vallen hier ook onder. Denk hierbij aan bepaalde verplichtingen vanuit de Nederlandsche of Europese Bank.

Je NAW voorbeeld is ook mooi. IT'ers van de oude strekking die enkel een database kennen maken alles relationeel.

Dat voorbeeld heeft vooral als moraal dat niet alleen de data in veel soorten en maten komt. Waarin ze opgeslagen worden en hoe ze opgeslagen worden kent ook vele soorten en maten. Er is meer dan alleen een ID veld of een foreign key.

Als er 80 integraties zijn, die ook meteen allemaal mee (moeten) veranderen bij de upgrade van 1 component hadden het misschien zelfs beter geen aparte componenten geweest. Dan zitten we al meer op het terrein van modulariteit en autonomie.

Het gaat om integratie met externe systemen, als in, systemen die geen direct onderdeel van je eigen systeem zijn maar waarmee wel gecommuniceerd moet worden. Wat componenten upgraden betreft zit je er ook een tikkeltje naast. Je kunt het systeem als zijnde 1 stuk software zien en daar een versienummer op drukken. Door gebruik te maken van componenten kun je bij kleine fixes makkelijker die fixes uitrollen. Je hoeft dan alleen de betreffende component te updaten en niet de gehele omgeving. Ik denk niet dat ik hoef uit te leggen wat voor beheer-technische en security voordelen dit heeft waarvan de klant ook profijt heeft. Om even weer terug te komen op wet- en regelgeving: ook dit heeft invloed op het wel of niet hebben van componenten en externe systemen. Er zijn nou eenmaal regels omwille van security die verplichten dat bepaalde zaken van elkaar gescheiden zijn.

De vergelijking die ze bij argenta maken met de open hart operatie zou dus mijn inziens nooit mogen opgaan, alles van belangrijke systemen van onder je bank onderuit trekken en vervangen lijkt mij vanuit mijn ervaring absoluut geen slim idee.

Dan is het wel erg duidelijk dat jij niets van klantcontact af weet. Wat hier is gebeurd is een overduidelijk geval van de klant informeren. Daarbij geef je nooit en te nimmer de volledige details, laat staan de volledige in-depth technische details. Wat je doet is domweg een simpel verhaaltje geven zodat de klant een goed idee heeft wat er gaande is, de meesten zullen de in-depth technische details toch niet begrijpen en vanuit bedrijfsoptiek is het ook helemaal niet gewenst dat klanten tot in de detail van dingen op de hoogte zijn (als je je graag werk op de hals wilt halen moet je klanten juist wel tot in detail informeren). Juist het voorbeeld van een open hart operatie is sterk. Vrijwel iedereen weet wat zoiets inhoudt en zal dat zien als zijnde iets dat complex en ingrijpend is.

Je vergeet hier om welke verhouding het gaat. Het betreft hier klant-bedrijf en niet techneut1-techneut2. M.a.w. je zit veel te veel in je eigen bubbeltje.

Mogelijk zijn er verzachtende omstandigheden en nuances die ik niet ken. Het feit dat het probleem zich op deze schaal heeft voorgedaan betekend dat er in het process serieuze zaken over het hoofd gezien zijn.

Met die eerste zin had je je moeten beseffen dat je die 2e zin nooit kunt uitspreken. Als je niet weet wat de nuances zijn (en die zullen er wel degelijk zijn, we hebben hier maar bar weinig informatie en dat zal ook nooit volledig worden) kun je ook nooit stellen dat er serieuze zaken over het hoofd zijn gezien. Iedere techneut weet dat er bij dit soort migraties en bij onderhoudswerkzaamheden in het algemeen er altijd een kans is dat er iets stuk gaat. Meestal zijn het kleine dingen maar vaak is het ook iets heel groots. Daarom bereid je je voor en plan je voor het ergste en weet je dat ondanks dit alles er altijd een kans blijft bestaan dat dingen goed stuk gaan. Daarom zijn migraties altijd spannend, nagelbijtend spannend.

Btw, wat er overigens ook nog in het verhaal mist is dat je niet tot in de eeuwigheid blijft schaduw draaien. Op een gegeven moment bereik je een punt dat je het oude systeem gaat uit zetten. Dat betekent weer een onderhoudsronde waarbij je allerlei zaken die nu nog zorgen dat dingen netjes 2 kanten op gaan en in sync blijven weer moet ontmantelen. Dat is een net zo risicovolle operatie als de eerste stap (de opmaat naar het schaduw draaien). Je hebt dus in feite 2 cruciale momenten waarop je je nagels stuk bijt. De vraag is in hoeverre de organisatie dat acceptabel vindt (lees: hoe bereidwillig men is om dat risico te lopen).

[Reactie gewijzigd door ppl op 22 juli 2024 16:08]

[Verwijderd]

Klopt. Om even mijn ervaring met de materie te schetsen: Ik heb als release maintainer een aantal keer een uitrol gedaan van een nieuwe software voor het beheer van oa. bus abonnementen (back office voor een vervoersmaatschappij). Hierin zaten (waarschijnlijk) veel meer reizigers dan er klanten zijn bij Argenta en moesten er ook betalingen gebeuren (dus bv. brieven gestuurd worden), betalingen geregistreerd worden, en zo verder. M.a.w. zou de datamigratie foutlopen, dan zou dat miljoenen euro's kosten (per dag, en zelfs meer en erger). Bussen zouden daar ook niet kunnen uitrijden. M.a.w. ook schadeclaims door overheid en andere partijen.

Als vanzelfsprekend werd dit niet zomaar op de live data gedaan. Als vanzelfsprekend waren er verschillende vormen van acceptatie-testen (inclusief maar zéker niet enkel performantietesten bij grote loads).

Bij zulke opleveringen doe je géén big bang.

Nooit.

Nee.

Nooit.

Ben je dat wel aan het doen, dan is je project-beheerder een idioot.

Toegegeven zijn er nogal veel idiote project-beheerders aan de slag in de IT sector de dag van vandaag. Zeg maar dat de meerderheid totaal niet snappen waar ze mee bezig zijn en dat de meerderheid gepromoveerd werden a.d.h.v. Peter Principle.

Ze zijn m.a.w. gepromoveerd tot hun niveau van incompetentie. In hun huidige functie zijn ze dus volledig waardeloos incompetent.

Die waar ik mee te maken had was ook niet echt fantastisch op de hoogte van waar hij mee bezig was. Maar dan zeg je als release-maintainer gewoon "neen, ik doe dit niet want a,b en c zijn niet getest" en daarna zeg je "Ja, ga inderdaad maar op je hoofd staan en zeg desnoods mijn contract op. Mijn reputatie staat hier ook op het spel".

Een project-beheerder die zulke opleveringen (zoals hier bij Argenta) op een big bang manier doet, is per definitie volledig waardeloos incompetent. Zo iemand is ook zéér gevaarlijk voor de waarde van de aandelen van het bedrijf. M.a.w. hoor je als CEO die niet aan het stuur te zetten van zo'n operatie.

M.a.w. is de CEO van Argenta ook incompetent geweest. Want hij is ervoor verantwoordelijk dat de mensen die dit soort zaken moeten sturen, competent zijn.

[Meekoh]

Leuk verhaal, maar trust me, je onderschat de beroerdheid van het gedrocht genaamd “Thaler” (banking software van inmiddels sopra) heel erg.
Als men praat over de oude lompe legacy cobol systemen dan hebben ze het over Thaler . Dat pakket is niet met zijn tijd meegegaan.

[Reactie gewijzigd door Meekoh op 22 juli 2024 16:08]

[elmariachi]

Ik had ook de indruk dat het hier niet over het systeem dat over het geld gaat zelf ging, wat bv. dan vermoedelijke die Thaler is waar jij het over hebt, maar wel over de laag voor één of andere smartphone-app en hun webbanking.

Het gaat niet over alleen de laag, ook de verwerking van het betalingsverkeer werd grondig vernieuwd.

[Meekoh]

In de financiele wereld zijn er best alternatieven beschikbaar voor dit soort producten. En niet perse geschreven door een bende yuppies. Het klopt dat het bij deze migratie niet perse om het core banking platform ging. Echter reageerde ik op je reactie over software pakketen en Big Bangs. Een pakket als Thaler is big bang period.

[WORPspeed]

Meestal komt het op kosten neer. Twee systemen paralel draaien kost een stuk meer en vereist weer speciale kennis etc. Vereist ook extra hardware die na een volledige migratie niet meer nodig is.

Dat tech bedrijven dit doen is 1 ding, maar als je denkt dat banken op datzelfde niveau hun infrastructuur geregeld hebben dan heb je het (in de meeste gevallen) mis.

[Apache]

Hardware kosten tov een software development traject van ettelijke jaren vallen compleet in het niets. En de huidige reputatie schade, verlies van klanten, etc had spotgoedkoop geweest.

"Speciale" kennis kan ik wel min of meer mee akkoord gaan, ondanks dat die kennis zeker te vinden is, moet de organisatie er ook voor openstaan. Als je met een bende omhoog gevallen dba'ers werkt die het tot manager/directeur geschopt hebben is dat nog veel minder vanzelfsprekend.

[Chrotenise]

Als jij denkt dat het feit dat klanten één dag niet kunnen bankieren leidt tot verlies van klanten heb je het mis. Pas als er een keten van dit soort zaken in korte tijd optreedt, gaan klanten het mogelijk overwegen. Is namelijk een serieuze ellende om over te stappen.

[Deralte]

Argenta heeft de laatste jaren verl klanten afgesnoept van de grootbanken. Oudere mensen die zijn overgeschakeld en deze problemen ondervinden (die ze bij hun oude bank nooit gehad hebben) zijn hier erg gevoelig aan. Reken maar dat er al een hoop van die mensen bij hun kantoor langsgeweest zijn om te klagen. Laat dit nog twee dagen aanhouden en ze gaan terug naar de oude stal...

[WORPspeed]

Achteraf zijn de kosten te verdedigen. Maar als alles goed was gegaan was het opeens: "waarom geef je zoveel uit aan extra hardware als we dat niet nodig hebben? Dat geld konden we beter gebruikt hebben"
En hardware inslaan, opslagkosten voor dubbele databases, extra mensen om het tweede systeem in de gaten te houden (die gedurende het hele project dus betaald meoten worden) en de schouderklop die je krijgt als je je project niet buiten het budget is gevallen zijn genoeg incentives voor organisaties om hierop te besparen. Voor de grotere banken denk ik dat voor hun imago schade zwaarder weegt dan de kosten, maar voor velen denk ik dat de kosten het niet waard zijn (in hun overweging, niet als feit)

[KeiFront]

Meestal komt het op kosten neer. Twee systemen paralel draaien kost een stuk meer en vereist weer speciale kennis etc. Vereist ook extra hardware die na een volledige migratie niet meer nodig is.

Dat tech bedrijven dit doen is 1 ding, maar als je denkt dat banken op datzelfde niveau hun infrastructuur geregeld hebben dan heb je het (in de meeste gevallen) mis.

Als ICT-consultant heb ik al vaker de interne keuken gezien van Financiële organisaties en ik kan je garanderen alles is dubbel uitgevoerd en streng beveiligd. Hoofdzakelijk vanwege wetgeving en om image schade te vermijden. Ik heb bijvoorbeeld ook al enkele malen een disaster recovery test meegemaakt.

Maar ja, als je als bank gaat besparen op ontwikkeling (outsourcing (if you pay peanuts you get monkeys)) en infrastructuur dan mag je verdiend op de blaren gaan zitten.

[WORPspeed]

Leuk voor jouw, maar als ICT consultant (ervaring binnen 1 bank so far) heb ik gezien hoe dat niet dubbel is uitgevoerd. Althans, wel voor disaster recovery etc, maar voor grote projecten deden ze niet aan parralel systemen. Go or no-go en dan een rollback als t nodig is.

[burne]

Misschien moet je je even inlezen in de geschiedenis van bedrijven als IBM, Burroughs, NCR enzovoort, en welke rol grote banken in hun geschiedenis gespeeld hebben. Banken zijn al een jaar of zestig afhankelijk van computers. Hun ICT is al heel lang een uiterst kritisch deel van hun bedrijfsproces en doen alsof banken nieuwkomertjes zijn die nu ook een beetje met computers aan het klooien zijn is niet terecht.

[WORPspeed]

Misschien moet je zelf werkzaam zijn in een bank en een groot project daar doen. Dit is geen oom van mn vader werkt bij Nintendo, dit is first-hand ervaring. (wel bij 1 bank overigens, dus ik spreek niet voor ze allemaal)

[YangWenli]

Grappige vergelijking want bij zo'n operatie worden de functies van het hart tijdelijk overgenomen door een machine. Waar is hier het backup systeem?

[ShellGhost]

Uitgeleend...

[ppl]

Dat is de verkeerde vraag. De juiste vraag is: vereist dit systeem net als een hart een backupsysteem? Dat antwoord blijkt een "nee" te zijn aangezien ze dit systeem nu platgooien. Dat doe je alleen als het ook daadwerkelijk kan. In geval van een hart kan dat niet want dan sterft de patient.

[Reactie gewijzigd door ppl op 22 juli 2024 16:08]

[Verwijderd]

Jammer genoeg waren de website in de loop van zondag en maandag deels bruikbaar met een rits onprettige neveneffecten. Erger, (een deel) van de saldi waren niet bijgewerkt.

Als IT-er denk ik dan:

0) De migratie/upgrade was gepland voor het volledige paasweekend ??? Waarom niet in het midden van de maand tussen de grote transactiepieken en kantoren wat langer openlaten om eventuele impact op te kunnen vangen.

1) De testomgeving is niet representatief voor productie, bvb de testomgeving is gaandeweg gestabiliseerd met de hand tijdens de ontwikkeling en niet regelmatig van scratch van een (geanonimiseerde) productie situatie geupgrade/gemigreerd of men test maar basic happy path use cases of een deel van de testomgeving draait nog accidenteel op een oude versie. Nu meld men leuk op hun sorryarg.be: "Er zijn in de nacht van 3 op 4 april verschillende ingrepen gebeurd op de infrastructuur en ook vandaag blijven we de stabiliteit van onze IT-omgeving testen. De resultaten van deze tests zijn positief."

2) Erger, deze vette showstopper duurt al enkele dagen na geplande inbruikname. Zelfs een kleinschalig gedisciplineerd team kan een rollback of disaster recovery voor mekaar krijgen. Kan men of wil men dit niet ? Wel spreken over bijstand door experten en dat ze late uurtjes draaien.

3) Liever het internet bankieren (inclusief portaal waar je gegevens over je kantoor zoals telnummer zou kunnen opzoeken) & mobile overdag uitschakelen om het betalingsverkeer van de kantoren tijdens de werkuren te kunnen garanderen. Ze zijn (19u15 nu) nog altijd niet online. We spreken over een bank waarbij een gemiddeld kantoor opengaat om 10u en sluit om 16u (met een uur middagpauze) en je uitsluitend bij je eigen kantoor van je rekeningen geld kan afhalen.

Hier falen niet alleen de ontwikkelaars, maar de hele ladder t/m de top

[Verwijderd]

De informatie die ik heb van een collega die momenteel bij Argenta zit, is de volgende:
- Het probleem is puur technisch.
- De architectuur van de database is slecht en zou niet simpel om op te lossen zijn.
- Hopelijk is er vandaag al een tijdelijke oplossing. Dit WE wordt dan alles goed gefixed.

Zeer vaag ... I know. Momenteel weet ik er ook niets meer over.

Edit: ik heb de naam van het "schuldig" bedrijf verwijderd want dit is slechts "hearsay".

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:08]

[Verwijderd]

"Het probleem is puur technisch. De architectuur van de database is slecht en zou niet simpel om op te lossen zijn."

Dat klinkt mijn niet als een "puur technisch probleem". De meeste "puur technische" problemen zijn makkelijker op te lossen dan conceptuele problemen...

[Frituurbaas]

tijdelijke oplossing

Dat is waar het mis gaat. Vanaf de lanceerdatum beginnen met workarounds betekend direct ernstige Technical Debt toevoegen aan het systeem. Nog voordat het goed en wel in gebruik is genomen is het al tot legacy verklaard.

[MPAnnihilator]

Ter info : er wordt ook reeds gepoogd misbruik te maken van de situatie. ( het phishing domein uit het artikel is inmiddels terug vrijgegeven , maar het is niet uit te sluiten dat er andere versies gaan opduiken )

https://www.hln.be/nieuws...men-bij-argenta~ae0ab4bb/

[biglia]

Ik ben klant bij Argenta, maar op vlak Internetbankieren en andere toepassingen staan ze toch wel wat achter t.o.v. Belfius waar ik ook klant ben. Het werkt wel allemaal maar de mogelijkheden zijn wat beperkt en het ziet er allemaal niet zo gelikt uit. Natuurlijk is het allemaal gratis en is Belfius betalend. Dat maakt ook veel verschil uit.

[wica]

Misschien denk ik te simpel, maar hadden ze geen rollback scenario klaar staan?
Voor een bank, mag het toch niet de kosten zijn, om een 2de productie omgeving, standby te hebben staan?

[sys64738]

Probleem is dat het systeem al paar dagen gedraaid heeft. Als het meteen klapt, is het makkelijker om naar het oude systeem terug te gaan.

Nu heb je een nieuw systeem dat voorloopt op het oude en transacties bevat die je op het oude systeem mist. Dus zomaar terug gaan is geen optie.

Ze hadden dit kunnen ondervangen door de transacties ook op het oude systeem na te spelen. Maar dat is misschien wel makkelijker gezegd dan gedaan.

Ook vraag je je af waarom de acceptatie-tests zo gefaald hebben. En waarom er gekozen is voor een (blijkbaar) big bang scenario ipv eerst groep klanten over te zetten en later de systemen samen te voegen.

Maar van de zijlijn is het altijd makkelijk commentaar geven. Er zullen gerust geen achterlijke mensen werken daar en ik heb met ze te doen. Het zal er wel gekkenhuis zijn.

[wica]

Nu heb je een nieuw systeem dat voorloopt op het oude en transacties bevat die je op het oude systeem mist. Dus zomaar terug gaan is geen optie.

Hier heb je een transactie log voor.
Waarmee je een systeem ten alle tijden moet kunnen herstellen vanaf een punt dat je zeker weet dat de data correct is. En dan "speel" je de transactie log weer opnieuw af, om up to date te komen.

Maar van de zijlijn is het altijd makkelijk commentaar geven.

Ja, dat is het idd, maar ik doe het toch wel met enige kennis.
In 2000 heb ik een betaling en uitbetaling systeem opgezet, waar per maand 1/2 miljoen in omging.
1 van de eisen was een transactie log, waarmee ten alle tijden transacties te achter halen waren en vanaf een bepaald punt, weer te herstellen was.
Betalingen uit verschillende bronnen, CC, bank-, sms betalingen en betaal nummers, etc

Als wij dit al hadden in 2000, dan is het iets wat een bank vandaag de dag zeker kan hebben.

[Reactie gewijzigd door wica op 22 juli 2024 16:08]

[Verwijderd]

Ik denk dat het afspelen van een transactie log een wat simpele oplossing is en geen techniek van 2000 maar van 1980. Dat gaat op voor één centraal systeem, met één centrale log dat je gaat upgraden naar een volgende versie. In een gedistribueerd systeem, met vele applicaties die met elkaar communiceren en waarvan sommige zelfs buiten het direct bereik van de organisatie liggen, is dit een irrelevante techniek. Bovendien kan je de transactie-log van een nieuw systeem niet zomaar op een oud systeem afspelen om het oude systeem weer "up-to-date" te brengen.

Nee, de goede aanpak is toch echt wel, in dit soort complexe omgevingen, om het nieuwe systeem parallel aan het oude te bouwen en (na testen) geleidelijk te gaan migreren in plaats van big-bang. Dat is de enige manier om relatief snel en met relatief weinig risico de nieuwe systemen in stelling te brengen en daarna de volumes te verhogen naarmate de nieuwe systemen hun degelijkheid en robuustheid bewijzen.

[Keypunchie]

Kans bestaat dat ze *nu* de transactielogs aan het reconcilieren zijn...

[Verwijderd]

Lichtjes onverantwoordelijk of niet al te veel inzitten met een goede dienstverlening is niet hetzelfde als achterlijk. Kwaliteit kan je het niet noemen, ofwel ? De dingen die je opnoemt zijn risico's die kunnen opgevangen worden tenzij er wat kort door de bocht kan of mag gegaan worden. Affijn de war room zal inderdaad wel gezellig zijn nu.

[TheCaptainFordo]

Rollbacks zijn ook maar tot een bepaald punt geldig, op een gegeven moment passeert men een point of no return, dan kan je niet makkelijk terug draaïen.

[RGAT]

Voor een particulier zijn de kosten van een standby systeem prima te betalen (tweede laptop van de mediamarkt van 400,- oid).
Naast het primaire systeem een standby systeem aanschaffen, onderhouden en naar repliceren is niet betaalbaar.

[Blokker_1999]

Tuurlijk wel. Vaak heb je zelfs meerdere omgevingen als je regelmatig nieuwe software uitvoert. Een speeltuin voor je developers, een testomgeving en dan uiteindelijk in productie. Alleen zijn die eerste 2 vaak een stuk kleinschaliger. Maar bij dit soort grote projecten is het vaak ook niet ongebruikelijk om de infrastructuur te vernieuwen waardoor je wel degelijk de capaciteit hebt. Alleen moet je op een bepaald moment over en dat kan niet altijd in de twee richtingen.

[RGAT]

Een testomgeving of zelfs een geheel nieuw vervangend systeem is wel iets heel anders dan een tweede standby omgeving welke permanent standby staat naast je primaire systeem wat je zo even kan inschakelen, die moet dus de capaciteit hebben en volledig up-to-date data...
Er ging hier iets mis tijdens het overschakelen naar een nieuw systeem, dan had er dus een derde standby systeem moeten zijn naast het oude en nieuwe systeem...
Een ontwikkelstraat helpt weinig meer op moment dat je de migratie uitvoert, ik mag hopen dat geen bank serieus overweegt om terug te vallen op een testomgeving voor daadwerkelijke betalingen

[Verwijderd]

Het probleem was hier wellicht niet zozeer het nieuwe systeem an sich, maar de big bang. De complexiteit van bancaire omgevingen is zo groot dat een big bang zelden een goede optie is, tenzij voor een beperkte en niet-bedrijfskritische scope die je perfect kan testen op voorhand.

Een standby systeem, in de zin van een kopie van het (nieuwe?) primaire systeem is hier niet relevant: het was ongetwijfeld geen infrastructuur incident probleem, maar een structureel probleem, hetzij in de infrastructuur of in de applicaties...).

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:08]

[burne]

Een van mijn klanten heeft niet alleen alles dubbel uitgevoerd in datacenters in Amsterdam, ze hebben zelfs een complete kopie in andere datacenters elders in het land draaien. Ook de ontwikkel-omgevingen zijn dubbel uitgevoerd. 60 programmeurs die duimen zitten te draaien is niet goedkoop.

Kosten van hardware zijn verwaarloosbaar in vergelijking met de kosten van langdurige downtime.

[wauwwie]

Al heb je alles tienvoudig uitgevoerd, het is logisch gezien maar één omgeving. Immers alles moet in sync zijn, je wilt geen transacties missen tussen de verschillende omgevingen. Dubbele transactie straten zijn duurder dan 2x de prijs van die straten, ze moeten ook nog in sync gehouden worden, danwel dat ze van elkaar weten wie welke transactie hebben.

En dit niet alleen bij banken, maar ook bij bijv retailers. Niets zo "leuk" als dat er tijdens een failover tussen locaties ineens drie vrachtwagens met artikelen in opslag staan die net ingeboekt waren, waarvan de transactie net is terug gedraaid door een failover...

[sympa]

Benken doen VZIW de transactieafhandeling op applicatieniveau en niet op het niveau van een binaire databaselog.
Maar goed, dubbel de data in sync houden is dubbel in sync. Voordeel is wel dat je verschillende software kan gebruiken zolang de applicatie aan dezelfde specificaties voldoet - dan is het dus meer dan 1 logische machine.
Dat is vooral handig als deze machine geacht wordt deterministisch (en bugvrij) te zijn natuurlijk.

[JohanNL]

Ik denk dat dat niet zo eenvoudig werkt, straks komt er een *handige* icter die een hardeschijf wisseltruc uitvoert o.i.d.
Het grote probleem is denk ik het paasweekend waarbij het personeel gewoon ( voor een groot gedeelte ) niet aanwezig is maar het betaalverkeer natuurlijk wel gewoon doorgaat.
Voor zover ik had gezien en gemerkt had elke bank na het Pasen wel enigszins problemen, storingen of vertragingen met ING voorop doordat pin transacties dubbel zijn afgeboekt.
Dit is gewoon geen toeval meer.

[elmariachi]

In België zijn alle banken gesloten in het paasweekend: https://www.febelfin.be/nl/banksluitingsdagen-2018

[Verwijderd]

In het paasweekend (ZA/ZO/MA) is er ook geen betaalverkeer. Dat zal veranderen met de onmiddellijke betalingen die er aankomen, maar voorlopig werken de banken op het ritme van de "Target Days": http://www.sepaforcorpora...t-closing-days-2017-2018/

[Youckle]

OTAP?

Ontwikkel
Test
Acceptatie
Productie

~zandbak

[RGAT]

En dat helpt hoe tegen onverwachte fouten?...
Ik ga er vanuit dat een bank een ontwikkelstraat heeft met DTAP/OTAP ja, maar hier ging er tijdens een ingewikkelde migratie naar een nieuw systeem iets mis, kan de software nog zo goed draaien tijdens testen als er iets anders mis gaat helpt je OTAP daar niks tegen...

[Quilt]

Argenta heeft een halfjaarwinst van 117 miljoen euro.
Dat is meer dan wat de meeste particulieren verdienen.

[RGAT]

Als jij wil dat jouw bank bij een storing overschakelt naar een Mediamarkt laptopje als standby systeem gaat die vlieger wel op ja
Als je echter een werkend standby systeem wilt heb je het over tientallen miljoenen als beginnetje in de kosten en dan gaat het ineens hard omlaag met de winst...

[cadsite]

Alles is gewoon in verhouding.

[Bezulba]

zal wel te veel gekost hebben.

[ShellGhost]

Wat denk je dat een productieomgeving kost? En denk je werkelijk dat ze geld hebben om een identieke omgeving er naast te hebben?
Het antwoord is nee. Een aantal kritieke dingen hebben ze dubbel, maar echt niet alles. Zou ook onmogelijk zijn omdat de productieomgeving daarvoor te dynamisch is. Data veranderd per seconde.

[Alcmaria]

natuurlijk hebben banken alles dubbel uitgevoerd en compleet gespiegeld draaien.. als het produktiesysteem onverhoopt in een klap down gaat.. dan mis je wel wat commits.. maar het backup systeem kan het bijna naadloos overnemen. Voor de duidelijkheid.. niet een klein beetje van de infra is dubbel uitgevoerd.. ALLES is dubbel uitgevoerd.. en loopt ongeveer 0.1 seconden achter op de actuele prod situatie.

[Verwijderd]

+ dat Argenta voor de meeste dingen compleet gratis is voor de consument.
Dat scheelt hun toch 26 miljoen euro per jaar.

[TheCaptainFordo]

In feite is er zelfs meer dan één, natuurlijk veranderen die niet live, maar close enough...

[Verwijderd]

Uiteraard is "alles" dubbel uitgevoerd. Dat was hier zeer waarschijnlijk niet het probleem: een kopie van een problematisch systeem is een problematisch systeem... Dubbele uitvoering beschermt tegen infrastructuurproblemen (server uitval, netwerk uitval...), niet tegen een niet goed voorbereide migratie naar een nieuw platform.

[Frituurbaas]

Vergis je niet in de kosten van een productie omgeving, voor een beetje bank loopt dat snel in de tientallen zo niet honderden miljoenen per jaar.

[Tommie12]

Moet grote paniek zijn daar, en er moet een software update gedaan zijn, anders kan dit niet.

Ik snap eigenlijk niet dat ze dan niet direct een "rollback" doen.

[Quilt]

Ze hebben 4 dagen gedeployed (van donderdag 20u tot maandagavond 20u).
Wellicht is het niet makkelijk te deployen.

Experten in body language moeten eens het hoera-bericht van CEO Marc Lauwers bekijken op Linkedin maandag. Je ziet taart en schuimwijn, maar links staat een paar man met het lichaam naar achter en de armen gekruist. Ik zou denken dat die er toen ook al niet gerust op waren.

[Tha_Clown]

De mensen met hun armen over elkaar kijken inderdaad niet erg gerust ...

Hier een link naar het bericht:
https://www.linkedin.com/...ivity:6386286352039768064

[Frituurbaas]

Mooie vondst, dat zijn de mannen die de afgelopen dagen 24 uur per dag hebben doorgewerkt om de boel draaiende te krijgen zo te zien. Die weten hoe houtje-touwtje alles aan elkaar is geknoopt met tijdelijke work-arounds. Ze weten als geen ander dat de top 10 issues de komende 3 jaar niet opgelost gaan worden, laat staan de 890 lager geprioriteerde zaken. </einde cynische zeikmodus>

[GrooV]

Uiteraard, alle bugs komen via een update

Een rollback is niet altijd mogelijk, vaak is een rollforward sneller maar dat hebben ze misschien onderschat

[Reactie gewijzigd door GrooV op 22 juli 2024 16:08]

[karliboe]

Zou om een upgrade/update gaan waar ze al enkele jaren aan gewerkt hadden. Wellicht een te complex systeem om eventjes een backup van terug te zetten.

[aequitas]

Een rollback is altijd even makkelijk of de juiste oplossing. Soms manifesteert een een probleem zich pas laat (bv als er een bepaald aantal logins/transacties tegelijk wordt gedaan waar niet goed op getest is). Het kan dan zijn dat er al zo veel state (accountgegevens, banksaldo's etc) veranderd is dat een rollback onvermijdelijk tot dataverlies, schade of nog meer storing zal leiden.

In mijn optiek is een big-bang migratie ook vaak het slechtste wat je kan doen, omdat je dan bijna geen kant meer uit kunt als het mis gaat. Beter is het om geleidelijk kleine gedeeltes stukje bij beetje te migreren. Hierdoor kan je makkelijker terugschakelen als het nodig is. Probleem is dat dit wel meer tijd en geld kost, het is maar net welk risico management wil nemen.

[Tommie12]

Er is een enorm verschil tussen risico nemen en dan 10% halen, en de tegoeden van je klanten garanderen, en daar nog een vergoeding voor betalen terwijl je elders aan nog goedkoper geld kan geraken.

Maar dat wist je als ervaren belegger toch al.

Mijn tante van 75 zou er niet mee kunnen lachen als ze vandaag 100€ op haar spaarrekening zet, en er volgende maand ineens maar 99€ meer op staat, of erger nog 90€. Zij kiest er niet voor om risico te nemen, dat doe jij wel als je 10% rendement haalt.

[aadje93]

tja, een keer geluk hebben met een zeepbel en dan de bank gaan beschuldigen dat ze de rente verlagen. Alhoewel dit totaal offtopic is, de centrale rente word door de ECB bepaald, en niet je eigen bank, de bank hangt hier slechts een klein verschil aan voor winst (ze kunnen voor 0% lenen bij de ECB, waarom zouden ze jou dan betalen om geld te stallen?

[gepebril]

Zeepbel...... https://99bitcoins.com/bitcoinobituaries/ zitten we nu op 274?

[aadje93]

Dat zei men in 2000 ook, tot heel de zaak in elkaar klapte 🤔

[gepebril]

Yup, Na de Internet bubble zijn we allemaal weer teruggegaan naar ISDN en PSTN. Zou wel mooi geweest zijn als het Internet het wel gered had.......... Nooit begrepen dat http, ftp, sip geen schijn van kans hadden......

[aadje93]

ik denk dat je de strekking van het verhaal van 2000 een beetje mist, kijk even naar de koersen van Intel, AMD en qualcom, zie je dan wat opvallends? Dit zijn enkele van de weinigen die het uberhaupt overleeft hebben, de rest met "com" in de naam of iets tech gerelateerds bestaat al niet meer.

Dat heeft niets met een protocol te maken, maar dat wil je blijkbaar niet begrijpen..

[gepebril]

BTC is wat anders dan Altcoins. In een opkomst van een nieuwe disruptive techniek zie je veel prutsers/oplichters die handig meeliften. Daarom vind ik de Internet bubble ook zo'n rare benaming. Internet is nog nooit zo groot geweest. Wellicht zaten we afgelopen maanden in crypto bubble, zeker geen BTC bubble.

[aadje93]

het was de .com buble, en zeker niet de eerste bedrijven hebben het overleeft Helaas heb ik het zelf niet heel bewust mee mogen maken, maar wel de verhalen gehoord. "the sky is the limit" voor alles met com in de naam of half IT-tech gerelateerd. Compleet opgeblazen koersen die 10tallen procenten per jaar omhoog gingen.

[Skindred]

Wanneer je het phishing domein in kwestie probeert op te zoeken bij DNS.be krijg je Access Denied :-) :
https://www.dnsbelgium.be...inName=argemta.be&lang=en

Verder nog leuk leesvoer:

https://www.dailybits.be/...ken-argenta-it-problemen/

[MPAnnihilator]

Die access denied bij dns.be krijg je omdat je er niet mag naar linken. Zoek het apart op en je zal zien dat het ondertussen vrij is ter registratie.

[Skindred]

Half waar, je mag wel linken met de link die ik voorzie.
Maar inderdaad als een domeinnaam beschikbaar is, dan kan je er uiteraard geen WHOIS gegevens van bekomen, vandaar komt dus de Access Denied.

https://www.dnsbelgium.be...domainName=hln.be&lang=en werkt dus bvb wel

[MPAnnihilator]

Klopt. Ze zijn nu in overgangsfase ivm GDPR , maar vroeger diende je altijd een captcha te gebruiken om de WHOIS gegevens te bekomen van een .be ( via hun website )
Volgens mij gaan ze er opnieuw naartoe vanaf 25 mei zoals ze zelf aangeven. Linken naar het resultaat van een WHOIS zijn ze bij dns.be geen fan van geweest. Nu met GDPR zal die beperking wellicht gefinetuned worden en zullen ze het systeem wellicht verder aanpassen. Je kan nu wel de status zien blijkbaar , maar nog niet de eigenaar... To be continued

[Verwijderd]

Mooie redirect:
http://argenta.be >
https://argenta.be >
https://argenta.be/portalserver/home >
http://sorryarg.be/

[The Zep Man]

En nog belangrijker, geen HTTPS. Slordig.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:08]

[tha_crazy]

Gezien dat dit een statische pagina is, waarop geen invulvelden zijn en de links naar hun eigen domein gaan met https, is er weinig mis mee dat hier geen HTTPS is.

[The Zep Man]

Behalve als je sessie gekaapt wordt door een man-in-the-middle, die je iets geheel anders kan voorschotelen. Webformulieren, exploits...

Er is geen excuus om enkel HTTP te gebruiken. Zeker niet voor een bank.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:08]

[Opperpanter2]

Inderdaad. Echt hardnekkige desinformatie dat https allen waarde heeft als er iets moet worden ingevuld of persoonlijke data wordt getoond.

https://www.troyhunt.com/...m-posts-to-https-but-you/

[skralan]

Als hun backend even stevig in elkaar zit als de sorrypagina zou ik me zorgen beginnen maken .

Background image is een pixelated afbeelding, onnodig, niet web-standard volgend, niet responsive, niet optimized.
In de html staat nog php-code die uitgecomment (met hardcoded values) was:

<!--?php
$copyYear = 2016; // Huidig jaar
$curYear = date('Y');
echo $copyYear . (($copyYear != $curYear) ? '-' . $curYear : '');
?-->

Ze hebben ook expliciet de moeite genomen om niet opgenomen te worden in zoekmachines
<meta name="robots" content="noindex, nofollow">
(om toekomstig schaamtegevoel te vermijden wanneer mensen zoeken op argenta problemen)

Edit: linkje naar achtergrond afbeelding toegevoegd.

[Reactie gewijzigd door skralan op 22 juli 2024 16:08]

[TheCaptainFordo]

Men is met de migratie reeds 3 jaar bezig geweest, je moet het inderdaad echt wel zien als een drastische overhaul van het interne bankiernetwerk. Te veel zeggen mag niet maar de overvloed aan logins is eerder een gevolg dan een oorzaak in mijn ogen. In ieder geval, men is hard bezig met de problemen op te lossen, ze hadden meer duidelijkheid moeten geven over de acties die ondernomen gingen worden zodat mensen zich beter konden voorbereiden. Het is namelijk geen routine maintenance.
In ieder geval, hopelijk zijn de problemen snel opgelost!