HighLoad++, Evgeniy Kuzovlev (EcommPay IT): डाउनटाइमच्या एका मिनिटाची किंमत $100000 असेल तेव्हा काय करावे

प्रत्येकजण विकास आणि चाचणी, कर्मचारी प्रशिक्षण, प्रेरणा वाढवण्याच्या प्रक्रियांबद्दल बोलतो, परंतु सेवा डाउनटाइमच्या एका मिनिटासाठी प्रचंड पैसे खर्च होतात तेव्हा या प्रक्रिया पुरेशा नसतात. तुम्ही कठोर SLA अंतर्गत आर्थिक व्यवहार करता तेव्हा काय करावे? समीकरणातून विकास आणि चाचणी घेऊन तुमच्या सिस्टमची विश्वासार्हता आणि दोष सहिष्णुता कशी वाढवायची?

पुढील HighLoad++ परिषद 6 आणि 7 एप्रिल 2020 रोजी सेंट पीटर्सबर्ग येथे आयोजित केली जाईल. साठी तपशील आणि तिकिटे दुवा. नोव्हेंबर 9, 18:00. HighLoad++ मॉस्को 2018, दिल्ली + कोलकाता हॉल. प्रबंध आणि सादरीकरण.

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

EcommPay IT काय करते?

आम्ही कोण आहोत? मी इथे तुझ्यासमोर का उभा आहे? मला इथे काही सांगण्याचा अधिकार का आहे? आणि आम्ही येथे अधिक तपशीलवार कशाबद्दल बोलू?

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

आम्ही आमची सर्व उत्पादने लिहिली आहेत (आणि आमच्याकडे बरीच आहेत - आमच्या मोठ्या आयटी उत्पादनांच्या ओळीत आमच्याकडे सुमारे 16 भिन्न घटक आहेत); आपण स्वतः लिहितो, स्वतःचा विकास करतो. आणि या क्षणी आम्ही दररोज सुमारे एक दशलक्ष व्यवहार करतो (लाखो कदाचित हे सांगण्याचा योग्य मार्ग आहे). आम्ही एक तरुण कंपनी आहोत - आम्ही फक्त सहा वर्षांचे आहोत.

6 वर्षापूर्वी अशी स्टार्टअप होती जेव्हा अगं व्यवसायासोबत आले. ते एका कल्पनेने एकत्र आले (एक कल्पनाशिवाय दुसरे काहीही नव्हते), आणि आम्ही धावलो. कोणत्याही स्टार्टअपप्रमाणे, आम्ही वेगाने धावलो... आमच्यासाठी गुणवत्तेपेक्षा वेग महत्त्वाचा होता.

काही क्षणी आम्ही थांबलो: आम्हाला समजले की आम्ही यापुढे त्या वेगाने आणि त्या गुणवत्तेसह जगू शकत नाही आणि आम्हाला प्रथम गुणवत्तेवर लक्ष केंद्रित करणे आवश्यक आहे. या क्षणी, आम्ही एक नवीन प्लॅटफॉर्म लिहिण्याचा निर्णय घेतला जो योग्य, मापन करण्यायोग्य आणि विश्वासार्ह असेल. त्यांनी हे प्लॅटफॉर्म लिहायला सुरुवात केली (त्यांनी गुंतवणूक करणे, विकास करणे, चाचणी करणे सुरू केले), परंतु काही क्षणी त्यांना जाणवले की विकास आणि चाचणी आम्हाला सेवा गुणवत्तेच्या नवीन स्तरावर पोहोचू देत नाही.

तुम्ही एखादे नवीन उत्पादन बनवता, तुम्ही ते उत्पादनात टाकता, परंतु तरीही कुठेतरी काहीतरी चूक होईल. आणि आज आपण नवीन गुणवत्तेची पातळी कशी गाठायची याबद्दल बोलू (आम्ही ते कसे केले, आमच्या अनुभवाबद्दल), विकास आणि चाचणी समीकरणातून बाहेर काढणे; आम्ही ऑपरेशनसाठी काय उपलब्ध आहे याबद्दल बोलू - कोणते ऑपरेशन स्वतः करू शकते, गुणवत्तेवर परिणाम करण्यासाठी ते चाचणीसाठी काय देऊ शकते.

डाउनटाइम्स. ऑपरेशनच्या आज्ञा.

नेहमीच मुख्य कोनशिला, आज आपण ज्याबद्दल बोलणार आहोत ते डाउनटाइम आहे. एक भयानक शब्द. आमच्याकडे डाउनटाइम असल्यास, आमच्यासाठी सर्व काही वाईट आहे. आम्ही ते वाढवायला धावत आहोत, अ‍ॅडमिन्सने सर्व्हर धरला आहे - देव न करो तो पडू नये, जसे ते त्या गाण्यात म्हणतात. आज आपण याबद्दल बोलणार आहोत.

जेव्हा आम्ही आमचा दृष्टिकोन बदलू लागलो तेव्हा आम्ही 4 आज्ञा तयार केल्या. मी त्यांना स्लाइड्सवर सादर केले आहे:

या आज्ञा अगदी सोप्या आहेत:

• त्वरीत समस्या ओळखा.
• त्यातून आणखी जलद सुटका करा.
• कारण समजून घेण्यात मदत करा (नंतर, विकासकांसाठी).
• आणि दृष्टिकोन प्रमाणित करा.

मला तुमचे लक्ष मुद्द्या क्रमांक 2 कडे वेधायचे आहे. आम्ही समस्येपासून मुक्त होत आहोत, ते सोडवत नाही. निर्णय घेणे दुय्यम आहे. आमच्यासाठी, प्राथमिक गोष्ट म्हणजे वापरकर्ता या समस्येपासून संरक्षित आहे. हे काही वेगळ्या वातावरणात अस्तित्वात असेल, परंतु या वातावरणाचा त्याच्याशी संपर्क होणार नाही. वास्तविक, आम्ही समस्यांच्या या चार गटांमधून जाऊ (काही अधिक तपशीलात, काही कमी तपशीलात), मी तुम्हाला सांगेन की आम्ही काय वापरतो, आम्हाला उपायांमध्ये कोणता संबंधित अनुभव आहे.

समस्यानिवारण: ते कधी होतात आणि त्यांच्याबद्दल काय करावे?

परंतु आम्ही क्रमाने सुरुवात करू, आम्ही बिंदू क्रमांक 2 ने प्रारंभ करू - समस्येपासून त्वरीत कसे मुक्त व्हावे? एक समस्या आहे - आम्हाला त्याचे निराकरण करण्याची आवश्यकता आहे. "याबद्दल आपण काय करावे?" - मुख्य प्रश्न. आणि जेव्हा आम्ही समस्येचे निराकरण कसे करावे याबद्दल विचार करू लागलो, तेव्हा आम्ही स्वतःसाठी काही आवश्यकता विकसित केल्या ज्या समस्यानिवारणाने पाळल्या पाहिजेत.

या आवश्यकता तयार करण्यासाठी, आम्ही स्वतःला हा प्रश्न विचारण्याचे ठरवले: “आम्हाला समस्या कधी येतात”? आणि समस्या, जसे की ते बाहेर आले, चार प्रकरणांमध्ये उद्भवते:

• हार्डवेअर अपयश.
• बाह्य सेवा अयशस्वी.
• सॉफ्टवेअर आवृत्ती बदलणे (समान उपयोजन).
• स्फोटक भार वाढ.

आम्ही पहिल्या दोनबद्दल बोलणार नाही. हार्डवेअरमधील खराबी अगदी सोप्या पद्धतीने सोडवली जाऊ शकते: आपल्याकडे सर्वकाही डुप्लिकेट असणे आवश्यक आहे. या डिस्क्स असल्यास, डिस्क्स RAID मध्ये एकत्र केल्या पाहिजेत; जर हा सर्व्हर असेल, तर सर्व्हर डुप्लिकेट करणे आवश्यक आहे; जर तुमच्याकडे नेटवर्क इन्फ्रास्ट्रक्चर असेल, तर तुम्हाला नेटवर्क इन्फ्रास्ट्रक्चरची दुसरी प्रत पुरवणे आवश्यक आहे, म्हणजेच तुम्ही ती घ्या आणि ते डुप्लिकेट करा. आणि काहीतरी अयशस्वी झाल्यास, आपण आरक्षित शक्तीवर स्विच करा. येथे अधिक काही सांगणे कठीण आहे.

दुसरे म्हणजे बाह्य सेवांचे अपयश. बहुतेकांसाठी, सिस्टम ही समस्या नाही, परंतु आपल्यासाठी नाही. आम्ही पेमेंट्सवर प्रक्रिया करत असल्याने, आम्ही वापरकर्ता (जो त्याचा कार्ड डेटा एंटर करतो) आणि बँका, पेमेंट सिस्टम (व्हिसा, मास्टरकार्ड, मीरा, इ.) यांच्यामध्ये उभा राहतो. आमच्या बाह्य सेवा (पेमेंट सिस्टम, बँका) अयशस्वी होतात. आम्ही किंवा तुम्ही (तुमच्याकडे अशा सेवा असल्यास) यावर प्रभाव टाकू शकत नाही.

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

