हमारे सामने कार्यालय की गलती सहिष्णुता का राज

आधुनिक बैंक की व्यवस्था कैसे की जाती है? एक बैक ऑफिस है जहां विभिन्न ऑपरेशन किए जाते हैं, खाते और रिपोर्ट रखी जाती हैं। एक मध्य कार्यालय है जहां निर्णय किए जाते हैं और जोखिमों का मूल्यांकन किया जाता है, जहां क्रेडिट जोखिमों का मूल्यांकन किया जाता है और धोखेबाजों का प्रतिकार किया जाता है। और एक फ्रंट ऑफिस है जहां वे ग्राहकों की सेवा करते हैं और विभिन्न चैनलों के माध्यम से बैंक के साथ बातचीत के लिए जिम्मेदार हैं।



Sberbank की उपलब्धता और विश्वसनीयता अलग-अलग हैं। इसका अपना विकास है, और कस्टमाइज़ेशन की अलग-अलग डिग्री, अलग-अलग SLAs के साथ बॉक्सिंग समाधान हैं। सभी प्रणालियाँ भारी संख्या में एक दूसरे के साथ एकीकृत हैं। इस पोस्ट में, हम आपको बताएंगे कि कैसे इस पूरे फ्रंट-एंड चींटी पहाड़ी को इस तरह से बनाया गया है ताकि निरंतर ग्राहक सेवा प्रदान की जा सके।

सिद्धांत से शुरू करते हैं। मुख्य सिद्धांत जिसके द्वारा एक असफल-सुरक्षित प्रणाली का निर्माण किया जाता है, एक पनडुब्बी से उधार लिया जा सकता है:

1. पनडुब्बी को स्वतंत्र डिब्बों में बांटा गया है। यदि एक डिब्बे में पानी भर जाता है, तो भी बाकी बच जाता है।
   
2. सभी महत्वपूर्ण घटक आरक्षित हैं। इंजन, ऑक्सीजन टैंक। और बीटल्स ने भी पेरिस्कोप के साथ पेरिस्कोप आरक्षित किए।
   
3. पनडुब्बी सतह पर महत्वपूर्ण परिस्थितियों से सुरक्षित है - यदि आवश्यक हो, तो यह गहराई तक जा सकता है और वहां काम कर सकता है जैसे कि कुछ भी नहीं हुआ था।
   

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

यह तर्क दिया जा सकता है कि क्लस्टर्ड डेटाबेस और हाई-एंड सर्वर के साथ ऐसा नहीं होता है - हार्डवेयर स्तर पर अतिरेक का निर्माण होता है। वर्नर वोगेल्स को उद्धृत करने के लिए, सीटीओ अमेज़ॅन: "हर समय सब कुछ विफल रहता है।" हम गिर गए और डेटाबेस क्लस्टर, और उच्च अंत सर्वर। कॉन्फ़िगरेशन त्रुटियों के कारण विफलता, प्रबंधन सॉफ़्टवेयर में समस्याओं के कारण। प्रत्येक समस्या के समाधान के साथ, ऐसे समाधानों में हमारा विश्वास कम हो गया। नतीजतन, हम इस निष्कर्ष पर पहुंचे: केवल उन प्रणालियों को जो एक दूसरे से स्वतंत्र भागों में विभाजित हैं - मुख्य रूप से प्रबंधन में स्वतंत्र - मना नहीं करते हैं।

मल्टी-ब्लॉक आर्किटेक्चर

हमारी समस्याओं का समाधान बहु-ब्लॉक वास्तुकला था। इसमें, डेटाबेस सहित सभी हार्डवेयर घटकों को शिथिल युग्मित, लगभग स्वतंत्र ब्लॉकों में विभाजित किया जाता है। प्रत्येक ब्लॉक क्लाइंट का हिस्सा होता है, जैसे कि डेटाबेस में शार्पनिंग करते समय। प्रत्येक ब्लॉक के भीतर नोड्स भू-अतिरेक सहित सभी स्तरों पर आरक्षित हैं। एक ब्लॉक में कोई भी समस्या दूसरों को प्रभावित नहीं करती है। ग्राहकों की संख्या में वृद्धि के साथ, हम आसानी से नए ब्लॉक जोड़ सकते हैं और सामान्य रूप से काम करना जारी रख सकते हैं।


सामान्य ब्लॉक आर्किटेक्चर। सभी ब्लॉक 2N योजना के अनुसार आरक्षित हैं। प्रत्येक डेटा सेंटर में एक शक्तिशाली हार्डवेयर लोड बैलेंसर है। डेटा केंद्र 2-3 स्वतंत्र संचार चैनलों द्वारा जुड़े हुए हैं।

सर्वर पाँच प्रकार के ब्लॉक में वितरित किए जाते हैं:

• राउटर - एक नियंत्रण इकाई जो ग्राहकों को बाकी इकाइयों में वितरित करता है
  
• क्लाइंट ब्लॉक - 10 मिलियन क्लाइंट तक सेवारत मुख्य ब्लॉक
  
