ING: grote storing is voorbij

De Nederlandse ING Bank claimt dat de grote storing van woensdag voorbij is. De storing duurde vanaf het einde van de ochtend tot 's avonds laat. De bank biedt excuses aan voor de lange storing en belooft niet nader uitgelegde maatregelen.

Statuspagina ING: storing

Het ging om een storing waarbij de diverse interne systemen van de bank problemen hadden met de uitwisseling van gegevens. Pinnen en geld opnemen gingen wel, maar inloggen bij mobiel- of internetbankieren ging niet en geld overmaken was ook niet mogelijk. Het is zeldzaam dat een storing bij mobiel- of internetbankieren zo lang duurt.

ING zegt dat het 'verhoogde dijkbewaking' heeft naar aanleiding van de storing en dat het dus zijn systemen met extra aandacht in de gaten houdt. De bank belooft 'daar waar mogelijk' maatregelen te nemen om een dergelijke storing in de toekomst te voorkomen. De statuspagina geeft nog steeds problemen weer met inloggen op de apps en op internetbankieren.

Reacties (158)

[Don Corleone]

Mensen die hier (en in het vorige nieuwsitem hierover) heel negatief reageren en roepen dat het belachelijk is enzo, zijn waarschijnlijk nog nooit zo'n grote verstoring betrokken geweest, laat staan dat ze een hele nacht hebben doorgehaald.
Ik kan jullie vertellen dat dit zenuwslopend en vermoeiend is. Ik ben incident coördinator geweest tijdens dit soort verstoringen en ik weet uit ervaring dat hier met man en macht aan wordt gewerkt. Daarnaast schijnen jullie allemaal te weten hoe je zo'n grote verstoring oplost, maar laat ik zeggen dat je echt geen idee hebt.
Vaak is het een raadsel hoe de verstoring is ontstaan. En in plaats van direct allerlei oplossingen te gaan proberen, met het risico het erger te maken, is vaak een goede situatie beoordeling het eerste wat je doet. Dit kost in het begin veel tijd, maar de winst pak je later wanneer je de oorzaak te pakken hebt.

Dit gezegd hebbende, vind ik ook dat ING gewoon de boel op orde moet hebben en er alles aan moet doen om grote verstoringen e voorkomen. Dit is geen oordeel, want ik ken de organisatie niet, maar een constatering.

[rutgervdijk]

Als support richting de reactie van @Don Corleone: Ik werk op dit moment met de teams bij een van die andere drie grote banken, onderdeel online banking/ authorisatie & authenticatie. Oftewel het deel dat als het stuk is, het voor iedereen (zakelijk/prive) grote impact heeft.

En het is, heel begrijpelijk, dat voor heel veel mensen buiten een bank, het niet te bevatten is hoe complex dergelijke systemen zijn. En dat hoeft ook niet. Maar toch even wat achtergrond: de mensen die dit soort diensten en applicaties beheren, onderhouden en aan verder ontwikkelen, zijn bijzonder kundig, hebben écht jaren ervaring en hebben een zeer hoog gevoel van verantwoordelijkheid. En die staan dus niet gezellig koffie te leuten als dit soort verstoringen optreden.

Het is inderdaad zoals Don Corleone zei, keihard werken om het probleem nú te fixen en het in het vervolg niet meer voor te laten komen. En dat laatste gebeurt dus ook. Vergeet ook niet dat de druk enorm hoog is gezien de regels en controle vanuit de De Nederlandsche Bank bij dit soort situaties.

Last but not least, ondanks de complexiteit, impact en omvang doen dit soort teams zowel het onderhoud van de huidige systemen als nieuwbouw en verbeteringen. Best een klus dus....

[Anoniem: 1802422]

Ik geloof meteen dat het een zeer complexe aangelegenheid is. Wat niet wegneemt dat verstoringen niet zelden achteraf ontstaan blijken te zijn door bv. domme fouten bij het implementeren van (tevoren onvoldoende geteste) updates of menselijke fouten waarvan je je afvraagt hoe dat toch kan.
Daarbij komt dat ik als klant meer begrip voor een dergelijke situatie zou kunnen hebben als er wat meer diepgaand wordt gecommuniceerd over wat er speelt. Bedrijven komen evenwel vrijwel nooit verder dat de standaard clichés zoals "wat vervelend" (deze wekt de meeste braakneigingen op) en "excuses voor het ongemak" (ongetwijfeld goed bedoeld, echter een no-brainer waar je niks aan hebt).

[bmwgozer]

Ik denk ook niet dat iets is om in IT te zitten en trots moeten zijn dat iets complex zijn. Maar dat zal wel aan mijn minimale IT kennis liggen

[ErikJanVens]

Wij hanteren daar de BOB-methode voor. Dat is het splitsen van besluitvorming in 3 fasen: beeldvorming, oordeelsvorming en dan pas besluitvorming. Niet meteen rennen maar op een goede en toch snelle manier tot gezamenlijke besluiten komen. Overigens vullen we die altijd aan met de C van communicatie.

[Don Corleone]