खरं तर, या चारपैकी, आम्ही विशेषत: सॉफ्टवेअर आवृत्त्यांच्या बदलावर प्रभाव टाकू शकतो - अशा कृती करा ज्यामुळे तैनातीच्या संदर्भात आणि लोडमधील विस्फोटक वाढीच्या संदर्भात परिस्थितीत सुधारणा होईल. वास्तविक, आम्ही तेच केले. येथे, पुन्हा, एक छोटी टीप ...

या चार समस्यांपैकी अनेक समस्या तुमच्याकडे ढग असल्यास लगेच सोडवल्या जातात. जर तुम्ही Microsoft Azhur, Ozone क्लाउडमध्ये असाल किंवा Yandex किंवा Mail वरून आमचे क्लाउड वापरत असाल, तर किमान हार्डवेअर खराब होणे ही त्यांची समस्या बनते आणि हार्डवेअर खराबीच्या संदर्भात तुमच्यासाठी सर्व काही लगेच ठीक होते.

आम्ही थोडी अपारंपरिक कंपनी आहोत. येथे प्रत्येकजण “कुबरनेट्स” बद्दल बोलत आहे, ढगांबद्दल - आमच्याकडे “कुबरनेट” किंवा ढग नाहीत. परंतु आमच्याकडे अनेक डेटा सेंटर्समध्ये हार्डवेअरचे रॅक आहेत, आणि आम्हाला या हार्डवेअरवर जगणे भाग पडले आहे, आम्हाला या सर्व गोष्टींसाठी जबाबदार आहे. म्हणून, आम्ही या संदर्भात बोलू. तर, समस्यांबद्दल. पहिले दोन कंसातून बाहेर काढले.

सॉफ्टवेअर आवृत्ती बदलत आहे. बेस

आमच्या विकसकांना उत्पादनात प्रवेश नाही. अस का? हे इतकेच आहे की आम्ही PCI DSS प्रमाणित आहोत आणि आमच्या विकसकांना "उत्पादन" मध्ये जाण्याचा अधिकार नाही. तो आहे, कालावधी. अजिबात. म्हणून, विकासाची जबाबदारी ज्या क्षणी विकासाने बिल्ड रिलीजसाठी सबमिट केली त्याच क्षणी संपते.

आमच्याकडे असलेला आमचा दुसरा आधार, जो आम्हाला खूप मदत करतो, तो म्हणजे अद्वितीय अदस्तांकित ज्ञानाचा अभाव. मला आशा आहे की ते तुमच्यासाठी समान असेल. कारण असे झाले नाही तर तुम्हाला अडचणी येतील. जेव्हा हे अद्वितीय, कागदोपत्री ज्ञान योग्य वेळी योग्य ठिकाणी नसेल तेव्हा समस्या उद्भवतील. समजा तुमच्याकडे एक व्यक्ती आहे ज्याला विशिष्ट घटक कसे तैनात करायचे हे माहित आहे - ती व्यक्ती तेथे नाही, तो सुट्टीवर आहे किंवा आजारी आहे - तेच आहे, तुम्हाला समस्या आहेत.

आणि तिसरा आधार ज्यावर आपण आलो आहोत. आम्ही यात वेदना, रक्त, अश्रू याद्वारे आलो - आम्ही या निष्कर्षापर्यंत पोहोचलो की आमच्या कोणत्याही बिल्डमध्ये त्रुटी आहेत, जरी ते त्रुटीमुक्त असले तरीही. आम्ही हे स्वतःसाठी ठरवले आहे: जेव्हा आम्ही काहीतरी उपयोजित करतो, जेव्हा आम्ही काहीतरी उत्पादनात रोल करतो तेव्हा आमच्याकडे त्रुटी असतात. आमच्या सिस्टमने ज्या आवश्यकता पूर्ण केल्या पाहिजेत त्या आम्ही तयार केल्या आहेत.

सॉफ्टवेअर आवृत्ती बदलण्यासाठी आवश्यकता