• पायलट ब्लॉक - यहाँ हम निष्ठावान ग्राहकों (लगभग 300 हज़ार लोग, मुख्य रूप से Sberbank कर्मचारी) पर अनुप्रयोगों के नए संस्करणों का परीक्षण करते हैं
  
• अतिथि इकाई - इसके माध्यम से अनधिकृत उपयोगकर्ताओं को परोसा जाता है; उदाहरण के लिए, जो साइट के माध्यम से आते हैं
  
• रिजर्व ब्लॉक - एक सुरक्षा ब्लॉक जो दो क्लाइंट ब्लॉक को एक साथ बदलने के लिए पर्याप्त शक्तिशाली है
  

प्रत्येक ब्लॉक के अंदर, एप्लिकेशन सर्वर और वेब सर्वर को सेवा चैनलों द्वारा अलग किया जाता है, लेकिन डेटाबेस आम हैं। इसलिए हम सबसे आम विफलता परिदृश्यों को अलग कर सकते हैं ताकि वे हमारे चैनल की सीमाओं से परे न जाएं।

यह कैसे काम करता है?

सबसे पहले, उपयोगकर्ता राउटर इकाई में प्रवेश करता है। यह ब्लॉक चेक करता है कि ग्राहक किस ब्लॉक को ब्लॉक करता है और उसे वहां भेजता है (या गेस्ट ब्लॉक में)। इसके अलावा, एक व्यक्ति शांतिपूर्वक अपने ब्लॉक के अंदर काम करता है। यदि मूल इकाई में कोई विफलता होती है, तो व्यक्ति राउटर पर वापस लौटता है और स्वचालित रूप से आगे के काम के लिए बैकअप इकाई को एक दिशा प्राप्त करता है।

ऑपरेशन के दौरान डेटा का क्या होता है? बैंक के साथ क्लाइंट के इंटरैक्शन के बारे में जानकारी क्लाइंट ब्लॉक से संग्रह डेटाबेस तक लगातार दोहराई जाती है। उपयोगकर्ता से मिलने के बाद, बैकअप यूनिट संग्रह डेटाबेस से उसके बारे में आवश्यक जानकारी को खींचती है और यदि आवश्यक हो, तो डेटा प्रदान करती है - इसलिए उपयोगकर्ता हमारे हिस्से में समस्याएं आने पर फ्रीज नहीं करता है।

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


प्रणाली की सामान्य योजना

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

सिस्टम अपडेट करते हैं

नए सॉफ्टवेयर संस्करण पहले पायलट ब्लॉक पर तैनात किए जाते हैं और सीमित दर्शकों को दिखाए जाते हैं। फिर धीरे-धीरे क्लाइंट ब्लॉक पर, और पहले से ही अंत में - रिजर्व वाले पर। इसलिए यदि सॉफ़्टवेयर के नए संस्करण के साथ क्लाइंट ब्लॉक में समस्याएं हैं, तो हम पुराने से बैकअप ब्लॉक में ग्राहकों को स्थानांतरित कर सकते हैं।

जब एक नई कार्यक्षमता एक ब्लॉक पर घूमती है, तो यह स्वचालित रूप से चालू नहीं होती है। व्यवस्थापक चेकबॉक्स का उपयोग करके ऐसा करते हैं - सुविधा टॉगल करें। आप समूहों द्वारा ग्राहकों को नए संस्करण में स्विच कर सकते हैं - यह है कि हम दर्शकों की वृद्धि के लिए अपडेट की प्रतिक्रिया कैसे जांचें।

स्वराज्य

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

1. लंबित अनुरोध । क्लाइंट ऑपरेशन को पूरा करने का अनुरोध करता है। हम इसे अपने डेटाबेस में सहेजते हैं और बैकएंड में इसे निष्पादित करने का प्रयास करते हैं। यदि बैकएंड जवाब नहीं देता है, तो हम क्लाइंट को एक संदेश दिखाते हैं कि ऑपरेशन स्वीकार कर लिया गया है और संसाधित किया जा रहा है। जब बैकएंड बढ़ जाता है, तो एक अलग "डॉकटर" डेटाबेस से अपूर्ण संचालन पढ़ता है, और बैकएंड सिस्टम में बैचों में उन्हें "धक्का" देता है। बड़ी संख्या में कम-कुशल प्रश्नों के साथ संचालन के साथ मुख्य तालिका को अधिभार नहीं देने के लिए, हम अतिरिक्त रूप से तथाकथित टोकन तालिका का उपयोग करते हैं - अपूर्ण कार्यों के पहचानकर्ताओं की एक सूची। सैकड़ों हजारों ऑपरेशनों के बाद उठने वाले बैकएंड को नहीं छोड़ने के लिए, हम बैचिंग का उपयोग करते हैं - हम दो सौ ऑपरेशन छोड़ते हैं और उदाहरण के लिए, कुछ सेकंड के लिए प्रतीक्षा करते हैं।
   
   
   
   लेकिन क्या होगा यदि उपयोगकर्ता के अनुरोध और बैकएंड रिकवरी के बीच महत्वपूर्ण परिवर्तन हुए हैं? उदाहरण के लिए, क्या विनिमय दरें बढ़ गई हैं? इस मामले में, दोहरा सत्यापन चालू हो जाता है। ये ऑपरेशन प्रविष्टि पर सहेजे जाते हैं, और फिर निष्पादन पर सत्यापित होते हैं। यदि कुछ अभिसरण नहीं करता है, तो ऑपरेशन समायोजित या अस्वीकार कर दिया जाएगा।
   