Die kende ik niet. Wij gebruiken Kepner Tregoe. KT is gericht op problem solving volgens een vaststaand proces.

KT begint met een Situatie Beoordeling. Hierin stel je eerst vast wat de afwijking is (wat is er feitelijk aan de hand?) en ga je inventariseren wat er aandacht nodig heeft. Deze aandachtspunten ga je vervolgens prioriteren en acties aan hangen. Zo kan het bijvoorbeeld zijn dat het onderzoeken van de oorzaak niet bovenaan staat, maar bijvoorbeeld een tijdelijke workaround. Dit kan overigens ook parallel lopen.
Voor het achterhalen van de grondoorzaak heb je het proces wat Probleem Analyse heet. Hierin beschrijf je het probleem en formuleer je mogelijke oorzaken. Met behulp van een matrix samen waarin je o.a. vastlegt waar afwijking zich voordoet (geografisch en waar in het proces), wat de omvang is en wanneer het is ontstaan, toets je hypotheses over de mogelijke oorzaak.
Daarnaast biedt het ook processen die je helpen met besluitvorming en potentiële problemen.

Sorry dat doordraaf, niet omdat ik aandelen heb of zo, maar omdat ik hier altijd super enthousiast van wordt. Het werkt echt heel goed. Ik heb namelijk nog nooit meegemaakt dat we een storing niet konden oplossen met behulp kan Kepner Tregoe Problem solving.
Als je meer hierover wilt weten stuur me maar een dm.

[rescue]

Kepner Tregoe fan hier. Dwingt je ook om inschatting te maken over de gevolgen van je handelen. Maar meest waardevol is het vastleggen van wat allemaal niet de oorzaak is. Scheelt veel tijd.

Maar behalve de methodiek is het belangrijkste toch gewoon slimme jongens en meisjes die end-to-end snappen hoe een oplossing werkt.

Bij ING zal dat lastig zijn, maar de huidige eiland automatisering help niet als er - volgens de laatste berichten - iets mis gaat met de communicatie tussen systemen.

Vraag me af hoe ze het probleem uiteindelijk gevonden hebben.

De avondploeg had het schijnbaar snel door :-)

[Don Corleone]

Het vastleggen van de "is niet" is vooral bedoeld om de mogelijke oorzaken te testen he? Je stelt dan de vraag: "Als ....de oorzaak is, hoe verklaar je dan het .... wel is en .... niet."

Naast het proces vraag ik altijd aan het team om samen een "praatplaat" te maken, zodat we allemaal weten waar we het over hebben. Vaak is dit al een heel goede stap in de richting van een oplossing, omdat mensen opeens (meer) gaan samenwerken.

[ErikJanVens]

Uitgebreid verhaal. Belangrijk dat je een methode voor probleemanalyse hebt waarin je het probleem loskoppelt van de beslissing. Dat betaalt zich terug als het probleem niet meteen te fixen is.

[Don Corleone]

Exact, dat is de basis.

[anandus]

Sorry dat doordraaf

Geen probleem, ik (en ook vast anderen) vond het interessant om te lezen

[Don Corleone]

Dank je!

[Tivoler]

Als je IT-ers dat vermogen niet hebben heb je gewoon een verkeerd team en overhead aan de door jou genoemde protocollen.

[Don Corleone]

Maar daar is ook aan gedacht.

Waar ik werk krijgt elke medewerker (dus ook teamleiders, managers en directeuren) een basis training Kepner Tregoe, zodat iedereen dezelfde taal spreekt. Je voorkomt hiermee dat techneuten direct in de 'oplosstand' schieten en tevens dat manager in hun rug staan te hijgen om een oplossing te forceren.
Daarnaast hebben we een groepje facilitators (waaronder ik) die weten hoe ze een groep techneuten hierin moeten begeleiden. Dit doen we alleen bij heel grote verstoring overigens.

[Tivoler]

Voor mij geen gekke termen daarvoor; gewoon nuchter communiceren met terugkoppeing en iemand corrigeren als je ziet dat het mis dreigt te gaan doordat ze te hard gaan.

[vdws]

...en die C (communicatie) laten doen door iemand die niet concreet werkt aan de oplossing maar wel snapt wat er wanneer gecommuniceerd moet worden.

[ErikJanVens]

Dat spreekt vanzelf.

[the_stickie]

Dat lijkt vanzelfsprekend, maar in teveel omgevingen moet dev en infra nog steeds asap en liever nu de boel oplossen terwijl er een paar managers in hun nek staan te hijgen en ze ook nog geacht worden om de x tijd een statusupdate uit te schrijven en uit te sturen.
Allemaal niet efficiënt, maar al te vaak realiteit, zeker in bedrijven waar it niet gezien wordt als prioriteit

[jp]

Was dat maar zo :-)

[ErikJanVens]

In theorie is er geen verschil tussen theorie en praktijk; in de praktijk wél!
Gelukkig kunnen we oefenen met deze methode en hebben we 'm nog nooit in het echt hoeven toepassen.

[coen254]

