100% परियोजना पहुंच सुनिश्चित करने की समस्याएं

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

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

1. एक डाटा सेंटर / क्लाउड होस्टिंग के एक क्षेत्र में संपूर्ण परियोजना का स्थानीयकरण

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

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

AWS अनुशंसित प्रोजेक्ट वर्कफ़्लो में अधिकतम प्रोजेक्ट अपटाइम प्राप्त करने के लिए कई डिफ़ॉल्ट उपलब्धता ज़ोन का उपयोग करना शामिल है।

2. आरक्षित स्थल पर पर्याप्त दोहराव का अभाव

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

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

3. एक स्विचिंग प्लान की कमी और बैकअप साइट पर नियमित स्विचिंग

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

4. एक ही चैनल पर / बादलों के एक ही क्षेत्र में आरक्षित स्थल का स्थानीयकरण

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

5. मुख्य और आरक्षित साइटों पर समान संस्करणों का प्लेसमेंट।

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

6. बाहरी सेवाओं पर निर्भरता परियोजना तक पहुँच रही है।

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

यह सब से दूर है, लेकिन कम से कम बुनियादी चीजें हैं। हम uptime.community बैठकों में इस पर अधिक विस्तार से चर्चा करते हैं, अगला एक अक्टूबर में होगा, लेकिन अब आप टेलीग्राम समूह में चैट कर सकते हैं।