हायलोड आयटी सिस्टमच्या ऑपरेशन आणि समर्थन प्रक्रियेतील पाच समस्या

हॅलो, हॅब्र! मी दहा वर्षांपासून हायलोड आयटी सिस्टमला समर्थन देत आहे. मी या लेखात 1000+ RPS मोड किंवा इतर तांत्रिक गोष्टींमध्ये काम करण्यासाठी nginx सेट करण्याच्या समस्यांबद्दल लिहिणार नाही. अशा प्रणालींच्या समर्थन आणि ऑपरेशनमध्ये उद्भवणार्‍या प्रक्रियांमधील समस्यांबद्दल मी माझी निरीक्षणे सामायिक करेन.

देखरेख

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

ईआरपी सिस्टीममधून ऑनलाइन स्टोअरचे उरलेले सामान यापुढे येत नाही अशा परिस्थितीत काय करावे? किंवा क्लायंटसाठी सूट मोजणाऱ्या CRM प्रणालीने प्रतिसाद देणे थांबवले आहे का? साइट कार्यरत असल्याचे दिसते. सशर्त Zabbix ला त्याचे 200 प्रतिसाद मिळतात. ड्यूटी शिफ्टला मॉनिटरिंगकडून कोणतीही सूचना प्राप्त झाली नाही आणि गेम ऑफ थ्रोन्सच्या नवीन सीझनचा पहिला भाग आनंदाने पाहत आहे.

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

म्हणून, सर्व्हरवर ऑपरेटिंग सिस्टमच्या तांत्रिक पॅरामीटर्सचे परीक्षण करण्याव्यतिरिक्त, आपल्याला व्यवसाय मेट्रिक्स कॉन्फिगर करणे आवश्यक आहे. थेट पैशांवर परिणाम करणारे मेट्रिक्स. बाह्य प्रणालींसह विविध परस्परसंवाद (CRM, ERP आणि इतर). ठराविक कालावधीसाठी ऑर्डरची संख्या. यशस्वी किंवा अयशस्वी क्लायंट अधिकृतता आणि इतर मेट्रिक्स.

बाह्य प्रणालींसह परस्परसंवाद

एक अब्ज रूबल पेक्षा जास्त वार्षिक उलाढाल असलेली कोणतीही वेबसाइट किंवा मोबाईल ऍप्लिकेशन बाह्य प्रणालींशी संवाद साधते. वर नमूद केलेल्या CRM आणि ERP पासून सुरुवात करून आणि खरेदीचे विश्लेषण करण्यासाठी आणि क्लायंटला तो निश्चितपणे खरेदी करेल असे उत्पादन ऑफर करण्यासाठी बाह्य बिग डेटा सिस्टममध्ये विक्री डेटाच्या हस्तांतरणासह समाप्त होईल (खरं तर नाही). अशा प्रत्येक प्रणालीचे स्वतःचे समर्थन आहे. आणि बर्याचदा या प्रणालींसह संप्रेषणामुळे वेदना होतात. विशेषत: जेव्हा समस्या जागतिक आहे आणि आपल्याला वेगवेगळ्या प्रणालींमध्ये त्याचे विश्लेषण करणे आवश्यक आहे.

काही प्रणाली त्यांच्या प्रशासकांसाठी फोन नंबर किंवा टेलिग्राम प्रदान करतात. कुठेतरी तुम्हाला व्यवस्थापकांना पत्र लिहावे लागेल किंवा या बाह्य प्रणालींच्या बग ट्रॅकर्सकडे जावे लागेल. जरी एका मोठ्या कंपनीच्या संदर्भात, भिन्न प्रणाली अनेकदा भिन्न ऍप्लिकेशन अकाउंटिंग सिस्टममध्ये कार्य करतात. कधीकधी अर्जाच्या स्थितीचा मागोवा घेणे अशक्य होते. तुम्हाला एका सशर्त जिरामध्ये विनंती प्राप्त होते. मग या पहिल्या जिराच्या कमेंटमध्ये तुम्ही दुसर्‍या जिरामधील अंकाची लिंक टाकली. अर्जातील दुसऱ्या जिरामध्ये, कोणीतरी आधीच एक टिप्पणी लिहित आहे की समस्येचे निराकरण करण्यासाठी तुम्हाला सशर्त प्रशासक आंद्रेला कॉल करणे आवश्यक आहे. आणि याप्रमाणे.