Dat er hard gewerkt word aan een oplossing neemt niet weg dat het belachelijk is dat er een outage van een dag is, en dat outages uberhaupt vaak voorkomen.

[CPV]

Outages zijn wel degelijk flink te verminderen, maar dan kost bankieren 10 x zoveel. En dan begint het volk daar weer over te klagen. Bedrijven maken dus een afweging waar ze balans leggen.

[911GT2]

Dat is niet helemaal waar. Vaak is een outage een onderdeel van een cultuur. Als men technical debt op technical debt blijft stapelen omdat men graag wil dat deliverables gehaald worden dan is dat vrij eenvoudig en vrij goedkoop te ondervangen. Probleem is dat je dat op management oplost en niet technisch. En dan moet je als manager wel het inzicht hebben en de mogelijkheden hebben om dat te doen.

Vaak moet er onder druk van aandeelhouders snelle winst geboekt worden. Dat dat verderop in de lijn tot problemen lijdt maakt hen niet uit. Die hebben tegen die tijd de winst gepakt en zijn verder gegaan.

[NitSuA]

Mijn ervaring (en perceptie) is dat de ING de meest innovatieve bank in Nederland is op het gebied van ICT, apps, functionlaiteiten etc. Er wordt veel ontwikkeld, en dan gaat er wel eens wat stuk. Maar nog steeds heb ik liever een bank die als eerste bij Apple Pay etc was aangesloten, dan een bank die 1 a 2 jaar de kat uit de boom kijkt en vervolgens heel schoorvoetend een nieuwe functionlaitiet doorvoerd.

Tuurlijk zal ook ING er alles aan doen om storingen te voorkomen, maar waar gehakt wordt vallen spaanders. Vergeet vooral ook niet het voordeel dat wordt gebracht door de hoge mate van innoveren binnen de ING. Het staat iedereen vrij om de bank te kiezen die bij hem/haar past.

[Reactie gewijzigd door NitSuA op 22 juli 2024 17:37]

[CorbataGames]

Ze lopen voor op wat ze aanbieden, maar vaak heb ik het idee dat alles daar nogal houtje-touwtje aan elkaar hangt. Ook van verhalen die ik van medewerkers gehoord heb...

[coen254]

We weten helemaal niet waar deze outage aan ligt. Misschien heeft de stagair te hard tegen de server geschopt of zo... Daarnaast heeft ING hier veel meer last van dan andere banken en zo veel meer kosten die niet hoor

[Don Corleone]

Dat ben ik op zich niet met je oneens. We hebben echter geen inside information, dus kunnen we er eigenlijk niet over oordelen.

[MrManuel]

Don, waar het mij als klant van ING om gaat is dat er soms inderdaad een storing kan zijn. Kan gebeuren.

Echter zijn er de afgelopen maanden echt met flinke regelmaat storingen. Ondertussen ben ik het vertrouwen in ieder geval kwijt.

[..bennie]

Herkenbaar. Aan de andere zijde ben ik ook bekend met de stress die grote online storingen met zich mee brengen. Uiteraard. En ja die kunnen voorkomen. Maar het is wel zaak om daar goed over te communiceren en al helemaal niet deze te ontkennen. Vooral de vele storinkjes die door ING niet werden erkend hebben mij vorige maand doen besluiten om de boel definitief naar KNAB te verhuizen. Ik moet eerlijk bekennen dat ik gisteren wel even blij werd dat ik dat besluit genomen had.

[djiwie]

Ik heb zelf grote verstoringen meegemaakt (en nachten doorgehaald) maar ik vind nog steeds belachelijk dat een storing met dergelijke grote impact zo lang heeft geduurd om op te lossen met minimale communicatie vanuit ING.

Ja, helemaal met je eens dat het zenuwslopend is en dat je moet buffelen. Maar het feit dat er hard gewerkt wordt om een storing op te lossen doet niets af aan het feit dat de impact van deze storing veel te groot was. Daaraan gekoppeld dat ING al jaren problemen heeft met de beschikbaarheid van systemen (de iDeal norm is al tijden niet gehaald) doet me vermoeden dat ING structurele problemen heeft die niet opgelost worden. Wat de aard van die problemen is, is mij een raadsel omdat ING er nauwelijks over communiceert. (En uitleggen wat er stuk was hoeft niet meteen een veiligheidsrisico te zijn.)

[Sebben]

Ik denk dat we gedoemd zijn tot meer van dit soort problemen. Bij meerdere belangrijke instanties overigens. Er wordt jaaaren doorgebouwd op dezelfde infrastructuur, personeel wordt gerouleerd, documentatie verouderd, en op een gegeven moment staan er gewoon machines te draaien waarvan niemand weet wat ze doen.

Ik heb iets te recentelijk nog uit betrouwbare bron vernomen dat er bij "een bank" systemen in de kelder staan die nog op ponskaarten draaien waarvan niemand hem kon vertellen waarvoor ze precies dienen, maar dat als die uit gezet worden, dat alles stuk gaat.

[Tjidde]

Ik ben het met je eens.

Het nadeel is, ook al loopt bij de ING alles via automatische testen en nog handmatige controle voordat deze op productie staan.

