ING bestrijdt storingen door betaalsystemen te scheiden
ING gaat het internetbankiersysteem afscheiden van het systeem dat wordt gebruikt voor mobiel bankieren. De bank wil hiermee de risico's voor storingen beperken en zodoende zorgen dat de omgevingen elkaar niet nadelig beïnvloeden.
Chief information officer Ron van Kemenade vertelde in een conference call dat ING inmiddels al is begonnen met de noodzakelijke voorbereidingen om de twee omgevingen technisch te splitsen. Het gehele traject moet 'ergens de komende maanden' worden afgerond. "Hierna hebben klanten altijd de beschikking over één werkende omgeving. Als mobiel internetbankieren dan onverhoopt niet meer werkt, zal Mijning.nl nog wel werken."
De splitsing moet daardoor storingen beperken. De bank heeft in januari te kampen gehad met diverse storingen waardoor gedurende meerdere dagen klanten niet meer konden betalen via de site of de mobiele apps. Ook betalen bij webwinkels met iDeal was toen niet mogelijk voor ING-klanten.
De storingen kwamen in twee gevallen door een menselijke fout, in een ander geval zorgde een haperende switch voor problemen. Een script veroorzaakte een storing door de verbinding tussen de database en opslagschrijven te verstoren. Hoewel dit volgens de bank een zeldzame gebeurtenis is, is het script aangepast en wordt er overleg gevoerd met toeleveranciers om herhaling te voorkomen.
Om de menselijke fouten te voorkomen, zal de bank tevens de processen om nieuwe software te installeren nog verder automatiseren en bovendien zullen er bij dergelijke installatieprocessen meerdere mensen meekijken. "Bij systeemwijzigingen die de dienstverlening van klanten potentieel kunnen verstoren, zullen we een nog strikter regime van ontwerpen, testen, plannen en doorvoeren toepassen."
Nadat vorig jaar de gehele infrastructuur van de internetbankieromgeving al is vernieuwd, zal de bank dit jaar verder investeren in de it-systemen van de bank. De cio wilde niet inhoudelijk ingaan op welke delen dit dan zijn of hoeveel geld hiermee gemoeid is, anders dan dat het reguliere it-jaarbudget al enkele tientallen miljoenen is.
Reacties (56)
Het plaatje onderaan het artikel is niet zichtbaar! Als je op het zwarte streepje klikt wel.
Voor Feedback : Geachte Redactie
[Reactie gewijzigd door moreasy op woensdag 15 februari 2012 11:47]
Ik ben blij dat we (consument) acties zien. Na de tweede storing kwam de uitlating "we gaan het nu voor eens en voor altijd oplossen", wat een boude opmerking is, want dat had al na de eerste keer moeten gebeuren (zulke opmerkingen zijn ook kenmerkend voor NS overigens).
Maar goed om te laten zien wat er nou gebeurd is en welke actie daarop wordt ondernomen. Ik vind het een positieve ontwikkeling.
Maar goed om te laten zien wat er nou gebeurd is en welke actie daarop wordt ondernomen. Ik vind het een positieve ontwikkeling.
ING gaat dus stappen maken in de verbetering van de infrastructuur, hulde.
Zeker nu wij mensen zo afhankelijk zijn van digitale systemen is het belangrijk dat de meerdere digitale systemen onafhankelijk blijven zodat het aantal PoF's, en de impact van een failure, niet enorm wordt.
Zeker nu wij mensen zo afhankelijk zijn van digitale systemen is het belangrijk dat de meerdere digitale systemen onafhankelijk blijven zodat het aantal PoF's, en de impact van een failure, niet enorm wordt.
Het lijkt mij niet anders dan normaal dat je verschillende systemen altijd scheid.
Alleen maar voor de duidelijkheid... Maargoed dat is mijn visie.
Alles aan elkaar plakken is naar mijn idee onoverzichtelijk.
Het lijkt erop alsof programmeurs hier de overhand hadden bij de het ontwikkelen van de infrastructuur..... iets wat maar al te vaak gebeurd.
Alleen maar voor de duidelijkheid... Maargoed dat is mijn visie.
Alles aan elkaar plakken is naar mijn idee onoverzichtelijk.
Het lijkt erop alsof programmeurs hier de overhand hadden bij de het ontwikkelen van de infrastructuur..... iets wat maar al te vaak gebeurd.
ik denk eerder dat dat komt doordat de ING al een grote infrastructuur had voor internetbankieren, en hier door "teveel focus op leveren aan klanten" teveel bijgepropt is.
ideal begon natuurlijk heel klein en kwam er later pas bij, maar is uit de klauwen gelopen en voor mobiel bankieren hebben ze ook al de bestaande omgeving gebruikt, wat daarop wijst...
ideal begon natuurlijk heel klein en kwam er later pas bij, maar is uit de klauwen gelopen en voor mobiel bankieren hebben ze ook al de bestaande omgeving gebruikt, wat daarop wijst...
Dit is een infrastructuur die in de loop van de afgelopen 10 jaar zo gegroeid is. Bij samenvoeging van ING en Postbank, is het ING deel geintegreerd bij de Postbank systemen, en daar is vervolgens weer op voortgebouwd. Ja, in theorie maak je alles zo mooi en gescheiden mogelijk, maar in de praktijk lukt dat niet altijd.
Zodat je alle business logica redundant implementeert, met drama's voor het onderhoud en beheer als gevolg?Het lijkt mij niet anders dan normaal dat je verschillende systemen altijd scheid.
Hiermee oversimpificeer je de problematiek.
Redundantie is uitstekend op infrastructureel gebied, maar bedrijfslogica leg je idealiter maar één keer vast.
De vraag vanuit de markt naar nieuwe functionaliteit en nieuwe interfaces is sterk en daar is m.i. teveel nadruk op komen te liggen. Maar wie weet hoe hard we hadden geklaagd als ze géén iPhone- of Android app hadden ontwikkeld?
Juist niet. Teveel managers met de hand op de knip. Je kunt daar als systeembeheerder of programmeur hard roepen dat iets anders moet want anders gaat het in de (nabije) toekomst verkeerd, als het geld kost zal het niet snel gebeuren.Het lijkt erop alsof programmeurs hier de overhand hadden bij de het ontwikkelen van de infrastructuur..... iets wat maar al te vaak gebeurd.
Is dat schema door ING zelf gemaakt & vrijgegeven? In dat geval heb ik wel respect voor hun openheid.
Gezien het gebruikte font en stilo lijkt het daar wel op, inderdaad goed dat ze dat doen. Wel ben ik bang voor de gevolgen die de betreffende medewerkers (die beide fouten op hun naam hebben staan) te wachten staan. Een fout is menselijk, dus hopelijk gaat ING hier goed mee om.
Omdat dat vanuit een proces komt dat "Change Management" heet denk ik.(Change? Kom op zeg! Hoe moeilijk is het om verandering neer te zetten?).
Stoor je je ook aan het feit dat ze Firewall schrijven en geen Vuurmuur?
Ontopic:
Begrijp ik dat ze de boel scheiden omdat de load op een gegeven moment te hoog was? (muv de voorvallen waar het door een menselijke fout kwam)
[Reactie gewijzigd door ThePope90 op woensdag 15 februari 2012 11:53]
Nee, ze scheiden de boel om een alternatief te kunnen bieden als er in 1 van de 2 delen een storing is. Lijkt me geen slechte keuze. Fouten kan je nooit voorkomen, maar je kunt wel fall back scenarios bedenken.
Dit verbaast me overigens wel: "en bovendien zullen er bij dergelijke installatieprocessen meerdere mensen meekijken". Betekent dat nou dat tot nu toe dit niet gebeurde?
Dit verbaast me overigens wel: "en bovendien zullen er bij dergelijke installatieprocessen meerdere mensen meekijken". Betekent dat nou dat tot nu toe dit niet gebeurde?
[Reactie gewijzigd door GJvdZ op woensdag 15 februari 2012 12:01]
Weet je wat het kost om 2 man achter een toetsenbord te hebben? Nee dit gebeurt dus niet standaard.
niks extras,
Wij zijn met 2 developers, de 1 doet een pull request, krijg ik meldig van en kijk zijn code/veranderingen na... en andersom, zo zijn we beide productief en zijn er altijd een extra paar ogen door de code gegaan! Zo weten we zeker van elkaar dat de code up-to-standards is.
Tevens hanteren wij ook een pull-push methode, voordat wij in in naar de master mergen, zo worden alle conflicten opgelost en meteen daarna ge-pushed.
Het is allemaal niet zo moeilijk als we denken, bij de ing heeft gewoon 1(of meerdere) arrogante zakken rond gelopen die zoiets hadden van:"Ohh, dat fix ik wel ff".
discipline komt het op neer.
Wij zijn met 2 developers, de 1 doet een pull request, krijg ik meldig van en kijk zijn code/veranderingen na... en andersom, zo zijn we beide productief en zijn er altijd een extra paar ogen door de code gegaan! Zo weten we zeker van elkaar dat de code up-to-standards is.
Tevens hanteren wij ook een pull-push methode, voordat wij in in naar de master mergen, zo worden alle conflicten opgelost en meteen daarna ge-pushed.
Het is allemaal niet zo moeilijk als we denken, bij de ing heeft gewoon 1(of meerdere) arrogante zakken rond gelopen die zoiets hadden van:"Ohh, dat fix ik wel ff".
discipline komt het op neer.
Ik vermoed niet dat de programmatuur hier het probleem is. Die wordt voordat het in productie gaat nog wel getest (functioneel en technisch). Maar het moet ook een keer gedployed worden. Dat heb ik dus nog niet structureel met 2 man zien gebeuren (hooguit in een test omgeving in het kader van overdracht).
Het patroon van code-review (met Git of welke tool dan ook ) is redelijk gebruikelijk, zeker in een team met wisselende niveaus van ontwikkelaats. Model van pull-push is ook versie beheer 101, dus ik verwacht dat het daar ook niet op stuk is gelopen.
Het patroon van code-review (met Git of welke tool dan ook ) is redelijk gebruikelijk, zeker in een team met wisselende niveaus van ontwikkelaats. Model van pull-push is ook versie beheer 101, dus ik verwacht dat het daar ook niet op stuk is gelopen.
Naar mijn mening is 'Change' een veel bekender begrip voor een aanpassing van een systeem. 'Verandering' vind ik juist een beetje dom staan... Als je 'Firewalls', 'Load balacers' en 'Switchers' allemaal gaat vertalen, dan zullen (nog) minder mensen het snappen.
Dat zal wel meevallen, dat is eerder luiheid van de doorsnee Nederlander om Engelse termen te gebruiken. De belgen zijn hier veel zuiverder in. Voor een hoop Engelse termen zijn prima Nederlandse woorden beschikbaar. Ze klinken misschien af en toe vreemd, maar ze betekenen toch vaak echt hetzelfde.
Heel veel processen (en functietitels) binnen grote organisaties als ING zijn gewoon Engels. Je vraagt geen wijziging aan, maar een RfC (Request for Change). Ik ken zelfs al geen Nederlands woord meer voor 'content' 
. Als je al wat langer in die branche meeloopt ga je automatisch in die termen denken, vandaar dat ze terugkomen in de visual (of moet ik 'afbeelding' zeggen?).
. Als je al wat langer in die branche meeloopt ga je automatisch in die termen denken, vandaar dat ze terugkomen in de visual (of moet ik 'afbeelding' zeggen?).Content is inhoud.
Zo kunnen we nog wel even doorgaan:
Vuurmuren, belastingsbalanceerders, schakelaars, sessiebeheer, gegevensopslag (-> database), schijven.
Chief Information Officer = Direkteur informatiesystemen (?)
Conference call = Telefonische vergadering
Vuurmuren, belastingsbalanceerders, schakelaars, sessiebeheer, gegevensopslag (-> database), schijven.
Chief Information Officer = Direkteur informatiesystemen (?)
Conference call = Telefonische vergadering
Een "Change" is niet eenvoudig als even een Windows update draaien. Dit zijn zeer complexe systemen. Met name door de hoge mate van beveiliging. Ondanks dat deze changes goed getest worden in tests kan de praktijk helaas altijd iets anders uitpakken.
Ik zie dat ING ondanks hun falen, met duidelijk communicatie de mensen op de hoogte heeft gehouden en met deze PVA laat zien dat ook ING zelf dit onacceptabel vind en er alles aan doet om het te voorkomen in de toekomst. Dit vind ik een goede zaak wat het vertrouwen in de bank goed doet.
Ik zie dat ING ondanks hun falen, met duidelijk communicatie de mensen op de hoogte heeft gehouden en met deze PVA laat zien dat ook ING zelf dit onacceptabel vind en er alles aan doet om het te voorkomen in de toekomst. Dit vind ik een goede zaak wat het vertrouwen in de bank goed doet.
De hoofdreden dat dit soort changes complex zijn is vaak niet de beveiliging, maar het unieke aspect aan iedere change. Microsoft weet dat een fixpack door een paar miljoen man gedownload wordt. Als het mis gaat is het dus goed mis en wordt iedere wijziging dus doorgetest tot je een ons weegt. Changes in een corporate environment worden meestal snel snel snel gedaan en door de complexiteit van de omgeving (vaak onstaan door organische groei en weinig geld voor opruimen) is het voor niemand in de organisatie duidelijk wat de impact precies is van een wijziging. Dus hoeveel QA je er ook opzet het gaat een keer mis.
iedereen die met netwerken werkt noemt het een change.(Change? Kom op zeg! Hoe moeilijk is het om verandering neer te zetten?).
zo heet dat in de gebruikte best praktische documentatie, dat is gewoon vak taal.
een change in dit verband omvat veel meer als enkel 'verandering'. dat omvat alles vanaf het punt dat er is besloten dat er iets moet veranderen tot aan het plannen, testen en aan het einde uitvoeren van zo'n verandering. dat kan dagen zo niet weken werkt zijn. dat alles wordt mooi samengevat in het word 'change' en 'change management'
[Reactie gewijzigd door Countess op woensdag 15 februari 2012 19:07]
Ik vind het erg prettig dat ze vertellen wat er fout gegaan is. Meestal moet je het met hooguit excusses doen. Veel mensen zal het niets zeggen. Maar wij tweakers kennen de bovenstaande termen wel.
Nu is het vooral de vraag gaat het helpen en zijn er straks echt veel minder storingen. De Tijd zal het leren
Nu is het vooral de vraag gaat het helpen en zijn er straks echt veel minder storingen. De Tijd zal het leren
Heel prettig ja, maar ze hebben het mij niet verteld. Ik moet het hier lezen, en ik ben klant. Verbeterpuntje voor de communicatie. 
Tuurlijk, want een bank met dagelijks miljoenen hits en duizenden actieve sessie op elk gewenst tijdstip is natuurlijk volledig 1-op-1 vergelijkbaar met jouw situatie (die - veilige aanname - niet in de buurt komt qua grootte en complexiteit). Mensen vergeten vaak dat commerciele oplossingen niet geschikt zijn (of niet goed opschalen) naar een dergelijke grootte. Daarbij wil je het ook in één keer goed doen, ipv halve oplossingen op te leveren. Tot slot staat letterlijk in de visual dat het slechts een schematische weergave van de werkelijkheid is (waar dus details in missen). Mocht jij dus uit eigen hand weten dat het bij ING amateurs zijn, dan werk je er zelf 'en wat ben je dan?' 
.
.In mijn ervaring is het probleem niet zozeer het opschalen van commerciele oplossingen maar de organische groei (noem het evolutie) van het systeemlandschap gecombineerd met pikdrift: jouw afdeling doet Oracle dus ik doe alles behalve Oracle om te voorkomen dat je mij opslurpt.. De vendoren lachen zich een deuk (iedereen kan aan bod komen), de integratiekosten zijn geweldig (alles in huis en alles moet met alles praten). Het omgekeerde (alles van 1 vendor) is natuurlijk ook niet wat je wilt, want dan zit je in de tang. Dus het is een catch-22.
Wat een volslagen naïviteit en minachting spreekt er uit je reactie zeg. 
Dit is niet zomaar een netwerkje met een paar servertjes en switches. Iedere server die hier staat is een enorm al dan niet gedistribueerd cluster, hetzelfde geldt voor de switches. Een 'hapering' kan een moeilijk te detecteren on op te lossen software fout zijn. Ik zou zeggen, veel succes met nagios om een bug te vinden in 1 van de vele switches die binnen 1 van de vele datacentra zich bevind.
Dit is niet zomaar een netwerkje met een paar servertjes en switches. Iedere server die hier staat is een enorm al dan niet gedistribueerd cluster, hetzelfde geldt voor de switches. Een 'hapering' kan een moeilijk te detecteren on op te lossen software fout zijn. Ik zou zeggen, veel succes met nagios om een bug te vinden in 1 van de vele switches die binnen 1 van de vele datacentra zich bevind.
Mee eens maar ja, geld op de plank leggen is in deze economie niet waar de meeste bedrijven voor keizen. Je moest eens weten hoeveel bedrijven echt een probleem hebben als bepaalde hardware (niet een switch) het ineens niet meer doet.
Het is natuurlijk wel heel erg triest dat ze dit NU pas gaan scheiden. Op deze manier hebben ze voor zichzelf een Single Point Of Failure gecreëerd.
Lijkt mij een designfout.
Lijkt mij een designfout.
Is dat niet een standaard gevolg van een groeiend systeem? Stel je wilt je systeem uitbreiden, ga je dan in een vroeg stadium al scheiden terwijl dat (op dat moment) nog niet direct voordelen biedt? Ook de IT afdeling heeft een budget, dus als het niet direct nodig is, zal er niet voor een scheiding van systemen gekozen worden. Het moeilijke is om op een bepaald moment te bepalen: we zijn nu te groot geworden, we moeten nu een scheiding van ons systeem gaan inplannen. Zoiets kost veel voorbereidingswerk, dus wellicht waren ze er al mee bezig toen de storing toesloeg, dat weten we niet. Het is heel makkelijk om (als buitenstaander) iets te zeggen over de operationele beslissingen binnen zo'n grote organisatie/systeem.
Klopt, maar ik denk dat bij de introductie van internetbankieren (IB) (en dan de eerste jaren ervan) het al bekend was dat IB een belangrijk onderdeel zou gaan worden van de dagelijkse gang van zaken. De groei in de eerste jaren zou mijns insziens voldoende aanleiding moeten bieden om hier ruimte voor vrij te maken in het budget.
Dus ja, uiteraard heeft een IT afdeling een budget, maar dit hadden ze kunnen voorzien.
Dus ja, uiteraard heeft een IT afdeling een budget, maar dit hadden ze kunnen voorzien.
Het idee dat je een SPOF-loos systeem kunt maken blijft toch erg hardnekkig: uiteindelijk komt het samen in het backend waar jouw rekening gegevens staan. Als je deze dubbel gaat uitvoeren dan wordt het helemaal spannend: welke van de 2e is de waarheid? Op zich ook wel oplosbaar, maar verre van triviaal.
En die integriteit is juist het allerbelangrijkste bij een financiele instelling. En elke professional weet dat als je confidentiallity en integrity het belangrijkst vind, de availability een stuk moeilijker wordt...
Sterker nog, volgens het CAP theorema is het onmogelijk om tegelijkertijd Consistency, Availability en Partition tolerance te hebben. Je kunt 2 van de 3 kiezen, maar de derde is dan niet mogelijk.
in dit geval introduceert ING dus de mogelijkheid dat er patitioning (scheiding) ontstaat tussen de twee systemen. Het gevolg lijkt wel dat consistency in gevaar komt. Je uitgaven via de website zijn mogelijk niet meteen zichtbaar in de mobiele app.
in dit geval introduceert ING dus de mogelijkheid dat er patitioning (scheiding) ontstaat tussen de twee systemen. Het gevolg lijkt wel dat consistency in gevaar komt. Je uitgaven via de website zijn mogelijk niet meteen zichtbaar in de mobiele app.
Juist. Interfaces en infrastructuren scheiden. Bij veel bedrijven zijn er grote problemen met het beveiligen van cruciale systemen. meestal doordat intern veel systemen gebruik maken van dezelfde hardware en dat maakt het kwetsbaar.
Dus verschillende infrastructuren voor verschillende diensten en de uiteindelijke data kan best wel weer op dezelfde servers staan. Dat geeft niets.
Dus verschillende infrastructuren voor verschillende diensten en de uiteindelijke data kan best wel weer op dezelfde servers staan. Dat geeft niets.
De reclame van ING snap ik helemaal niet.
als je al vaak storingen hebt ga je mensen niet aanraden om te gaan chatten via hun betaal systeem.
In hun reclame laten ze zien hoe een jongen 1 cent overmaakt met een bereicht en dat meisje stuurd 14 cent terug met een ander bericht.
als je al vaak storingen hebt ga je mensen niet aanraden om te gaan chatten via hun betaal systeem.
In hun reclame laten ze zien hoe een jongen 1 cent overmaakt met een bereicht en dat meisje stuurd 14 cent terug met een ander bericht.
[Reactie gewijzigd door churchill9 op woensdag 15 februari 2012 12:44]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
