बैंक कसरी असफल भयो ?

एक असफल IT पूर्वाधार माइग्रेसनको परिणामस्वरूप 1,3 बिलियन बैंक ग्राहक रेकर्डहरू भ्रष्टाचार भयो। यो सबै अपर्याप्त परीक्षण र जटिल IT प्रणालीहरूको लागि तुच्छ मनोवृत्तिको कारण थियो। Cloud4Y ले यो कसरी भयो बताउँछ।

2018 अंग्रेजी मा TSB बैंक लोयड्स बैंकिङ समूह (दुबै कम्पनीहरू 1995 मा मर्जर) संग उनको दुई वर्ष पुरानो "डिभोर्स" धेरै महँगो थियो भनेर महसुस गरे। TSB अझै पनि हतारमा क्लोन गरिएको Lloyds IT प्रणालीहरू मार्फत आफ्नो पुरानो साझेदारसँग बाँधिएको थियो। सबैभन्दा नराम्रो कुरा, बैंकले 127 मिलियन डलर वार्षिक इजाजतपत्र शुल्क "गुजारा" तिर्नुपर्ने थियो।

थोरै व्यक्तिहरू आफ्ना एक्सीहरूलाई पैसा तिर्न मन पराउँछन्, त्यसैले अप्रिल 22, 2018 मा 18:00 TSB ले सबै कुरा परिवर्तन गर्ने 18-महिना योजनाको अन्तिम चरण सुरु गर्यो। २०१५ मा TSB लाई २.२ बिलियन डलरमा किनेको स्पेनी कम्पनी बान्को सबाडेलको आईटी प्रणालीमा अर्बौं ग्राहक रेकर्डहरू हस्तान्तरण गर्ने योजना थियो।

बान्को सबाडेलका सीईओ जोसे ओलुले बार्सिलोनाको एक प्रतिष्ठित कन्फरेन्स हलमा उत्सव कर्मचारी बैठकमा क्रिसमस 2 भन्दा २ हप्ता अघि आगामी कार्यक्रमको बारेमा कुरा गरे। सबैभन्दा महत्त्वपूर्ण माइग्रेसन उपकरण ब्यान्को सबाडेल: प्रोटियो द्वारा विकसित प्रणालीको नयाँ संस्करण हुनु थियो। यसलाई विशेष गरी TSB माइग्रेसन प्रोजेक्टको लागि Proteo2017UK नामकरण गरिएको थियो।

Proteo4UK को प्रस्तुतीकरणमा, Banco Sabadell का कार्यकारी निर्देशक Jaime Guardiola Romojaro ले नयाँ प्रणाली एउटा ठूलो स्तरको परियोजना हो जसको युरोपमा कुनै एनालॉग छैन, जसमा 1000 भन्दा बढी विशेषज्ञहरूले काम गरेका छन् भनी गर्व गरे। र यसको कार्यान्वयनले युकेमा बान्को सबाडेलको बृद्धिलाई महत्त्वपूर्ण बढावा दिनेछ।

अप्रिल 22, 2018 माइग्रेसन डेको रूपमा सेट गरिएको थियो। यो मध्य वसन्त मा एक शान्त आइतबार साँझ थियो। अभिलेख एक प्रणालीबाट अर्को प्रणालीमा स्थानान्तरण हुन थालेपछि बैंकको सूचना प्रविधि प्रणालीमा कमी आएको थियो । आइतवार ढिलो बैंक खाताहरूमा सार्वजनिक पहुँच पुनर्स्थापित भएपछि, एकले बैंक बिस्तारै र सुचारु रूपमा सेवामा फर्कने अपेक्षा गर्दछ।

तर ओल्यु र गार्डियोला रोमोजारोले Proteo4UK परियोजनाको कार्यान्वयनको बारेमा मञ्चबाट खुसीसाथ प्रसारण गरिरहँदा, माइग्रेसन प्रक्रियाका लागि जिम्मेवार कर्मचारीहरू धेरै चिन्तित थिए। १८ महिना लाग्ने यो आयोजना समयभन्दा धेरै ढिलो र बजेटभन्दा बढी थियो । थप परीक्षणहरू सञ्चालन गर्न समय थिएन। तर कम्पनीको सबै डाटा (जुन, सम्झनुहोस्, अरबौं रेकर्डहरू छन्) अर्को प्रणालीमा स्थानान्तरण गर्नु एक हर्कुलियन कार्य हो।

