Rabobank heeft storing met mobiel bankieren en internetbankieren - update

Rabobank heeft een storing met mobiel bankieren en internetbankieren. Klanten kunnen niet inloggen. De storing treedt op sinds donderdagochtend kwart over tien. Het is onbekend hoe lang de storing zal duren.

De site vermeldt bij het inloggen dat 'om technische reden het gevraagde onderdeel niet beschikbaar' is, terwijl de app een melding laat zien dat de app en site niet beschikbaar zijn door een storing en dat de bank werkt aan een oplossing.

Volgens AlleStoringen begon de storing rond kwart over tien op donderdagochtend. De bank zegt niet waardoor de storing komt en geeft ook geen indicatie van wanneer de diensten weer zullen werken. Het lijkt er vooralsnog op dat de storing alle klanten treft.

Update, 13:37: De storing is opgelost, zo meldt Rabobank.

Reacties (115)

[casberrypi]

De meesten gebruiken toch echt een externe dienst voor dit soort dingen. Self-hosten van een statuspagina is leuk als je héél groot bent of/en hele bijzondere use-case hebt.

Als je maar één webserver hebt voor een dienst ga je die statuspagina overigens wel heel vaak nodig hebben.

De door jou geschetste situatie lijkt me bij een professioneel bedrijf niet voor mogen komen.

Waarschijnlijker is dat de engineers niet de tijd hebben of nemen om een status-update te schrijven of de personen in te lichten die dat moeten doen, of dat het niet duidelijk is wiens verantwoordelijkheid dat eigenlijk is.

Onder stress moeten belangrijke beslissingen gemaakt worden en dan valt deze er wel eens af.

Vooral omdat als je precies weet wat het probleem is, het meestal snel is opgelost. Het analyseren kost het meeste tijd, en engineers vinden het moeilijk om te zeggen dat ze het nog niet weten.

Dus komt er vaak niets. Niet goed, maar vaak durven mensen niet te schrijven dat het probleem bekend is en dat het wordt onderzocht.

[RobertMe]

De meesten gebruiken toch echt een externe dienst voor dit soort dingen. Self-hosten van een statuspagina is leuk als je héél groot bent of/en hele bijzondere use-case hebt.

Als ik zo even begin te graven: volgens mij had Facebook het dus bij hun grote netwerk storing van laatst. Ik meen dat GitHub het ook wel eens heeft gehad dat de status pagina eruit lag als onderdeel van de storing. En ik ben momenteel aan het twijfelen of OVH niet een soortgelijk issue had toen laatst hun DC in Straatsburg in brand stond. Maar vooral die laatste weet ik niet meer zeker. Het zijn dus echt niet alleen maar kleintjes die met zo'n issue kampen.

En die wat een status pagina hosten op status.<mijndomein> die hebben dus sowieso weer een issue als er een DNS storing is waardoor de boel eruit ligt. Want grote kans dat als de nameserver van <mijndomein> er uit ligt dat die dus ook niet meer status.<mijndomein> kan verwerken. Idealiter wordt er dus gebruik gemaakt van <product>status.<TLD> of zelfs nog op een ander TLD ook zodat de status pagina / domein ook resolved als de rootservers van het TLD er uit liggen.

[Jeroen hofman]

het s de laatste tijd wel raak met deze storingen,
Zag woensdagavond al, dat de pin automaten ook deels out off order waren.
Verder zie ik ook dat er ook hier in mijn woonplaats een ATM weg is.
Binnen nu en ? 2 jaar zijn alle ATM autom... weg, cash geld zal er dan ook niet meer zijn. en daar wil men juist naar toe

[Verwijderd]

Het cash zal blijven, al willen banken anders.
We hebben een monutaire unie die een munt hebben, wat wil zeggen dat inwoners uit andere landen hier ook terecht moeten kunnen met cash.
Dat NL voorop wil lopen met digitaal, moet niet het probleem hoeven te zijn/worden van inwoners uit landen EU landen.

