हाईलोड++, एवगेनी कुज़ोवलेव (ईकॉमपे आईटी): जब एक मिनट के डाउनटाइम की लागत $100000 हो तो क्या करें

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

अगला हाईलोड++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। के लिए विवरण और टिकट लिंक. 9 नवंबर, 18:00। हाईलोड++ मॉस्को 2018, दिल्ली + कोलकाता हॉल। थीसिस और प्रदर्शन.

एवगेनी कुज़ोवलेव (इसके बाद - ईसी): - दोस्तों, नमस्ते! मेरा नाम कुज़ोवलेव एवगेनी है। मैं EcommPay कंपनी से हूं, एक विशिष्ट प्रभाग EcommPay IT है, जो कंपनियों के समूह का IT प्रभाग है। और आज हम डाउनटाइम्स के बारे में बात करेंगे - उनसे कैसे बचा जाए, अगर उन्हें टाला नहीं जा सकता तो उनके परिणामों को कैसे कम किया जाए। विषय इस प्रकार बताया गया है: "क्या करें जब एक मिनट के डाउनटाइम की लागत $100 हो"? आगे देखते हुए, हमारी संख्या तुलनीय है।

EcommPay IT क्या करता है?

हम कौन हैं? मैं यहाँ आपके सामने क्यों खड़ा हूँ? मुझे यहां आपको कुछ बताने का अधिकार क्यों है? और हम यहां किस बारे में अधिक विस्तार से बात करेंगे?

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

हमने अपने सभी उत्पाद स्वयं लिखे (और हमारे पास उनमें से बहुत सारे हैं - बड़े आईटी उत्पादों की हमारी श्रृंखला में हमारे पास लगभग 16 अलग-अलग घटक हैं); हम स्वयं लिखते हैं, हम स्वयं विकास करते हैं। और फिलहाल हम एक दिन में लगभग दस लाख लेनदेन करते हैं (लाखों शायद इसे कहने का सही तरीका है)। हम एक काफी युवा कंपनी हैं - हम केवल छह साल पुरानी हैं।

6 साल पहले यह एक ऐसा स्टार्टअप था जब लोग बिजनेस के साथ आते थे। वे एक विचार से एकजुट थे (एक विचार के अलावा और कुछ नहीं था), और हम भागे। किसी भी स्टार्टअप की तरह, हम तेजी से दौड़े... हमारे लिए, गति गुणवत्ता से अधिक महत्वपूर्ण थी।

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

आप एक नया उत्पाद बनाते हैं, आप उसे उत्पादन में लगाते हैं, लेकिन फिर भी कहीं न कहीं कुछ गलत हो जाएगा। और आज हम इस बारे में बात करेंगे कि नए गुणवत्ता स्तर तक कैसे पहुंचा जाए (हमने यह कैसे किया, हमारे अनुभव के बारे में), विकास और परीक्षण को समीकरण से बाहर ले जाएं; हम इस बारे में बात करेंगे कि ऑपरेशन के लिए क्या उपलब्ध है - ऑपरेशन स्वयं क्या कर सकता है, गुणवत्ता को प्रभावित करने के लिए यह परीक्षण के लिए क्या पेशकश कर सकता है।

डाउनटाइम। संचालन के आदेश.

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

जब हमने अपना दृष्टिकोण बदलना शुरू किया, तो हमने 4 आज्ञाएँ बनाईं। मैंने उन्हें स्लाइडों पर प्रस्तुत किया है:

ये आज्ञाएँ काफी सरल हैं:

• समस्या को तुरंत पहचानें.
• इससे और भी तेजी से छुटकारा पाएं.
• कारण समझने में सहायता करें (बाद में, डेवलपर्स के लिए)।
• और दृष्टिकोणों का मानकीकरण करें।

मैं आपका ध्यान बिंदु संख्या 2 की ओर आकर्षित करना चाहता हूं। हम समस्या से छुटकारा पा रहे हैं, समाधान नहीं। निर्णय लेना गौण है. हमारे लिए प्राथमिक बात यह है कि उपयोगकर्ता इस समस्या से सुरक्षित रहे। यह किसी पृथक वातावरण में मौजूद होगा, लेकिन इस वातावरण का इससे कोई संपर्क नहीं होगा। दरअसल, हम समस्याओं के इन चार समूहों (कुछ अधिक विस्तार में, कुछ कम विस्तार में) से गुजरेंगे, मैं आपको बताऊंगा कि हम क्या उपयोग करते हैं, समाधान में हमारे पास क्या प्रासंगिक अनुभव है।

समस्या निवारण: वे कब घटित होते हैं और उनके बारे में क्या करना चाहिए?

लेकिन हम क्रम से शुरू करेंगे, हम बिंदु संख्या 2 से शुरू करेंगे - समस्या से जल्दी कैसे छुटकारा पाएं? एक समस्या है - हमें इसे ठीक करना होगा. "हमें इसके बारे में क्या करना चाहिए?" - मुख्य प्रश्न. और जब हमने यह सोचना शुरू किया कि समस्या को कैसे ठीक किया जाए, तो हमने अपने लिए कुछ आवश्यकताएँ विकसित कीं जिनका समस्या निवारण के लिए पालन किया जाना चाहिए।

इन आवश्यकताओं को तैयार करने के लिए, हमने खुद से यह सवाल पूछने का फैसला किया: "हमें समस्याएँ कब आती हैं"? और समस्याएँ, जैसा कि बाद में पता चला, चार मामलों में होती हैं:

• हार्डवेयर विफलता।
• बाहरी सेवाएँ विफल रहीं.
• सॉफ़्टवेयर संस्करण बदलना (समान परिनियोजन)।
• विस्फोटक भार वृद्धि.

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

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

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

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

यदि आपके पास बादल है तो इन चार समस्याओं में से कई तुरंत हल हो जाती हैं। यदि आप Microsoft Azhur, Ozone क्लाउड में हैं, या Yandex या Mail से हमारे क्लाउड का उपयोग करते हैं, तो कम से कम हार्डवेयर की खराबी उनकी समस्या बन जाती है और हार्डवेयर की खराबी के संदर्भ में आपके लिए सब कुछ तुरंत ठीक हो जाता है।

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