यो बाहिर आयो कि इन्जिनियरहरू राम्रो कारणको लागि नर्भस थिए।

साइटमा एउटा स्टब जुन ग्राहकहरूले धेरै लामो देखे

TSB ले खाताहरूमा पहुँच खोलेको 20 मिनेट पछि, माइग्रेसन सहज रूपमा भयो भन्ने पूर्ण विश्वस्त हुँदै, समस्याहरूको पहिलो रिपोर्ट आयो।

मानिसहरूको बचत अचानक तिनीहरूको खाताबाट गायब भयो। नगण्य रकमको खरिदहरू गल्तीले बहु-हजार-डलर खर्चको रूपमा रेकर्ड गरियो। केही व्यक्तिहरूले आफ्नो व्यक्तिगत खातामा लग इन गरे र उनीहरूको बैंक खाता होइन, तर पूर्ण रूपमा फरक व्यक्तिहरूको खाताहरू हेरे।

21:00 मा, TSB प्रतिनिधिहरूले स्थानीय वित्तीय नियामक (युके वित्तीय आचरण प्राधिकरण, FCA) लाई बैंक समस्यामा भएको जानकारी दिए। तर FCA ले पहिले नै नोटिस लिइसकेको छ: TSB ले साँच्चै नराम्रो तरिकाले बिगारेको छ, र ग्राहकहरूलाई मूर्ख बनाएको छ। र, निस्सन्देह, तिनीहरूले गुनासो गर्न थाले सामाजिक संजाल (र आजकल, ट्विटर वा फेसबुक मा केहि लाइनहरु छोड्न विशेष गरी गाह्रो छैन)। 23:30 बजे, FCA लाई अर्को वित्तीय नियामक, प्रुडेन्सियल रेगुलेसन अथोरिटी (PRA) द्वारा सम्पर्क गरियो, जसले पनि केहि गलत भएको महसुस गर्यो।

मध्यरात पछि तिनीहरूले बैंक प्रतिनिधिहरू मध्ये एक मार्फत प्राप्त गर्न सफल भए। र तिनीहरूलाई एउटै प्रश्न सोध्नुहोस्: "के भइरहेको छ?"

यो त्रासदीको मापन बुझ्न समय लाग्यो, तर अब हामी जान्दछौं कि 1,3 मिलियन ग्राहकहरु को 5,4 बिलियन रेकर्ड माइग्रेसन को समयमा क्षतिग्रस्त भएको थियो। कम्तिमा एक हप्ताको लागि, ग्राहकहरूले आफ्नो कम्प्युटर वा मोबाइल उपकरणहरूबाट आफ्नो पैसा व्यवस्थापन गर्न असमर्थ थिए। तिनीहरूले ऋण तिर्न असमर्थ थिए, र धेरै बैंक ग्राहकहरूले आफ्नो क्रेडिट इतिहास, साथै ढिलाइ शुल्क मा एक दोष प्राप्त गरे।

यो TSB ग्राहक अनलाइन बैंक जस्तो देखिन्थ्यो

जब ग्लिचहरू देखा पर्न थाले, लगभग तुरुन्तै पछि, बैंक प्रतिनिधिहरूले जोड दिए कि समस्याहरू "अन्तरन्तर" थिए। तीन दिन पछि, एक विज्ञप्ति जारी गरियो कि सबै प्रणालीहरू सामान्य छन्। तर ग्राहकहरूले समस्याहरू रिपोर्ट गर्न जारी राखे। 26 अप्रिल 2018 सम्म यो बैंकका प्रमुख कार्यकारी, पॉल पेस्टरले स्वीकार गरे कि TSB "आफ्नो घुँडा टेकेको" बैंकको IT पूर्वाधारमा "ब्यान्डविथ समस्या" जारी रह्यो जसले लगभग एक मिलियन ग्राहकहरूलाई अनलाइन बैंकिङ सेवाहरू पहुँच गर्नबाट रोकेको थियो।