Echter kan 1 klein ding een halve ketting reactie veroorzaken waardoor je niet precies weet waar het probleem zit en dan moet men oprecht opzoek naar een naald in een hooiberg.

Het is nog niet zo heel lang geleden dat als je iets van bankieren wou doen dat je naar de bank moest of een papiertje op de bus moest doen.

Ik denk wij als mensheid te gewend zijn geraakt aan het moet maar altijd werken en ik moet op elke seconde van de dag mijn bankzaken kunnen doen. Waarom? Zou het mijn god niet weten.

Als je iets echt tijdens een outage moet doen (zeggende dat die een dag duurt) wat niet tot morgen kan wachten, heb je een luxe probleem. Enige waarvoor het echt vervelend is dat het niet zou werken is mensen die onderling iets aan elkaar verkopen.

Als jij een rekening krijgt van een bedrijf en je komt de laatste dag er achter shit nog niet betaald. En je belt het bedrijf op van hoi ik wou de rekening betalen maar de bank is stuk, mag het morgen ook? Dat er maar verdacht weinig bedrijven zullen zeggen nee of met een reactie komen dat komen er wel kosten boven op.


Het enige wat ik wel vervelend vind maar dat is niet alleen bij ING is hun status pagina. Ik heb liever iets meer details in de status(en wat overzichtelijker). De mensen die een status pagina opzoeken hebben toch al iets meer kennis van zaken.

[Henno Keers]

Wij hebben een paar weken geleden een presentatie gehad van de twee Major incident managers van ING. Procesmatig hebben ze het goed voor elkaar, wij kijken sterk naar hun proces voor inrichting van ons MIM proces.
Wat wel opviel is dat ze geen standaard SB vastlegging en methodiek hebben voor PA (of die niet met ons wilden delen, ik heb ze er wel naar gevraagd), wat met zoveel IT'ers volgens kan leiden tot vertragingen doordat er niet dezelfde taal gesproken wordt en de betrokken personen aannames doen en in trial / error / adhoc oplossingen vervallen.
Er moet helderheid zijn over:
Wat is een afwijking?
Wat is de normaal?
Moeten we wel iets oplossen (3x Ja = PA) of moeten we een besluit nemen?
Hoe wordt data vastgelegd?
Wat? / Waar? / Wanneer? / Omvang?

[Scaptors]

Eens!

[redtails]

Als je een bankrekeningnummer "mee kon nemen" naar een andere bank, zoals bij een mobiele telefoonnummer, dan zou er een stuk meer concurrentie zijn. Concurrentie is altijd goed en houdt bedrijven scherp en eerlijk. Zonder concurrentie worden ondernemers lui en makkelijk.

Dat de naam en codes van de bank verwerkt zitten in het IBAN maakt dit (oppervlakkig gezien) lastig. Echter, gezien dat het letterlijk een nummer is, is er geen technische reden waarom dit niet zou kunnen.

[William_H]

Dat is ook een typisch Nederlands probleem. Duitse en Belgische hebben gewoon een IBAN opbouw als volgt DE XXXX XXXX XXXX XXXX of BE XXXX XXXX XXXX XXXX. Daar wordt dus geen banknaam in verwerkt. Die kun je dus perfect porteren. Maar Nederland moet het weer anders doen. Met als klap op de vuurpijl, de ING, die z'n omzetting naar het IBAN systeem opgelost heeft met nullen voor het oude Postbank nummer te zetten...

[redtails]

In 't buitenland zijn de eerste paar cijfers de banknummers. De letters in een IBAN rekening worden intern omgezet naar cijfers waarbij A=10 Z=35. Dus INGB = 18 23 16 11. Waarom letters in NL worden gebruikt en niet in andere landen weet ik niet.

[pe1opg]

Het kan wel maar de banken willen niet. Het systeem is er zelfs, waarschijnlijk heeft het alleen geen grote capaciteit.
Mijn vader had in de jaren 60-70-80 een abn en later een abnamro rekeningnummer 506940315 meen ik dat t was. Toen we in 1981 gingen verhuizen en een Hypotheek was geregeld bij de Rabobank heeft hij het bankrekeningnr. mee kunnen nemen en is het tot 2018 zo in gebruik gebleven.
De rekening is in 2018 opgeheven.
De ibancalculator zei dat het een abnamro rekening was, maar de iban was wel degelijk NLxxRABO0506940315
Conclusie: het kan dus wel, maar de banken hebben hier een heel mooi iets om klanten te behouden als ze zeggen dat het niet kan.

[Forte]

Als je IBAN meer als een 06-nummer gezien zou worden zou dat inderdaad best wel eens een mooie oplossing zijn. Heb een vrij simpele IBAN nummer nu en dat belemmert mij enigszins wel om te switchen naar een andere bank. Luxeproblemen

[108rogar]

Mwoa, de overstapservice werkt anders ook heel aardig hoor. Maar misschien voelt dat voor mensen toch een beetje eng.

[MrManuel]

Dat is wel iets waar ik inderdaad mijn twijfels zover bij hem nog gehad..