2. डेटा कैशिंग । जब कोई उपयोगकर्ता प्रवेश करता है, उदाहरण के लिए, Sberbank Online, तो उसके बारे में सभी आवश्यक जानकारी पहले से ही दिखाई देती है - बिल, कार्ड, ऋण, आदि। यह डेटा एक दर्जन प्रणालियों से सेवा बस के माध्यम से अनुरोध किया गया है। यदि प्रतिक्रिया जल्दी से एकत्र की गई थी, तो कुछ ही सेकंड में, हम ग्राहक को डेटा दिखाते हैं और इसे हमारे डेटाबेस के सिस्टम कैश में सहेजते हैं। यदि नहीं, तो हम पहले कैश किए गए डेटा के लिए डेटाबेस में देखते हैं और क्लाइंट को दिखाते हैं। बेशक, इसके लिए, कैश एक निश्चित आयु से अधिक नहीं होना चाहिए। जब सेवा बस फिर भी मांग पर आवश्यक डेटा एकत्र करती है, तो इसे डेटाबेस कैश में अपडेट किया जाता है और पुराने के बजाय क्लाइंट को भेजा जाता है।
   
   एप्लिकेशन का उपयोग करते समय, इसका मतलब है कि एक व्यक्ति प्रवेश करने के कुछ सेकंड बाद अपने खाते की स्थिति देखेगा। हालाँकि डेटा कुछ पुराना हो सकता है। यदि ऐसा होता है, तो कुछ सेकंड के बाद डेटा को आमतौर पर वास्तविक एक द्वारा बदल दिया जाता है - जिसका अर्थ है कि सेवा बस ने आपकी ज़रूरत की सभी चीज़ों को एकत्र किया है।
   
   इसके अलावा, हमारे पास प्रतिकृति का उपयोग करके पूर्व-कैशिंग है। अधिकतर विभिन्न संदर्भ डेटा के लिए। हम बैकेंड में इस डेटा को लोड करते हैं, क्लाइंट शांति से ऑपरेशन के लिए अनुरोध करता है, और हम इसे भेजते हैं। यहां तक ​​कि अगर डेटा को बनाए रखने के लिए जिम्मेदार सिस्टम काम नहीं करते हैं, तो उपयोगकर्ता को एक बार फिर इंतजार नहीं करना होगा।
   
3. तकनीकी खराबी । यदि बैकेंड सिस्टम क्रैश हो गया है या रखरखाव चल रहा है, तो हम इसे ध्वजांकित करते हैं। और फिर इसके माध्यम से गुजरने वाले ऑपरेशन तुरंत इनकार से मिलते हैं। इसलिए हम एप्लिकेशन सर्वर को टाइमआउट के जवाब के इंतजार में अनुरोधों के साथ बहने से बचाते हैं। इस मोड में, हमारे द्वारा पहले वर्णित ऑपरेशन और डेटा की कैशिंग का उपयोग किया जा सकता है। तकनीकी ब्रेक प्रत्येक एकीकरण परिदृश्य के लिए मैन्युअल रूप से प्रशासक द्वारा या स्वचालित रूप से अनुरोधों की संख्या के आधार पर निर्धारित किए जाते हैं।
   

किसी भी मामले में, हम उपयोगकर्ता की अपेक्षा को कम से कम करना चाहते हैं - यदि कोई समस्या है, तो वह तुरंत ऑपरेशन की असंभवता के बारे में एक संदेश प्राप्त करता है। हम इस तरह के संदेशों की संख्या को कम करने की कोशिश करते हैं, इसलिए हम कुछ कैश्ड डेटा के जीवन काल को बढ़ाते हैं - यह हमें बैंक की सेवाओं के साथ सामान्य बातचीत का विस्तार करने की अनुमति देता है।

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

नतीजतन, लेख में वर्णित सिद्धांतों का पालन करते हुए, आप 99.99% और उच्चतर उपलब्धता के साथ सिस्टम प्राप्त कर सकते हैं।

हमारी योजनाएँ

अब योजनाओं को हमारी एकल प्रणाली के समय-से-बाजार को कम से कम करना है, ताकि चैनलों की तकनीकी और व्यावसायिक विशेषताओं को ध्यान में रखते हुए, सर्वव्यापीता सुनिश्चित की जा सके। और इस कदम के दौरान उनकी संचालन क्षमता बनाए रखते हुए विरासत प्रणालियों को भी स्थानांतरित करें।

हम पद की तैयारी में सक्रिय सहायता के लिए रोमन शेखोवत्सोव को धन्यवाद देते हैं