माइग्रेसनमा दुई हप्ता, अनलाइन बैंकिङ अनुप्रयोग अझै पनि SQL डाटाबेस सम्बन्धित आन्तरिक त्रुटिहरू अनुभव भइरहेको रिपोर्ट गरिएको थियो।
भुक्तानी कठिनाइहरू, विशेष गरी व्यापार र धितो बिलहरूको साथ, चार हप्तासम्म जारी रह्यो। र सर्वव्यापी पत्रकारहरूले पत्ता लगाए कि TSB ले माइग्रेसन संकटको सुरुमै Lloyds Banking Group को मद्दतको प्रस्ताव अस्वीकार गरेको थियो। सामान्यतया, सेप्टेम्बर 3 सम्म अनलाइन सेवाहरूमा लगइन र पैसा स्थानान्तरण गर्ने क्षमतासँग सम्बन्धित समस्याहरू देखिएका थिए।

बिटको इतिहास

पहिलो ATM 27 जुन 1967 मा Enfield मा Barclays नजिक खोलिएको थियो

ग्राहकको आवश्यकता र बैंकबाट अपेक्षाहरू बढ्दै जाँदा बैंकिङ IT प्रणालीहरू जटिल बन्दै गएका छन्। लगभग 40-60 वर्ष पहिले, हामी नगद जम्मा गर्न वा टेलर मार्फत झिक्न व्यापारिक समयमा हाम्रो स्थानीय बैंक शाखामा जाँदा खुसी हुन्थ्यो।

खातामा रहेको रकम हामीले बैंकलाई दिएको नगद र सिक्कासँग सीधै सम्बन्धित थियो। हाम्रो घरको लेखा कलम र कागजको साथ ट्र्याक गर्न सकिन्छ, र कम्प्युटर प्रणालीहरू ग्राहकहरूको लागि पहुँचयोग्य थिएनन्। बैंकका कर्मचारीहरूले पासबुक र अन्य मिडियाबाट पैसा गणना गर्ने यन्त्रहरूमा डेटा राखे।

तर 1967 मा उत्तर लन्डनमा पहिलो पटक स्थापना गरिएको थियो एटीएम जुन बैंक परिसरमा अवस्थित थिएन। र यो घटनाले बैंकिङ परिवर्तन गर्यो। वित्तीय संस्थाहरूको विकासको लागि प्रयोगकर्ताको सुविधा एक बेन्चमार्क भएको छ। र यसले बैंकहरूलाई ग्राहकहरू र तिनीहरूको पैसासँग काम गर्ने सन्दर्भमा अझ परिष्कृत हुन मद्दत गरेको छ। जे भए पनि, कम्प्युटर प्रणालीहरू बैंकका कर्मचारीहरूलाई मात्र उपलब्ध भए तापनि तिनीहरू ग्राहकहरूसँग अन्तरक्रिया गर्ने पुरानो, "कागज" तरिकाबाट सन्तुष्ट थिए। यो केवल एटीएम र त्यसपछि अनलाइन बैंकिंग को आगमन संग थियो कि आम जनता को बैंक आईटी प्रणाली को प्रत्यक्ष पहुँच प्राप्त भयो।

एटीएमहरू सुरुवात मात्र थिए। चाँडै नै मानिसहरूले नगद दर्तामा लाइनबाट बच्न केवल फोनद्वारा बैंकलाई कल गर्न सक्षम भए। यसका लागि प्रयोगकर्ताले “१” (पैसा निकाल्ने) वा “२” (डिपोजिट फन्ड) कुञ्जी थिच्दा प्रसारित हुने डुअल-टोन मल्टि-फ्रिक्वेन्सी (DTMF) संकेतहरू बुझ्न सक्षम रिडरमा सम्मिलित विशेष कार्डहरू आवश्यक पर्दछ।

