फेलओव्हर: परिपूर्णता आणि... आळशीपणा आपला नाश करत आहे

उन्हाळ्यात, खरेदी क्रियाकलाप आणि वेब प्रकल्पांच्या पायाभूत सुविधांमधील बदलांची तीव्रता पारंपारिकपणे कमी होते, कॅप्टन ऑब्विअस आम्हाला सांगतात. फक्त कारण आयटी तज्ञ देखील कधीकधी सुट्टीवर जातात. आणि CTO सुद्धा. जे लोक पदावर आहेत त्यांच्यासाठी हे सर्व अधिक कठीण आहे, परंतु आता तो मुद्दा नाही: कदाचित म्हणूनच सध्याच्या आरक्षण योजनेबद्दल हळूहळू विचार करण्यासाठी आणि त्यात सुधारणा करण्यासाठी योजना तयार करण्यासाठी उन्हाळा हा सर्वोत्तम कालावधी आहे. आणि येगोर अँड्रीव्हचा अनुभव प्रशासन विभाग, ज्याबद्दल ते परिषदेत बोलले अपटाइम दिवस.

बॅकअप साइट्स तयार करताना तुम्हाला अनेक अडचणी येऊ शकतात. आणि त्यांच्यात अडकणे पूर्णपणे अशक्य आहे. आणि इतर अनेक गोष्टींप्रमाणेच या सगळ्यामध्ये आपला नाश करणारी गोष्ट म्हणजे परिपूर्णता आणि... आळशीपणा. आम्ही सर्वकाही, सर्वकाही, सर्वकाही उत्तम प्रकारे करण्याचा प्रयत्न करीत आहोत, परंतु आम्हाला ते अचूकपणे करण्याची आवश्यकता नाही! आपल्याला फक्त काही गोष्टी करण्याची आवश्यकता आहे, परंतु त्या योग्यरित्या करा, त्या पूर्ण करा जेणेकरून ते योग्यरित्या कार्य करतील.

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

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

श्तोष (c) आम्ही दुसरी साइट घेतो, एक समान प्रणाली तयार करतो... जटिलता दुप्पट होते - आमच्याकडे दोन घटक आहेत. आम्ही एका साइटवरून दुसर्‍या साइटवर डेटा हस्तांतरित करण्यासाठी एक विशिष्ट लॉजिक देखील रोल आउट करतो - म्हणजे, डेटा प्रतिकृती, स्थिर डेटा कॉपी करणे इ. तर, प्रतिकृती तर्कशास्त्र सहसा खूप गुंतागुंतीचे असते आणि म्हणून, प्रणालीची एकूण जटिलता 2 नाही तर 3, 5, 10 पट जास्त असू शकते.

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

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

ही वेळ आली आहे “w from कथा”... जीवनातील, अर्थातच.

उदाहरण क्रमांक एक

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

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

उदाहरण क्रमांक दोन

कंपनी ब्लॉग: विशेष प्रशिक्षित लोक तेथे बातम्या लिहितात, आम्ही अशा आणि अशा प्रदर्शनात भाग घेतला, परंतु आम्ही आणखी एक नवीन उत्पादन जारी केले, इत्यादी. समजा हे वर्डप्रेस, एक छोटा डेटाबेस आणि थोडासा स्टॅटिकसह मानक PHP आहे. अर्थात, हे पुन्हा लक्षात येते की तुम्ही कोणत्याही परिस्थितीत झोपू नये - “पाच मिनिटांपेक्षा जास्त नाही!” एवढेच. पण पुढे विचार करूया. हा ब्लॉग काय करतो? लोक यॅन्डेक्स वरून, Google वरून काही प्रश्नांवर आधारित, सेंद्रियपणे येतात. मस्त. विक्रीचा काही संबंध आहे का? एपिफनी: खरोखर नाही. जाहिरात रहदारी मुख्य साइटवर जाते, जी वेगळ्या मशीनवर असते. बुकिंग स्कीमबद्दल विचार सुरू करूया. चांगल्या मार्गाने, ते काही तासांत वाढवणे आवश्यक आहे आणि यासाठी तयारी करणे चांगले होईल. दुसर्‍या डेटा सेंटरमधून मशीन घेणे, त्यावर पर्यावरण रोल करणे, म्हणजे वेब सर्व्हर, PHP, वर्डप्रेस, MySQL, आणि ते तेथे सोडणे वाजवी असेल. या क्षणी जेव्हा आपल्याला समजते की सर्व काही तुटलेले आहे, तेव्हा आपल्याला दोन गोष्टी करण्याची आवश्यकता आहे - mysql डंप 50 मीटर रोल आउट करा, ते एका मिनिटात तेथे उडून जाईल आणि बॅकअपमधून काही विशिष्ट चित्रे बाहेर काढा. हे सुद्धा तिथे नाही देव जाणे किती दिवस. अशा प्रकारे, अर्ध्या तासात संपूर्ण गोष्ट उठते. कोणतीही प्रतिकृती, किंवा देव मला माफ कर, स्वयंचलित फेलओव्हर. निष्कर्ष: बॅकअपमधून आपण जे पटकन रोल आउट करू शकतो त्याचा बॅकअप घेण्याची आवश्यकता नाही.

