हाइलोड आईटी प्रणालीहरूको सञ्चालन र समर्थनको प्रक्रियाहरूमा पाँच समस्याहरू

नमस्ते, Habr! मैले दस वर्षदेखि हाइलोड आईटी प्रणालीहरूलाई समर्थन गर्दै आएको छु। म यस लेखमा 1000+ RPS मोड वा अन्य प्राविधिक चीजहरूमा काम गर्न nginx सेटअप गर्ने समस्याहरूको बारेमा लेख्ने छैन। म त्यस्ता प्रणालीहरूको समर्थन र सञ्चालनमा उत्पन्न हुने प्रक्रियाहरूमा भएका समस्याहरूको बारेमा मेरो अवलोकनहरू साझा गर्नेछु।

निगरानी गर्दै

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

अनलाईन स्टोरको बाँकी सामानहरू अब ERP प्रणालीबाट आउँदैन भने अवस्थालाई के गर्ने? वा ग्राहकहरूको लागि छुट गणना गर्ने CRM प्रणालीले प्रतिक्रिया दिन बन्द गरेको छ? साइट काम गरिरहेको देखिन्छ। सशर्त Zabbix ले यसको 200 प्रतिक्रिया प्राप्त गर्दछ। ड्युटी शिफ्टले अनुगमनबाट कुनै सूचना प्राप्त गरेको छैन र खुसीसाथ गेम अफ थ्रोन्सको नयाँ सिजनको पहिलो एपिसोड हेरिरहेको छ।

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

तसर्थ, सर्भरहरूमा अपरेटिङ सिस्टमहरूको प्राविधिक मापदण्डहरू निगरानीको अतिरिक्त, तपाईंले व्यापार मेट्रिक्स कन्फिगर गर्न आवश्यक छ। मेट्रिक्स जसले पैसालाई प्रत्यक्ष असर गर्छ। बाह्य प्रणालीहरूसँग विभिन्न अन्तरक्रियाहरू (CRM, ERP र अन्य)। समय को एक निश्चित अवधि को लागी आदेश को संख्या। सफल वा असफल ग्राहक प्राधिकरण र अन्य मेट्रिक्स।

बाह्य प्रणाली संग अन्तरक्रिया

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

केही प्रणालीहरूले आफ्ना प्रशासकहरूलाई फोन नम्बर वा टेलिग्राम प्रदान गर्छन्। कतै तपाईंले प्रबन्धकहरूलाई पत्रहरू लेख्नुपर्नेछ वा यी बाह्य प्रणालीहरूको बग ट्र्याकरहरूमा जानुहोस्। एउटै ठूला कम्पनीको सन्दर्भमा पनि, विभिन्न प्रणालीहरू प्रायः फरक अनुप्रयोग लेखा प्रणालीहरूमा सञ्चालन हुन्छन्। कहिलेकाहीँ अनुप्रयोगको स्थिति ट्र्याक गर्न असम्भव हुन्छ। तपाईंले एउटा सशर्त जिरामा अनुरोध प्राप्त गर्नुहुन्छ। त्यसपछि यो पहिलो जिराको कमेन्टमा तपाईले अर्को जिरामा मुद्दाको लिङ्क राख्नुभयो। एप्लिकेसनमा दोस्रो जिरामा कसैले कमेन्ट लेखिसकेको छ तपाईंले समस्या समाधान गर्न सशर्त प्रशासक Andrey लाई कल गर्न आवश्यक छ। र त्यसमा।

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

तपाईंले अन्तरक्रिया गर्नुहुने प्रत्येक प्रणालीले प्राथमिकताका आधारमा समस्याहरू समाधान गर्न स्पष्ट SLA सँग सेवाको रूपमा समर्थन प्रदान गर्नुपर्छ। र सशर्त प्रशासक एन्ड्रीसँग तपाईंको लागि एक मिनेट हुँदा होइन।

अड्चन मान्छे

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

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

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

ठूला परियोजनाहरूमा, कम्पनीहरूले विकासकर्ताको तलबमा कमी गर्दैनन्। तिनीहरू समान परियोजनाहरूबाट महँगो मध्यहरू वा वरिष्ठहरू खोज्दैछन्। समर्थन संग स्थिति अलि फरक छ। तिनीहरूले यी लागतहरू हर सम्भव तरिकामा कम गर्न प्रयास गरिरहेका छन्। कम्पनीहरूले सस्तो हिजोको Enikey कामदारहरू भाडामा लिए र साहसपूर्वक युद्धमा जान्छन्। यो रणनीति सम्भव छ यदि हामी Zelenograd मा एक प्लान्ट को एक व्यापार कार्ड वेबसाइट को बारे मा कुरा गर्दै हुनुहुन्छ।