इन्टरनेट र मोबाइल बैंकिङले ग्राहकहरूलाई पावर बैंकको मुख्य प्रणालीको नजिक ल्याएको छ। तिनीहरूको फरक सीमाहरू र सेटिङहरूको बावजुद, यी सबै प्रणालीहरूले एकअर्कासँग र मुख्य मेनफ्रेमसँग प्रभावकारी रूपमा अन्तरक्रिया गर्नुपर्छ, खाता ब्यालेन्स जाँचहरू, पैसा स्थानान्तरण गर्ने, र यस्तै।

थोरै ग्राहकहरूले सूचना मार्ग कत्तिको जटिल छ भन्ने बारे सोच्छन् जब तपाईं, उदाहरणका लागि, आफ्नो खातामा पैसाको बारेमा जानकारी हेर्न वा अद्यावधिक गर्न अनलाइन बैंकमा लग इन गर्नुहुन्छ। जब तपाइँ लग इन गर्नुहुन्छ, यो डाटा सर्भरहरूको सेट मार्फत पास हुन्छ; जब तपाइँ लेनदेन गर्नुहुन्छ, प्रणालीले यो डाटा ब्याकएन्ड पूर्वाधारमा डुप्लिकेट गर्दछ, जसले त्यसपछि भारी लिफ्टिङ गर्दछ - बिलहरू तिर्न एक खाताबाट अर्कोमा पैसा स्थानान्तरण, भुक्तानीहरू, र सदस्यता जारी राख्नुहोस्।

अब यस प्रक्रियालाई धेरै अरबले गुणा गर्नुहोस्। बिल एण्ड मेलिन्डा गेट्स फाउन्डेसनको सहयोगमा विश्व बैंकले संकलन गरेको तथ्यांक अनुसार, 69 प्रतिशत विश्वभरका वयस्कहरूको बैंक खाता छ। यी मध्ये प्रत्येक व्यक्तिले तिर्न बिलहरू छन्। कसैले धितो तिर्छ वा बच्चाहरूको क्लबहरूको लागि पैसा स्थानान्तरण गर्दछ, कसैले नेटफ्लिक्स सदस्यता वा क्लाउड सर्भर भाडामा तिर्छ। र यी सबै मानिसहरू एक भन्दा बढी बैंक प्रयोग गर्छन्।

एक बैंकको असंख्य आन्तरिक आईटी प्रणालीहरू (मोबाइल बैंकिङ, एटीएम, आदि) एक अर्कासँग मात्र अन्तरक्रिया गर्नु हुँदैन। उनीहरूलाई ब्राजिल, चीन र जर्मनीका अन्य बैंकिङ प्रणालीहरूसँग अन्तरक्रिया गर्न आवश्यक छ। फ्रान्सेली एटीएमले बोलिभियामा कतै जारी गरेको बैंक कार्डमा रहेको पैसा वितरण गर्न सक्षम हुनुपर्छ।

पैसा सधैं विश्वव्यापी भएको छ, तर पहिले कहिल्यै प्रणाली यति जटिल भएको थिएन। बैंक आईटी प्रणालीहरू प्रयोग गर्ने तरिकाहरूको संख्या बढ्दै गएको छ, तर पुराना तरिकाहरू अझै पनि प्रयोगमा छन्। बैंकको सफलता धेरै हदसम्म यसको आईटी पूर्वाधार कत्तिको "सम्भारयोग्य" छ र बैंकले प्रणाली निष्क्रिय हुने अचानक असफलतालाई कसरी प्रभावकारी रूपमा सामना गर्न सक्छ भन्नेमा निर्भर गर्दछ।

कुनै परीक्षण छैन - समस्याहरूको लागि तयारी गर्नुहोस्

Banco de Sabadell CEO Jaime Guardiola (बाँया) विश्वस्त थिए कि सबै कुरा सहज रूपमा जान्छ। काम लागेन ।