उदाहरण क्रमांक तीन, अधिक क्लिष्ट

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

हे सर्व कसे राखून ठेवता येईल? आपल्याला कोणत्याही परिस्थितीत कारची आवश्यकता आहे: वेळ एक तास खूपच कमी आहे. Mysql: येथे आम्हाला आधीपासूनच प्रतिकृती, थेट प्रतिकृती आवश्यक आहे, कारण एका तासात 100 GB बहुधा डंपमध्ये जोडले जाणार नाही. स्टॅटिक्स, चित्रे: पुन्हा, एका तासात 500 GB जोडण्यासाठी वेळ नसेल. म्हणून, चित्रे त्वरित कॉपी करणे चांगले आहे. रेडिस: येथेच गोष्टी मनोरंजक होतात. रेडिसमध्ये, सत्रे संग्रहित केली जातात - आम्ही ते फक्त घेऊन दफन करू शकत नाही. कारण हे फार चांगले होणार नाही: सर्व वापरकर्ते लॉग आउट केले जातील, त्यांच्या टोपल्या रिकामी केल्या जातील, इत्यादी. लोकांना त्यांचे वापरकर्तानाव आणि पासवर्ड पुन्हा एंटर करण्यास भाग पाडले जाईल आणि बरेच लोक खरेदी पूर्ण करू शकत नाहीत. पुन्हा, रूपांतरणे कमी होतील. दुसरीकडे, रेडिस थेट अद्ययावत आहे, शेवटच्या लॉग-इन केलेल्या वापरकर्त्यांना कदाचित गरज नाही. आणि एक चांगली तडजोड म्हणजे रेडिस घेणे आणि कालपासून बॅकअपमधून ते पुनर्संचयित करणे किंवा, जर तुम्ही ते दर तासाला, एक तासापूर्वी केले तर. सुदैवाने, बॅकअपमधून पुनर्संचयित करणे म्हणजे एक फाइल कॉपी करणे. आणि सर्वात मनोरंजक कथा आहे Elasticsearch. MySQL प्रतिकृती कोणी कधी उचलली आहे? Elasticsearch प्रतिकृती कोणी कधी उचलली आहे? आणि नंतर ते सामान्यपणे कोणासाठी कार्य केले? मला असे म्हणायचे आहे की आपण आपल्या सिस्टममध्ये एक विशिष्ट अस्तित्व पाहतो. हे उपयुक्त आहे असे दिसते - परंतु ते गुंतागुंतीचे आहे.
आमच्या सहकारी अभियंत्यांना त्यासोबत काम करण्याचा अनुभव नाही या अर्थाने जटिल. किंवा एक नकारात्मक अनुभव आहे. किंवा आम्ही समजतो की हे अजूनही अगदी नवीन तंत्रज्ञान आहे ज्यामध्ये बारकावे किंवा कच्चापणा आहे. आम्हाला वाटतं... अरेरे, लवचिक देखील हेल्दी आहे, बॅकअपमधून ते पुनर्संचयित करण्यासाठी देखील बराच वेळ लागतो, मी काय करावे? आम्हाला समजते की आमच्या बाबतीत लवचिक शोधासाठी वापरले जाते. आमचे ऑनलाइन स्टोअर कसे विकते? आम्ही मार्केटर्सकडे जातो आणि विचारतो की लोक कुठून येतात. ते उत्तर देतात: "Yandex Market कडून 90% थेट उत्पादन कार्डवर येतात." आणि एकतर ते विकत घेतात किंवा करत नाहीत. म्हणून, 10% वापरकर्त्यांना शोध आवश्यक आहे. आणि लवचिक प्रतिकृती ठेवणे, विशेषत: वेगवेगळ्या झोनमधील भिन्न डेटा केंद्रांमध्ये, खरोखर खूप बारकावे आहेत. कोणता निर्गमन? आम्ही आरक्षित साइटवरून लवचिक घेतो आणि त्याच्याशी काहीही करत नाही. प्रकरण पुढे ढकलल्यास, आम्ही कदाचित ते कधीतरी वाढवू, परंतु हे निश्चित नाही. वास्तविक, निष्कर्ष समान आहे, अधिक किंवा वजा: आम्ही पुन्हा, पैशांवर परिणाम करणारी सेवा आरक्षित करत नाही. आकृती सोपी ठेवण्यासाठी.