[SRI]

Ik denk dat een of meerdere teams van ING binnenkort een flinke post mortem gaan hebben. Maar wellicht niet vandaag want denk dat een aantal devs na gisteravond vandaag laat of niet werken.

[willieverhoef]

Als ze nu een minder lang vergaderen maar gewoon hun werk doen. Juist dat blaming zal niet zorgen voor een betere sfeer en zo ook kwaliteit. Gewoon een bonus voor iedere maand 99.99 up en inleveren 2 dagen bij 99.90 ..

[Loen]

Dan denk ik dat je niet door hebt wat het effect van een goed uitgevoerde (blameless) post mortem kan zijn.

Zie bijvoorbeeld https://www.atlassian.com...ment/postmortem/blameless voor meer info

[Reactie gewijzigd door Loen op 22 juli 2024 17:37]

[Kevinp]

Maar misschien moet dat ook naar buiten worden gecommuniceerd. Als je bij de best practices kijkt staat er simpel. Waar mensen werken worden fouten gemaakt.

Accepteer dat en ga door.

Als iedereen wat minder gehaast is wordt het veel beter. Want zeker de engineers die het op moeten lossen zullen erg hard gewerkt hebben gisteren. De managers mogelijk hard geschreeuwd.

[Loen]

Zeker, ik ben fan van bedrijven die, als er fouten gemaakt worden, daar open en eerlijk over communiceren. Zoals gitlab een jaar of 5 geleden een livestream had nadat ze een db per ongeluk gedropped hadden (of zoiets).
Ik kan me echter ook voorstellen dat een financiële instelling met al haar belangen (van veelal niet technische partijen) dat minder snel zal doen. Jammer.

Moet ik natuurlijk wel bij vermelden dat iedereen weet of kan zien hoe gitlab in elkaar zit als open source product... Hoe het ing landschap in elkaar zit zal een iets grotere confidentiality rating hebben

[Kevinp]

Je kan toch gewoon eerlijk zeggen, we hebben een update gemaakt om x mogelijk te maken (dat is niet eens nodig maar helpt wel) en daar is toch iets mis gegaan wat we niet verwacht hebben.

Terugdraaien kan niet vanwege afhankelijkheden die ook al een update hebben en wel werken.

We gaan de bug oplossen en zsm komen met een oplossing. Het kan wat langer duren want we willen deze uiteraard goed testen.

[fireboy]

Jaren geleden toen ik er nog werkte was het 1 grote brei aan diverse systemen die maar even met elkaar moesten babbelen. Elk onderdeel (sparen/beleggen/creditcards/hypotheken enz) had z'n eigen backend systemen. Daar zijn destijds meerdere pogingen ondernomen om het te stroomlijnen, echter die liepen keer op keer op een fiasco uit. Miljoenen aan hardware en software werd er domweg doorheen gejast. Allemaal een erfenis uit het verleden toen het nog aparte onderdelen waren. Geen idee of ze in de afgelopen 5 jaar het nu wel op orde hebben gekregen, maar als ik diverse onderdelen in de app of website bekijk vrees ik dat er nog weinig veranderd is.

[TwiekertBOB]

Interessant stukje om te lezen.

Dank je wel voor delen!

[Frame164]

Problemen worden alleen goed opgelost door met elkaar te communiceren, niet door domweg hard te werken. En dat met elkaar praten hoort bij het werk.

[cariolive23]

En dat met elkaar praten hoort bij het werk.

Toch is dat wat anders dan "vergaderen". Ik merk dat er bij Nederlandse bedrijven een cultuur is van vergaderen om het vergaderen: Staat in de agenda en dus gaan we vergaderen. Ook al hebben we niks te zeggen, dan roepen we gewoon maar wat. En omdat het een standaard lijkt te zijn van 50 minuten vergaderen, wordt die 50 minuten ook volgemaakt. Ook wanneer je na een kwartier echt wel klaar bent en er op dat moment gewoon niks meer is te melden. Neem maar eens een week lang alle vergaderingen op, laat iemand er notulen van maken met daarbij ook een tijdstempel, en je zult zien dat er bij 9 van de 10 vergaderingen in de 2e helft van de vergadering eigenlijk niks nieuws meer wordt gezegd. En zeker geen in dingen die voor de hele groep van belang zijn.

Met elkaar praten kun je ook 1-op-1 doen, of alleen met diegene die het aangaat. Dan kan de rest gewoon doorwerken.

[Arnout]

Dat zou je verwachten als buitenstaander. Echter is dit wel een patroon, deze storing van gister is geen uitzondering, en daaraan kan je afleiden dat het incident proces, tot aan post mortem / RCA, niet of niet goed functioneert.

Dat ze nu ook "verhoogde dijkbewaking" doen zegt ook genoeg, dat zouden ze namelijk elke dag moeten doen.

[RobbieB]

Reken maar dat ze hier niet met een simpel RCA formuliertje vanaf komen. Bij dit soort incidenten staat de DNB ‘op de stoep’ en mag je tot in detail uit gaan leggen wat er mis ging en hoe je dit gaat voorkomen. Incl deadlines wanneer je die maatregelen geïmplementeerd hebt.