TSB को कम्प्युटर प्रणाली चाँडै समस्या समाधान गर्न धेरै राम्रो थिएन। त्यहाँ, अवश्य पनि, सफ्टवेयर ग्लिचहरू थिए, तर वास्तविकतामा यसको आईटी प्रणालीहरूको अत्यधिक जटिलताको कारण बैंक "ब्रेक" भयो। प्रतिवेदन अनुसार, जुन ठूलो आउटेजको प्रारम्भिक दिनहरूमा तयार गरिएको थियो, "नयाँ अनुप्रयोगहरूको संयोजन, दुई सक्रिय/सक्रिय डाटा केन्द्रहरूको प्रयोगको साथमा माइक्रो सेवाहरूको बढ्दो प्रयोगले उत्पादनमा जटिल जोखिम निम्त्यायो।"

केही बैंकहरू, जस्तै HSBC, विश्वव्यापी रूपमा सञ्चालन गर्दछ र त्यसैले पनि धेरै जटिल, अन्तरसम्बन्धित प्रणालीहरू छन्। तर ल्यान्कास्टरका एक एचएसबीसी आईटी प्रबन्धकका अनुसार तिनीहरू नियमित रूपमा परीक्षण, माइग्रेट र अपडेट हुन्छन्। उसले HSBC लाई अन्य बैंकहरूले कसरी आफ्नो IT प्रणालीहरू व्यवस्थित गर्नुपर्छ: कर्मचारीहरूलाई समर्पित गरेर र आफ्नो समय खर्च गरेर। तर एकै समयमा उनी स्वीकार्छन् कि सानो बैंकको लागि, विशेष गरी एक जसलाई माइग्रेसन अनुभव छैन, यो सही तरिकाले गर्नु धेरै गाह्रो काम हो।

TSB माइग्रेसन गाह्रो थियो। र, विज्ञहरूका अनुसार, बैंक कर्मचारीहरू योग्यताको सन्दर्भमा जटिलताको यो स्तरमा पुग्न सकेनन्। थप रूपमा, तिनीहरूले उनीहरूको समाधान जाँच गर्न वा पहिले नै माइग्रेसन परीक्षण गर्न पनि चिन्ता गरेनन्।

बैंकिङ समस्याहरूमा बेलायती संसदमा एक भाषणको क्रममा, एफसीएका प्रमुख कार्यकारी एन्ड्र्यू बेलीले यो शंकाको पुष्टि गरे। खराब कोडले TSB मा प्रारम्भिक समस्याहरू मात्र निम्त्याएको हुन सक्छ, तर विश्वव्यापी वित्तीय नेटवर्कको अन्तरसम्बन्धित प्रणालीहरूले यसको गल्तीहरू निरन्तर र अपरिवर्तनीय थिए भन्ने हो। बैंकले आफ्नो IT संरचनामा अन्यत्र अप्रत्याशित त्रुटिहरू देख्न जारी राख्यो। ग्राहकहरूले सन्देशहरू प्राप्त गरे जुन अर्थहीन वा तिनीहरूको समस्याहरूसँग सम्बन्धित थिएन।

रिग्रेसन परीक्षणले उत्पादनमा जारी हुनु अघि खराब कोड समातेर विपत्ति रोक्न मद्दत गर्न सक्छ र बगहरू सिर्जना गरेर क्षति पुर्‍याउन सक्छ जुन फिर्ता गर्न सकिँदैन। तर बैंकले आफूलाई थाहा नभएको माइनफिल्डबाट भाग्ने निर्णय गर्यो। परिणामहरू अनुमानित थिए। अर्को समस्या लागतको "अनुकूलन" थियो। यो कसरी प्रकट भयो? तथ्य यो हो कि यो पहिले लोयड्समा भण्डारण गरिएका ब्याकअप प्रतिलिपिहरूलाई हटाउने निर्णय गरिएको थियो, किनभने तिनीहरूले धेरै पैसा "खाए"।

ब्रिटिश बैंकहरू (र अरू पनि) चार-नौ उपलब्धता स्तर, अर्थात् ९९.९९% हासिल गर्न प्रयासरत छन्। अभ्यासमा, यसको मतलब यो हो कि आईटी प्रणाली हरेक समय उपलब्ध हुनुपर्छ, प्रति वर्ष 99,99 मिनेट डाउनटाइमको साथ। "थ्री नाइन" प्रणाली, 52%, पहिलो नजरमा धेरै फरक छैन। तर वास्तवमा यसको मतलब डाउनटाइम प्रति वर्ष 99,9 घण्टा पुग्छ। बैंकको लागि, "चार नाइन" राम्रो छ, तर "तीन नाइन" होइन।