उदाहरण क्रमांक चार, आणखी कठीण

इंटिग्रेटर: फुले विकणे, टॅक्सी कॉल करणे, वस्तू विकणे, सर्वसाधारणपणे काहीही. एक गंभीर गोष्ट जी मोठ्या संख्येने वापरकर्त्यांसाठी 24/7 कार्य करते. पूर्ण वाढ झालेल्या मनोरंजक स्टॅकसह, जेथे मनोरंजक तळ, उपाय, उच्च भार आणि सर्वात महत्त्वाचे म्हणजे, 5 मिनिटांपेक्षा जास्त झोपणे दुखते. केवळ आणि इतकेच नाही कारण लोक खरेदी करणार नाहीत, परंतु लोकांना दिसेल की ही गोष्ट कार्य करत नाही, ते अस्वस्थ होतील आणि कदाचित परत येणार नाहीत.

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

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

उदाहरण क्रमांक पाच, पूर्ण हार्डकोर

जगभरातील लाखो वापरकर्त्यांसह एक आंतरराष्ट्रीय सेवा. सर्व टाइम झोन आहेत, कमाल वेगाने जास्त भार, तुम्ही अजिबात झोपू शकत नाही. एक मिनिट - आणि ते दुःखी होईल. काय करायचं? पूर्ण कार्यक्रमानुसार, पुन्हा आरक्षित करा. मी मागील उदाहरणात बोललो ते सर्व आम्ही केले आणि थोडे अधिक. एक आदर्श जग आणि आमची पायाभूत सुविधा IaaC devops च्या सर्व संकल्पनांनुसार आहे. म्हणजेच, सर्वकाही गिटमध्ये आहे आणि आपण फक्त बटण दाबा.

काय गहाळ आहे? एक - व्यायाम. त्यांच्याशिवाय हे अशक्य आहे. असे दिसते की आमच्याबरोबर सर्वकाही परिपूर्ण आहे, आमच्याकडे सामान्यतः सर्वकाही नियंत्रणात असते. आम्ही बटण दाबतो, सर्वकाही होते. जरी असे असले तरी - आणि आम्ही समजतो की हे अशा प्रकारे होत नाही - आमची प्रणाली इतर काही प्रणालींशी संवाद साधते. उदाहरणार्थ, हे रूट 53, s3 स्टोरेज, काही api सह एकत्रीकरण पासून dns आहे. आम्ही या सट्टा प्रयोगात सर्वकाही अंदाज लावू शकणार नाही. आणि जोपर्यंत आम्ही स्विच खेचत नाही तोपर्यंत ते कार्य करेल की नाही हे आम्हाला कळणार नाही.

बहुधा एवढेच. आळशी होऊ नका किंवा ते जास्त करू नका. आणि अपटाइम तुमच्यासोबत असू शकेल!

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