[vdws]

Het punt is dat veel op papier bewezen wordt en hoe je e.e.a. procesmatig regelt, vastlegt etc.

Belangrijk, zeker voor een bank, maar wanneer de "shit hits the fan" kan je alles nog zo goed geborgd hebben (en nogmaals dat moet je ook doen) maar dan komt het toch neer op wat knappe koppen die de boel weer aan de praat krijgen. En hopelijk het budget krijgen om de lessons learned uit de post-mortem ook daadwerkelijk te implementeren voordat de waan van de dag weer de overhand krijgt.

[RobbieB]

Een belangrijk deel in een goede post mortem is dan ook niet alleen ‘hoe kunnen we dit voorkomen’, maar ook ‘hoe kunnen we het de volgende keer sneller herstellen’.

[JeroenH]

En, zo'n beetje het moeilijkste wat er is, "hoe gaan we de cultuurverandering die hiervoor nodig is bewerkstelligen"

[Kevinp]

Nutteloos die laatste vraag.

Ja als precies hetzelfde gebeurd misschien.

Maar logischer wijs is er of iets kapot gegaan qua hardware. Dan is voorkomen bv deze redundant uitvoeren.

Of er is een software update uitgevoerd welke je niet terug kon draaien omdat alles er aan vast ook al was geupdate.

Je kan zeggen dan doen we dat niet meer. Maar dat komt altijd een keer voor, en wordt het risico als laag ingeschat.

Waar mensen werken worden fouten gemaakt. En zolang dat geen fouten zijn die de core raken (zoals bv transacties kunnen doen die niet mogen) is er niet zoveel aan de hand en is het vooral onhandig.

[Arnout]

Ik vraag het me ten zeerste af. Ze komen ook weg met het structureel niet halen van de iDeal uptime.

[Reactie gewijzigd door Arnout op 22 juli 2024 17:37]

[dog4life]

Klopt, ik weet echter niet of er nog veel plek is voor de DNB als de ECB er ook al bovenop zit

[RobbieB]

ECB laat vrijwel alles bij lokale regulators liggen. Zeker bij NL dat als gidsland gezien wordt op het gebied van technologische ontwikkelingen in de financiële sector en de regulering daarop.

[localhost]

Vaak is bij dit soort systemen binnen enkele minuten bekend in welke hoek het probleem gezocht moet worden. Afhankelijk van wat de oorzaak was, kan "verhoogde dijkbewaking" bijvoorbeeld betekenen:

• Changes/wijzigingen die doorgevoerd zijn worden vandaag extra zorgvuldig gepland en op elkaar afgestemd. Tientallen/honderden changes per dag is heel normaal bij dit soort systemen. Bij een goed ontwerp heeft zo'n wijziging geen invloed, en meerdere changes tegelijkertijd ook niet. Wellicht dit keer wel. Of deels nog onverklaard.
• Onbekend probleem in technische apparatuur (vaak netwerk, maar ook b.v. storage) waardoor er extreme vertragingen optreden is of verbindingen worden verbroken. Dan ga je die apparatuur extra in de gaten houde.n

Op NPO Radio 1 werd net gemeld door een Topman (niet IT) van ING:
"Het was een storing tussen de Mobiele Server en de Web Server".

[Wannial]

Het probleem lag niet direct bij het inloggen zelf, mensen met tan codes konden namelijk zonder problemen inloggen en zaken doen.

Ik kon er overigens zelf weer in om 2325,daarvoor regelmatig geprobeerd en een half uur ervoor kreeg ik in de app nogsteeds dezelfde foutmelding.

[djwice]

@arnoudwokke zie boven. Bij mij ook met de digipass kon ik er gewoon in en iDeal betalingen doen. Het opvragen van de betaal- en spaarrekeningen transacties liep alleen niet goed. Bij iDeal kreeg ik tijdens de storing ook de rekening saldi bij MijnING niet.

Dus wellicht lag de koppeling met het appID koppelingssysteem en het transactie systeem er uit.

Dat zou kunnen impliceren dat er iets is misgegaan met het systeem dat API keys managed. Bijvoorbeeld een reset van bestaande keys bij de invoering van een sterker encryptie algoritme.

[Reactie gewijzigd door djwice op 22 juli 2024 17:37]

[vdws]

Of niet iets simpels als verlopen certificaten? Alleen dan is het wel gek dat het zo lang geduurd heeft. 1 feb. lijkt mij geen toeval.

[Marzman]

Of gewoon een 'nieuwe feature' die niet goed werkte https://www.bnr.nl/nieuws...g-om-fraude-tegen-te-gaan

[Reactie gewijzigd door Marzman op 22 juli 2024 17:37]

[gooos]

Dat is toch niet zo spannend. Dat is gewoon bij een ieder het getal veranderen tenzij die een andere waarde heeft ingevoerd met een einddatum na 1 februari / met geen einddatum.