तर हरेक पटक कम्पनीले आफ्नो IT पूर्वाधारमा परिवर्तन गर्छ, यसले जोखिम लिन्छ। आखिर, केहि गलत हुन सक्छ। परिवर्तनहरू कम गर्नाले समस्याहरूबाट बच्न मद्दत गर्न सक्छ, जबकि आवश्यक परिवर्तनहरू सावधानीपूर्वक परीक्षणको आवश्यकता पर्दछ। र बेलायती नियामकहरूले यस बिन्दुमा आफ्नो ध्यान केन्द्रित गरेका छन्।

सायद डाउनटाइमबाट बच्ने सबैभन्दा सजिलो तरिका भनेको थोरै परिवर्तनहरू गर्नु हो। तर हरेक बैंक, कुनै पनि अन्य कम्पनी जस्तै, प्रतिस्पर्धी रहन ग्राहकहरु र आफ्नै व्यवसाय को लागी अधिक र अधिक उपयोगी सुविधाहरू प्रस्तुत गर्न बाध्य छ। एकै समयमा, बैंकहरू अझै पनि आफ्ना ग्राहकहरूको हेरचाह गर्न, उनीहरूको बचत र व्यक्तिगत डेटाको सुरक्षा गर्न, सेवाहरू प्रयोग गर्नका लागि सहज अवस्थाहरू प्रदान गर्न बाध्य छन्। यो बाहिर जान्छ कि संगठनहरू आफ्नो IT पूर्वाधारको स्वास्थ्य कायम राख्न धेरै समय र पैसा खर्च गर्न बाध्य छन्, जबकि एकै साथ नयाँ सेवाहरू प्रदान गर्दै।

बेलायतको वित्तीय आचरण प्राधिकरणले जारी गरेको तथ्याङ्क अनुसार सन् २०१७ र २०१८ को बीचमा बेलायतमा वित्तीय सेवा क्षेत्रमा रिपोर्ट गरिएको प्रविधि असफलताको संख्या १८७ प्रतिशतले बढेको छ। अक्सर, विफलता को कारण नयाँ कार्यक्षमता को सञ्चालन मा समस्या छ। एकै साथ, बैंकहरूले सबै सेवाहरूको निरन्तर निर्बाध सञ्चालन र लेनदेनको लगभग तत्काल रिपोर्टिङ सुनिश्चित गर्न महत्त्वपूर्ण छ। ग्राहकहरू सधैं चिन्तित हुन्छन् जब तिनीहरूको पैसा कतै ह्याङ्ग आउट हुन्छ। र एक ग्राहक जो पैसा को बारे मा चिन्तित छ सधैं समस्या को संकेत हो।

TSB मा असफलताको केही महिना पछि (जसबेलासम्म बैंकका सीईओले राजीनामा दिएका थिए), बेलायतका वित्तीय नियामकहरू र बैंक अफ इङ्गल्याण्ड कागजात जारी गरे परिचालन दिगोपन मुद्दाहरूमा छलफलको लागि। त्यसैले उनीहरूले बैंकहरू नवप्रवर्तनको खोजीमा कत्तिको गहिराइमा पुगेका छन्, र उनीहरूले अहिले रहेको प्रणालीको स्थिर सञ्चालनको ग्यारेन्टी गर्न सक्छन् कि भनेर प्रश्न उठाउने प्रयास गरे।

