HighLoad ++, Eugene Kuzovlev (EcommPay IT): क्या करना है जब एक मिनट के डाउनटाइम की लागत $ 100,000 होती है

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



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

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

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

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



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

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

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

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

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

डाउनटाइम। शोषण की आज्ञाएँ।

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



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

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

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

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

समस्या निवारण: जब वे होते हैं और उनके साथ क्या करना है?

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



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

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

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

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

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

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

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

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

सॉफ्टवेयर संस्करण बदलें। अड्डों

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



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

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

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

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

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

  नीला / हरा तैनात। मार्ग

  
  इसके अलावा, सब कुछ इतना आसान नहीं है "ब्लू / ग्रीन डिप्लॉय" ... हमारे सभी घटकों को तीन समूहों में विभाजित किया जा सकता है:
  
  
  • यह फ्रंटएंड (भुगतान पृष्ठ जो हमारे ग्राहक देखते हैं);
  • प्रसंस्करण कोर;
  • भुगतान प्रणालियों (बैंकों, मास्टरकार्ड, वीज़ा ...) के साथ काम करने के लिए एक एडॉप्टर।
  
  और एक nuance है - nuance लाइनों के बीच का मार्ग है। यदि आप बस 100% ट्रैफ़िक स्विच करते हैं, तो आपको ये समस्याएँ नहीं हैं। लेकिन अगर आप 2% स्विच करना चाहते हैं, तो सवाल शुरू होते हैं: "यह कैसे करना है?" माथे पर सबसे सरल बात: आप nginx में राउंड रॉबिन को बेतरतीब ढंग से चुन सकते हैं, और आपके पास 2% बचे हैं, 98% - दाईं ओर। लेकिन यह हमेशा उपयुक्त नहीं होता है।
  
  यहां, उदाहरण के लिए, उपयोगकर्ता एक से अधिक अनुरोधों में सिस्टम के साथ इंटरैक्ट करता है। यह सामान्य है: 2, 3, 4, 5 प्रश्न - आपके सिस्टम समान हो सकते हैं। और अगर आपके लिए यह महत्वपूर्ण है कि सभी उपयोगकर्ता अनुरोध एक ही पंक्ति में आते हैं जो पहला अनुरोध आया था, या (दूसरे क्षण) सभी उपयोगकर्ता अनुरोध स्विच करने के बाद एक नई लाइन में आते हैं (वह स्विच करने से पहले सिस्टम के साथ काम करना शुरू कर सकता है), - तब यह यादृच्छिक वितरण आपको शोभा नहीं देता। फिर निम्नलिखित विकल्प हैं:
  
  
  
  पहला विकल्प, सबसे आसान - क्लाइंट के बुनियादी मापदंडों (आईपी हैश) पर आधारित है। आपके पास एक IP है, और आप IP द्वारा दाएँ-से-बाएँ साझा करते हैं। फिर मेरे द्वारा वर्णित दूसरा मामला आपके लिए काम करेगा जब एक तैनाती थी, उपयोगकर्ता पहले से ही आपके सिस्टम के साथ काम करना शुरू कर सकता है, और तैनाती के क्षण से सभी अनुरोध एक नई लाइन (उसी के लिए, कहेंगे) में जाएंगे।
  
  यदि किसी कारण से यह आपको सूट नहीं करता है और आपको उस पंक्ति में अनुरोध भेजने की आवश्यकता है जहां उपयोगकर्ता का प्राथमिक, अंतरंग अनुरोध आया है, तो आपके पास दो विकल्प हैं ...
  पहला विकल्प: आप पेड नगनेक्स + ले सकते हैं। एक स्टिकी सत्र तंत्र है, जो उपयोगकर्ता के प्रारंभिक अनुरोध पर, उपयोगकर्ता के लिए एक सत्र को उजागर करता है और इसे एक विशेष अपस्ट्रीम में बांधता है। सत्र के जीवनकाल के बाद के सभी उपयोगकर्ता अनुरोध उसी अपस्ट्रीम पर जाएंगे जहां सत्र सेट किया गया था।
  
  यह हमें शोभा नहीं देता, क्योंकि हमारे पास पहले से ही नग्नेक्स सामान्य था। निगंक्स + को स्विच करना यह नहीं है कि यह महंगा है, यह सिर्फ हमारे लिए थोड़ा दर्दनाक था और बहुत सही नहीं है। उदाहरण के लिए, "स्टिक्स सेशंस" ने हमारे लिए इस सरल कारण से काम नहीं किया कि "स्टिक्स सत्र" "एली-या" के आधार पर रूट करने का अवसर प्रदान नहीं करते हैं। वहाँ आप निर्दिष्ट कर सकते हैं कि हम "स्टिकी सेशंस" क्या करते हैं, उदाहरण के लिए, आईपी या आईपी और कुकी या पोस्ट पैरामीटर द्वारा, लेकिन "एली-या" पहले से ही अधिक जटिल है।
  
  इसलिए, हम चौथे विकल्प पर आए। हमने "स्टेरॉयड" पर nginx लिया (यह खुलापन है) - यह वही nginx है जो इसके अलावा अंतिम-लिपियों को शामिल करने का समर्थन करता है। आप एक आखिरी-स्क्रिप्ट लिख सकते हैं, इस "ओपन" को स्लिप कर सकते हैं, और जब यूजर रिक्वेस्ट आएगा तो इस लास्ट-स्क्रिप्ट को निष्पादित किया जाएगा।
  
  और हमने लिखा है, वास्तव में, इस तरह की एक स्क्रिप्ट, खुद को "ओपनरेस्ट" सेट करती है और इस स्क्रिप्ट में हम "या" के संयोजन के लिए 6 अलग-अलग मापदंडों के माध्यम से सॉर्ट करते हैं। इस या उस पैरामीटर की उपलब्धता के आधार पर, हम जानते हैं कि उपयोगकर्ता एक पृष्ठ पर या दूसरे से, एक पंक्ति में या दूसरे से आया था।
  
  

  नीला / हरा तैनात। फायदे और नुकसान

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

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

  
  हमने बात की कि कम से कम और त्वरित रोलबैक की समस्या को कैसे हल किया जाए, लेकिन सवाल यह है: "कैसे जल्दी से तैनात करें?"
  
  
  
  यहाँ संक्षिप्त और सरल है।
  
  
  • आपके पास एक सीडी सिस्टम (कंटीन्यूअस डिलीवरी) होना चाहिए - इसके बिना, कहीं नहीं। यदि आपके पास एक सर्वर है, तो आप पेन के साथ फंस सकते हैं। हमारे पास लगभग डेढ़ हजार सर्वर और 1,500 हैंडल हैं, निश्चित रूप से - हम इस कमरे के आकार को केवल तैनात करने के लिए एक विभाग लगा सकते हैं।
  • तैनाती समानांतर होनी चाहिए। यदि आपके पास लगातार तैनाती है, तो सब कुछ खराब है। एक सर्वर सामान्य है, आप पूरे दिन में डेढ़ हजार सर्वरों को तैनात करेंगे।
  • फिर से, तेजी लाने के लिए, यह आवश्यक नहीं है, शायद। जब desploey आमतौर पर परियोजना का निर्माण करता है। क्या आपके पास एक वेब परियोजना है, एक फ्रंट-एंड हिस्सा है (आप वहां एक वेब पैक बनाते हैं, एनपीएम कुछ ऐसा इकट्ठा करता है), और यह प्रक्रिया मूल रूप से अल्पकालिक है - 5 मिनट, लेकिन ये 5 मिनट महत्वपूर्ण हो सकते हैं। इसलिए, उदाहरण के लिए, हम ऐसा नहीं करते हैं: हमने इन 5 मिनटों को हटा दिया, हम कलाकृतियों को तैनात करते हैं।
    
    एक कलाकृति क्या है? एक विरूपण साक्ष्य एक इकट्ठे निर्माण है जिसमें पूरे विधानसभा का हिस्सा पहले ही पूरा हो चुका है। हम इस कलाकृतियों को कलाकृतियों के भंडारण में संग्रहीत करते हैं। हमने एक समय में दो ऐसे स्टोरेज का उपयोग किया था - यह नेक्सस था और अब आर्टिफैक्टिक है।) हमने शुरुआत में नेक्सस का इस्तेमाल किया था क्योंकि हमने जावा एप्लिकेशन में इस दृष्टिकोण का अभ्यास करना शुरू कर दिया था (यह इसे अच्छी तरह से अनुकूल करता है)। फिर उन्होंने PHP द्वारा लिखे गए अनुप्रयोगों का हिस्सा वहां रखा; और नेक्सस अब उपयुक्त नहीं था, और इसलिए हमने jFrog Artefactory को चुना, जो लगभग हर चीज़ को कलाकृत कर सकता है। हमें यह भी पता चला कि कलाकृतियों के इस भंडारण में हम अपने स्वयं के बाइनरी पैकेजों को संग्रहीत करते हैं, जो हम सर्वरों के लिए एकत्र करते हैं।
  
  

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

  
  हमने सॉफ्टवेयर संस्करण को बदलने की बात की। हमारे पास अगली चीज विस्फोटक भार वृद्धि है। यहाँ मुझे शायद यह समझ में आ गया है कि लोड की विस्फोटक वृद्धि काफी सही बात नहीं है ...
  
  हमने एक नई प्रणाली लिखी - यह सेवा-उन्मुख, फैशनेबल सुंदर, हर जगह काम करने वाले, हर जगह कतार में, हर जगह अतुल्यकालिक है। और ऐसी प्रणालियों में, डेटा विभिन्न प्रवाह पर जा सकता है। पहले लेन-देन के लिए, 1, 3, 10 वां कार्यकर्ता शामिल हो सकता है, दूसरे लेनदेन के लिए - 2, 4, 5 वां। और आज, मान लीजिए, सुबह आपके पास एक डेटा स्ट्रीम है जो पहले तीन श्रमिकों का उपयोग करता है, और शाम को यह नाटकीय रूप से बदल जाता है, और सब कुछ अन्य तीन श्रमिकों का उपयोग करता है।
  
  और यहां यह पता चला है कि आपको श्रमिकों को किसी भी तरह से स्केल करने की आवश्यकता है, आपको किसी तरह अपनी सेवाओं को स्केल करने की आवश्यकता है, लेकिन साथ ही संसाधनों के प्रवाह को रोकना है।
  
  
  
  हमने खुद के लिए आवश्यकताओं को निर्धारित किया है। : Service discovery, – , – . , , . «», «», .
  
  ? . 70 . «», «» , , . 100 «», 100 . . , – 24/7 , , , 70 , .
  
  «», IP Scale-Nomad – ScaleNo, : . , : « ?» – , .
  
  , , , , , – , . 3-5 – .
  
  
  
  यह कैसे काम करता है? ! : : , – , – , – .
  
  , . 45 – . 2 , ( – , ). – , 5-10 , .
  
  «», , «» . , , – . . № 2 – « ».
  
  

  . ?

  
  – « ?» ! . ?
  
  
  
  !
  
  
  • .
  • , , .
  • – . , , - .
  
  , , . . , . « ». :
  
  
  
  «» «», . «» . «» «» , , – «» «», – «» «» Telegraf.
  
  New Relic. , . , . 1,5 , , : « ». , , . «-» , 15 «-». .
  
  , – Debugger. «», , , «». यह क्या है , 15-30 , « » , .
  
  , ( ) – , . , «» – , «» . – , , , .
  
  

  ?

  
  ? ?
  
  
  
  
  • Response time / RPS – . , - .
  • .
  • .
  • .
  
  – «», «» . , - , . – ( ). - 5-10-15 – , ( ).
  
  – :
  
  
  
  – 6 , – . – RPS, RTS. – «». «» , - … , .
  
  , – . OpenTracing – , , , ; . OpenTracing- , . , , . , , .
  
  
  
  , 3 – . , , 20-30 .
  
  , – .
  
  , , , , . , .
  
  
  
  ? , : (, «»); , . , , … – -. , : « »?
  
  … -, ( ) , . : – , , ( ). , - . ! . .
  
  , .
  
  
  
  , – , , , , , - . , , .
  
  
  
  ( – ), ELK Stack – . -, , ELK, , ELK. .
  
  
  
  . , , , , «», id- ( ). . क्यों? , , . , – OpenTracing, .
  
  , , – «» (Zipkin) «» (Jaeger). «» – , «». «» , , , , . «» .
  
  «»: , Api ( Api PHP , , – , ), . «», – , . ? :
  
  
  
  «» span'. , , (1-2-3 – , ). , . , Error. Error , . , span:
  
  
  
  . , , . : – , , .
  
  , . , . , «» PHP – , welcome to use, :
  
  
  
  – OpenTracing Api, php-extention, . . , . : , extention up to you.
  
  
  
  . – . ? :
  
  
  
  «»? , ! «» , , , . ?
  
  
  
  
  • . , . 60 , . , , – , .
  • . , , RnD-. , (, ) , , .
  • , – , . .
  • हमारे पास सहिष्णुता है। उदाहरण के लिए, हम डाउनटाइम पर विचार नहीं करते हैं यदि हम दो मिनट के भीतर 2% यातायात खो देते हैं। यह, सिद्धांत रूप में, हमारे आंकड़ों में नहीं आता है। यदि प्रतिशत या समय में अधिक है, तो हम पहले से ही गिनते हैं।
  • और हम हमेशा पोस्टमार्टम लिखते हैं। हमारे साथ जो कुछ भी होता है, वह किसी भी स्थिति में जहां उत्पादन स्थल पर अनुचित व्यवहार किया जाता है, बर्तन में परिलक्षित होगा। पोस्टमार्टम एक दस्तावेज है जिसमें आप लिखते हैं कि आपके साथ क्या हुआ, आपने इसे ठीक करने के लिए क्या किया, इसकी विस्तृत समयावधि और (यह एक अनिवार्य अवरोध है!) भविष्य में ऐसा होने से रोकने के लिए आप क्या करेंगे। यह आवश्यक है, बाद के विश्लेषण के लिए आवश्यक है।
  
  

  डाउनटाइम पर क्या विचार करें?

  
  
  
  यह सब किस ओर ले गया?
  
  यह इस तथ्य की ओर ले गया कि (हमें कुछ निश्चित स्थिरता की समस्या थी, यह पिछले 6 महीनों में ग्राहकों या हमें पसंद नहीं आया), हमारा स्थिरता सूचक 99.97 था। हम कह सकते हैं कि यह बहुत ज्यादा नहीं है। हां, हमारे पास प्रयास करने के लिए कुछ है। इस सूचक का लगभग आधा हिस्सा स्थिरता है, क्योंकि यह हमारा नहीं, बल्कि हमारे वेब एप्लिकेशन फ़ायरवॉल का है, जो हमारे सामने खड़ा है और इसे एक सेवा के रूप में उपयोग किया जाता है, लेकिन यह ग्राहकों के लिए महत्वपूर्ण नहीं है।
  
  हमने रात को सोना सीखा। अंत में! छह महीने पहले, हमें नहीं पता था कि कैसे। और परिणामों के साथ इस नोट पर, मैं एक टिप्पणी करना चाहता हूं। कल रात एक परमाणु रिएक्टर नियंत्रण प्रणाली पर एक अद्भुत रिपोर्ट थी। यदि इस प्रणाली को लिखने वाले लोग मुझे सुनते हैं, तो कृपया मुझे भूल जाओ कि मैंने "2% डाउनटाइम नहीं है" के बारे में क्या कहा। आपके लिए, 2% डाउनटाइम है, भले ही दो मिनट के लिए "!
  
  वह सब है! आपके सवाल
  
  
  
  

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

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

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

  
  प्र: - नमस्कार। मेरे पास एक छोटा सा सवाल है। आपके पास संवेदनशील PCI DSS डेटा है। मैं जानना चाहता था कि आप पैन को कतारों में कैसे स्टोर करते हैं जिसे आपको फेंकने की आवश्यकता है? क्या आप किसी एन्क्रिप्शन का उपयोग करते हैं? और यहां से निम्नलिखित दूसरा सवाल उठता है: पीसीआई डीएसएस पर, परिवर्तन (एडमींस को खारिज करना, और इसी तरह) के मामले में समय-समय पर डेटाबेस को फिर से एन्क्रिप्ट करना आवश्यक है - यह एक्सेसिबिलिटी के साथ कैसे होता है?
  
  
  
  EK: - अद्भुत प्रश्न! सबसे पहले, हम कतारों में पैन स्टोर नहीं करते हैं। हमारे पास पैन को स्टोर करने का अधिकार स्पष्ट रूप से कहीं भी नहीं है, सिद्धांत रूप में, इसलिए, हम एक विशेष सेवा का उपयोग करते हैं (हम इसे "शिक्षाविद" कहते हैं) - यह एक ऐसी सेवा है जो केवल एक ही चीज़ करती है: यह एक संदेश प्राप्त करती है और एक एन्क्रिप्टेड संदेश भेजती है। और हम इस एन्क्रिप्टेड संदेश के साथ सब कुछ संग्रहीत करते हैं। तदनुसार, हमारे लिए महत्वपूर्ण लंबाई किलोबाइट्स के तहत है, ताकि यह गंभीर और विश्वसनीय प्रत्यक्ष हो।
  
  Q: - क्या अब आपको 2 किलोबाइट की आवश्यकता है?
  
  EK: - ऐसा लगता है कि कल यह 256 था ... खैर, और कहाँ?!
  
  तदनुसार, यह पहला है। और दूसरी बात, जो समाधान मौजूद है, वह फिर से एन्क्रिप्शन की प्रक्रिया का समर्थन करता है - "केक" (कुंजी) के दो जोड़े हैं जो "डेक" देते हैं कि एन्क्रिप्ट (कुंजी कुंजी हैं, डीके कुंजी की डेरिवेटिव हैं जो एन्क्रिप्ट करते हैं)। और प्रक्रिया की दीक्षा के मामले में (यह नियमित रूप से 3 महीने से) कुछ तक होता है), हम "केक" की एक नई जोड़ी अपलोड करते हैं, और हमारे पास डेटा फिर से एन्क्रिप्टेड है। हमारे पास अलग-अलग सेवाएं हैं जो सभी डेटा को फाड़ देती हैं, इसे नए तरीके से एन्क्रिप्ट करती हैं; डेटा को मुख्य पहचानकर्ता के पास संग्रहीत किया जाता है जिसके साथ वे एन्क्रिप्ट किए गए हैं। तदनुसार, जैसे ही हम डेटा को नई कुंजी से एन्क्रिप्ट करते हैं, हम पुरानी कुंजी को हटा देते हैं।
  
  

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

  
  Q: - यानि अगर किसी ऑपरेशन के लिए कोई रिटर्न आया है, तो उसे पुरानी चाबी से डिक्रिप्ट करें?
  
  EC: - हाँ।
  
  Q: - फिर एक और छोटा सा सवाल। जब किसी प्रकार की विफलता, गिरावट, घटना होती है, तो लेनदेन को मैनुअल मोड में धकेलना आवश्यक है। ऐसी स्थिति है।
  
  ईके: - हां, यह करता है।
  
  Q: - आपको यह डेटा कहां से मिलेगा? या क्या आप खुद इस स्टोर में पेन लेकर जाते हैं?
  
  ईके: - नहीं, ठीक है, निश्चित रूप से - हमारे पास कुछ प्रकार की बैक-ऑफिस प्रणाली है जिसमें हमारे समर्थन के लिए एक इंटरफ़ेस है। यदि हमें पता नहीं है कि लेन-देन किस स्थिति में है (उदाहरण के लिए, जबकि भुगतान प्रणाली ने टाइमआउट के साथ जवाब नहीं दिया), तो हम एक प्राथमिकता नहीं जानते हैं, अर्थात हम केवल पूर्ण विश्वास के साथ अंतिम स्थिति प्रदान करते हैं। इस मामले में, हम लेनदेन को मैन्युअल प्रसंस्करण के लिए एक विशेष स्थिति में डंप करते हैं। अगले दिन सुबह, जैसे ही समर्थन प्राप्त होता है कि इस तरह के लेनदेन भुगतान प्रणाली में रहते हैं, वे मैन्युअल रूप से उन्हें इस इंटरफ़ेस में संसाधित करते हैं।
  
  
  
  Q: - मेरे पास कुछ सवाल हैं। उनमें से एक पीसीआई डीएसएस ज़ोन की निरंतरता है: आपको उनके लूप लॉग कैसे मिलते हैं? ऐसा सवाल क्योंकि डेवलपर लॉग में कुछ भी डाल सकता है! दूसरा प्रश्न: आप कैसे हॉटफ़िक्स रोल करते हैं? डेटाबेस में पेन एक विकल्प है, लेकिन मुफ्त हॉट-फ़िक्स हो सकता है - वहां क्या प्रक्रिया है? और तीसरा प्रश्न संभवतः आरटीओ, आरपीओ से संबंधित है। आपकी उपलब्धता ९९.९ 7, लगभग चार नाइन थी, लेकिन जैसा कि मैं इसे समझता हूं, आपके पास एक दूसरा डेटा सेंटर, एक तीसरा डेटा सेंटर और एक पांचवा डेटा सेंटर है ... आप उनके सिंक्रनाइज़ेशन, प्रतिकृति, और सब कुछ कैसे करते हैं?
  
  EK: - चलो पहले से शुरू करते हैं। लॉग के बारे में पहला सवाल था? जब हम लॉग लिखते हैं, तो हमारे पास एक परत होती है जो सभी संवेदनशील डेटा को मास्क करती है। वह मुखौटा और अतिरिक्त क्षेत्रों को देखती है। तदनुसार, हमारे लॉग पहले से ही मुखौटा डेटा और एक पीसीआई डीएसएस लूप के साथ बाहर आते हैं। यह परीक्षण विभाग को सौंपे गए नियमित कार्यों में से एक है। वे प्रत्येक कार्य को जांचने के लिए बाध्य हैं, जिसमें वे लॉग भी शामिल हैं जो वे लिखते हैं, और यह कोड समीक्षा में नियमित कार्यों में से एक है, ताकि यह नियंत्रित किया जा सके कि डेवलपर ने कुछ नहीं लिखा है। इसके बाद के सत्यापन को नियमित रूप से सूचना सुरक्षा विभाग द्वारा सप्ताह में एक बार किया जाता है: लॉग को अंतिम दिन के लिए चुन लिया जाता है, और यह सब जांचने के लिए उन्हें टेस्ट सर्वर से एक विशेष स्कैनर-विश्लेषक के माध्यम से चलाया जाता है।
  हॉट फ़िक्स के बारे में। यह हमारी परिनियोजन अनुसूची में शामिल है। हमारे पास हॉटफ़िक्स के बारे में एक अलग आइटम है। हम मानते हैं कि जब हमें आवश्यकता होती है, तो हम घड़ी के आसपास हॉटफ़िक्स तैनात करते हैं। जैसे ही संस्करण को इकट्ठा किया जाता है, जैसे ही इसे चलाया जाता है, जैसे ही हमारे पास विरूपण साक्ष्य होता है, हमें समर्थन से कॉल पर सिस्टम प्रशासक मिलता है, और वह इसे उस समय तैनात करेगा जब यह आवश्यक हो।
  
  "चार नौ के बारे में।" हमारे पास अब जो संख्या है, वास्तव में यह हासिल किया गया था, और हमने इसे दूसरे डेटा सेंटर में मांगा। अब हमारे पास एक दूसरा डेटा सेंटर है, और हम उनके बीच मार्ग शुरू कर रहे हैं, और क्रॉस-डेटा प्रतिकृति केंद्र का सवाल वास्तव में एक गैर-तुच्छ प्रश्न है। हमने इसे अलग-अलग तरीकों से नियत समय में हल करने की कोशिश की: हमने उसी "टारेंटयुला" का उपयोग करने की कोशिश की - यह हमारे लिए काम नहीं करता, मैं अभी कह रहा हूं। इसलिए, हम इस तथ्य पर आए कि हम मैन्युअल रूप से "सनसनी" का क्रम बनाते हैं। हमारे पास वास्तव में प्रत्येक एप्लिकेशन डेटा केंद्रों के बीच आवश्यक सिंक्रोनाइज़ेशन "परिवर्तन - किया" ड्राइव के अतुल्यकालिक मोड में है।
  
  Q: - अगर आपके पास एक दूसरा है, तो तीसरा क्यों नहीं है? क्योंकि अभी तक किसी का भी विभाजन नहीं हुआ है ...
  
  : - और हमारे पास विभाजन-मस्तिष्क नहीं है। इस तथ्य के कारण कि प्रत्येक एप्लिकेशन मल्टीमास्टर को ड्राइव करता है, यह हमारे लिए मायने नहीं रखता है कि अनुरोध किस केंद्र में आया है। हम इस तथ्य के लिए तैयार हैं कि जिस स्थिति में हमारा एक डेटा सेंटर क्रैश हो गया है (हम उस पर लेट रहे हैं) और उपयोगकर्ता के अनुरोध के बीच में एक दूसरे डेटा सेंटर में स्विच किया गया, हम इस उपयोगकर्ता को खोने के लिए तैयार हैं, वास्तव में; लेकिन यह इकाइयाँ होंगी, पूर्ण इकाइयाँ होंगी।
  
  प्र: - शुभ संध्या। रिपोर्ट के लिए धन्यवाद। आपने अपने डिबगर के बारे में बात की, जो उत्पादन में कुछ परीक्षण लेनदेन करता है। लेकिन हमें परीक्षण लेनदेन के बारे में बताएं! यह कितना गहरा है?
  
  ईसी: - यह पूरे घटक के पूर्ण चक्र से गुजरता है। परीक्षण लेनदेन और घटक के लिए मुकाबला एक के बीच कोई अंतर नहीं हैं। और तर्क की दृष्टि से, यह प्रणाली में कुछ अलग परियोजना है, जिस पर केवल परीक्षण लेनदेन का पीछा किया जाता है।
  
  Q: - और आप इसे कहाँ से काटते हैं? इसलिए कोर भेजा ...
  
  : - हम परीक्षण लेनदेन के लिए इस मामले में "कोर" से पीछे हैं ... हमारे पास रूटिंग जैसी एक चीज है: "कोर" को पता है कि किस भुगतान प्रणाली को भेजना है - हम एक नकली भुगतान प्रणाली को भेजते हैं, जो बस एक HTTP- प्रतिक्रिया देता है और वह सब है ।
  
  प्रश्न: - कृपया मुझे बताएं, क्या आपके पास एक विशाल मोनोलिथ में लिखा गया आवेदन है, या आपने इसे कुछ सेवाओं या समरूप सेवाओं के लिए काट दिया है?
  
  : - हमारे पास एक अखंड नहीं है, निश्चित रूप से, हमारे पास एक सेवा-उन्मुख अनुप्रयोग है। हमारे पास एक मजाक है कि हमारे पास मोनोलिथ की सेवा है - वे वास्तव में काफी बड़े हैं। इस भाषा को माइक्रोसर्विसेज कहने से शब्द बिल्कुल नहीं बदलते हैं, लेकिन ये ऐसी सेवाएं हैं जिनके भीतर वितरित मशीन श्रमिक काम करते हैं।
  
  

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

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

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

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

  विज्ञापन का एक सा :)

  
  हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या अपने दोस्तों से, $ 4.99 से डेवलपर्स के लिए क्लाउड-आधारित VPS , एंट्री-लेवल सर्वरों का एक अनोखा एनालॉग , जो आपके लिए हमारे द्वारा ईजाद किया गया था: VPS (KVM) E5-2696 v3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई का समर्थन करके हमें समर्थन दें । $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।
  
  डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?