Al een ervaren hoe het is als een betaal automaat je bank kaart niet accepteert, of aangeeft dat de kaart niet goed is, terwijl ze dat wel is?

[swhnld]

maar dan kan iedereen ook fraude plegen, bij een bank is dat niet wenselijk waardoor de DNB bepaalde eisen stelt aan het proces.

Overigens, zo veel veranderd er niet binnen het internet bankieren, dus waarom zou dat stukje door honderden programmeurs gedaan worden, eerder 1 of 2 teams die daaraan werken lijkt mij.

[Tarquin]

Let wel, alle code wordt wel gereviewed.
En de code van internet-bankieren is iets anders dan het systeem dat de transacties doet.

En alle code komt uiteraard voor eeuwig in een versiebeheersysteem en is altijd terug te leiden naar jou.

Maar ik ben in een genereuze bui en ik geef jou toegang tot de code en je collega's letten niet op.
De vraag is eerder: Hoe denk je er mee weg te komen? Dat kun je niet zomaar wegwuiven.
Want ze komen er achter, héél snel.
De vraag is niet zozeer hoe je fraude pleegt (bijvoorbeeld door van elke 1000 transacties bij ééntje het rekeningnummer te vervangen).
De vraag is: Hoeveel geld heb je ongeveer nodig om de rest van je leven onder te kunnen duiken?
Als je die vraag beantwoordt zie je dat het niet leuk meer is.

[swhnld]

Ik werkte in de banksector eind van de eeuw, en toen nam toch iemand 40 miljoen gulden mee bij de ABN en ontvluchte het land., volgens mij is die uiteindelijk wel gepakt en veel geld teruggevonden, maar mensen kunnen in de verleiding komen domme fouten te maken, dus stelt de DNB regels op waar je aan moet voldoen, doe je dat niet kan je bank licentie sneuvelen zoals DSB een keer overkomen is.

[La1974]

Je hebt blijkbaar geen idee waarover je het hebt.

[Creesch]

Er zit toch vaak wel iets meer nuance op het pushen naar productie, zeker bij dit soort organisaties. Je noemt het wel tussen neus en lippen door maar gaat er stiekem een beetje aan voorbij.

mét een review

In theorie kan iedereen het maar zijn voor zaken op productie speciale credentials nodig die je alleen maar kan krijgen via goedkeuring. Afhankelijk van wat er gedaan moet worden is goedkeuring een simpel vinkje of toch een lijst aan voorwaarden. Bij nieuwe functionaliteit zal daar over het algemeen toch een lijstje zijn die moet worden afgevinkt, o.a. zaken zoals test evidence dat er geen regressie is opgetreden, tests gedaan op nieuwe functionaliteit, is er een security check gedaan op nieuwe code (best belangrijk bij banken), etc.

Hebben die mensen bijzondere superkrachten waardoor zij betere code schrijven dan anderen?

Nee natuurlijk niet, daar gaat het in bovenstaande situatie ook niet om. Mensen die toestemming kunnen geven schrijven niet eens code, ze zijn er simpelweg om sanity check uit te voeren op het process. Zijn alle stappen doorlopen die minimaal nodig zijn om een product naar productie te brengen. En dan doel ik echt niet op ouderwets waterval maar simpelweg of het team dat iets naar productie wil brengen kan laten zien dat ze de basis zaken op orde hebben betreffende QA en het risico acceptabel is.

Dan wordt elke fout ook meteen opgelost door de mensen die hem zelf gemaakt hebben.

Het één sluit het ander niet uit. Een op kwaliteit ingerichte organisatie zal inderdaad de flexibiliteit bezitten om als er problemen optreden op productie dit ook snel op te pakken. Zaken zoals het aanpassen van een foutieve waarde in een configuratie zal inderdaad minder stappen met zich meenemen dan wat ik hierboven beschreef voor het deployen van een nieuwe applicatie of nieuwe functionaliteit in een applicatie.

[Tarquin]