यदि हामी ठूलो अनलाइन स्टोरको बारेमा कुरा गर्दैछौं भने, त्यसपछि डाउनटाइमको प्रत्येक घण्टा एनीकी प्रशासकको मासिक तलब भन्दा बढी खर्च हुन्छ। सुरुवात बिन्दुको रूपमा वार्षिक कारोबारको 1 बिलियन रूबल लिनुहोस्। यो मूल्याङ्कनबाट कुनै पनि अनलाइन स्टोरको न्यूनतम कारोबार हो 100 को लागि शीर्ष 2018। यस रकमलाई प्रति वर्ष घण्टाको संख्याले विभाजन गर्नुहोस् र 100 rubles भन्दा बढी शुद्ध घाटा प्राप्त गर्नुहोस्। र यदि तपाइँ रातको घण्टा गणना गर्नुहुन्न भने, तपाइँ सुरक्षित रूपमा रकम दोब्बर गर्न सक्नुहुन्छ।

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

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

जिम्मेवारी विकास गर्न गाह्रो कौशल हो। कि त व्यक्तिसँग छ वा छैन। त्यसकारण, अन्तर्वार्ताको क्रममा, म विभिन्न प्रश्नहरूको साथ यसको उपस्थिति पहिचान गर्ने प्रयास गर्छु जसले अप्रत्यक्ष रूपमा देखाउँछ कि व्यक्ति जिम्मेवारी लिन अभ्यस्त छ कि छैन। यदि कुनै व्यक्तिले उसको आमाबाबुले भनेको कारणले विश्वविद्यालय रोजेको हो वा श्रीमतीले पर्याप्त कमाउन नसकेकोले जागिर परिवर्तन गरेको जवाफ दिन्छ भने, त्यस्ता व्यक्तिहरूसँग नमिल्नु राम्रो हुन्छ।

विकास टोलीसँग अन्तरक्रिया

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

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

सामान्य वा कम प्राथमिकता भएका मुद्दाहरू रिलीजबाट रिलीजमा सारियो। प्रश्नमा "कार्य कहिले पूरा हुन्छ?" तपाईंले यस शैलीमा जवाफहरू प्राप्त गर्नुहुनेछ: "माफ गर्नुहोस्, त्यहाँ अहिले धेरै कार्यहरू छन्, आफ्नो टोली नेतृत्व वा रिलिज प्रबन्धकलाई सोध्नुहोस्।"

उत्पादकता समस्याहरूले नयाँ सुविधाहरू सिर्जना गर्नु भन्दा उच्च प्राथमिकता लिन्छन्। यदि प्रयोगकर्ताहरूले बगहरूमा निरन्तर ठोकर खाएमा खराब समीक्षाहरू आउन लामो हुनेछैन। क्षतिग्रस्त प्रतिष्ठा पुनर्स्थापित गर्न गाह्रो छ।

विकास र समर्थन बीचको अन्तरक्रियाका मुद्दाहरू DevOps द्वारा समाधान गरिन्छ। यो संक्षिप्त नाम प्रायः एक विशिष्ट व्यक्तिको रूपमा प्रयोग गरिन्छ जसले विकासको लागि परीक्षण वातावरण सिर्जना गर्न मद्दत गर्दछ, CICD पाइपलाइनहरू निर्माण गर्दछ र द्रुत रूपमा परीक्षण कोड उत्पादनमा ल्याउँछ। DevOps सफ्टवेयर विकासको लागि एक दृष्टिकोण हो जब प्रक्रियामा सबै सहभागीहरूले एकअर्कासँग नजिकबाट अन्तरक्रिया गर्छन् र सफ्टवेयर उत्पादनहरू र सेवाहरू द्रुत रूपमा सिर्जना र अद्यावधिक गर्न मद्दत गर्छन्। मेरो मतलब विश्लेषक, विकासकर्ता, परीक्षक र समर्थन हो।

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

स्रोत: www.habr.com