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

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

निगरानी

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

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

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

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

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

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

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

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

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

आदमी - टोंटी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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