Er zit toch vaak wel iets meer nuance op het pushen naar productie, zeker bij dit soort organisaties. Je noemt het wel tussen neus en lippen door maar gaat er stiekem een beetje aan voorbij.

Ja, die nuance is er: je hebt controles en procedures en rechten.
De essentie is dat die allemaal geautomatiseerd zijn en niet meer door een 'releasemanager' worden afgetekend.
Ze gebeuren echt nog wel maar automatisch en razendsnel.
Dat maakt in de praktijk dat iedereen effectief echt wel naar productie kan pushen, maar als je dat snel zegt klinkt het ongecontroleerd en onzorgvuldig - en dat is het zeker niet.

[Creesch]

De essentie is dat die allemaal geautomatiseerd zijn en niet meer door een 'releasemanager' worden afgetekend.

Wellicht niet door een releasemanager op die manier maar geheel geautomatiseerd hoeft het zeker niet te zijn. Afhankelijk van de omvang van de change zal vaak minimaal een PO handmatig moeten goedkeuren, iemand van een ander team, in sommige gevallen via een PO ook nog door een CIO, etc.
Dit kan nog steeds vrij snel gaan, zeker in een mooi ingerichte ci/cd omgeving waar het merendeel van de QA processen zijn geautomatiseerd. Maar er zit zeker één of meerdere handmatige stappen op om te garanderen dat het QA proces ook echt is doorlopen.

Wat je omschrijft bestaat wel binnen de software ontwikkeling, maar is niet de absolute waarheid. Zeker niet als het gaat om banken. Sterker nog, Nederlandse banken zijn vrij progressief qua software ontwikkeling, op het moment dat je over de grens te maken krijgt met ontwikkel teams van banken kom je de releasemanager alsnog tegen

[Mangu429]

Oplossing: Geef iedereen die speciale rechten om naar productie te brengen. Dan wordt elke fout ook meteen opgelost door de mensen die hem zelf gemaakt hebben. Gaat echt een stuk sneller dan overal procedures en controles in te bouwen.

Niet iedereen die een fout maakt kan het zelf oplossen.

Fouten kunnen ook enkel maar opgelost worden als ze bekend zijn. Zoals het er nu naar uitziet is de oorzaak van de storing onbekend. daar sta je dan met je honderden personen.

[casberrypi]

Een onbekende oorzaak is voor mij onbegrijpelijk. Dan mist er monitoring en logging. Zeker bij complexe architectuur moet direct duidelijk kunnen zijn waarom een onderdeel faalt.

Natuurlijk is het zo dat op een gegeven moment monitoring kan aangeven dat álles mis is, en onduidelijk wordt of iets de oorzaak van de storing is, of een gevolg ervan. Operations engineers moeten de samenhang van de architectuur kennen en dit soort data kunnen interpreteren.

[casberrypi]

Eens, en maak dan direct reverten naar een vorige revisie heel makkelijk.

Bijvoorbeeld in het geval dat je systeem microservices in een container gebruikt de vorige last-known-good container gewoon door te laten draaien, maar traffic intussen naar een nieuwe container te sturen.

3 uur is niet 'meteen opgelost' genoeg.

[Verwijderd]

Toch niet, dat is niet hoe het werkt, weet niet waar jij die informatie vandaan haalt, maar hij klopt in ieder geval niet.

[Creesch]

Bij websites waar meerdere teams aan werken is dat heel goed mogelijk hoor.
Omdat individuele teams vaak aan een blokje functionaliteit werken en daarbij niet perse oog hebben voor de integratie in de rest van de website. Vaak zijn er wel standaarden qua UI elementen, kleuren, etc maar hoe er invulling gegeven wordt aan de UX kan dan weer verschillen per team.

Nu kan je stellen dat dit niet direct met CD te maken heeft maar meer met agile werken. Maar met CD is er vaak een focus op het automatiseren van testen waarbij het wederom gaat om de technische functionaliteit en niet zozeer de integratie in de rest van de website.

[Arendax]

Dan ligt het dus aan het ontbreken van een ontwerp en/of het ontbreken van afspraken tussen teams.