सॉफ़्टवेयर संस्करण बदलना. अड्डों

हमारे डेवलपर्स के पास उत्पादन तक पहुंच नहीं है। ऐसा क्यों? यह सिर्फ इतना है कि हम पीसीआई डीएसएस प्रमाणित हैं, और हमारे डेवलपर्स को "उत्पाद" में शामिल होने का अधिकार नहीं है। बस इतना ही, अवधि. बिल्कुल भी। इसलिए, विकास की ज़िम्मेदारी ठीक उसी समय समाप्त हो जाती है जब विकास बिल्ड को रिलीज़ के लिए प्रस्तुत करता है।

हमारा जो दूसरा आधार है, जो हमें बहुत मदद भी करता है, वह है अद्वितीय अप्रलेखित ज्ञान का अभाव। मुझे आशा है कि यह आपके लिए भी वैसा ही होगा। क्योंकि अगर ऐसा नहीं होगा तो आपको दिक्कत होगी. समस्याएँ तब उत्पन्न होंगी जब यह अद्वितीय, अप्रलेखित ज्ञान सही समय पर सही स्थान पर मौजूद नहीं होगा। मान लीजिए कि आपके पास एक व्यक्ति है जो एक विशिष्ट घटक को तैनात करना जानता है - वह व्यक्ति वहां नहीं है, वह छुट्टी पर है या बीमार है - बस, आपको समस्याएं हैं।

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

सॉफ़्टवेयर संस्करण बदलने के लिए आवश्यकताएँ