या समस्येचा सर्वोत्तम उपाय म्हणजे संवादासाठी एकच जागा तयार करणे, उदाहरणार्थ स्लॅकमध्ये. बाह्य प्रणाली चालविण्याच्या प्रक्रियेतील सर्व सहभागींना सामील होण्यासाठी आमंत्रित करणे. आणि एक सिंगल ट्रॅकर जेणेकरुन अनुप्रयोगांची डुप्लिकेट होऊ नये. सूचनांचे निरीक्षण करण्यापासून ते भविष्यात बग सोल्यूशन्सच्या आउटपुटपर्यंत अनुप्रयोगांचा एकाच ठिकाणी मागोवा घेतला पाहिजे. तुम्ही म्हणाल की हे अवास्तव आहे आणि ऐतिहासिकदृष्ट्या असे घडले आहे की आम्ही एका ट्रॅकरमध्ये काम करतो आणि ते दुसऱ्या ट्रॅकरमध्ये काम करतात. वेगवेगळ्या प्रणाली दिसू लागल्या, त्यांच्या स्वतःच्या स्वायत्त आयटी संघ होत्या. मी सहमत आहे, आणि म्हणून CIO किंवा उत्पादन मालक स्तरावर वरून समस्येचे निराकरण करणे आवश्यक आहे.

तुम्ही ज्या प्रत्येक प्रणालीशी संवाद साधता त्या प्रत्येक प्रणालीने प्राधान्याने समस्यांचे निराकरण करण्यासाठी स्पष्ट SLA सह सेवा म्हणून समर्थन प्रदान केले पाहिजे. आणि सशर्त प्रशासक अँड्रीकडे तुमच्यासाठी एक मिनिट असेल तेव्हा नाही.

बॉटलनेक मॅन

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

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

सपोर्ट स्टाफची क्षमता आणि जबाबदारी

मोठ्या प्रकल्पांवर, कंपन्या विकसकांच्या पगारात कसूर करत नाहीत. ते तत्सम प्रकल्पांमधून महागडे मध्यम किंवा वरिष्ठ शोधत आहेत. समर्थनासह परिस्थिती थोडी वेगळी आहे. ते प्रत्येक शक्य मार्गाने हे खर्च कमी करण्याचा प्रयत्न करत आहेत. कंपन्या स्वस्त कालच्या Enikey कामगारांना भाड्याने देतात आणि धैर्याने युद्धात उतरतात. जर आपण झेलेनोग्राडमधील प्लांटच्या व्यवसाय कार्ड वेबसाइटबद्दल बोलत असाल तर हे धोरण शक्य आहे.

जर आपण मोठ्या ऑनलाइन स्टोअरबद्दल बोलत असाल, तर डाउनटाइमच्या प्रत्येक तासाची किंमत एनकी प्रशासकाच्या मासिक पगारापेक्षा जास्त आहे. चला प्रारंभिक बिंदू म्हणून वार्षिक उलाढालीचे 1 अब्ज रूबल घेऊ. रेटिंगवरून कोणत्याही ऑनलाइन स्टोअरची ही किमान उलाढाल आहे 100 साठी टॉप 2018. ही रक्कम प्रति वर्ष तासांच्या संख्येने विभाजित करा आणि 100 रूबलपेक्षा जास्त निव्वळ तोटा मिळवा. आणि जर तुम्ही रात्रीचे तास मोजत नसाल तर तुम्ही सुरक्षितपणे रक्कम दुप्पट करू शकता.

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

आता जबाबदारीकडे. माझ्या प्रॅक्टिसमध्ये, असे एक प्रकरण होते जेव्हा कर्तव्यावरील प्रशासकाने साइटच्या अनुपलब्धतेबद्दल मॉनिटरिंग सिस्टमच्या सूचनेला वेळेत प्रतिसाद दिला नाही. शुक्रवारी संध्याकाळी आनंददायी उन्हाळ्यात, मॉस्कोमधील एका प्रसिद्ध ऑनलाइन स्टोअरची वेबसाइट शांतपणे पडली. शनिवारी सकाळी, या साइटच्या उत्पादन व्यवस्थापकास साइट का उघडली नाही हे समजले नाही आणि स्लॅकमध्ये समर्थन आणि तातडीच्या सूचना चॅटमध्ये शांतता होती. अशा चुकीमुळे आम्हाला सहा आकड्यांचा खर्च आला आणि या कर्तव्यदक्ष अधिकाऱ्याने त्याची नोकरी केली.

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