[Creesch]

Of wellicht is het niet zwart wit en draagt CD daadwerkelijk bij aan of stimuleert het soort ontwikkeling waardoor je eerder te maken krijgt met fragmentatie tussen wat diverse teams binnen een bedrijf
ontwikkelen.

[k0enf0rNL]

Je kan toch niet goedpraten dat een dienst 8 uur per maand down is. Dat is een SLA van 99% voor een bank die miljoenen klanten heeft.

[k0enf0rNL]

Ik bedoelde natuurlijk uptime geen SLA. Dat neemt niet weg dat ik het vreemd vind dat een bank die door miljoenen mensen gebruikt wordt een downtime mag hebben van 8 uur per maand. Ik zou mijn geld in ieder geval niet bij de Rabo neerzetten als hun servers zo brak zijn dat je soms uren niks kunt doen.

Maar misschien heb ik te hoge verwachtingen bij een bank die 1 miljard winst maakt per jaar. https://www.rabobank.com/...lanten%20en%20medewerkers

[La1974]

8 uur per maand? Heb je daar cijfers van?

[k0enf0rNL]

4 uur 2 weken geleden en 4 uur vandaag. Dat klinkt voor mij als 8 uur deze maand.

[La1974]

Dacht al dat dat je reactie zou zijn. Maar er is een groot verschil tussen 8 uur deze maand en 8 uur per maand.

Of zeg jij ook dat een bedrijf als Facebook dat vele, vele miljarden meer winst maakt dan Rabobank er 5 uur per maand uit ligt?

En trouwens, de storing bij Rabobank van twee weken geleden was vorige maand. Dus toch 4 uur per maand? Minder dan Facebook dat veel meer winst maakt.

Je snapt, onzin. Maar dat is het risico met het noemen van statistieken die niet kloppen. Een veel gemaakte fout.

[Reactie gewijzigd door La1974 op 23 juli 2024 05:24]

[Travelan]

Sowieso wordt er iets in het proces aangepast om de kans kleiner te maken. Er is ergens een fout ingeslopen die moet worden voorkomen. Als ze dat niet doen, dan is het dom. Eigenlijk is dit gewoon een dure stresstest van je proces. Voor de prijs van een dag boze klanten kun je de zwakste schakel in je proces bloot leggen ;-)

[FreezeXJ]

Uiteraard... De truc is vooral dat je dezelfde (soort) fout niet 2x maakt. De voorraad fouten is helaas onuitputtelijk, maar je kunt de meest voorkomende goed bestrijden.

[Tarquin]

Dan ben ik wel geïnteresseerd in hoe jij denkt dat het werkt!

[EmbarrassedBit]

Dat is allemaal ongetwijfeld waar, maar tegelijk obscureren dergelijke formele verklaringen dat het verband tussen wat er materieel geproduceerd wordt (hetgeen waar al die code voor moet dienen) en de functionaliteitsopbrengst voor van de eindgebruiker steeds zwakker wordt. Karl Marx stelde reeds dat economische reproductie (in dit geval het operationeel houden van de digitale systemen waar iedereen van afhankelijk is) afhankelijk is van kapitaalsaccumulatie. De structurele crises van kapitaalsaccumulatie die inherent zijn aan kapitalisme resulteren dan in structurele crises van economische reproductie. Naarmate de kosten (tijdelijke voorsprong op de criminelen behouden) sneller stijgen dan de winsten (wat mensen bereid zijn te betalen voor bankdiensten) wordt er meer en meer ingezet op stochastische QA als een soort doping, die evenwel niets verandert aan het feit dat de absolute last van een storing steeds groter wordt in een samenleving die meer en meer afhankelijk is van het betrouwbaar functioneren van digitale systemen.

