विफलता: पूर्णतावाद और...आलस्य हमें बर्बाद कर रहे हैं

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

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

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

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

शतोष (सी) हम दूसरी साइट लेते हैं, एक समान प्रणाली बनाते हैं... जटिलता दोगुनी हो जाती है - हमारे पास दो संस्थाएं हैं। हम डेटा को एक साइट से दूसरी साइट पर स्थानांतरित करने के लिए एक निश्चित तर्क भी पेश करते हैं - यानी, डेटा प्रतिकृति, स्थैतिक डेटा की प्रतिलिपि बनाना, इत्यादि। इसलिए, प्रतिकृति तर्क आमतौर पर बहुत जटिल होता है, और इसलिए, सिस्टम की कुल जटिलता 2 नहीं, बल्कि 3, 5, 10 गुना अधिक हो सकती है।

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

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

बेशक, यह "कहानियों की कहानी" का समय है...जीवन से।

उदाहरण नंबर एक

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

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

उदाहरण संख्या दो

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

उदाहरण संख्या तीन, अधिक जटिल

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

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

उदाहरण संख्या चार, और भी कठिन

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

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

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

उदाहरण संख्या पांच, पूर्ण कट्टर

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

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

शायद बस इतना ही. आलसी मत बनो या इसे ज़्यादा मत करो। और अपटाइम आपके साथ हो सकता है!

स्रोत: www.habr.com