Het zou me ronduit verbazen als dat de oorzaak geweest blijkt te zijn. Denk dat het meer toeval is dat deze storing en die wijziging op dezelfde dag vielen.

[meowmofo]

Het zijn juist de niet zo spannende 'o, dat doen we wel even' changes die de grootste storingen veroorzaken omdat er te makkelijk over nagedacht wordt. Ik zou de de mogelijkheid niet direct afschieten dat de 2 iets met elkaar vandoen hebben.

[gooos]

Eens, maar dit zou toch niet meer dan een eenvoudige update query mogen zijn op database niveau voor de app limiet-instelling. Dat lijkt me eenvoudig te testen op correcte werking in een test omgeving zonder dat het daarna tot problemen in productie zal leiden. Maar wellicht dat ik er helemaal naast zit hoor.

[djwice]

Release elke eerste woensdag van de maand.

[Reactie gewijzigd door djwice op 22 juli 2024 17:37]

[vdws]

Wie weet...

[Creesch]

Eh, zou kunnen, maar als ze agile werken dan heb je sprints van pak 'm beet twee weken en release je niet op een vaste datum. Neemt niet weg dat het met de deployment van e.a. te maken zou kunnen hebben.

[the_stickie]

In mijn ervaring betekent agile niet persé dat productie systemen geen vaste release cyclus hebben. Evengoed betekent het dat dev/validatie en/of staging wat dynamischer zijn (met sprints). In zo’n gevallen wordt vaak toch vastgehouden aan vaste cycli in productie, al was het maar omdat dat het planning voor andere teams, die ook ander werk hebben dan de releases te ondersteunen (denk dba, servicedesk/onsite, infra en zelfs sales) toch makkelijker maakt.
Zeker bij wat kritischer systemen hoeft niet elke change die van dev komt asap in productie - integendeel

[Creesch]

In mijn ervaring betekent agile niet persé dat productie systemen geen vaste release cyclus hebben

Ik bedoelde ook niet te zeggen dat het het een of het ander is. Sterker nog, het kan in een organisatie verschillen per afdeling en het type systemen. Dat laatste vooral op basis van hoe kritisch deze zijn voor de gehele keten en dus de impact van falen.

Soms heeft het juist de voorkeur als releases niet tegelijk worden gedaan, juist omdat het dan inzichtelijker is wanneer het fout gaat en dat het door een specifieke release komt.

En in sommige gevallen kan een organisatie werken met een omgekeerde kalender waar op specifieke dagen/momenten geen deployments gedaan mogen worden of alleen bij hoge uitzondering. Denk aan dagen waarvan bekend is dat er een hogere productie load is.

En ja, het kan nog steeds zo zijn dat de eerste woensdag van de maand het release moment is. Het is alleen geen gegeven dat dit zo is en daarmee de meest waarschijnlijke oorzaak.

[the_stickie]

Ik denk dat we exact hetzelfde bedoelen

[ZeroMinded]

Ja hoor, dat gebeurt in agile ook dmv “release trains”. Ik zie dat vaak in hele grote organisaties.

[fireboy]

Hihi, ooit in het verleden dat ik er nog werkte zag ik dat een https certificaat enkele dagen later zou verlopen....de paniek die er toen uitbrak toen ik dat melde bij functioneel beheer... hilarisch gewoon.

[kraanwagen]

Is het nog mogelijk met tan-codes in te loggen? Ik dacht dat uitgefaseerd was.

[Wannial]

Met zo'n ouderwets kastje waar je pas in moet. Wordt alleen enorm ontmoedigd.

[Reactie gewijzigd door Wannial op 22 juli 2024 17:37]

[Ramoncito]

Ik kan me anders heel goed herinneren dat ik een bericht kreeg dat mijn TAN-codes per die-en-die datum ongeldig zouden worden. Ik zou ze anders ook nog altijd hebben gehad.

[pbk]

Erg vervelend gisteren, maar kon vanochtend inderdaad weer gewoon inloggen.

[SpoekGTi]

Gisteren rond 22:30 kon ik overal al weer bij

[pbk]

Na 21:30 uur niet meer geprobeerd. Toen werkte het nog niet, dus het zal rond die tijd wel ergens zijn opgelost.

[Amito]

Was inderdaad rond dat tijdstip:
https://allestoringen.nl/storing/ing/

[tim687]

Wel mooi, dat als je op de klantenservice pagina op Storingen klikt, dat je wordt doorgestuurd naar de Klantenservice pagina.

Tijdens het schrijven van dit bericht kwam ik er achter dat heel ing.nl een access denied is.

[TwiekertBOB]

Ik kan er nu wel op...

Misschien is het nog niet helemaal stabiel, maar het is dus niet volledig down.

[tim687]

Na het verwijderen van cookies en website gegevens kon ik er wel op.

Vind het altijd zo verwonderlijk dat een website zo kapot kan gaan en het dan opgelost is als je cookies verwijderd

[Don Corleone]

De website is niet kapot, er zat waarschijnlijk nog iets van 'foute' informatie van de website in jouw cache.

[wooha]