Op termijn zal dit leiden tot een meer dirigistische rol van de overheid in de ontwikkeling van digitale systemen, als antwoord op de eis van de burger die zich afvraagt of altijd wel de meest efficiente keuzes gemaakt werden en worden. Ontwikkelaars en tech-ideologen zullen dan zoals altijd heel smalend doen over "boomer-politici en beta-wetenschappers die het software-ontwikkelingsproces niet begrijpen". Daar zit een kern van waarheid in, maar is i.i.g. vooral ingegeven door het feit dat men zichzelf te brilliant acht om externe inspraak in de eigen technologische (i.e. politieke) keuzes te aanvaarden.

Dat is analoog aan het hele debat over encryptie. "Domme boomers en huisvrouwen begrijpen niet dat als je encryptie verzwakt om de criminelen te vatten, je meteen encryptie voor iedereen verzwakt... wij begrijpen tenminste hoe het werkt, dus laat het aan ons over en hou je er buiten!" Ook dat is waar, maar zelfs als ze het zouden begrijpen, zouden we evolueren naar een situatie waarin de meerderheid bereid is om encryptie te verzwakken om bepaalde vormen van zware criminaliteit te beheersen. De doorsnee burger schat namelijk de marginale maatschappelijke opbrengst van integere encryptie lager in dan het belang van het effectief kunnen beheersen van bepaalde vormen van zware criminaliteit. Als de maatschappij dan terug moet naar de situatie van voor de jaren '90... wel, je zou er van versteld staan hoeveel mensen dat een aanvaardbare prijs vinden.

[Reactie gewijzigd door EmbarrassedBit op 23 juli 2024 05:24]

[Keypunchie]

Heb je met je hoofd op het woordenboek geslapen vannacht?

Ik heb al 3x je bericht gelezen, maar door de dure woorden ‘obscureer’ je volkomen wat je wilt zeggen.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 05:24]

[casberrypi]

Complex product, complex problems.

[Kimbo72]

Ik ben geen bank waar het steeds fout gaat.
Mensen zijn niet van mijn afhankelijk.

[MrMarcie]

Helaas betaal ik een stuk meer. Maar eens overstappen naar een andere bank.

[Kimbo72]

Zit je zeker bij de ING?

[MrMarcie]

Nee, Rabo. ING heb ik jaar of 10 geleden al afscheid van genomen.

[polord1]

Mwoea, de banken verschillen niet zoveel van elkaar qua klandizie, heb gezegd dat ik dat voor de depositogarantiestelsel deed..

[TheVivaldi]

En winkels en dienstverleners (bijv. busvervoerders) ook: “We accepteren geen contant geld.”

[beerse]

Vorig jaar, het begin van de covid-19 periode zag je dat steeds vaker.
Tegenwoordig zie ik op veel plaatsen juist weer de vraag om contant te betalen, met name in de ambulante handel (markt, oliebollenkraam en dergelijke).
Detail: zakelijk betaal je voor pin vaak per-transactie wat vooral bij kleine bedragen in de papieren kan gaan lopen.

[AceAceAce]

omzet met pinnen is zo lastig om buiten de boeken te houden he...
als ik een oliebollenkraam tegenkom die eist dat ik contant moet betalen dan koop ik daar niet. Zelfde met taxichauffeurs

[beerse]

Op 1 euro voor een oliebol 15 cent transactie kosten afrekenen.... dan snap ik het wel. Zelfs al is het maar 7 cent transactie kosten, dan vind ik dat nog veel.

[AceAceAce]

In mijn voorbeeld van de oliebollemkraam werd 50ct gevraagd op een transactie van een paar euro, terwijl het maar zoiets kost als wat jij noemt.

Maar men vergeet dat cash ook niet gratis is. Sterker nog, duurder:

Contante betalingen kosten ook geld
Als een pintransactie geld kost, dan is het logisch toch, dat een winkelier dat doorberekent? @stijn_meijer ziet het anders: 'Het lijkt me logischer om bij te moeten betalen voor contant afrekenen. Dat kost immers meer tijd en is risicovoller.'