तीन आवश्यकताएँ हैं:

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

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

  यहां दूसरे प्रश्न का समाधान न्यूनतमकरण है: आप अपने ट्रैफ़िक का केवल एक हिस्सा एक नई लाइन पर, एक नए कोड वाली लाइन पर भेज सकते हैं (उदाहरण के लिए, 2%)। और ये 2% 100% नहीं हैं! यदि किसी असफल परिनियोजन के कारण आपने अपना 100% ट्रैफ़िक खो दिया है, तो यह डरावना है; यदि आपने अपना 2% ट्रैफ़िक खो दिया है, तो यह अप्रिय है, लेकिन यह डरावना नहीं है। इसके अलावा, उपयोगकर्ताओं को संभवतः इस पर ध्यान भी नहीं दिया जाएगा, क्योंकि कुछ मामलों में (सभी में नहीं) वही उपयोगकर्ता, F5 दबाने पर, दूसरे, कार्यशील संस्करण पर ले जाया जाएगा।

  नीला/हरा परिनियोजन. मार्ग

  हालाँकि, सब कुछ इतना सरल नहीं है "नीला/हरा परिनियोजन"... हमारे सभी घटकों को तीन समूहों में विभाजित किया जा सकता है:

  • यह फ्रंटएंड है (भुगतान पृष्ठ जो हमारे ग्राहक देखते हैं);
  • प्रसंस्करण कोर;
  • भुगतान प्रणालियों (बैंक, मास्टरकार्ड, वीज़ा...) के साथ काम करने के लिए एडाप्टर।

  और यहां एक बारीकियां है - बारीकियां लाइनों के बीच रूटिंग में निहित है। यदि आप 100% ट्रैफ़िक स्विच करते हैं, तो आपको ये समस्याएँ नहीं होंगी। लेकिन यदि आप 2% स्विच करना चाहते हैं, तो आप प्रश्न पूछना शुरू कर देते हैं: "यह कैसे करें?" सबसे सरल बात सीधी है: आप यादृच्छिक विकल्प द्वारा nginx में राउंड रॉबिन सेट कर सकते हैं, और आपके पास बाईं ओर 2%, दाईं ओर 98% है। लेकिन यह हमेशा उपयुक्त नहीं होता.

  उदाहरण के लिए, हमारे मामले में, एक उपयोगकर्ता एक से अधिक अनुरोधों के साथ सिस्टम के साथ इंटरैक्ट करता है। यह सामान्य है: 2, 3, 4, 5 अनुरोध - आपके सिस्टम समान हो सकते हैं। और यदि आपके लिए यह महत्वपूर्ण है कि उपयोगकर्ता के सभी अनुरोध उसी पंक्ति पर आते हैं जिस पर पहला अनुरोध आया था, या (दूसरा बिंदु) स्विच के बाद उपयोगकर्ता के सभी अनुरोध नई लाइन पर आते हैं (वह पहले से ही काम करना शुरू कर सकता था) सिस्टम, स्विच से पहले), - तो यह यादृच्छिक वितरण आपके लिए उपयुक्त नहीं है। फिर निम्नलिखित विकल्प हैं:

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

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

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

  इसलिए, हम चौथे विकल्प पर आए। हमने स्टेरॉयड पर nginx लिया (यह openresty है) - यह वही nginx है, जो अतिरिक्त रूप से अंतिम स्क्रिप्ट को शामिल करने का समर्थन करता है। आप एक अंतिम स्क्रिप्ट लिख सकते हैं, इसे "ओपन रेस्ट" दे सकते हैं, और उपयोगकर्ता का अनुरोध आने पर यह अंतिम स्क्रिप्ट निष्पादित की जाएगी।

  और हमने, वास्तव में, ऐसी एक स्क्रिप्ट लिखी, खुद को "ओपनरेस्टी" सेट किया और इस स्क्रिप्ट में हम "या" संयोजन द्वारा 6 अलग-अलग मापदंडों को क्रमबद्ध करते हैं। एक या दूसरे पैरामीटर की उपस्थिति के आधार पर, हम जानते हैं कि उपयोगकर्ता एक पृष्ठ या दूसरे, एक पंक्ति या किसी अन्य पर आया था।

  नीला/हरा परिनियोजन. फायदे और नुकसान

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

  
  
  इसलिए, यह हमारे काम नहीं आया - हमने ओपनरेस्टी की। तदनुसार, रूटिंग से हमें कुछ इस तरह मिला:

  तदनुसार, नीले/हरे परिनियोजन के फायदे और नुकसान दोनों हैं जिनका मैंने उल्लेख किया है।

  दो नुकसान:

  • आपको रूटिंग से परेशान होने की ज़रूरत है;
  • दूसरा मुख्य नुकसान है खर्च.

  आपको दोगुने सर्वर की आवश्यकता है, आपको दोगुने परिचालन संसाधनों की आवश्यकता है, आपको इस पूरे चिड़ियाघर को बनाए रखने के लिए दोगुने प्रयास खर्च करने की आवश्यकता है।

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

  त्वरित तैनाती कैसे करें?

  हमने इस बारे में बात की कि न्यूनतमकरण और त्वरित रोलबैक की समस्या को कैसे हल किया जाए, लेकिन सवाल यह है: "जल्दी से कैसे तैनात करें?"

  
  
  यहाँ यह संक्षिप्त और सरल है।

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

    एक कलाकृति क्या है? एक आर्टिफैक्ट एक असेंबल किया गया निर्माण है जिसमें सभी असेंबली भाग पहले ही पूरे हो चुके होते हैं। हम इस कलाकृति को कलाकृति भंडारण में संग्रहीत करते हैं। एक समय में हम ऐसे दो स्टोरेज का उपयोग करते थे - यह नेक्सस था और अब जेफ्रॉग आर्टिफैक्टरी)। हमने शुरुआत में "नेक्सस" का उपयोग किया क्योंकि हमने जावा अनुप्रयोगों में इस दृष्टिकोण का अभ्यास करना शुरू कर दिया था (यह इसके लिए उपयुक्त था)। फिर उन्होंने PHP में लिखे कुछ एप्लिकेशन वहां डाल दिए; और "नेक्सस" अब उपयुक्त नहीं था, और इसलिए हमने जेफ्रॉग आर्टेफैक्ट्री को चुना, जो लगभग हर चीज को आर्टिफैक्टराइज कर सकता है। हम यहां तक ​​पहुंच गए हैं कि इस आर्टिफैक्ट भंडार में हम अपने स्वयं के बाइनरी पैकेज संग्रहीत करते हैं जिन्हें हम सर्वर के लिए एकत्र करते हैं।

  विस्फोटक भार वृद्धि

  हमने सॉफ़्टवेयर संस्करण बदलने के बारे में बात की। अगली चीज़ जो हमारे पास है वह है भार में विस्फोटक वृद्धि। यहाँ, मेरा आशय संभवतः भार की विस्फोटक वृद्धि से है जो बिल्कुल सही चीज़ नहीं है...

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

  और यहां यह पता चला है कि आपको किसी भी तरह से श्रमिकों को स्केल करने की आवश्यकता है, आपको किसी तरह से अपनी सेवाओं को स्केल करने की आवश्यकता है, लेकिन साथ ही संसाधन ब्लॉट को रोकने की भी आवश्यकता है।

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

  यह हमारे लिए समस्या क्यों है? चलिए थोड़ा पीछे चलते हैं. अब हमारे पास लगभग 70 भुगतान प्रणालियाँ हैं। उदाहरण के लिए, सुबह में ट्रैफ़िक Sberbank से होकर गुजरता है, फिर Sberbank गिर जाता है, और हम इसे किसी अन्य भुगतान प्रणाली पर स्विच कर देते हैं। सर्बैंक से पहले हमारे पास 100 कर्मचारी थे, और उसके बाद हमें एक और भुगतान प्रणाली के लिए 100 कर्मचारियों को तेजी से बढ़ाने की जरूरत है। और यह सब मानवीय भागीदारी के बिना होना वांछनीय है। क्योंकि अगर मानवीय भागीदारी है, तो वहां 24/7 एक इंजीनियर बैठा होना चाहिए, जिसे केवल यही करना चाहिए, क्योंकि ऐसी विफलताएं, जब 70 सिस्टम आपके पीछे हों, नियमित रूप से होती रहती हैं।

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

  अभी तक हमने इसे ओपन सोर्स नहीं किया है, लेकिन अगर रिपोर्ट के बाद अचानक यह एहसास हो कि आपको ऐसी किसी चीज की जरूरत है, आपको इसकी जरूरत है, मेरे संपर्क आखिरी स्लाइड में हैं - कृपया मुझे लिखें। यदि कम से कम 3-5 लोग हों तो हम इसे प्रायोजित करेंगे।

  
  
  यह काम किस प्रकार करता है? आइये एक नजर डालते हैं! आगे देखते हुए: बाईं ओर हमारी निगरानी का एक टुकड़ा है: यह एक पंक्ति है, शीर्ष पर घटना प्रसंस्करण का समय है, मध्य में लेनदेन की संख्या है, नीचे श्रमिकों की संख्या है।

  अगर आप देखेंगे तो इस तस्वीर में एक गड़बड़ी है. शीर्ष चार्ट पर, एक चार्ट 45 सेकंड में क्रैश हो गया - एक भुगतान प्रणाली बंद हो गई। तुरंत, 2 मिनट में ट्रैफ़िक लाया गया और कतार दूसरी भुगतान प्रणाली पर बढ़ने लगी, जहाँ कोई कर्मचारी नहीं थे (हमने संसाधनों का उपयोग नहीं किया - इसके विपरीत, हमने संसाधन का सही ढंग से निपटान किया)। हम गर्मी नहीं लगाना चाहते थे - वहाँ न्यूनतम संख्या थी, लगभग 5-10 कर्मचारी, लेकिन वे सामना नहीं कर सके।

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

  निगरानी. समस्या की शीघ्र पहचान कैसे करें?

  अब पहला बिंदु यह है कि "समस्या को शीघ्रता से कैसे पहचानें?" निगरानी! हमें कुछ बातें जल्दी समझ लेनी चाहिए. हमें कौन सी बातें जल्दी समझ लेनी चाहिए?

  
  
  तीन बातें!

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

  मैं शायद आपको यहां कुछ भी अच्छा नहीं बताऊंगा। मैं स्पष्ट कैप्टन बनूँगा। हमने देखा कि बाज़ार में क्या था। हमारे पास एक "मज़ेदार चिड़ियाघर" है। इस प्रकार का चिड़ियाघर अब हमारे पास है:

  
  
  हम सर्वर के मुख्य संकेतकों की निगरानी के लिए, हार्डवेयर की निगरानी के लिए ज़ैबिक्स का उपयोग करते हैं। हम डेटाबेस के लिए Okmeter का उपयोग करते हैं। हम अन्य सभी संकेतकों के लिए "ग्राफाना" और "प्रोमेथियस" का उपयोग करते हैं जो पहले दो में फिट नहीं होते हैं, कुछ "ग्राफाना" और "प्रोमेथियस" के साथ, और कुछ "ग्राफाना" के साथ "इन्फ्लक्स" और टेलीग्राफ के साथ।

  एक साल पहले हम न्यू रेलिक का उपयोग करना चाहते थे। अच्छी बात है, यह सब कुछ कर सकता है। लेकिन जितनी वह सब कुछ कर सकती है, वह उतनी ही महंगी है। जब हम 1,5 हजार सर्वरों की संख्या तक बढ़ गए, तो एक विक्रेता हमारे पास आया और कहा: "आइए अगले वर्ष के लिए एक समझौता करें।" हमने कीमत देखी और कहा, नहीं, हम ऐसा नहीं करेंगे। अब हम न्यू रेलिक को छोड़ रहे हैं, हमारे पास न्यू रेलिक की निगरानी में लगभग 15 सर्वर बचे हैं। कीमत बिल्कुल बेतहाशा निकली.

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

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

  निगरानी के लिए कौन से संकेतक महत्वपूर्ण हैं?

  हम मुख्य रूप से किसकी निगरानी करते हैं? हमारे लिए कौन से संकेतक महत्वपूर्ण हैं?

  
  

  • मोर्चों पर प्रतिक्रिया समय/आरपीएस एक बहुत ही महत्वपूर्ण संकेतक है। वह तुरंत उत्तर देता है कि आपके साथ कुछ गड़बड़ है।
  • सभी कतारों में संसाधित संदेशों की संख्या.
  • श्रमिकों की संख्या.
  • बुनियादी शुद्धता मेट्रिक्स.

  अंतिम बिंदु "व्यवसाय", "व्यवसाय" मीट्रिक है। यदि आप एक ही चीज़ की निगरानी करना चाहते हैं, तो आपको एक या दो मैट्रिक्स को परिभाषित करने की आवश्यकता है जो आपके लिए मुख्य संकेतक हैं। हमारा मीट्रिक थ्रूपुट है (यह सफल लेनदेन की संख्या और कुल लेनदेन प्रवाह का अनुपात है)। यदि 5-10-15 मिनट के अंतराल पर इसमें कुछ परिवर्तन होता है, तो इसका मतलब है कि हमें समस्याएँ हैं (यदि यह मौलिक रूप से बदलता है)।

  यह हमारे लिए कैसा दिखता है यह हमारे एक बोर्ड का उदाहरण है:

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

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

  
  
  ग्राफ़ हमें दिखाता है कि भुगतान प्रणालियों में से एक ने 3 सेकंड में प्रतिक्रिया देना शुरू कर दिया - हमें समस्याएं हैं। इसके अलावा, समस्या शुरू होने पर यह चीज़ 20-30 सेकंड के अंतराल पर प्रतिक्रिया करेगी।

  और निगरानी त्रुटियों का तीसरा वर्ग जो मौजूद है वह तार्किक निगरानी है।

  सच कहूँ तो, मुझे नहीं पता था कि इस स्लाइड पर क्या बनाया जाए, क्योंकि हम लंबे समय से बाज़ार में ऐसी चीज़ की तलाश कर रहे थे जो हमारे लिए उपयुक्त हो। हमें कुछ नहीं मिला, इसलिए हमें इसे स्वयं करना पड़ा।

  
  
  तार्किक निगरानी से मेरा क्या तात्पर्य है? ठीक है, कल्पना कीजिए: आप अपने लिए एक सिस्टम बनाते हैं (उदाहरण के लिए, एक टिंडर क्लोन); आपने इसे बनाया, इसे लॉन्च किया। सफल प्रबंधक वास्या पुपकिन ने इसे अपने फोन पर डाला, वहां एक लड़की को देखा, उसे पसंद किया... और यह बात लड़की के पास नहीं गई - यह बात उसी बिजनेस सेंटर के सुरक्षा गार्ड मिखाइलच के पास गई। प्रबंधक नीचे जाता है, और फिर आश्चर्य करता है: "यह सुरक्षा गार्ड मिखाइल उसे देखकर इतनी प्रसन्नता से क्यों मुस्कुराता है?"

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

  यह इस बारे में था कि समस्या को शीघ्रता से कैसे पहचाना जाए।

  तैनाती के कारणों का निर्धारण कैसे करें

  समस्याओं का तीसरा समूह जिसे हम हल करते हैं, समस्या की पहचान करने के बाद, इससे छुटकारा पाने के बाद, विकास के कारण को समझना, परीक्षण करना और इसके बारे में कुछ करना अच्छा होगा। तदनुसार, हमें जांच करने की आवश्यकता है, हमें लॉग बढ़ाने की आवश्यकता है।

  
  
  यदि हम लॉग के बारे में बात कर रहे हैं (मुख्य कारण लॉग है), तो हमारे अधिकांश लॉग ईएलके स्टैक में हैं - लगभग सभी के पास समान हैं। कुछ के लिए, यह ईएलके में नहीं हो सकता है, लेकिन यदि आप गीगाबाइट में लॉग लिखते हैं, तो देर-सबेर आप ईएलके में आ जाएंगे। हम उन्हें टेराबाइट्स में लिखते हैं।

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

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

  हमने "जैगर" को देखा: आप एप्लिकेशन को इंस्ट्रूमेंट कर सकते हैं, आप एपीआई में लिख सकते हैं (उस समय PHP के लिए एपीआई मानक, हालांकि, अनुमोदित नहीं था - यह एक साल पहले था, लेकिन अब इसे पहले ही मंजूरी दे दी गई है), लेकिन वहां बिल्कुल कोई ग्राहक नहीं था. "ठीक है," हमने सोचा, और अपने ग्राहक को लिखा। हमें क्या मिला? यह मोटे तौर पर ऐसा दिखता है:

  
  
  जैगर में, प्रत्येक संदेश के लिए स्पैन बनाए जाते हैं। अर्थात्, जब कोई उपयोगकर्ता सिस्टम खोलता है, तो उसे प्रत्येक आने वाले अनुरोध के लिए एक या दो ब्लॉक दिखाई देते हैं (1-2-3 - उपयोगकर्ता से आने वाले अनुरोधों की संख्या, ब्लॉकों की संख्या)। उपयोगकर्ताओं के लिए इसे आसान बनाने के लिए, हमने लॉग और टाइम ट्रेस में टैग जोड़े हैं। तदनुसार, किसी त्रुटि की स्थिति में, हमारा एप्लिकेशन उचित त्रुटि टैग के साथ लॉग को चिह्नित करेगा। आप त्रुटि टैग द्वारा फ़िल्टर कर सकते हैं और केवल वे स्पैन जिनमें त्रुटि वाला यह ब्लॉक शामिल है, प्रदर्शित होंगे। यदि हम विस्तार का विस्तार करते हैं तो यह ऐसा दिखता है:

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

  तदनुसार, चीजें हमारे लिए अच्छी रहीं। हमने अपना स्वयं का एक्सटेंशन लिखा और हमने इसे ओपन सोर्स किया। यदि आप ट्रेसिंग के साथ काम करना चाहते हैं, यदि आप PHP में "जैगर" के साथ काम करना चाहते हैं, तो हमारा एक्सटेंशन है, उपयोग करने के लिए आपका स्वागत है, जैसा कि वे कहते हैं:

  
  
  हमारे पास यह एक्सटेंशन है - यह ओपनट्रेसिंग एपीआई के लिए एक क्लाइंट है, इसे php-एक्सटेंशन के रूप में बनाया गया है, यानी आपको इसे असेंबल करना होगा और सिस्टम पर इंस्टॉल करना होगा। एक साल पहले कुछ भी अलग नहीं था. अब अन्य ग्राहक भी हैं जो घटकों की तरह हैं। यहां यह आप पर निर्भर है: या तो आप कंपोजर के साथ घटकों को पंप करते हैं, या आप अपने ऊपर एक्सटेंशन का उपयोग करते हैं।

  कॉर्पोरेट मानक

  हमने तीन आज्ञाओं के बारे में बात की। चौथी आज्ञा दृष्टिकोणों को मानकीकृत करना है। इसके बारे में क्या है? यह इस बारे में है:

  
  
  यहाँ "कॉर्पोरेट" शब्द क्यों है? इसलिए नहीं कि हम कोई बड़ी या नौकरशाही कंपनी हैं, नहीं! मैं यहां "कॉर्पोरेट" शब्द का उपयोग इस संदर्भ में करना चाहता था कि हर कंपनी, हर उत्पाद के अपने मानक होने चाहिए, जिनमें आप भी शामिल हैं। हमारे पास क्या मानक हैं?

  
  

  • हमारे पास तैनाती नियम हैं। हम उसके बिना कहीं नहीं जा सकते, हम नहीं जा सकते। हम सप्ताह में लगभग 60 बार तैनात करते हैं, यानी हम लगभग लगातार तैनात करते हैं। उसी समय, उदाहरण के लिए, हमारे पास तैनाती नियमों में शुक्रवार को तैनाती पर एक निषेध है - सिद्धांत रूप में, हम तैनाती नहीं करते हैं।
  • हमें दस्तावेज़ीकरण की आवश्यकता है. यदि इसके लिए कोई दस्तावेज नहीं है तो एक भी नया घटक उत्पादन में नहीं आता है, भले ही वह हमारे आरएनडी विशेषज्ञों की कलम से पैदा हुआ हो। हमें उनसे परिनियोजन निर्देश, एक निगरानी मानचित्र और एक मोटा विवरण (ठीक है, जैसा कि प्रोग्रामर लिख सकते हैं) की आवश्यकता है कि यह घटक कैसे काम करता है, इसका समस्या निवारण कैसे किया जाए।
  • हम समस्या का कारण नहीं, बल्कि समस्या का समाधान करते हैं - जैसा कि मैंने पहले ही कहा है। उपयोगकर्ता को समस्याओं से बचाना हमारे लिए महत्वपूर्ण है।
  • हमारे पास मंजूरी है. उदाहरण के लिए, यदि हमने दो मिनट के भीतर 2% ट्रैफ़िक खो दिया है तो हम इसे डाउनटाइम नहीं मानते हैं। यह मूलतः हमारे आँकड़ों में शामिल नहीं है। यदि यह प्रतिशत के संदर्भ में अधिक है या अस्थायी है, तो हम पहले ही गिनती कर लेते हैं।
  • और हम हमेशा पोस्टमॉर्टम लिखते हैं। हमारे साथ जो कुछ भी होता है, कोई भी स्थिति जहां किसी ने उत्पादन में असामान्य व्यवहार किया है, वह पोस्टमार्टम में दिखाई देगा। पोस्टमॉर्टम एक दस्तावेज़ है जिसमें आप लिखते हैं कि आपके साथ क्या हुआ, एक विस्तृत समय, आपने इसे ठीक करने के लिए क्या किया और (यह एक अनिवार्य अवरोध है!) भविष्य में ऐसा होने से रोकने के लिए आप क्या करेंगे। यह बाद के विश्लेषण के लिए अनिवार्य और आवश्यक है।

  डाउनटाइम क्या माना जाता है?

  
  
  इस सबका परिणाम क्या हुआ?

  इससे यह तथ्य सामने आया कि (हमें स्थिरता के साथ कुछ समस्याएं थीं, यह ग्राहकों या हमारे लिए उपयुक्त नहीं था) पिछले 6 महीनों में हमारा स्थिरता संकेतक 99,97 था। हम कह सकते हैं कि ये बहुत ज़्यादा नहीं है. हां, हमारे पास प्रयास करने के लिए कुछ है। इस सूचक में से, लगभग आधा स्थिरता है, जैसा कि यह था, हमारी नहीं, बल्कि हमारे वेब एप्लिकेशन फ़ायरवॉल की, जो हमारे सामने खड़ा है और एक सेवा के रूप में उपयोग किया जाता है, लेकिन ग्राहकों को इसकी परवाह नहीं है।

  हमने रात को सोना सीखा. अंत में! छह महीने पहले हम नहीं कर सके। और परिणामों के साथ इस नोट पर, मैं एक नोट बनाना चाहूँगा। कल रात एक परमाणु रिएक्टर की नियंत्रण प्रणाली के बारे में एक अद्भुत रिपोर्ट आई थी। यदि इस प्रणाली को लिखने वाले लोग मेरी बात सुन सकते हैं, तो कृपया भूल जाइए कि मैंने "2% डाउनटाइम नहीं है" के बारे में क्या कहा था। आपके लिए, 2% डाउनटाइम है, भले ही दो मिनट के लिए!

  बस इतना ही! आपके प्रश्न।

  
  

  बैलेंसर्स और डेटाबेस माइग्रेशन के बारे में

  दर्शकों से प्रश्न (इसके बाद - बी): - शुभ संध्या। ऐसी व्यवस्थापक रिपोर्ट के लिए बहुत-बहुत धन्यवाद! आपके बैलेंसर्स के बारे में एक छोटा सा प्रश्न। आपने बताया कि आपके पास एक WAF है, यानी, जैसा कि मैं इसे समझता हूं, आप किसी प्रकार के बाहरी बैलेंसर का उपयोग करते हैं...

  ईके: - नहीं, हम अपनी सेवाओं का उपयोग बैलेंसर के रूप में करते हैं। इस मामले में, WAF हमारे लिए विशेष रूप से DDoS सुरक्षा उपकरण है।

  में: – क्या आप बैलेंसर्स के बारे में कुछ शब्द कह सकते हैं?

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

  में: - एक साधारण प्रश्न भी। यहां नीला/हरा परिनियोजन है। उदाहरण के लिए, डेटाबेस माइग्रेशन के साथ आप क्या करते हैं?

  ईके: - अच्छा प्रश्न! देखिए, नीले/हरे परिनियोजन में हमारे पास प्रत्येक पंक्ति के लिए अलग-अलग कतारें हैं। यानी, अगर हम इवेंट कतारों के बारे में बात कर रहे हैं जो कार्यकर्ता से कार्यकर्ता तक प्रसारित होती हैं, तो नीली रेखा और हरी रेखा के लिए अलग-अलग कतारें होती हैं। यदि हम डेटाबेस के बारे में ही बात कर रहे हैं, तो हमने जानबूझकर इसे जितना संभव हो उतना छोटा कर दिया, व्यावहारिक रूप से सब कुछ कतारों में स्थानांतरित कर दिया; डेटाबेस में हम केवल लेनदेन का ढेर संग्रहीत करते हैं। और हमारा लेनदेन स्टैक सभी लाइनों के लिए समान है। इस संदर्भ में डेटाबेस के साथ: हम इसे नीले और हरे रंग में अलग नहीं करते हैं, क्योंकि कोड के दोनों संस्करणों को पता होना चाहिए कि लेनदेन के साथ क्या हो रहा है।

  दोस्तों, मेरे पास भी आपको प्रोत्साहित करने के लिए एक छोटा सा पुरस्कार है - एक किताब। और सर्वोत्तम प्रश्न के लिए मुझे यह पुरस्कार दिया जाना चाहिए।

  में: - नमस्ते। रिपोर्ट के लिए धन्यवाद. सवाल ये है. आप भुगतानों की निगरानी करते हैं, आप उन सेवाओं की निगरानी करते हैं जिनके साथ आप संचार करते हैं... लेकिन आप कैसे निगरानी करते हैं कि कोई व्यक्ति किसी तरह आपके भुगतान पृष्ठ पर आया, भुगतान किया, और परियोजना ने उसे पैसे का श्रेय दिया? यानी, आप कैसे मॉनिटर करते हैं कि मर्चेंट उपलब्ध है और उसने आपका कॉलबैक स्वीकार कर लिया है?

  ईके: - इस मामले में हमारे लिए "व्यापारी" भुगतान प्रणाली के समान ही बाहरी सेवा है। हम व्यापारी की प्रतिक्रिया की गति की निगरानी करते हैं।

  डेटाबेस एन्क्रिप्शन के बारे में

  में: - नमस्ते। मेरे पास थोड़ा संबंधित प्रश्न है। आपके पास PCI DSS संवेदनशील डेटा है. मैं जानना चाहता था कि आप पैन को उन कतारों में कैसे संग्रहीत करते हैं जिन्हें आपको स्थानांतरित करने की आवश्यकता है? क्या आप किसी एन्क्रिप्शन का उपयोग करते हैं? और यह दूसरे प्रश्न की ओर ले जाता है: पीसीआई डीएसएस के अनुसार, परिवर्तनों (प्रशासकों की बर्खास्तगी, आदि) के मामले में डेटाबेस को समय-समय पर फिर से एन्क्रिप्ट करना आवश्यक है - इस मामले में पहुंच का क्या होता है?

  
  
  ईके: - अद्भुत प्रश्न! सबसे पहले, हम पैन को कतार में संग्रहीत नहीं करते हैं। सिद्धांत रूप में, हमारे पास पैन को स्पष्ट रूप में कहीं भी संग्रहीत करने का अधिकार नहीं है, इसलिए हम एक विशेष सेवा का उपयोग करते हैं (हम इसे "केडेमन" कहते हैं) - यह एक ऐसी सेवा है जो केवल एक ही काम करती है: यह इनपुट के रूप में एक संदेश प्राप्त करती है और भेजती है एक एन्क्रिप्टेड संदेश बाहर. और हम इस एन्क्रिप्टेड संदेश के साथ सब कुछ संग्रहीत करते हैं। तदनुसार, हमारी कुंजी लंबाई एक किलोबाइट से कम है, इसलिए यह गंभीर और विश्वसनीय है।

  में: – क्या अब आपको 2 किलोबाइट की आवश्यकता है?

  ईके: - ऐसा लगता है जैसे कल ही यह 256 था... अच्छा, और कहाँ?!

  तदनुसार, यह पहला है। और दूसरी बात, जो समाधान मौजूद है, वह पुन: एन्क्रिप्शन प्रक्रिया का समर्थन करता है - "केक" (कुंजी) के दो जोड़े हैं, जो एन्क्रिप्ट करने वाले "डेक" देते हैं (कुंजी कुंजी हैं, डेक एन्क्रिप्ट करने वाली कुंजी के व्युत्पन्न हैं) . और यदि प्रक्रिया शुरू की जाती है (यह नियमित रूप से होता है, 3 महीने से लेकर ± कुछ तक), तो हम "केक" की एक नई जोड़ी डाउनलोड करते हैं, और हम डेटा को फिर से एन्क्रिप्ट करते हैं। हमारे पास अलग-अलग सेवाएँ हैं जो सभी डेटा को हटा देती हैं और उसे नए तरीके से एन्क्रिप्ट करती हैं; डेटा को उस कुंजी के पहचानकर्ता के बगल में संग्रहीत किया जाता है जिसके साथ इसे एन्क्रिप्ट किया गया है। तदनुसार, जैसे ही हम डेटा को नई कुंजी के साथ एन्क्रिप्ट करते हैं, हम पुरानी कुंजी को हटा देते हैं।

  कभी-कभी भुगतान मैन्युअल रूप से करने की आवश्यकता होती है...

  में: - यानी, अगर किसी ऑपरेशन के लिए रिफंड आ गया है, तो क्या आप अभी भी इसे पुरानी कुंजी से डिक्रिप्ट करेंगे?

  ईके: - हाँ।

  में: – फिर एक और छोटा सा सवाल. जब किसी प्रकार की विफलता, गिरावट या घटना होती है, तो लेनदेन को मैन्युअल रूप से आगे बढ़ाना आवश्यक है। ऐसी स्थिति है.

  ईके: - हाँ कभी कभी।

  में: – आपको यह डेटा कहां से मिलता है? या क्या आप स्वयं इस भंडारण सुविधा में जाते हैं?

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

  
  
  में: - मेरे पास दो सवाल है। उनमें से एक पीसीआई डीएसएस ज़ोन की निरंतरता है: आप उनके सर्किट को कैसे लॉग करते हैं? यह प्रश्न इसलिए है क्योंकि डेवलपर लॉग में कुछ भी डाल सकता था! दूसरा प्रश्न: आप हॉटफ़िक्स कैसे रोल आउट करते हैं? डेटाबेस में हैंडल एक विकल्प है, लेकिन मुफ्त हॉट-फ़िक्सेस हो सकते हैं - वहां की प्रक्रिया क्या है? और तीसरा प्रश्न संभवतः आरटीओ, आरपीओ से संबंधित है। आपकी उपलब्धता 99,97 थी, लगभग चार नौ, लेकिन जैसा कि मैं इसे समझता हूं, आपके पास एक दूसरा डेटा सेंटर, एक तीसरा डेटा सेंटर और पांचवां डेटा सेंटर है... आप उन्हें कैसे सिंक्रनाइज़ करते हैं, उन्हें दोहराते हैं, और बाकी सब कुछ?

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

  "चार नौ" के बारे में। अब हमारे पास जो आंकड़ा है वह वास्तव में हासिल कर लिया गया है, और हमने दूसरे डेटा सेंटर में इसके लिए प्रयास किया। अब हमारे पास दूसरा डेटा सेंटर है, और हम उनके बीच रूट करना शुरू कर रहे हैं, और क्रॉस-डेटा सेंटर प्रतिकृति का मुद्दा वास्तव में एक गैर-तुच्छ प्रश्न है। हमने एक ही समय में विभिन्न तरीकों का उपयोग करके इसे हल करने की कोशिश की: हमने उसी "टारेंटयुला" का उपयोग करने की कोशिश की - यह हमारे लिए काम नहीं आया, मैं आपको तुरंत बताऊंगा। इसीलिए हमने "सेंस" को मैन्युअल रूप से ऑर्डर करना शुरू कर दिया। वास्तव में, हमारे सिस्टम में प्रत्येक एप्लिकेशन डेटा केंद्रों के बीच अतुल्यकालिक रूप से आवश्यक "परिवर्तन - किया गया" सिंक्रनाइज़ेशन चलाता है।

  में: - यदि आपको दूसरा मिल गया, तो आपको तीसरा क्यों नहीं मिला? क्योंकि अभी तक किसी का भी दिमाग ख़राब नहीं हुआ है...

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

  में: - शुभ संध्या। रिपोर्ट के लिए धन्यवाद. आपने अपने डिबगर के बारे में बात की, जो उत्पादन में कुछ परीक्षण लेनदेन चलाता है। लेकिन हमें परीक्षण लेनदेन के बारे में बताएं! यह कितनी गहराई तक जाता है?

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

  में: -आप इसे कहां से काटते हैं? यहां कोर ने भेजा...

  ईके: - हम इस मामले में परीक्षण लेनदेन के लिए "कोर" से पीछे हैं... हमारे पास रूटिंग जैसी कोई चीज़ है: "कोर" जानता है कि किस भुगतान प्रणाली को भेजना है - हम एक नकली भुगतान प्रणाली को भेजते हैं, जो केवल एक http सिग्नल देता है और बस इतना ही।

  में: - कृपया मुझे बताएं, क्या आपका आवेदन एक विशाल मोनोलिथ में लिखा गया था, या आपने इसे कुछ सेवाओं या माइक्रोसर्विसेज में भी काट दिया था?

  ईके: - हमारे पास एक मोनोलिथ नहीं है, बेशक, हमारे पास एक सेवा-उन्मुख एप्लिकेशन है। हम मज़ाक करते हैं कि हमारी सेवा मोनोलिथ से बनी है - वे वास्तव में काफी बड़े हैं। इसे माइक्रोसर्विसेज कहना कठिन है, लेकिन ये ऐसी सेवाएँ हैं जिनके अंतर्गत वितरित मशीनों के कर्मचारी काम करते हैं।

  यदि सर्वर पर सेवा से समझौता किया गया है...

  में: - फिर मेरा अगला प्रश्न है। भले ही यह एक मोनोलिथ था, फिर भी आपने कहा कि आपके पास इनमें से कई इंस्टेंट सर्वर हैं, वे सभी मूल रूप से डेटा प्रोसेस करते हैं, और सवाल यह है: “इंस्टेंट सर्वर या किसी एप्लिकेशन में से किसी एक के समझौता होने की स्थिति में, कोई भी व्यक्तिगत लिंक , क्या उनके पास किसी प्रकार का अभिगम नियंत्रण है? उनमें से कौन क्या कर सकता है? किस जानकारी के लिए मुझे किससे संपर्क करना चाहिए?

  
  
  ईके: - हाँ निश्चित रूप से। सुरक्षा आवश्यकताएँ काफी गंभीर हैं. सबसे पहले, हमारे पास खुले डेटा मूवमेंट हैं, और पोर्ट केवल वे हैं जिनके माध्यम से हम ट्रैफ़िक मूवमेंट का पहले से अनुमान लगाते हैं। यदि कोई घटक 5-4-3-2 के माध्यम से डेटाबेस (मान लीजिए, मस्कुल के साथ) के साथ संचार करता है, तो केवल 5-4-3-2 ही उसके लिए खुला होगा, और अन्य पोर्ट और अन्य ट्रैफ़िक दिशा-निर्देश उपलब्ध नहीं होंगे। इसके अलावा, आपको यह समझने की आवश्यकता है कि हमारे उत्पादन में लगभग 10 अलग-अलग सुरक्षा लूप हैं। और भले ही एप्लिकेशन के साथ किसी तरह से छेड़छाड़ की गई हो, भगवान न करे, हमलावर सर्वर प्रबंधन कंसोल तक नहीं पहुंच पाएगा, क्योंकि यह एक अलग नेटवर्क सुरक्षा क्षेत्र है।

  में: - और इस संदर्भ में, मेरे लिए जो अधिक दिलचस्प है वह यह है कि आपके पास सेवाओं के साथ कुछ अनुबंध हैं - वे क्या कर सकते हैं, किन "कार्यों" के माध्यम से वे एक-दूसरे से संपर्क कर सकते हैं... और सामान्य प्रवाह में, कुछ विशिष्ट सेवाएँ कुछ अनुरोध करती हैं पंक्ति, दूसरी ओर "क्रियाओं" की एक सूची। ऐसा प्रतीत होता है कि वे सामान्य स्थिति में दूसरों की ओर रुख नहीं करते हैं, और उनके पास ज़िम्मेदारी के अन्य क्षेत्र भी हैं। यदि उनमें से किसी एक के साथ समझौता किया जाता है, तो क्या यह उस सेवा के "कार्यों" को बाधित करने में सक्षम होगा?..

  ईके: - मैं समझता हूँ। यदि सामान्य स्थिति में किसी अन्य सर्वर के साथ संचार की अनुमति थी, तो हाँ। एसएलए अनुबंध के अनुसार, हम इस बात की निगरानी नहीं करते हैं कि आपको केवल पहले 3 "कार्यों" की अनुमति है, और आपको 4 "कार्यों" की अनुमति नहीं है। यह शायद हमारे लिए अनावश्यक है, क्योंकि हमारे पास पहले से ही सर्किट के लिए सिद्धांत रूप में 4-स्तरीय सुरक्षा प्रणाली है। हम अंदरूनी स्तर के बजाय आकृतियों से अपना बचाव करना पसंद करते हैं।

  वीज़ा, मास्टरकार्ड और सर्बैंक कैसे काम करते हैं

  में: - मैं उपयोगकर्ता को एक डेटा सेंटर से दूसरे डेटा सेंटर में स्विच करने के बारे में एक बिंदु स्पष्ट करना चाहता हूं। जहाँ तक मुझे पता है, वीज़ा और मास्टरकार्ड 8583 बाइनरी सिंक्रोनस प्रोटोकॉल का उपयोग करके काम करते हैं, और वहाँ मिश्रण हैं। और मैं जानना चाहता था, अब हमारा मतलब स्विचिंग से है - क्या यह सीधे "वीज़ा" और "मास्टरकार्ड" है या भुगतान प्रणाली से पहले, प्रसंस्करण से पहले?

  ईके: - यह मिश्रण से पहले है. हमारे मिश्रण एक ही डेटा सेंटर में स्थित हैं।

  में: - मोटे तौर पर कहें तो, क्या आपके पास एक कनेक्शन बिंदु है?

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

  में: - उन्हें कैसे आरक्षित किया जा सकता है? मैं जानता हूं कि वीज़ा सैद्धांतिक रूप से केवल एक कनेक्शन की अनुमति देता है!

  ईके: - वे उपकरण की आपूर्ति स्वयं करते हैं। किसी भी स्थिति में, हमें ऐसे उपकरण प्राप्त हुए जो अंदर से पूरी तरह से अनावश्यक हैं।

  में: – तो स्टैंड उनके कनेक्ट्स ऑरेंज से है?..

  ईके: - हाँ।

  में: - लेकिन इस मामले में क्या: यदि आपका डेटा सेंटर गायब हो जाता है, तो आप इसका उपयोग कैसे जारी रख सकते हैं? या यातायात यूं ही रुक जाता है?

  ईके: - नहीं। इस मामले में, हम बस ट्रैफ़िक को दूसरे चैनल पर स्विच कर देंगे, जो स्वाभाविक रूप से हमारे लिए अधिक महंगा होगा और हमारे ग्राहकों के लिए अधिक महंगा होगा। लेकिन ट्रैफ़िक वीज़ा, मास्टरकार्ड से हमारे सीधे कनेक्शन के माध्यम से नहीं, बल्कि सशर्त Sberbank (बहुत अतिरंजित) के माध्यम से जाएगा।

  अगर मैंने सर्बैंक के कर्मचारियों को ठेस पहुंचाई है तो मैं माफी मांगता हूं। लेकिन हमारे आँकड़ों के अनुसार, रूसी बैंकों में सेर्बैंक सबसे अधिक बार गिरता है। ऐसा कोई महीना नहीं जाता जब सर्बैंक में कुछ न कुछ घटता हो।

  
  
  

  कुछ विज्ञापन 🙂

  हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

  एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com