हाईलोड आईटी सिस्टम के संचालन और समर्थन की प्रक्रियाओं में पांच समस्याएं

नमस्ते, हबर! मैं दस वर्षों से हाईलोड आईटी सिस्टम का समर्थन कर रहा हूं। मैं इस लेख में nginx को 1000+ RPS मोड में काम करने के लिए स्थापित करने या अन्य तकनीकी चीजों की समस्याओं के बारे में नहीं लिखूंगा। मैं ऐसी प्रणालियों के समर्थन और संचालन में आने वाली प्रक्रियाओं में आने वाली समस्याओं के बारे में अपनी टिप्पणियाँ साझा करूँगा।

निगरानी

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

उस स्थिति में क्या करें जब किसी ऑनलाइन स्टोर का बचा हुआ सामान ईआरपी सिस्टम से नहीं आता है? या क्या ग्राहकों के लिए छूट की गणना करने वाली सीआरएम प्रणाली ने प्रतिक्रिया देना बंद कर दिया है? ऐसा प्रतीत होता है कि साइट काम कर रही है. कंडीशनल ज़ैबिक्स को इसकी 200 प्रतिक्रिया प्राप्त होती है। ड्यूटी शिफ्ट को मॉनिटरिंग से कोई सूचना नहीं मिली है और वह गेम ऑफ थ्रोन्स के नए सीज़न का पहला एपिसोड खुशी से देख रहा है।

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

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

बाहरी प्रणालियों के साथ सहभागिता

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

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

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

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

टोंटीवाला आदमी

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

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

सहायक कर्मचारियों की योग्यता और जिम्मेदारी

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

यदि हम एक बड़े ऑनलाइन स्टोर के बारे में बात कर रहे हैं, तो प्रत्येक घंटे के डाउनटाइम की लागत एक एनीकी प्रशासक के मासिक वेतन से अधिक है। आइए शुरुआती बिंदु के रूप में वार्षिक कारोबार के 1 बिलियन रूबल को लें। रेटिंग के हिसाब से यह किसी भी ऑनलाइन स्टोर का न्यूनतम कारोबार है 100 के लिए टॉप 2018. इस राशि को प्रति वर्ष घंटों की संख्या से विभाजित करें और 100 रूबल से अधिक का शुद्ध घाटा प्राप्त करें। और यदि आप रात के घंटों की गिनती नहीं करते हैं, तो आप सुरक्षित रूप से राशि दोगुनी कर सकते हैं।

लेकिन पैसा मुख्य चीज़ नहीं है, है ना? (नहीं, बेशक मुख्य बात) प्रतिष्ठा संबंधी नुकसान भी हैं। एक प्रसिद्ध ऑनलाइन स्टोर के पतन से सामाजिक नेटवर्क पर समीक्षाओं की लहर और विषयगत मीडिया में प्रकाशन दोनों हो सकते हैं। और रसोई में दोस्तों की "वहां कुछ भी न खरीदें, उनकी वेबसाइट हमेशा डाउन रहती है" की शैली में होने वाली बातचीत को बिल्कुल भी मापा नहीं जा सकता है।

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

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

विकास टीम के साथ बातचीत

जब उपयोगकर्ताओं को ऑपरेशन के दौरान किसी उत्पाद के साथ साधारण समस्याएं आती हैं, तो समर्थन उन्हें स्वयं ही हल कर देता है। समस्या को पुन: उत्पन्न करने का प्रयास करता है, लॉग का विश्लेषण करता है, इत्यादि। लेकिन जब उत्पाद में कोई बग दिखाई दे तो क्या करें? इस मामले में, समर्थन डेवलपर्स को कार्य सौंपता है और यहीं से मज़ा शुरू होता है।

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

सामान्य या कम प्राथमिकता वाले मुद्दों को रिलीज़ से रिलीज़ की ओर ले जाया जाता है। इस प्रश्न पर कि "कार्य कब पूरा होगा?" आपको इस शैली में उत्तर प्राप्त होंगे: "क्षमा करें, अभी बहुत सारे कार्य हैं, अपनी टीम के नेतृत्वकर्ता या रिलीज़ मैनेजर से पूछें।"

नई सुविधाएँ बनाने की तुलना में उत्पादकता समस्याओं को अधिक प्राथमिकता दी जाती है। यदि उपयोगकर्ताओं को लगातार बग का सामना करना पड़ता है तो खराब समीक्षा आने में अधिक समय नहीं लगेगा। क्षतिग्रस्त प्रतिष्ठा को पुनः स्थापित करना कठिन है।

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

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

स्रोत: www.habr.com