Die access denied meldingen zag ik dinsdagavond grofweg 23:30 al, dus de avond voordat de storing begon. Dat was bij mijn laatste actie, het drukken op de uitlogknop, dus na een paar reloads heb ik dat verder genegeerd. Eerder heb ik dat niet meegemaakt volgens mijn actieve herinnering, maar ik gebruik Mijn ING ook maar een paar keer per maand.

Vanavond zag ik ook access denied meldingen. Die verdwenen in een private window, terwijl ze in het originele window nog aanhielden tot ik daar alle cookies had gewist.

Blijkbaar gaat er soms wat mis met een (browser) sessie, of een achterliggend systeem waaraan de sessie gekoppeld is.

[EeePC]

Ik probeerde net in te loggen in de app (iOS) maar kreeg een foutmelding. En nu moet ik me opnieuw aanmelden/activeren.… Lijkt dus zeker nog niet opgelost te zijn. Of hebben ze de toegang gereset?

[SRI]

Geen idee, voor mij werkt het dus het lijkt mij onlogisch. Heb je Android of iOS?

Heb je niet zelf de app opnieuw geïnstalleerd gisteren toen het niet werkte?

[Reactie gewijzigd door SRI op 22 juli 2024 17:37]

[EeePC]

Wellicht gister mislukte inlogpogingen op iPhone als foutief inlog gezien ofzo, en daarom een reset? Op de iPad werkt app ok.

[Pinkman]

Ik kan nog steeds niet inloggen in de app.

[Mancave54]

Ik kan nog steeds niet inloggen in de app.

Ging bij mij vanmorgen ook niet.
Toestel even opnieuw opstarten loste het probleem op.

[Pinkman]

Heb even een restart gedaan van mijn telefoon, nog steeds kan ik niet inloggen. (Via WiFi & abo)

"Niet gelukt, probeer het later opnieuw. Onze excuses voor het ongemak."

[xrfx]

Het lijkt erop alsof het bij ING wel vaker gebeurt dan bij anderen. Sinds een jaar of 5 zitten we bij twee banken en er nog geen moment spijt van gehad (behalve dan ons uitstapje naar Bunq). Ja, de kosten zijn dubbel, maar amper last van dit soort storingen. En uhm, Netflix en Spotify - en alle andere overbodige streaming abonnementen - zijn duurder dan wat ik voor mijn bankzaken betaal.

Je vraagt je inderdaad wel af waar dit aan kan hebben gelegen. Een vrij lange outage, waarbij je het idee hebt dat ze een disaster recovery ofzo hebben moeten doen. Dit is niet een verlopen certificaatje of deployment geweest gok ik.

[Frame164]

Je begint met een vage aanname,en maakt daar een conclusie van....

Misschien eerst eens de cijfers er bij pakken voordat je zo iets zegt. Ik heb geen idee of het vaker voorkomt dan elders.

PS: waarom zijn streaming abonnementen overbodig?

[xrfx]

Ik zeg toch dat het erop lijkt ;-) En dat er voldoende mensen aangeven (met cijfers en links in het vorige artikel) dat ze niet eens voldoen aan de minimale uptime die iDeal eist, terwijl andere banken dat wel doen. Had ik inderdaad wel even kunnen vermelden.

Streamingdiensten zijn een luxeproduct en je kan prima zonder leven - geen idee of het leven daardoor leuker wordt. Bankzaken daarentegen zijn een stuk essentiëler. Ik denk zelfs dat je bijna niet meer zonder kan als je ergens nog loon wil ontvangen (of je facturen betaald wil krijgen).

[Metian]

Wat ik me afvraag, zijn er dan geen back-up systemen die dit bij een storing kunnen overnemen (al dan niet met vertraging in het verkeer)?

Bijvoorbeeld een ziekenhuis met aggregaten die de stroomvoorziening tijdelijk kunnen herstellen tot de stroomstoring voorbij is. Misschien niet beste voorbeeld, maar het idee komt op hetzelfde neer. Snap best dat dit soort systemen lastiger zijn, maar toch het zou toch een deel schelen dan dat er een hele dag storing is.

[Paganstars]

Technisch gezien; Ja een fail-over is mogelijk. Maar ik vermoed dat er meer kapot was waardoor fail-over niet ging. Ik weet ook niet hoe de infra er technisch bij ING uit ziet, maar ik heb vaker met dit bijltje gehakt, waarbij kritische infra eruit knalde en fail-over niet ging doordat de loadbalancing het niet aan kon (cascading failures, altijd feest).

Ik ben bang dat ING flink aan de bak mag met dit feestje... Ik heb het te doen met hun IT

[digibaro]

Ja, een 2e bankrekening nemen bij een andere bank. Ik was in de "luxe" positie dat ik zo online kon betalen bij thuisbezorgd. ;-)

[CPV]

Oh, dus internetbankieren is dus al een eerste levensbehoefte. Sommigen verhongeren blijkbaar zonder.

[911GT2]

Ik snap dat het duur is, maar waarom heeft ING geen tweede productiesysteem wat blijft draaien op 'legacy' software totdat nieuwe implementaties bewezen zijn?