फेलओभर: पूर्णतावाद र... आलस्यले हामीलाई बर्बाद गर्दैछ

गर्मीमा, दुबै खरीद गतिविधि र वेब परियोजनाहरूको पूर्वाधारमा परिवर्तनहरूको तीव्रता परम्परागत रूपमा घट्छ, क्याप्टेन स्पष्टले हामीलाई बताउँछ। केवल किनभने आईटी विशेषज्ञहरू पनि कहिलेकाहीं छुट्टीमा जान्छन्। र CTO पनि। अफिसमा रहनेहरूका लागि यो सबै धेरै गाह्रो छ, तर यो अहिलेको बिन्दु होइन: सायद यसैले विद्यमान आरक्षण योजनाको बारेमा बिस्तारै सोच्न र यसलाई सुधार गर्ने योजना बनाउनको लागि गर्मी सबैभन्दा राम्रो अवधि हो। र बाट Yegor Andreev को अनुभव प्रशासन विभागजसको बारेमा उनले सम्मेलनमा बोलेका थिए अपटाइम दिन.

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

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

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

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

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

तपाईं यो कसरी लड्न सक्नुहुन्छ? हामीले आफैंसँग झूट बोल्न बन्द गर्न आवश्यक छ, आफैलाई चापलूसी गर्न छोड्नु पर्छ कि हामी अब यहाँ एक स्पेसशिप निर्माण गर्न जाँदैछौं, तर पर्याप्त रूपमा बुझ्नुहोस् कि यो परियोजना कति लामो हुन सक्छ। र यो अधिकतम समयको लागि, हामी हाम्रो प्रणालीको विश्वसनीयता बढाउन वास्तवमा कुन विधिहरू प्रयोग गर्नेछौं भनेर छनौट गर्नेछौं।

यो पक्कै पनि जीवनबाट "कथाहरूबाट w"...को लागि समय हो।

उदाहरण नम्बर एक

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

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

उदाहरण नम्बर दुई

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

उदाहरण नम्बर तीन, थप जटिल

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

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

उदाहरण नम्बर चार, अझ गाह्रो

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

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

र सबै कुरा स्पष्ट देखिन्छ। प्रतिकृति स्विच गर्नु एक तुच्छ कार्य हो, वा यो आफैं स्विच हुनेछ। DNS मा डोमेन नाम पुन: लेख्नु उही श्रृंखलाबाट हो। समस्या यो छ कि जब यस्तो परियोजना असफल हुन्छ, आतंक सुरु हुन्छ, र सबैभन्दा बलियो, दाह्री भएका प्रशासकहरू पनि यसको लागि संवेदनशील हुन सक्छन्। स्पष्ट निर्देशन बिना "टर्मिनल खोल्नुहोस्, यहाँ आउनुहोस्, हाम्रो सर्भरको ठेगाना अझै यस्तै छ," पुनरुत्थानको लागि छुट्याइएको 5-मिनेट समय सीमा पूरा गर्न गाह्रो छ। ठीक छ, साथै, जब हामी यी नियमहरू प्रयोग गर्छौं, पूर्वाधारमा केही परिवर्तनहरू रेकर्ड गर्न सजिलो हुन्छ, उदाहरणका लागि, र तदनुसार नियमहरू परिवर्तन गर्नुहोस्।
ठीक छ, यदि रिजर्भेसन प्रणाली धेरै जटिल छ र केहि बिन्दुमा हामीले गल्ती गर्यौं, त्यसपछि हामी हाम्रो जगेडा साइट नष्ट गर्न सक्छौं, र थप रूपमा डेटालाई दुवै साइटहरूमा कद्दूमा बदल्न सक्छौं - यो पूर्ण रूपमा दुःखी हुनेछ।

उदाहरण नम्बर पाँच, पूर्ण हार्डकोर

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

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

सायद यति नै हो। अल्छी नहुनुहोस् वा यसलाई अधिक नगर्नुहोस्। र अपटाइम तपाईं संग हुन सक्छ!

स्रोत: www.habr.com