तीन आवश्यकता आहेत:

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

  
  
  हे सर्वज्ञात आहे, आम्ही त्याचा शोध कधी लावला नाही - हा निळा/हिरवा उपयोजन आहे. हे काय आहे? तुमची अॅप्लिकेशन्स इन्स्टॉल केलेल्या सर्व्हरच्या प्रत्येक गटासाठी तुमच्याकडे एक प्रत असणे आवश्यक आहे. प्रत "उबदार" आहे: त्यावर कोणतीही रहदारी नाही, परंतु कोणत्याही क्षणी ही रहदारी या कॉपीवर पाठविली जाऊ शकते. या प्रतमध्ये मागील आवृत्ती आहे. आणि डिप्लॉयमेंटच्या वेळी, तुम्ही कोड निष्क्रिय कॉपीमध्ये रोल आउट करता. त्यानंतर तुम्ही रहदारीचा काही भाग (किंवा सर्व) नवीन आवृत्तीवर स्विच कराल. अशा प्रकारे, जुन्या आवृत्तीपासून नवीन आवृत्तीमध्ये रहदारीचा प्रवाह बदलण्यासाठी, आपल्याला फक्त एक क्रिया करणे आवश्यक आहे: आपल्याला अपस्ट्रीममध्ये बॅलन्सर बदलणे आवश्यक आहे, दिशा बदलणे आवश्यक आहे - एका अपस्ट्रीममधून दुसर्‍याकडे. हे अतिशय सोयीचे आहे आणि द्रुत स्विचिंग आणि द्रुत रोलबॅकची समस्या सोडवते.

  येथे दुस-या प्रश्नाचे समाधान कमी करणे आहे: तुम्ही तुमच्या ट्रॅफिकचा फक्त काही भाग नवीन लाइनवर, नवीन कोड असलेल्या ओळीवर पाठवू शकता (उदाहरणार्थ, 2% असू द्या). आणि हे 2% 100% नाहीत! अयशस्वी तैनातीमुळे तुम्ही तुमची १००% रहदारी गमावली असेल, तर ते धडकी भरवणारे आहे; जर तुम्ही तुमची 100% रहदारी गमावली असेल, तर ते अप्रिय आहे, परंतु ते भितीदायक नाही. शिवाय, वापरकर्त्यांना बहुधा हे लक्षातही येणार नाही, कारण काही प्रकरणांमध्ये (सर्वात नाही) समान वापरकर्ता, F2 दाबून, दुसर्‍या कार्यरत आवृत्तीवर नेला जाईल.

  निळा/हिरवा उपयोजन. राउटिंग

  तथापि, सर्व काही इतके सोपे नाही "ब्लू/ग्रीन डिप्लॉय"... आमचे सर्व घटक तीन गटांमध्ये विभागले जाऊ शकतात:

  • हे फ्रंटएंड आहे (आमच्या ग्राहकांना दिसणारी पेमेंट पृष्ठे);
  • प्रक्रिया कोर;
  • पेमेंट सिस्टमसह काम करण्यासाठी अडॅप्टर (बँका, मास्टरकार्ड, व्हिसा...).

  आणि येथे एक सूक्ष्मता आहे - सूक्ष्मता ओळींच्या दरम्यानच्या राउटिंगमध्ये आहे. जर तुम्ही १००% रहदारी बदलली तर तुम्हाला या समस्या येत नाहीत. परंतु तुम्हाला 100% स्विच करायचे असल्यास, तुम्ही प्रश्न विचारण्यास सुरुवात करता: "हे कसे करावे?" सर्वात सोपी गोष्ट सरळ आहे: तुम्ही यादृच्छिक निवडीनुसार nginx मध्ये राऊंड रॉबिन सेट करू शकता आणि तुमच्याकडे 2% डावीकडे, 2% उजवीकडे आहे. परंतु हे नेहमीच योग्य नसते.

  उदाहरणार्थ, आमच्या बाबतीत, वापरकर्ता एकापेक्षा जास्त विनंतीसह सिस्टमशी संवाद साधतो. हे सामान्य आहे: 2, 3, 4, 5 विनंत्या - तुमची प्रणाली समान असू शकते. आणि जर तुमच्यासाठी हे महत्त्वाचे असेल की वापरकर्त्याच्या सर्व विनंत्या त्याच ओळीवर येतात ज्यावर पहिली विनंती आली होती किंवा (दुसरा मुद्दा) वापरकर्त्याच्या सर्व विनंत्या स्विच केल्यानंतर नवीन ओळीवर येतात (त्याने आधी काम सुरू केले असते. सिस्टम, स्विच करण्यापूर्वी), - मग हे यादृच्छिक वितरण आपल्यासाठी योग्य नाही. मग खालील पर्याय आहेत:

  
  
  पहिला पर्याय, सर्वात सोपा, क्लायंटच्या मूलभूत पॅरामीटर्सवर आधारित आहे (आयपी हॅश). तुमच्याकडे IP आहे आणि तुम्ही IP पत्त्याद्वारे उजवीकडून डावीकडे विभागता. मग मी वर्णन केलेले दुसरे प्रकरण तुमच्यासाठी कार्य करेल, जेव्हा उपयोजन केले जाते, तेव्हा वापरकर्ता आधीच तुमच्या सिस्टमसह कार्य करण्यास प्रारंभ करू शकतो आणि उपयोजनाच्या क्षणापासून सर्व विनंत्या नवीन ओळीवर जातील (त्याच, म्हणा).

  जर काही कारणास्तव हे आपल्यास अनुरूप नसेल आणि आपण ज्या ओळीवर वापरकर्त्याची प्रारंभिक, प्रारंभिक विनंती आली आहे त्या ओळीवर विनंत्या पाठवल्या पाहिजेत, तर आपल्याकडे दोन पर्याय आहेत...
  पहिला पर्याय: तुम्ही सशुल्क nginx+ खरेदी करू शकता. एक स्टिकी सेशन्स मेकॅनिझम आहे, जी वापरकर्त्याच्या सुरुवातीच्या विनंतीनुसार, वापरकर्त्याला एक सत्र नियुक्त करते आणि ते एक किंवा दुसर्या अपस्ट्रीमशी जोडते. त्यानंतरच्या सर्व वापरकर्ता विनंत्या सत्राच्या जीवनकाळात त्याच अपस्ट्रीमवर पाठवल्या जातील जिथे सत्र पोस्ट केले गेले होते.

  हे आम्हाला शोभत नाही कारण आमच्याकडे आधीपासूनच नियमित nginx होते. nginx+ वर स्विच करणे हे महाग आहे असे नाही, ते आमच्यासाठी काहीसे क्लेशदायक होते आणि फारसे योग्य नव्हते. उदाहरणार्थ, “स्टिक्स सेशन्स”, “एकतर-किंवा” वर आधारित रूटिंगला “स्टिक्स सेशन्स” परवानगी देत ​​​​नाही या साध्या कारणासाठी आमच्यासाठी कार्य करत नाही. आम्ही "स्टिक सेशन्स" काय करतो ते तुम्ही तेथे निर्दिष्ट करू शकता, उदाहरणार्थ, IP पत्त्याद्वारे किंवा IP पत्त्याद्वारे आणि कुकीजद्वारे किंवा पोस्ट पॅरामीटरद्वारे, परंतु "एकतर-किंवा" तेथे अधिक क्लिष्ट आहे.

  म्हणून, आम्ही चौथ्या पर्यायावर आलो. आम्ही स्टिरॉइड्सवर nginx घेतले (हे ओपनरेस्टी आहे) - हे समान nginx आहे, जे शेवटच्या स्क्रिप्टच्या समावेशास देखील समर्थन देते. तुम्ही शेवटची स्क्रिप्ट लिहू शकता, त्याला "ओपन रेस्ट" देऊ शकता आणि ही शेवटची स्क्रिप्ट वापरकर्त्याची विनंती आल्यावर अंमलात आणली जाईल.

  आणि आम्ही, खरं तर, अशी स्क्रिप्ट लिहिली, स्वतःला "ओपनरेस्टी" सेट केले आणि या स्क्रिप्टमध्ये आम्ही "किंवा" जोडून 6 भिन्न पॅरामीटर्सद्वारे क्रमवारी लावतो. एक किंवा दुसर्या पॅरामीटरच्या उपस्थितीवर अवलंबून, आम्हाला माहित आहे की वापरकर्ता एक किंवा दुसर्या पृष्ठावर आला आहे, एक ओळ किंवा दुसर्या.

  निळा/हिरवा उपयोजन. फायदे आणि तोटे

  अर्थात, हे थोडे सोपे करणे शक्य आहे (समान “स्टिकी सेशन्स” वापरा), परंतु आमच्याकडे अशी सूक्ष्मता देखील आहे की केवळ एका व्यवहाराच्या एका प्रक्रियेच्या चौकटीत वापरकर्ता आमच्याशी संवाद साधत नाही... परंतु पेमेंट सिस्टम देखील आमच्याशी संवाद साधतात: आम्ही व्यवहारावर प्रक्रिया केल्यानंतर (पेमेंट सिस्टमला विनंती पाठवून), आम्हाला कूलबॅक प्राप्त होतो.
  आणि समजा, जर आमच्या सर्किटमध्ये आम्ही सर्व विनंत्यांमध्ये वापरकर्त्याचा आयपी पत्ता फॉरवर्ड करू शकलो आणि आयपी पत्त्यावर आधारित वापरकर्त्यांना विभाजित करू शकलो, तर आम्ही तोच “व्हिसा” सांगणार नाही: “मित्रा, आम्ही एक रेट्रो कंपनी आहोत, आम्हाला वाटते. आंतरराष्ट्रीय (वेबसाइट आणि रशियामध्ये) होण्यासाठी... कृपया आम्हाला वापरकर्त्याचा IP पत्ता अतिरिक्त फील्डमध्ये प्रदान करा, तुमचा प्रोटोकॉल प्रमाणित आहे”! ते मान्य करणार नाहीत हे स्पष्ट आहे.

  
  
  म्हणून, हे आमच्यासाठी कार्य करत नाही - आम्ही खुलेपणा केला. त्यानुसार, राउटिंगसह आम्हाला असे काहीतरी मिळाले:

  ब्लू/ग्रीन डिप्लॉयमेंटचे, त्यानुसार, मी नमूद केलेले फायदे आणि तोटे आहेत.

  दोन तोटे:

  • आपल्याला राउटिंगचा त्रास करणे आवश्यक आहे;
  • दुसरा मुख्य तोटा म्हणजे खर्च.

  तुम्हाला दुप्पट सर्व्हरची गरज आहे, तुम्हाला दुप्पट ऑपरेशनल संसाधनांची आवश्यकता आहे, तुम्हाला या संपूर्ण प्राणीसंग्रहालयाची देखभाल करण्यासाठी दुप्पट मेहनत करावी लागेल.

  तसे, फायद्यांमध्ये आणखी एक गोष्ट आहे ज्याचा मी आधी उल्लेख केलेला नाही: लोड वाढीच्या बाबतीत आपल्याकडे राखीव आहे. तुमच्याकडे लोडमध्ये स्फोटक वाढ असल्यास, तुमच्याकडे मोठ्या संख्येने वापरकर्ते आहेत, तर तुम्ही फक्त 50 ते 50 वितरणामध्ये दुसरी ओळ समाविष्ट कराल - आणि तुम्ही अधिक सर्व्हर असण्याच्या समस्येचे निराकरण करेपर्यंत तुमच्या क्लस्टरमध्ये त्वरित x2 सर्व्हर असतील.

  जलद उपयोजन कसे करावे?

  आम्ही कमीतकमी आणि द्रुत रोलबॅकची समस्या कशी सोडवायची याबद्दल बोललो, परंतु प्रश्न कायम आहे: "त्वरीत कसे तैनात करावे?"

  
  
  हे येथे लहान आणि सोपे आहे.

  • तुमच्याकडे सीडी सिस्टम (सतत वितरण) असणे आवश्यक आहे - तुम्ही त्याशिवाय जगू शकत नाही. तुमच्याकडे एक सर्व्हर असल्यास, तुम्ही व्यक्तिचलितपणे उपयोजित करू शकता. आमच्याकडे सुमारे दीड हजार सर्व्हर आणि दीड हजार हँडल आहेत, अर्थातच - आम्ही फक्त तैनात करण्यासाठी या खोलीच्या आकाराचे विभाग लावू शकतो.
  • उपयोजन समांतर असणे आवश्यक आहे. जर तुमची तैनाती अनुक्रमिक असेल, तर सर्वकाही खराब आहे. एक सर्व्हर सामान्य आहे, तुम्ही दिवसभर दीड हजार सर्व्हर तैनात कराल.
  • पुन्हा, प्रवेग साठी, हे कदाचित यापुढे आवश्यक नाही. तैनाती दरम्यान, प्रकल्प सहसा बांधला जातो. तुमच्याकडे एक वेब प्रोजेक्ट आहे, एक फ्रंट-एंड भाग आहे (तुम्ही तिथे वेब पॅक करता, तुम्ही एनपीएम संकलित करता - असे काहीतरी), आणि ही प्रक्रिया तत्त्वतः, अल्पायुषी आहे - 5 मिनिटे, परंतु ही 5 मिनिटे गंभीर व्हा म्हणूनच, उदाहरणार्थ, आम्ही असे करत नाही: आम्ही ही 5 मिनिटे काढून टाकली, आम्ही कलाकृती तैनात करतो.

    आर्टिफॅक्ट म्हणजे काय? आर्टिफॅक्ट एक असेंबल बिल्ड आहे ज्यामध्ये सर्व असेंबली भाग आधीच पूर्ण झाले आहेत. ही कलाकृती आम्ही आर्टिफॅक्ट स्टोरेजमध्ये ठेवतो. एकेकाळी आम्ही असे दोन स्टोरेज वापरले होते - ते Nexus आणि आता jFrog आर्टिफॅक्टरी होते. आम्ही सुरुवातीला "Nexus" वापरला कारण आम्ही जावा ऍप्लिकेशन्समध्ये या पद्धतीचा सराव करू लागलो (ते त्यास अनुकूल होते). मग त्यांनी PHP मध्ये लिहिलेले काही ऍप्लिकेशन्स तिथे ठेवले; आणि "नेक्सस" यापुढे योग्य नव्हते, आणि म्हणून आम्ही jFrog आर्टफॅक्टरी निवडली, जी जवळजवळ प्रत्येक गोष्ट आर्टिफॅक्टरीझ करू शकते. आम्ही इथपर्यंत पोहोचलो आहोत की या आर्टिफॅक्ट रिपॉजिटरीमध्ये आम्ही आमचे स्वतःचे बायनरी पॅकेजेस संग्रहित करतो जे आम्ही सर्व्हरसाठी गोळा करतो.

  स्फोटक भार वाढ

  आम्ही सॉफ्टवेअर आवृत्ती बदलण्याबद्दल बोललो. आमच्याकडे असलेली पुढील गोष्ट म्हणजे लोडमध्ये स्फोटक वाढ. येथे, मला कदाचित लोडच्या स्फोटक वाढीचा अर्थ असा आहे की योग्य गोष्ट नाही...

  आम्ही एक नवीन प्रणाली लिहिली - ती सेवा देणारी, फॅशनेबल, सुंदर, सर्वत्र कामगार, सर्वत्र रांगा, सर्वत्र असिंक्रोनी आहे. आणि अशा प्रणालींमध्ये, डेटा वेगवेगळ्या प्रवाहांमधून वाहू शकतो. पहिल्या व्यवहारासाठी, 1ला, 3रा, 10वा कार्यकर्ता वापरला जाऊ शकतो, दुसऱ्या व्यवहारासाठी - 2रा, 4था, 5वा. आणि आज, समजा, सकाळी तुमच्याकडे डेटा प्रवाह आहे जो पहिल्या तीन कामगारांचा वापर करतो आणि संध्याकाळी तो नाटकीयरित्या बदलतो आणि प्रत्येक गोष्ट इतर तीन कामगारांचा वापर करते.

  आणि येथे असे दिसून आले की आपल्याला कामगारांना कसे तरी मोजण्याची आवश्यकता आहे, आपल्याला आपल्या सेवांचे प्रमाण कसे तरी मोजावे लागेल, परंतु त्याच वेळी संसाधनांचा फुगवटा टाळता येईल.

  
  
  आम्ही आमच्या गरजा परिभाषित केल्या आहेत. या आवश्यकता अगदी सोप्या आहेत: सेवा शोध, पॅरामीटरायझेशन - अशा स्केलेबल सिस्टम तयार करण्यासाठी सर्वकाही मानक आहे, एक मुद्दा वगळता - संसाधन घसारा. आम्ही म्हणालो की आम्ही संसाधने कमी करण्यास तयार नाही जेणेकरून सर्व्हर हवा गरम करतात. आम्ही "कन्सल" घेतला, आम्ही "नोमॅड" घेतला, जो आमच्या कामगारांचे व्यवस्थापन करतो.

  आमच्यासाठी ही समस्या का आहे? चला थोडं मागे जाऊया. आमच्या मागे जवळपास 70 पेमेंट सिस्टम आहेत. सकाळी, वाहतूक Sberbank मधून जाते, नंतर Sberbank पडले, उदाहरणार्थ, आणि आम्ही ते दुसर्या पेमेंट सिस्टमवर स्विच करतो. Sberbank पूर्वी आमच्याकडे 100 कामगार होते आणि त्यानंतर आम्हाला दुसर्‍या पेमेंट सिस्टमसाठी 100 कामगार वाढवायचे आहेत. आणि हे सर्व मानवी सहभागाशिवाय घडणे इष्ट आहे. कारण जर मानवी सहभाग असेल तर तिथे २४ तास बसून एक अभियंता असायला हवा, जो फक्त हेच करत असावा, कारण ७० सिस्टीम तुमच्या मागे असताना असे अपयश नियमितपणे घडतात.

  म्हणून, आम्ही नोमॅडकडे पाहिले, ज्याचा ओपन आयपी आहे, आणि आमची स्वतःची गोष्ट लिहिली, स्केल-नोमॅड - स्केलनो, जे अंदाजे खालील गोष्टी करते: ते रांगेच्या वाढीवर लक्ष ठेवते आणि गतिशीलतेवर अवलंबून कामगारांची संख्या कमी करते किंवा वाढवते. रांगेतील जेव्हा आम्ही ते केले तेव्हा आम्हाला वाटले: "कदाचित आम्ही ते ओपन सोर्स करू शकतो?" मग त्यांनी तिच्याकडे पाहिले - ती दोन कोपेक्स इतकी साधी होती.

  आतापर्यंत आम्ही ते ओपन सोर्स केलेले नाही, परंतु अचानक अहवालानंतर, तुम्हाला अशा गोष्टीची गरज असल्याचे लक्षात आल्यावर, माझे संपर्क शेवटच्या स्लाइडमध्ये आहेत - कृपया मला लिहा. किमान 3-5 लोक असतील तर आम्ही स्पॉन्सर करू.

  
  
  हे कसे कार्य करते? चला एक नजर टाकूया! पुढे पहात आहे: डाव्या बाजूला आमच्या निरीक्षणाचा एक तुकडा आहे: ही एक ओळ आहे, शीर्षस्थानी इव्हेंट प्रक्रियेची वेळ आहे, मध्यभागी व्यवहारांची संख्या आहे, तळाशी कामगारांची संख्या आहे.

  पाहिल्यास या चित्रात एक त्रुटी आहे. शीर्ष चार्टवर, चार्टपैकी एक 45 सेकंदात क्रॅश झाला - पेमेंट सिस्टमपैकी एक खाली गेली. ताबडतोब, 2 मिनिटांत रहदारी आणली गेली आणि दुसर्‍या पेमेंट सिस्टमवर रांग वाढू लागली, जिथे कामगार नव्हते (आम्ही संसाधनांचा वापर केला नाही - त्याउलट, आम्ही संसाधनाची योग्य प्रकारे विल्हेवाट लावली). आम्हाला गरम करायचे नव्हते - किमान संख्या होती, सुमारे 5-10 कामगार, परंतु ते सामना करू शकले नाहीत.

  शेवटचा आलेख "कुबडा" दर्शवितो, ज्याचा अर्थ फक्त "स्केलेनो" ने ही रक्कम दुप्पट केली आहे. आणि मग, आलेख थोडा घसरला तेव्हा त्याने तो थोडा कमी केला - कामगारांची संख्या आपोआप बदलली. ही गोष्ट कशी चालते. आम्ही मुद्दा क्रमांक 2 बद्दल बोललो - "त्वरीत कारणे कशी दूर करावी."

  देखरेख. त्वरीत समस्या कशी ओळखायची?

  आता पहिला मुद्दा "समस्या लवकर कशी ओळखायची?" देखरेख! आपल्याला काही गोष्टी लवकर समजल्या पाहिजेत. आपण कोणत्या गोष्टी लवकर समजून घेतल्या पाहिजेत?

  
  
  तीन गोष्टी!

  • आपल्या स्वतःच्या संसाधनांची कामगिरी आपण त्वरीत समजून घेतली पाहिजे आणि समजून घेतली पाहिजे.
  • आपण अपयश पटकन समजून घेतले पाहिजे आणि आपल्यासाठी बाह्य असलेल्या सिस्टमच्या कार्यप्रदर्शनाचे परीक्षण केले पाहिजे.
  • तिसरा मुद्दा म्हणजे तार्किक त्रुटी ओळखणे. जेव्हा सिस्टम आपल्यासाठी कार्य करत असते तेव्हा सर्व निर्देशकांनुसार सर्वकाही सामान्य असते, परंतु काहीतरी चूक होते.

  मी कदाचित तुम्हाला इथे काही छान सांगणार नाही. मी कॅप्टन ऑब्वियस असेन. आम्ही बाजारात काय आहे ते शोधत होतो. आमच्याकडे एक "मजेदार प्राणीसंग्रहालय" आहे. आमच्याकडे आता असे प्राणीसंग्रहालय आहे:

  
  
  आम्ही हार्डवेअरचे निरीक्षण करण्यासाठी, सर्व्हरच्या मुख्य निर्देशकांचे निरीक्षण करण्यासाठी Zabbix वापरतो. आम्ही डेटाबेससाठी Okmeter वापरतो. आम्ही इतर सर्व निर्देशकांसाठी “Grafana” आणि “Prometheus” वापरतो जे पहिल्या दोनमध्ये बसत नाहीत, काही “Grafana” आणि “Prometheus” सह आणि काही “Grafana” सह “Influx” आणि Telegraf.

  एक वर्षापूर्वी आम्हाला नवीन अवशेष वापरायचे होते. छान गोष्ट, ती सर्व काही करू शकते. पण ती जेवढं सगळं करू शकते, तेवढीच ती महागडी आहे. जेव्हा आम्ही 1,5 हजार सर्व्हरचे व्हॉल्यूम वाढलो, तेव्हा एक विक्रेता आमच्याकडे आला आणि म्हणाला: "पुढच्या वर्षासाठी एक करार करूया." आम्ही किंमत पाहिली आणि म्हणालो नाही, आम्ही ते करणार नाही. आता आम्ही नवीन अवशेष सोडत आहोत, आमच्याकडे न्यू रेलिकच्या देखरेखीखाली सुमारे 15 सर्व्हर शिल्लक आहेत. किंमत पूर्णपणे जंगली असल्याचे बाहेर वळले.

  आणि एक साधन आहे जे आम्ही स्वतः लागू केले - हे डीबगर आहे. सुरुवातीला आम्ही त्याला "बॅगर" म्हणतो, पण नंतर एक इंग्रजी शिक्षक तिथून निघून गेला, तो हसला आणि त्याचे नाव बदलून "डेबगर" ठेवले. हे काय आहे? हे असे साधन आहे जे प्रत्येक घटकावर 15-30 सेकंदात, सिस्टमच्या "ब्लॅक बॉक्स" प्रमाणे, घटकाच्या एकूण कार्यक्षमतेवर चाचण्या चालवते.

  उदाहरणार्थ, एखादे बाह्य पृष्ठ (पेमेंट पृष्ठ) असल्यास, तो फक्त ते उघडतो आणि ते कसे दिसले पाहिजे ते पाहतो. यावर प्रक्रिया होत असल्यास, तो एक चाचणी "व्यवहार" पाठवतो आणि हा "व्यवहार" आल्याची खात्री करतो. जर हे पेमेंट सिस्टमशी कनेक्शन असेल, तर आम्ही त्यानुसार चाचणी विनंती करतो, जिथे आम्ही करू शकतो आणि आमच्याबरोबर सर्व काही ठीक आहे हे पाहतो.

  निरीक्षणासाठी कोणते संकेतक महत्त्वाचे आहेत?

  आम्ही प्रामुख्याने कशाचे निरीक्षण करतो? आमच्यासाठी कोणते संकेतक महत्त्वाचे आहेत?

  
  

  • मोर्चांवरील प्रतिसाद वेळ / RPS हा एक अतिशय महत्त्वाचा सूचक आहे. तो लगेच उत्तर देतो की तुमच्यात काहीतरी चूक आहे.
  • सर्व रांगेत प्रक्रिया केलेल्या संदेशांची संख्या.
  • कामगारांची संख्या.
  • मूलभूत शुद्धता मेट्रिक्स.

  शेवटचा मुद्दा म्हणजे “व्यवसाय”, “व्यवसाय” मेट्रिक. तुम्हाला त्याच गोष्टीचे निरीक्षण करायचे असल्यास, तुम्हाला एक किंवा दोन मेट्रिक्स परिभाषित करणे आवश्यक आहे जे तुमच्यासाठी मुख्य निर्देशक आहेत. आमचे मेट्रिक थ्रूपुट आहे (हे एकूण व्यवहार प्रवाहातील यशस्वी व्यवहारांच्या संख्येचे गुणोत्तर आहे). जर 5-10-15 मिनिटांच्या अंतराने त्यात काहीतरी बदलले तर याचा अर्थ आम्हाला समस्या आहेत (जर ते आमूलाग्र बदलले तर).

  आमच्यासाठी ते कसे दिसते ते आमच्या बोर्डांपैकी एकाचे उदाहरण आहे:

  
  
  डाव्या बाजूला 6 आलेख आहेत, हे ओळींनुसार आहे - कामगारांची संख्या आणि रांगेतील संदेशांची संख्या. उजव्या बाजूला - RPS, RTS. खाली समान "व्यवसाय" मेट्रिक आहे. आणि "व्यवसाय" मेट्रिकमध्ये आपण लगेच पाहू शकतो की दोन मधल्या आलेखांमध्ये काहीतरी चूक झाली आहे... ही आणखी एक प्रणाली आहे जी आपल्या मागे उभी आहे जी पडली आहे.

  दुसरी गोष्ट जी आम्हाला करायची होती ती म्हणजे बाह्य पेमेंट सिस्टमच्या पडझडीचे निरीक्षण करणे. येथे आम्ही OpenTracing घेतले - एक यंत्रणा, मानक, प्रतिमान जी तुम्हाला वितरित प्रणाली शोधू देते; आणि ते थोडे बदलले होते. मानक OpenTracing प्रतिमान सांगतो की आम्ही प्रत्येक वैयक्तिक विनंतीसाठी एक ट्रेस तयार करतो. आम्हाला याची गरज नव्हती आणि आम्ही ते सारांश, एकत्रीकरण ट्रेसमध्ये गुंडाळले. आम्ही एक साधन तयार केले जे आम्हाला आमच्या मागे असलेल्या सिस्टमच्या गतीचा मागोवा घेण्यास अनुमती देते.

  
  
  आलेख आम्हाला दाखवतो की पेमेंट सिस्टमपैकी एकाने 3 सेकंदात प्रतिसाद देण्यास सुरुवात केली - आम्हाला समस्या आहेत. शिवाय, 20-30 सेकंदांच्या अंतराने जेव्हा समस्या सुरू होतात तेव्हा ही गोष्ट प्रतिक्रिया देईल.

  आणि अस्तित्वात असलेल्या मॉनिटरिंग त्रुटींचा तिसरा वर्ग म्हणजे लॉजिकल मॉनिटरिंग.

  खरे सांगायचे तर, या स्लाइडवर काय काढायचे हे मला माहित नव्हते, कारण आम्ही बाजारात बर्याच काळापासून आमच्यासाठी अनुकूल असलेल्या वस्तू शोधत होतो. आम्हाला काहीही सापडले नाही, म्हणून आम्हाला ते स्वतः करावे लागले.

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

  अशा परिस्थितीत... आमच्यासाठी, ही परिस्थिती थोडी वेगळी वाटते, कारण (मी लिहिले आहे) हे प्रतिष्ठेचे नुकसान आहे ज्यामुळे अप्रत्यक्षपणे आर्थिक नुकसान होते. आमची परिस्थिती उलट आहे: आम्हाला थेट आर्थिक नुकसान होऊ शकते - उदाहरणार्थ, जर आम्ही यशस्वी म्हणून व्यवहार केला, परंतु तो अयशस्वी झाला (किंवा उलट). मला माझे स्वतःचे साधन लिहावे लागले जे व्यवसाय निर्देशक वापरून कालांतराने यशस्वी व्यवहारांची संख्या ट्रॅक करते. बाजारात काहीही सापडले नाही! नेमकी हीच कल्पना मला सांगायची होती. या प्रकारच्या समस्येचे निराकरण करण्यासाठी बाजारात काहीही नाही.

  ही समस्या त्वरीत कशी ओळखायची याबद्दल होती.

  उपयोजनाची कारणे कशी ठरवायची

  समस्यांचा तिसरा गट जो आपण सोडवतो तो म्हणजे आपण समस्या ओळखल्यानंतर, त्यातून सुटका केल्यानंतर, विकासाचे कारण समजून घेणे, चाचणी करणे आणि त्याबद्दल काहीतरी करणे चांगले होईल. त्यानुसार, आम्हाला तपास करणे आवश्यक आहे, आम्हाला नोंदी वाढवण्याची गरज आहे.

  
  
  जर आपण लॉगबद्दल बोलत आहोत (मुख्य कारण लॉग आहे), तर आमच्या लॉगचा मोठा भाग ELK स्टॅकमध्ये आहे - जवळजवळ प्रत्येकाकडे समान आहे. काहींसाठी, ते ELK मध्ये असू शकत नाही, परंतु आपण गीगाबाइट्समध्ये लॉग लिहिल्यास, लवकरच किंवा नंतर आपण ELK वर याल. आम्ही ते टेराबाइट्समध्ये लिहितो.

  
  
  येथे एक समस्या आहे. आम्ही ते दुरुस्त केले, वापरकर्त्यासाठी त्रुटी दुरुस्त केली, तेथे काय आहे ते खोदण्यास सुरुवात केली, किबानामध्ये चढलो, तेथे व्यवहार आयडी प्रविष्ट केला आणि यासारखे फूटक्लोथ मिळाले (बरेच दाखवते). आणि या फुटक्लॉथमध्ये काहीही स्पष्ट नाही. का? होय, कारण कोणता भाग कोणत्या कामगाराचा आहे, कोणता भाग कोणत्या घटकाचा आहे हे स्पष्ट होत नाही. आणि त्या क्षणी आम्हाला कळले की आम्हाला ट्रेसिंगची गरज आहे - तेच ओपनट्रेसिंग ज्याबद्दल मी बोललो होतो.

  आम्ही एक वर्षापूर्वी याचा विचार केला, आमचे लक्ष बाजाराकडे वळवले आणि तेथे दोन साधने होती - “झिपकिन” आणि “जेगर”. “जागर” हा खरे तर असा वैचारिक वारसदार आहे, “झिपकिन” चा वैचारिक उत्तराधिकारी आहे. झिपकिनमध्ये सर्व काही चांगले आहे, त्याशिवाय ते एकत्रित कसे करायचे हे माहित नाही, ट्रेसमध्ये लॉग कसे समाविष्ट करायचे हे माहित नाही, फक्त वेळ ट्रेस. आणि "जेगर" ने याचे समर्थन केले.

  आम्ही "जेगर" कडे पाहिले: तुम्ही इन्स्ट्रुमेंट अॅप्लिकेशन्स करू शकता, तुम्ही Api मध्ये लिहू शकता (त्या वेळी PHP साठी Api मानक, तथापि, मंजूर झाले नव्हते - हे एक वर्षापूर्वी होते, परंतु आता ते आधीच मंजूर झाले आहे), परंतु तेथे पूर्णपणे ग्राहक नव्हते. "ठीक आहे," आम्ही विचार केला आणि आमचा स्वतःचा क्लायंट लिहिला. आम्हाला काय मिळाले? हे अंदाजे असे दिसते:

  
  
  Jaeger मध्ये, प्रत्येक संदेशासाठी स्पॅन तयार केले जातात. म्हणजेच, जेव्हा वापरकर्ता सिस्टम उघडतो, तेव्हा त्याला प्रत्येक येणार्‍या विनंतीसाठी एक किंवा दोन ब्लॉक दिसतात (1-2-3 - वापरकर्त्याकडून येणार्‍या विनंत्यांची संख्या, ब्लॉकची संख्या). वापरकर्त्यांसाठी हे सोपे करण्यासाठी, आम्ही लॉग आणि टाइम ट्रेसमध्ये टॅग जोडले. त्यानुसार, त्रुटी आढळल्यास, आमचा अर्ज योग्य त्रुटी टॅगसह लॉग चिन्हांकित करेल. तुम्ही एरर टॅगद्वारे फिल्टर करू शकता आणि फक्त एरर असलेले हे ब्लॉक असलेले स्पॅन प्रदर्शित केले जातील. आपण कालखंड वाढवल्यास असे दिसते:

  
  
  स्पॅनच्या आत ट्रेसचा एक संच आहे. या प्रकरणात, हे तीन चाचणी ट्रेस आहेत आणि तिसरा ट्रेस आम्हाला एक त्रुटी आल्याचे सांगतो. त्याच वेळी, येथे आपल्याला टाइम ट्रेस दिसतो: आमच्याकडे शीर्षस्थानी एक टाइम स्केल आहे आणि आम्ही हे किंवा ते लॉग कोणत्या वेळेच्या अंतराने रेकॉर्ड केले ते पाहतो.

  त्यानुसार, आमच्यासाठी गोष्टी चांगल्या झाल्या. आम्ही आमचे स्वतःचे विस्तार लिहिले आणि आम्ही ते ओपन सोर्स केले. तुम्हाला ट्रेसिंगसह काम करायचे असल्यास, तुम्हाला PHP मध्ये “Jager” सोबत काम करायचे असल्यास, आमचा विस्तार आहे, वापरण्यास स्वागत आहे, जसे ते म्हणतात:

  
  
  आमच्याकडे हा विस्तार आहे - तो OpenTracing Api साठी क्लायंट आहे, तो php-extention म्हणून बनवला आहे, म्हणजेच, तुम्हाला ते एकत्र करून सिस्टमवर स्थापित करावे लागेल. एक वर्षापूर्वी काही वेगळे नव्हते. आता इतर क्लायंट आहेत जे घटकांसारखे आहेत. येथे हे तुमच्यावर अवलंबून आहे: एकतर तुम्ही संगीतकारासह घटक बाहेर काढता किंवा तुम्ही विस्तार वापरता.

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

  आम्ही तीन आज्ञांबद्दल बोललो. चौथी आज्ञा म्हणजे दृष्टिकोन प्रमाणित करणे. हे कशाबद्दल आहे? हे याबद्दल आहे:

  
  
  येथे "कॉर्पोरेट" हा शब्द का आहे? आम्ही मोठी किंवा नोकरशाही कंपनी आहोत म्हणून नाही, नाही! मला येथे “कॉर्पोरेट” हा शब्द या संदर्भात वापरायचा आहे की प्रत्येक कंपनी, प्रत्येक उत्पादनाची स्वतःची मानके असावीत, तुमच्यासह. आमच्याकडे कोणते मानक आहेत?

  
  

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

  डाउनटाइम काय मानले जाते?

  
  
  या सगळ्यामुळे काय घडले?

  यामुळे गेल्या 6 महिन्यांत (आम्हाला स्थिरतेच्या काही समस्या होत्या, हे क्लायंट किंवा आमच्या दोघांनाही शोभत नाही) हे तथ्य घडून आले की आमचा स्थिरता निर्देशक 99,97 होता. आपण असे म्हणू शकतो की हे फारसे नाही. होय, आमच्याकडे प्रयत्न करण्यासारखे काहीतरी आहे. या इंडिकेटरपैकी, जवळपास अर्धी स्थिरता आहे, ती आमची नाही, तर आमच्या वेब ऍप्लिकेशन फायरवॉलची आहे, जी आमच्यासमोर उभी आहे आणि सेवा म्हणून वापरली जाते, परंतु क्लायंट याकडे लक्ष देत नाहीत.

  आम्ही रात्री झोपायला शिकलो. शेवटी! सहा महिन्यांपूर्वी आम्ही करू शकलो नाही. आणि परिणामांसह या नोटवर, मी एक टीप करू इच्छितो. काल रात्री अणुभट्टीसाठी नियंत्रण प्रणालीबद्दल एक अद्भुत अहवाल आला. ही प्रणाली लिहिणारे लोक मला ऐकू शकत असल्यास, कृपया मी "2% डाउनटाइम नाही" बद्दल काय म्हटले आहे ते विसरून जा. तुमच्यासाठी, 2% डाउनटाइम आहे, जरी दोन मिनिटांसाठी!

  इतकंच! तुमचे प्रश्न.

  
  

  बॅलन्सर्स आणि डेटाबेस माइग्रेशन बद्दल

  श्रोत्यांकडून प्रश्न (यापुढे – बी): – शुभ संध्याकाळ. अशा अ‍ॅडमिन रिपोर्टसाठी मनःपूर्वक धन्यवाद! तुमच्या बॅलन्सर्सबद्दल एक छोटा प्रश्न. तुम्ही नमूद केले आहे की तुमच्याकडे डब्ल्यूएएफ आहे, म्हणजेच मला समजले आहे, तुम्ही काही प्रकारचे बाह्य संतुलन वापरता...

  EK: - नाही, आम्ही आमच्या सेवा बॅलन्सर म्हणून वापरतो. या प्रकरणात, WAF हे केवळ आमच्यासाठी एक DDoS संरक्षण साधन आहे.

  मध्ये: - आपण बॅलन्सर्सबद्दल काही शब्द बोलू शकता?

  EK: - मी आधीच म्हटल्याप्रमाणे, हा ओपनरेस्टीमधील सर्व्हरचा एक गट आहे. आमच्याकडे आता 5 राखीव गट आहेत जे विशेष प्रतिसाद देतात... म्हणजे, एक सर्व्हर जो केवळ ओपनरेस्टी चालवतो, तो फक्त ट्रॅफिकला प्रॉक्सी करतो. त्यानुसार, आम्ही किती धरतो हे समजून घेण्यासाठी: आमच्याकडे आता अनेक शंभर मेगाबिटचा नियमित वाहतूक प्रवाह आहे. ते सामना करतात, त्यांना चांगले वाटते, ते स्वतःला ताणत नाहीत.

  मध्ये: - तसेच एक साधा प्रश्न. येथे ब्लू/ग्रीन डिप्लॉयमेंट आहे. तुम्ही काय करता, उदाहरणार्थ, डेटाबेस स्थलांतराने?

  EK: - चांगला प्रश्न! पहा, ब्लू/ग्रीन डिप्लॉयमेंटमध्ये आमच्याकडे प्रत्येक ओळीसाठी वेगळ्या रांगा आहेत. म्हणजेच, जर आपण कार्यकर्त्याकडून कार्यकर्त्याकडे प्रसारित केलेल्या इव्हेंट रांगेबद्दल बोलत असाल तर, निळ्या ओळीसाठी आणि हिरव्या ओळीसाठी स्वतंत्र रांगा आहेत. जर आपण डेटाबेसबद्दलच बोलत असाल, तर आम्ही मुद्दाम ते शक्य तितके संकुचित केले, सर्वकाही व्यावहारिकरित्या रांगेत हलवले; डेटाबेसमध्ये आम्ही फक्त व्यवहारांचा स्टॅक ठेवतो. आणि आमचा व्यवहार स्टॅक सर्व ओळींसाठी समान आहे. या संदर्भात डेटाबेससह: आम्ही ते निळ्या आणि हिरव्यामध्ये विभागत नाही, कारण कोडच्या दोन्ही आवृत्त्यांना व्यवहारात काय होत आहे हे माहित असणे आवश्यक आहे.

  मित्रांनो, तुम्हाला प्रोत्साहन देण्यासाठी माझ्याकडे एक छोटेसे बक्षीस आहे - एक पुस्तक. आणि मला सर्वोत्तम प्रश्नासाठी पुरस्कार मिळायला हवा.

  मध्ये: - नमस्कार. अहवालाबद्दल धन्यवाद. हा प्रश्न आहे. तुम्ही पेमेंट्सचे निरीक्षण करता, तुम्ही ज्या सेवांशी संवाद साधता त्या सेवांचे निरीक्षण करता... पण तुम्ही कसे निरीक्षण करता की एखादी व्यक्ती तुमच्या पेमेंट पेजवर आली, पेमेंट केले आणि प्रोजेक्टने त्याला पैसे जमा केले? म्हणजेच, मार्चंट उपलब्ध आहे आणि त्याने तुमचा कॉलबॅक स्वीकारला आहे यावर तुम्ही कसे निरीक्षण कराल?

  EK: - या प्रकरणात आमच्यासाठी "व्यापारी" ही पेमेंट सिस्टम सारखीच बाह्य सेवा आहे. आम्ही व्यापाऱ्याच्या प्रतिसादाच्या गतीवर लक्ष ठेवतो.

  डेटाबेस एनक्रिप्शन बद्दल

  मध्ये: - नमस्कार. माझा थोडासा संबंधित प्रश्न आहे. तुमच्याकडे PCI DSS संवेदनशील डेटा आहे. मला हे जाणून घ्यायचे आहे की तुम्ही ज्या रांगेत PAN ठेवता त्या रांगेत तुम्ही कसे ठेवता? तुम्ही कोणतेही एन्क्रिप्शन वापरता का? आणि यामुळे दुसरा प्रश्न उद्भवतो: पीसीआय डीएसएसच्या मते, बदल झाल्यास (प्रशासकांना डिसमिस करणे इ.) डेटाबेसमध्ये वेळोवेळी पुन्हा एनक्रिप्ट करणे आवश्यक आहे - या प्रकरणात प्रवेशयोग्यतेचे काय होईल?

  
  
  EK: - आश्चर्यकारक प्रश्न! प्रथम, आम्ही पॅन रांगेत ठेवत नाही. आम्हाला तत्त्वतः स्पष्ट स्वरूपात पॅन कोठेही संग्रहित करण्याचा अधिकार नाही, म्हणून आम्ही एक विशेष सेवा वापरतो (आम्ही त्याला "कॅडेमॉन" म्हणतो) - ही एक अशी सेवा आहे जी फक्त एक गोष्ट करते: ती इनपुट म्हणून संदेश प्राप्त करते आणि पाठवते. एक कूटबद्ध संदेश बाहेर. आणि आम्ही या एनक्रिप्टेड संदेशासह सर्वकाही संग्रहित करतो. त्यानुसार, आमची की लांबी एक किलोबाइटच्या खाली आहे, जेणेकरून हे गंभीर आणि विश्वासार्ह आहे.

  मध्ये: - तुम्हाला आता 2 किलोबाइट्सची गरज आहे का?

  EK: - असे दिसते की कालच ते 256 होते... बरं, अजून कुठे?!

  त्यानुसार, हे पहिले आहे. आणि दुसरे म्हणजे, अस्तित्वात असलेले सोल्यूशन, ते री-एनक्रिप्शन प्रक्रियेस समर्थन देते - "केक्स" (की) च्या दोन जोड्या आहेत, जे एन्क्रिप्ट करणारे "डेक" देतात (की म्हणजे की, डेक हे कूटबद्ध केलेल्या कीजचे डेरिव्हेटिव्ह आहेत) . आणि जर प्रक्रिया सुरू केली गेली (ती नियमितपणे होते, 3 महिन्यांपासून ± काही पर्यंत), आम्ही "केक" ची नवीन जोडी डाउनलोड करतो आणि आम्ही डेटा पुन्हा कूटबद्ध करतो. आमच्याकडे स्वतंत्र सेवा आहेत ज्या सर्व डेटा काढून टाकतात आणि नवीन मार्गाने एन्क्रिप्ट करतात; डेटा कूटबद्ध केलेल्या कीच्या आयडेंटिफायरच्या पुढे संग्रहित केला जातो. त्यानुसार, आम्ही नवीन कीसह डेटा एनक्रिप्ट करताच, आम्ही जुनी की हटवतो.

  काहीवेळा पेमेंट व्यक्तिचलितपणे करावे लागते...

  मध्ये: – म्हणजे, जर काही ऑपरेशनसाठी परतावा आला असेल, तरीही तुम्ही जुन्या कीसह ते डिक्रिप्ट कराल का?

  EK: - होय.

  मध्ये: - मग आणखी एक छोटा प्रश्न. जेव्हा काही प्रकारचे बिघाड, पडणे किंवा घटना घडते, तेव्हा व्यवहार स्वतःहून पुढे ढकलणे आवश्यक आहे. अशी परिस्थिती आहे.

  EK: - होय, कधीकधी.

  मध्ये: - तुम्हाला हा डेटा कुठून मिळेल? किंवा तुम्ही स्वतः या स्टोरेज सुविधेकडे जाता का?

  EK: - नाही, नक्कीच, आमच्याकडे काही प्रकारची बॅक-ऑफिस प्रणाली आहे ज्यामध्ये आमच्या समर्थनासाठी एक इंटरफेस आहे. व्यवहार कोणत्या स्थितीत आहे हे आम्हाला माहिती नसल्यास (उदाहरणार्थ, पेमेंट सिस्टमने कालबाह्यतेसह प्रतिसाद देईपर्यंत), आम्हाला प्राधान्य माहित नाही, म्हणजेच आम्ही केवळ पूर्ण आत्मविश्वासाने अंतिम स्थिती नियुक्त करतो. या प्रकरणात, आम्ही मॅन्युअल प्रक्रियेसाठी व्यवहार एका विशेष स्थितीसाठी नियुक्त करतो. सकाळी, दुसर्‍या दिवशी, सपोर्टला असे आणि असे व्यवहार पेमेंट सिस्टममध्ये राहिल्याची माहिती प्राप्त होताच, ते या इंटरफेसमध्ये मॅन्युअली प्रक्रिया करतात.

  
  
  मध्ये: - माझ्याकडे दोन प्रश्न आहेत. त्यापैकी एक पीसीआय डीएसएस झोन चालू आहे: आपण त्यांचे सर्किट कसे लॉग कराल? हा प्रश्न आहे कारण डेव्हलपरला लॉगमध्ये काहीही ठेवता आले असते! दुसरा प्रश्न: तुम्ही हॉटफिक्स कसे रोल आउट करता? डेटाबेसमध्ये हँडल वापरणे हा एक पर्याय आहे, परंतु तेथे विनामूल्य हॉट-फिक्सेस असू शकतात - तेथे प्रक्रिया काय आहे? आणि तिसरा प्रश्न बहुधा RTO, RPO शी संबंधित आहे. तुमची उपलब्धता 99,97 होती, जवळजवळ चार नाइन, पण मला समजले त्याप्रमाणे, तुमच्याकडे दुसरे डेटा सेंटर, तिसरे डेटा सेंटर आणि पाचवे डेटा सेंटर आहे... तुम्ही त्यांना कसे सिंक्रोनाइझ कराल, त्यांची प्रतिकृती बनवा आणि इतर सर्व काही कसे करता?

  EK: - चला पहिल्यापासून सुरुवात करूया. लॉग बद्दल पहिला प्रश्न होता? जेव्हा आम्ही लॉग लिहितो, तेव्हा आमच्याकडे एक स्तर असतो जो सर्व संवेदनशील डेटाला मास्क करतो. ती मास्क आणि अतिरिक्त फील्डकडे पाहते. त्यानुसार, आमचे लॉग आधीच मास्क केलेला डेटा आणि PCI DSS सर्किटसह बाहेर येतात. हे चाचणी विभागाला नियुक्त केलेल्या नियमित कामांपैकी एक आहे. विकासकाने काहीतरी लिहून ठेवले नाही हे नियंत्रित करण्यासाठी, त्यांनी लिहिलेल्या लॉगसह प्रत्येक कार्य तपासणे आवश्यक आहे आणि कोड पुनरावलोकनांदरम्यान हे नियमित कार्यांपैकी एक आहे. त्यानंतरच्या तपासण्या माहिती सुरक्षा विभागाद्वारे आठवड्यातून एकदा नियमितपणे केल्या जातात: शेवटच्या दिवसाचे लॉग निवडकपणे घेतले जातात आणि ते सर्व काही तपासण्यासाठी चाचणी सर्व्हरवरून विशेष स्कॅनर-विश्लेषकाद्वारे चालवले जातात.
  हॉट-फिक्स बद्दल. हे आमच्या उपयोजन नियमांमध्ये समाविष्ट आहे. आमच्याकडे हॉटफिक्सबद्दल वेगळे कलम आहे. आमचा विश्वास आहे की जेव्हा आम्हाला गरज असते तेव्हा आम्ही चोवीस तास हॉटफिक्स तैनात करतो. आवृत्ती असेंबल होताच, ती चालवल्याबरोबर, आमच्याकडे आर्टिफॅक्ट होताच, आमच्याकडे सपोर्टच्या कॉलवर एक सिस्टम प्रशासक ड्युटीवर असतो आणि जेव्हा आवश्यक असेल तेव्हा तो ते तैनात करतो.

  सुमारे "चार नाइन" आता आमच्याकडे असलेला आकडा खर्‍या अर्थाने साध्य झाला आहे आणि आम्ही दुसर्‍या डेटा सेंटरमध्ये त्यासाठी प्रयत्न केले. आता आमच्याकडे दुसरे डेटा सेंटर आहे, आणि आम्ही त्यांच्या दरम्यान मार्ग काढू लागलो आहोत, आणि क्रॉस-डेटा सेंटर प्रतिकृतीचा मुद्दा खरोखरच एक क्षुल्लक प्रश्न आहे. आम्ही एकाच वेळी वेगवेगळ्या माध्यमांचा वापर करून ते सोडवण्याचा प्रयत्न केला: आम्ही समान "टॅरंटुला" वापरण्याचा प्रयत्न केला - ते आमच्यासाठी कार्य करत नाही, मी तुम्हाला लगेच सांगेन. म्हणूनच आम्ही "सेन्स" मॅन्युअली ऑर्डर करणे समाप्त केले. खरं तर, आमच्या सिस्टीममधील प्रत्येक अनुप्रयोग डेटा केंद्रांमध्ये असिंक्रोनस पद्धतीने आवश्यक "बदल - पूर्ण" सिंक्रोनाइझेशन चालवतो.

  मध्ये: - जर तुम्हाला दुसरा मिळाला तर तुम्हाला तिसरा का नाही मिळाला? कारण अजून कोणाचाही मेंदू फुटलेला नाही...

  EK: - पण आमच्याकडे स्प्लिट ब्रेन नाही. प्रत्येक अर्ज मल्टीमास्टरद्वारे चालविला जातो या वस्तुस्थितीमुळे, विनंती कोणत्या केंद्राकडे आली याने आमच्यासाठी फरक पडत नाही. आम्ही या वस्तुस्थितीसाठी तयार आहोत की आमच्या डेटा सेंटरपैकी एक अयशस्वी झाल्यास (आम्ही यावर अवलंबून आहोत) आणि वापरकर्त्याच्या विनंतीच्या मध्यभागी दुसऱ्या डेटा सेंटरवर स्विच केल्यास, आम्ही हा वापरकर्ता गमावण्यास तयार आहोत; परंतु ही एकके, निरपेक्ष एकके असतील.

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

  EK: - हे संपूर्ण घटकाच्या संपूर्ण चक्रातून जाते. घटकासाठी, चाचणी व्यवहार आणि उत्पादन व्यवहार यामध्ये फरक नाही. परंतु तार्किक दृष्टिकोनातून, हा सिस्टममधील एक वेगळा प्रकल्प आहे, ज्यावर केवळ चाचणी व्यवहार चालवले जातात.

  मध्ये: - तुम्ही ते कुठे कापले? येथे कोर पाठवले...

  EK: – चाचणी व्यवहारांसाठी आम्ही या प्रकरणात “Kor” च्या मागे आहोत... आमच्याकडे राउटिंगसारखी गोष्ट आहे: “Kor” ला माहित आहे की कोणत्या पेमेंट सिस्टमला पाठवायचे आहे - आम्ही बनावट पेमेंट सिस्टमला पाठवतो, जी फक्त HTTP सिग्नल देते आणि एवढेच.

  मध्ये: - कृपया मला सांगा, तुमचा अर्ज एका मोठ्या मोनोलिथमध्ये लिहिला होता, किंवा तुम्ही तो काही सेवांमध्ये किंवा अगदी मायक्रोसर्व्हिसेसमध्ये कापला होता?

  EK: - आमच्याकडे मोनोलिथ नाही, अर्थातच आमच्याकडे सेवा-देणारं अनुप्रयोग आहे. आम्ही विनोद करतो की आमची सेवा मोनोलिथपासून बनलेली आहे - ते खरोखर खूप मोठे आहेत. याला मायक्रोसर्व्हिसेस म्हणणे कठीण आहे, परंतु या अशा सेवा आहेत ज्यामध्ये वितरित मशीनचे कामगार काम करतात.

  सर्व्हरवरील सेवेशी तडजोड झाल्यास...

  मध्ये: - मग माझा पुढचा प्रश्न आहे. जरी तो एक मोनोलिथ असला तरीही, तरीही तुम्ही म्हणालात की तुमच्याकडे यापैकी बरेच इन्स्टंट सर्व्हर आहेत, ते सर्व मुळात डेटावर प्रक्रिया करतात आणि प्रश्न असा आहे: “इन्स्टंट सर्व्हर किंवा अनुप्रयोगापैकी एकाशी तडजोड झाल्यास, कोणतीही वैयक्तिक लिंक , त्यांच्याकडे काही प्रकारचे प्रवेश नियंत्रण आहे का? त्यापैकी कोण काय करू शकतो? कोणत्या माहितीसाठी मी कोणाशी संपर्क साधावा?

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

  मध्ये: - आणि या संदर्भात, माझ्यासाठी सर्वात मनोरंजक गोष्ट म्हणजे तुमची सेवांसोबत काही विशिष्ट करार आहेत - ते काय करू शकतात, कोणत्या "कृतींद्वारे" ते एकमेकांशी संपर्क साधू शकतात... आणि सामान्य प्रवाहात, काही विशिष्ट सेवा काही विनंती करतात. पंक्ती, दुसऱ्या बाजूला “क्रियांची” यादी. ते सामान्य परिस्थितीत इतरांकडे वळत नाहीत असे वाटत नाही आणि त्यांच्याकडे जबाबदारीची इतर क्षेत्रे आहेत. जर त्यांपैकी एकाशी तडजोड केली गेली, तर ती त्या सेवेच्या "कृती" मध्ये व्यत्यय आणू शकेल का?..

  EK: - मला समजले. जर सामान्य परिस्थितीत दुसर्‍या सर्व्हरसह संप्रेषणास अजिबात परवानगी असेल तर होय. SLA करारानुसार, आम्ही निरीक्षण करत नाही की तुम्हाला फक्त पहिल्या 3 "कृती" ची परवानगी आहे आणि तुम्हाला 4 "कृती" करण्याची परवानगी नाही. हे कदाचित आमच्यासाठी अनावश्यक आहे, कारण आमच्याकडे आधीपासूनच 4-स्तरीय संरक्षण प्रणाली आहे, तत्त्वतः, सर्किट्ससाठी. आम्ही आतील बाजूंच्या पातळीवर न राहता आराखड्याने स्वतःचा बचाव करण्यास प्राधान्य देतो.

  Visa, MasterCard आणि Sberbank कसे काम करतात

  मध्ये: – वापरकर्त्याला एका डेटा सेंटरमधून दुसऱ्या डेटा सेंटरमध्ये स्विच करण्याबद्दल मला एक मुद्दा स्पष्ट करायचा आहे. माझ्या माहितीनुसार, Visa आणि MasterCard 8583 बायनरी सिंक्रोनस प्रोटोकॉल वापरून कार्य करतात आणि तेथे मिक्स आहेत. आणि मला हे जाणून घ्यायचे होते, आता आमचा अर्थ स्विचिंग आहे – ते थेट “व्हिसा” आणि “मास्टरकार्ड” आहे की पेमेंट सिस्टम्सपूर्वी, प्रक्रिया करण्यापूर्वी?

  EK: - हे मिश्रणापूर्वी आहे. आमची मिक्स एकाच डेटा सेंटरमध्ये आहेत.

  मध्ये: - साधारणपणे सांगायचे तर, तुमच्याकडे एक कनेक्शन पॉइंट आहे का?

  EK: - "व्हिसा" आणि "मास्टरकार्ड" - होय. फक्त कारण व्हिसा आणि मास्टरकार्डला दुसरी जोडी मिश्रित करण्यासाठी स्वतंत्र करार पूर्ण करण्यासाठी पायाभूत सुविधांमध्ये गंभीर गुंतवणूक आवश्यक आहे, उदाहरणार्थ. ते एका डेटा सेंटरमध्ये राखीव आहेत, परंतु, जर देवाने मनाई केली, तर आमचे डेटा सेंटर, जिथे व्हिसा आणि मास्टरकार्डला जोडण्यासाठी मिक्स आहेत, ते मरण पावले, तर आमचा व्हिसा आणि मास्टरकार्डचा कनेक्शन तुटतो...

  मध्ये: - ते कसे आरक्षित केले जाऊ शकतात? मला माहित आहे की व्हिसा तत्त्वतः फक्त एक कनेक्शनला परवानगी देतो!

  EK: - ते स्वतः उपकरणे पुरवतात. कोणत्याही परिस्थितीत, आम्हाला उपकरणे प्राप्त झाली जी आत पूर्णपणे अनावश्यक आहेत.

  मध्ये: - तर स्टँड त्यांच्या कनेक्ट्स ऑरेंजचा आहे?..

  EK: - होय.

  मध्ये: - परंतु या प्रकरणाचे काय: जर तुमचे डेटा सेंटर गायब झाले तर तुम्ही ते कसे वापरणे सुरू ठेवू शकता? की वाहतूक फक्त थांबते?

  EK: - नाही. या प्रकरणात, आम्ही रहदारी दुसर्‍या चॅनेलवर स्विच करू, जे नैसर्गिकरित्या आमच्यासाठी अधिक महाग आणि आमच्या क्लायंटसाठी अधिक महाग असेल. परंतु रहदारी व्हिसा, मास्टरकार्डशी आमच्या थेट कनेक्शनद्वारे होणार नाही, परंतु सशर्त Sberbank (अत्यंत अतिशयोक्तीपूर्ण) द्वारे जाईल.

  जर मी Sberbank कर्मचार्‍यांना नाराज केले असेल तर मी माफी मागतो. परंतु आमच्या आकडेवारीनुसार, रशियन बँकांमध्ये, Sberbank बहुतेकदा पडतो. Sberbank मध्ये काहीतरी पडल्याशिवाय एक महिना जात नाही.

  
  
  

  काही जाहिराती 🙂

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

  डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com