उक्त दस्तावेजले ऐनमा परिवर्तनको प्रस्ताव पनि गरेको छ । यो कम्पनी भित्रका मानिसहरूलाई कम्पनीको आईटी प्रणालीहरूमा के गल्ती हुन्छ भनेर जवाफदेही बनाउने बारेमा थियो। बेलायती सांसदहरूले यसलाई यसरी व्याख्या गरे: "जब तपाईं व्यक्तिगत रूपमा जिम्मेवार हुनुहुन्छ, र तपाईं दिवालिया हुन सक्नुहुन्छ वा जेल जान सक्नुहुन्छ, यसले विश्वसनीयता र सुरक्षाको मुद्दामा समर्पित समयको मात्रा बढाउन सहित कामप्रतिको दृष्टिकोणमा ठूलो परिवर्तन ल्याउनेछ।"

परिणामहरू

प्रत्येक अपडेट र प्याच जोखिम व्यवस्थापनमा आउँदछ, विशेष गरी जब करोडौं डलर संलग्न हुन्छन्। आखिर, यदि केहि गलत भयो भने, यो पैसा र प्रतिष्ठाको सन्दर्भमा महँगो हुन सक्छ। यो स्पष्ट चीजहरू देखिन्छ। र माइग्रेसनको समयमा बैंकको असफलताले उनीहरूलाई धेरै सिकाएको हुनुपर्छ।

थियो। तर उहाँले मलाई सिकाउनुभएन। नोभेम्बर 2019 मा, TSB, जसले पुन: नाफा हासिल गर्यो र बिस्तारै आफ्नो प्रतिष्ठा सुधार्दै थियो, "खुसी" ग्राहकहरू नयाँ असफलता सूचना प्रविधिको क्षेत्रमा। बैंकलाई दोस्रो प्रहारको अर्थ भनेको लागत कटौती गर्न सन् २०२० मा ८२ शाखा बन्द गर्न बाध्य हुनेछ । वा उसले आईटी विशेषज्ञहरूलाई मात्र बचत गर्न सकेन।

IT को साथ कंजूसता अन्ततः एक लागत मा आउँछ। TSB ले 134 मा $ 2018 मिलियन नाफाको तुलनामा 206 मा $ 2017 मिलियन घाटा रिपोर्ट गर्यो। माइग्रेसन पछि लाग्ने लागत, ग्राहक क्षतिपूर्ति, धोखाधडी लेनदेनहरू सच्याउन (जो बैंकिङ अराजकताको समयमा तीव्र रूपमा बढ्यो), र तेस्रो-पक्ष सहायता, जम्मा $ 419 मिलियन। बैंकको आईटी प्रदायकलाई पनि संकटमा भूमिकाको लागि $ 194 मिलियन बिल गरिएको थियो।

यद्यपि, TSB बैंक असफलताबाट जे पनि पाठ सिकियोस्, अवरोधहरू अझै पनि आउनेछन्। तिनीहरू अपरिहार्य छन्। तर परीक्षण र राम्रो कोड संग, क्र्यास र डाउनटाइम धेरै कम गर्न सकिन्छ। Cloud4Y, जसले प्रायः ठूला कम्पनीहरूलाई क्लाउड पूर्वाधारमा माइग्रेट गर्न मद्दत गर्दछ, एक प्रणालीबाट अर्को प्रणालीमा छिटो सर्ने महत्त्व बुझ्दछ। तसर्थ, हामी लोड परीक्षण सञ्चालन गर्न सक्छौं र बहु-स्तर ब्याकअप प्रणाली प्रयोग गर्न सक्छौं, साथै अन्य विकल्पहरू जसले तपाईंलाई माइग्रेसन सुरु गर्नु अघि सबै सम्भव जाँच गर्न अनुमति दिन्छ।

तपाइँ ब्लगमा अरू के पढ्न सक्नुहुन्छ? Cloud4Y

→ नुनिलो सौर्य ऊर्जा
→ साइबर सुरक्षाको अग्रपंक्तिमा पेन्टेस्टरहरू
→ द ग्रेट स्नोफ्लेक थ्योरी
→ बेलुनहरूमा इन्टरनेट
→ डाटा सेन्टरमा तकिया आवश्यक छ?

हाम्रो सदस्यता लिनुहोस् तार- च्यानल, ताकि अर्को लेख नछुटाउन! हामी हप्तामा दुई पटक भन्दा बढी र केवल व्यापार मा लेख्छौं।

स्रोत: www.habr.com