विकास कार्यसंघाशी संवाद

जेव्हा वापरकर्त्यांना ऑपरेशन दरम्यान उत्पादनामध्ये साध्या समस्या येतात तेव्हा समर्थन त्यांचे स्वतःच निराकरण करते. समस्येचे पुनरुत्पादन करण्याचा प्रयत्न करते, लॉगचे विश्लेषण करते आणि असेच. परंतु जेव्हा उत्पादनात बग दिसून येतो तेव्हा काय करावे? या प्रकरणात, समर्थन विकासकांना कार्य नियुक्त करते आणि येथूनच मजा सुरू होते.

विकासक सतत ओव्हरलोड आहेत. ते नवीन वैशिष्ट्ये तयार करत आहेत. विक्रीसह बगचे निराकरण करणे ही सर्वात मनोरंजक क्रियाकलाप नाही. पुढील स्प्रिंट पूर्ण करण्यासाठी डेडलाइन जवळ येत आहेत. आणि मग समर्थनातील अप्रिय लोक येतात आणि म्हणतात: "सर्व काही ताबडतोब सोडा, आम्हाला समस्या आहेत." अशा कामांची प्राथमिकता अत्यल्प आहे. विशेषत: जेव्हा समस्या सर्वात गंभीर नसते आणि साइटची मुख्य कार्यक्षमता कार्य करते आणि जेव्हा रिलीझ मॅनेजर फुगलेल्या डोळ्यांनी धावत नाही आणि लिहितो: "हे कार्य तातडीने पुढील रिलीज किंवा हॉटफिक्समध्ये जोडा."

सामान्य किंवा कमी प्राधान्य असलेल्या समस्या रिलीझमधून रिलीझमध्ये हलवल्या जातात. "कार्य कधी पूर्ण होईल?" या प्रश्नावर तुम्हाला या शैलीत उत्तरे मिळतील: "माफ करा, सध्या बरीच कामे आहेत, तुमच्या टीम लीड्सला विचारा किंवा व्यवस्थापकाला रिलीझ करा."

नवीन वैशिष्ट्ये तयार करण्यापेक्षा उत्पादकता समस्यांना जास्त प्राधान्य दिले जाते. जर वापरकर्ते सतत बग्सवर अडखळत असतील तर वाईट पुनरावलोकने येण्यास जास्त वेळ लागणार नाही. खराब झालेली प्रतिष्ठा पुनर्संचयित करणे कठीण आहे.

विकास आणि समर्थन यांच्यातील परस्परसंवादाच्या समस्या DevOps द्वारे सोडवल्या जातात. हे संक्षेप अनेकदा एखाद्या विशिष्ट व्यक्तीच्या स्वरूपात वापरले जाते जे विकासासाठी चाचणी वातावरण तयार करण्यात मदत करते, CICD पाइपलाइन तयार करते आणि त्वरीत चाचणी कोड उत्पादनात आणते. DevOps हा सॉफ्टवेअर डेव्हलपमेंटचा एक दृष्टीकोन आहे जेव्हा प्रक्रियेतील सर्व सहभागी एकमेकांशी जवळून संवाद साधतात आणि सॉफ्टवेअर उत्पादने आणि सेवा द्रुतपणे तयार आणि अद्यतनित करण्यात मदत करतात. मला म्हणजे विश्लेषक, विकसक, परीक्षक आणि समर्थन.

या दृष्टिकोनामध्ये, समर्थन आणि विकास हे त्यांचे स्वतःचे ध्येय आणि उद्दिष्टे असलेले भिन्न विभाग नाहीत. विकास ऑपरेशनमध्ये गुंतलेला आहे आणि उलट. वितरीत संघांचे प्रसिद्ध वाक्यांश: "समस्या माझ्या बाजूने नाही" यापुढे चॅटमध्ये वारंवार दिसत नाही आणि अंतिम वापरकर्ते थोडे आनंदी होतात.

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