Berend Jan Beugel van de Betaalvereniging Nederland denkt daar ook zo over. Volgens hem kost een contante betaling de winkelier zelfs meer. 25 cent, schat hij. Je hebt met contante betalingen bijvoorbeeld te maken met waardetransport om het geld veilig te vervoeren, en een verzekering tegen diefstal. Toch wordt voor contante betalingen geen extra geld gerekend. Volgens Beugel doordat het deels verdekte kosten zijn. Zo betaalt een winkelier niet voor het tellen en sorteren aan het eind van de dag, maar het kost wel tijd.

Uit 2017:
https://radar.avrotros.nl...g-mag-dat-ueberhaupt-nog/

[La1974]

Dat de online omgeving niet werkt wil niet zeggen dat je niet kan betalen in de winkel.

[mk1992]

Betalingsverkeer komt door dit soort storingen niet in het geding, gelukkig.

[Ganymedus]

Als er een kans is op een afbreukrisico door een storing bij een externe partij is het altijd verstandig om hier maatregelen in te treffen. Of de kosten van het afbreukrisico opwegen tegen de maatregelen is dan de volgende vraag.

Als particulier zie ik weinig redenen om redundantie in te bouwen op mijn mobiel- / internetbankieren. Ik kan prima enkele dagen zonder. Uiteindelijk zijn voor mij de essentiële (brandstof, voedsel) (ook) kosten te betalen met een pinpas of cash, de energierekening etc. gaan geautomatiseerd. Als die door een storing enkele dagen later plaatsvinden zit ik nog steeds binnen het betaaltermijn.
Binnen een bedrijf is dat wellicht anders, alleen dat hangt sterk af van de business waar je in zit.

Kun je mij (wellicht 'ons') meenemen in welke noodzaak jij ziet voor redundantie?

/edit: wat typo's verwijderd

[Reactie gewijzigd door Ganymedus op 23 juli 2024 05:24]

[Grrrrrene]

Maar dan moet je je geld ook over die banken verdelen, want anders kun je nog niks. Ik vind het bovendien wat overdreven. Je kunt nu even een paar minuten/uren niks, maar morgen werkt alles vast wel weer. Wat moet jij vandaag betalen, wat echt vandaag betaald moet worden omdat het morgen te laat is? En had je dat dan niet gisteren al kunnen agenderen, zodat het er vandaag gewoon uit gaat?

[watercoolertje]

Als je zo last minute iets moet doen waar je zo afhankelijk van bent heb je je zaken zelf gewoon niet op orde, met een enkele uitzondering (auto kopen via MP en dan niet kunnen overschrijven op locatie door storing oid).

Ik ga er iig niet een extra rekening (laat staan 2) voor openen, kan mijn geld wel beter besteden...

[Reactie gewijzigd door watercoolertje op 23 juli 2024 05:24]

[Mangu429]

In this day and age, is het wel echt nodig om bij 2 of 3 banken te zitten zodat je de kans verkleint dat je financieel niks kan als er storingen zijn.

Tot er een landelijke storing in het PIN systeem komt die alles treft.

[gabba25]

De tip was naar Tweakers

[JDx]

Tja ik heb wel meerdere rekeningen waar het op kan, hij kan alleen met Rabobank betalen.

[gorgi_19]

Buiten dat valt het meer op als iets niet werkt, dan als iets wel werkt.

Als je voor jezelf eens nagaat hoeveel voorzieningen en diensten gewoon blijven draaien zonder dat je er bewust van bent. Alleen als iets niet werkt, wordt het in de media genoemd.

[Mangu429]

Dan nog kun je een toename in storingen waarnemen.

[Creesch]

Dan valt er ook weinig zinnigs over te zeggen natuurlijk, wellicht is er geen toename dan is er ook geen oorzaak. Daarnaast is het puur speculeren, het kan ook zijn dat het aantal storingen per dienst niet toeneemt maar simpelweg omdat het aantal diensten groeit waar we gebruik van maken er wel een toename is van het aantal storingen die we zelf ervaren.

[jqv]

Dat is wat jou opvalt.
Maar is dat dan wel zo.

Zou een interessant onderzoek zijn of jouw gevoel echt wel klopt.