विकासक मंगळाचे आहेत, प्रशासक शुक्राचे आहेत

योगायोग यादृच्छिक आहेत आणि खरंच ते दुसर्या ग्रहावर होते ...

बॅकएंड डेव्हलपर प्रशासकांसह कार्यसंघामध्ये कसे कार्य करतो याबद्दल मला यश आणि अपयशाच्या तीन कथा सामायिक करायच्या आहेत.

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

+ सर्व शक्ती आपल्या हातात आहे.
+ सर्व्हरवरून प्रवेशासाठी कोणालाही भीक मागण्याची गरज नाही.
+ संपूर्ण बोर्डवर जलद प्रतिक्रिया वेळ.
+ विहीर पंप कौशल्य.
+ उत्पादन आर्किटेक्चरची संपूर्ण माहिती आहे.

- उच्च जबाबदारी.
- उत्पादन खंडित होण्याचा धोका.
- सर्व क्षेत्रांमध्ये एक चांगला तज्ञ असणे कठीण आहे.

स्वारस्य नाही, चला पुढे जाऊया.

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

• उत्पादनासाठी सरासरी उपयोजन वेळ 4-5 तास
• उत्पादनासाठी जास्तीत जास्त उपयोजन वेळ 9h
• डेव्हलपरसाठी, प्रोडक्शनमधील अॅप्लिकेशन हा प्रोडक्शन सर्व्हरप्रमाणेच ब्लॅक बॉक्स असतो. आणि सर्वसाधारणपणे त्यापैकी किती?
• खराब प्रकाशन गुणवत्ता, वारंवार त्रुटी
• विकसक प्रकाशन प्रक्रियेत गुंतलेला नाही

बरं, मी काय अपेक्षा केली होती, अर्थातच, नवोदितांना उत्पादनात परवानगी नाही. ठीक आहे, संयमाने आपण इतरांचा विश्वास संपादन करू लागतो. परंतु काही कारणास्तव, प्रशासकांसह हे इतके सोपे नाही.

कायदा 1. प्रशासक अदृश्य आहे.
प्रकाशन दिवस, विकासक आणि प्रशासक संवाद साधत नाहीत. प्रशासकाला कोणतेही प्रश्न नाहीत. पण का नंतर समजते. प्रशासक एक तत्त्वनिष्ठ व्यक्ती आहे, त्याच्याकडे त्वरित संदेशवाहक नाहीत, कोणालाही फोन नंबर देत नाहीत, सोशल नेटवर्क्समध्ये त्याचे प्रोफाइल नाही. होय, त्याचा कुठेही फोटो नाही, कसा दिसतोस यार? आम्ही या व्हॉयेजर 15 शी संपर्क प्रस्थापित करण्याचा प्रयत्न करत सुमारे 1 मिनिटे गोंधळलेल्या स्थितीत जबाबदार व्यवस्थापकासोबत बसतो, त्यानंतर कॉर्पोरेट मेलवर संदेश येतो जो त्याने पूर्ण केला आहे. आम्ही मेलद्वारे पत्रव्यवहार करणार आहोत का? का नाही? सोयीस्कर, नाही का? ठीक आहे, चला थंड होऊया. प्रक्रिया आधीच सुरू आहे, मागे वळणे नाही. आम्ही पुन्हा संदेश वाचला. "मी पूर्ण केले". आपण काय पूर्ण केले? कुठे? तुला कुठे शोधायचे? येथे तुम्हाला समजते की प्रति रिलीझ 4 तास सामान्य का आहे. आम्हाला विकासाचा धक्का बसतो, पण आम्ही रिलीझ पूर्ण करतो. आता सोडण्याची इच्छा नाही.

कायदा 2. चुकीची आवृत्ती.
पुढील प्रकाशन. अनुभव प्राप्त केल्यावर, आम्ही प्रशासकांसाठी सर्व्हरसाठी आवश्यक सॉफ्टवेअर आणि लायब्ररींच्या याद्या तयार करण्यास सुरवात करतो, काहींसाठी आवृत्त्या दर्शवितो. नेहमीप्रमाणे, आम्हाला एक कमकुवत रेडिओ सिग्नल मिळतो की प्रशासकाने तेथे काहीतरी पूर्ण केले आहे. प्रतिगमन चाचणी सुरू होते, ज्यास सुमारे एक तास लागतो. सर्व काही कार्य करत आहे असे दिसते, परंतु एक गंभीर बग आहे. महत्त्वाची कार्यक्षमता काम करत नाही. पुढील काही तास टॅम्बोरिनसह नृत्य, कॉफीच्या मैदानावर भविष्य सांगणे, कोडच्या प्रत्येक भागाचे तपशीलवार पुनरावलोकन. अॅडमिन म्हणतो की त्याने ते केले. krivorukovy विकसकांनी लिहिलेला अनुप्रयोग कार्य करत नाही आणि सर्व्हर कार्य करतो. त्याचे प्रश्न काय आहेत. काही तासाच्या शेवटी, आम्हाला प्रॉडक्शन सर्व्हरवर लायब्ररीची आवृत्ती आणि चॅटमध्ये बिंगो टाकण्यासाठी प्रशासक मिळतो - ते आम्हाला आवश्यक नाही. आम्ही प्रशासकाला आवश्यक आवृत्ती स्थापित करण्यास सांगतो, प्रतिसादात आम्हाला कळते की OS पॅकेज व्यवस्थापकामध्ये या आवृत्तीच्या अनुपस्थितीमुळे तो हे करू शकत नाही. येथे, मेमरीच्या डब्यातून, व्यवस्थापकाला आठवते की दुसर्या प्रशासकाने या समस्येचे निराकरण केले आहे, फक्त त्याच्या हातांनी इच्छित आवृत्ती गोळा करून. पण नाही, आम्ही ते करणार नाही. नियमाने मनाई केली आहे. कार्ल, आम्ही आधीच कित्येक तास बसलो आहोत, काय नियम आहेत?! आम्हाला आणखी एक धक्का बसला आहे, रिलीज कसा तरी पूर्ण होत आहे.

कायदा 3, लहान
त्वरित तिकीट, मुख्य कार्यक्षमता उत्पादनातील वापरकर्त्यांपैकी एकासाठी कार्य करत नाही. दोन तास पोक करा, तपासा. विकासाच्या वातावरणात, सर्वकाही कार्य करते. एक स्पष्ट समज आहे की php-fpm लॉगमध्ये पाहणे चांगले होईल. प्रकल्पावर त्या वेळी ELK किंवा Prometheus सारखी लॉगिंग यंत्रणा नव्हती. आम्ही प्रशासन विभागाकडे तिकीट उघडतो जेणेकरून ते सर्व्हरवरील php-fpm लॉगमध्ये प्रवेश करू शकतील. येथे तुम्हाला हे समजून घेणे आवश्यक आहे की आम्ही सहज प्रवेशासाठी विचारत नाही, तुम्हाला ब्लॅक होल आणि प्रशासकांची 24/7 व्यस्तता आठवते का? जर तुम्ही त्यांना स्वतः लॉग पाहण्यास सांगितले, तर हे "या जीवनात नाही" या प्राधान्याने कार्य आहे. तिकीट तयार केले आहे, आम्हाला प्रशासन विभागाच्या प्रमुखांकडून त्वरित प्रतिसाद मिळतो: "तुम्हाला उत्पादनातील लॉगमध्ये प्रवेश करण्याची आवश्यकता नाही, बगशिवाय लिहा." एक पडदा.

कायदा 4 आणि त्यापुढील
लायब्ररीच्या वेगवेगळ्या आवृत्त्या, कॉन्फिगर केलेले सॉफ्टवेअर, सर्व्हर लोडसाठी अपुरी तयारी आणि इतर समस्यांमुळे आम्ही उत्पादनात आणखी डझनभर समस्या गोळा करत आहोत. कोड बग, अर्थातच, देखील घडतात, आम्ही सर्व पापांसाठी प्रशासकांना दोष देणार नाही, आम्ही त्या प्रकल्पासाठी फक्त आणखी एका वैशिष्ट्यपूर्ण ऑपरेशनचा उल्लेख करू. आमच्याकडे बरेच पार्श्वभूमी कामगार होते जे पर्यवेक्षकाद्वारे लॉन्च केले गेले होते आणि काही स्क्रिप्ट क्रॉनमध्ये जोडल्या गेल्या होत्या. कधी कधी याच कामगारांनी काम बंद केले. रांगेत असलेल्या सर्व्हरवर, भार विजेच्या वेगाने वाढला आणि दु: खी वापरकर्त्यांनी कताई लोडरकडे पाहिले. द्रुत निराकरणासाठी, अशा कामगारांना रीस्टार्ट करणे पुरेसे होते, परंतु पुन्हा, केवळ प्रशासक हे करू शकतात. असे प्राथमिक ऑपरेशन केले जात असताना, संपूर्ण दिवस जाऊ शकतो. येथे, अर्थातच, हे लक्षात घेण्यासारखे आहे की कुटिल प्रोग्रामरने कामगार लिहावे जेणेकरून ते पडू नये, परंतु जेव्हा ते पडतात तेव्हा हे का समजून घेणे चांगले होईल, जे उत्पादनात प्रवेश नसल्यामुळे कधीकधी अशक्य आहे. , आणि परिणामी, विकसक लॉगची कमतरता.

परिवर्तने.
हे सर्व बराच काळ सहन करून, संघासह आम्ही आमच्यासाठी अधिक यशस्वी दिशेने वाटचाल करू लागलो. सारांश, आमच्यासमोर कोणती आव्हाने होती?

• विकासक आणि प्रशासन विभाग यांच्यातील उच्च-गुणवत्तेच्या संवादाचा अभाव
• प्रशासक, हे दिसून आले (!), अनुप्रयोग कसे कार्य करते, त्याचे काय अवलंबन आहे आणि ते कसे कार्य करते हे अजिबात समजत नाही.
• विकासकांना उत्पादन वातावरण कसे कार्य करते हे समजत नाही आणि परिणामी, समस्यांना प्रभावीपणे प्रतिसाद देऊ शकत नाही.
• उपयोजन प्रक्रियेला खूप वेळ लागतो.
• अस्थिर प्रकाशन.

आम्ही काय केले आहे?
प्रत्येक रिलीझसाठी, रिलीझ नोट्सची एक सूची तयार केली गेली होती, ज्यामध्ये कामाच्या पुढील रिलीझसाठी सर्व्हरवर आवश्यक असलेल्या कामांची सूची समाविष्ट होती. सूचीमध्ये अनेक विभाग आहेत, जे कार्य रिलीझसाठी जबाबदार प्रशासक आणि विकासकाने केले पाहिजे. विकासकांना सर्व उत्पादन सर्व्हरवर प्रवेश (रूट नाही) मिळाला, ज्याने सर्वसाधारणपणे विकासाला गती दिली आणि विशेषतः समस्या सोडवणे. तसेच, विकासकांना उत्पादन कसे कार्य करते, ते कोणत्या सेवांमध्ये विभागलेले आहे, प्रतिकृतीची किंमत कुठे आणि किती आहे हे समजून घेतले. एका भागातून, लढाऊ भार अधिक समजण्यायोग्य बनले आहेत, जे निःसंशयपणे कोडच्या गुणवत्तेवर परिणाम करतात. रिलीझ प्रक्रियेदरम्यान संप्रेषण एका मेसेंजरच्या चॅटमध्ये झाले. प्रथम, आमच्याकडे सर्व क्रियांचा एक लॉग होता आणि दुसरे म्हणजे, संप्रेषण जवळच्या वातावरणात झाले. कृतींचा एकापेक्षा जास्त वेळा इतिहास असल्याने नवीन कर्मचाऱ्यांना समस्या जलद सोडवता येतात. हा एक विरोधाभास आहे, परंतु यामुळे अनेकदा प्रशासकांनाच मदत होते. मी नक्की सांगणार नाही, पण प्रकल्प कसा चालतो, कसा लिहिला जातो हे अ‍ॅडमिन्सना अधिक समजू लागले आहे असे वाटते. कधी-कधी आम्ही एकमेकांशी काही तपशीलही शेअर केला. सरासरी प्रकाशन वेळ एक तास कमी करण्यात आला. कधीकधी आम्ही 30-40 मिनिटांत फिट होतो. डझनभर नाही तर बग्सची संख्या अनेक वेळा कमी झाली आहे. अर्थात, ऑटोटेस्ट्स सारख्या इतर घटकांनी देखील प्रकाशन वेळ कमी करण्यावर प्रभाव टाकला. प्रत्येक प्रकाशनानंतर, आम्ही पूर्वलक्ष्यी करू लागलो. जेणेकरून नवीन काय आहे, काय बदलले आहे आणि काय काढले आहे याची संपूर्ण टीमला कल्पना येईल. दुर्दैवाने, प्रशासक नेहमीच त्यांच्याकडे येत नसत, बरं, प्रशासक व्यस्त असतात... विकासक म्हणून, माझ्या कामातील समाधान निःसंशयपणे वाढले आहे. जेव्हा तुम्ही तुमच्या क्षमतेच्या क्षेत्रातील जवळपास कोणतीही समस्या त्वरीत सोडवू शकता, तेव्हा तुम्हाला घोड्यासारखे वाटते. नंतर, मला जाणवेल की आम्ही काही प्रमाणात DevOps संस्कृतीची ओळख करून दिली आहे, अर्थातच पूर्णपणे नाही, परंतु परिवर्तनाची ती सुरुवातही प्रभावी होती.

कथा तिसरी
स्टार्टअप. एक प्रशासक, लघु विकास विभाग. आगमन झाल्यावर, मी पूर्ण शून्य आहे, कारण मेल प्रवेशाशिवाय माझ्याकडे कुठेही नाही. आम्ही प्रशासकाला लिहितो, आम्ही प्रवेश देण्यास सांगतो. याव्यतिरिक्त, अशी माहिती आहे की त्याला नवीन कर्मचा-याबद्दल माहिती आहे आणि लॉगिन / पासवर्ड जारी करण्याची आवश्यकता आहे. ते रेपॉजिटरी आणि व्हीपीएन मधून प्रवेश देतात. विकी, टीमसिटी, रनडेस्कमध्ये प्रवेश का द्यावा? संपूर्ण बॅक-एंड भाग लिहिण्यासाठी बोलाविलेल्या व्यक्तीसाठी निरुपयोगी गोष्टी. केवळ कालांतराने आपल्याला काही साधनांमध्ये प्रवेश मिळतो. आगमन अर्थातच अविश्वासाने भेटले. मी चॅट्स आणि अग्रगण्य प्रश्नांद्वारे प्रकल्पाची पायाभूत सुविधा कशी कार्य करते हे हळूहळू अनुभवण्याचा प्रयत्न करत आहे. मुळात मला काही कळत नाही. उत्पादन पूर्वीसारखेच ब्लॅक बॉक्स आहे. परंतु त्याहूनही अधिक, चाचणीसाठी वापरल्या जाणार्‍या स्टेज सर्व्हरचा ब्लॅक बॉक्स देखील आहे. तेथे गिटमधून शाखा तैनात करण्याव्यतिरिक्त, आम्ही काहीही करू शकत नाही. तसेच, आम्ही आमचा ऍप्लिकेशन .env फाइल्सप्रमाणे कॉन्फिगर करू शकत नाही. अशा ऑपरेशन्ससाठी प्रवेश करण्याची परवानगी नाही. तुम्हाला भीक मागण्यात गुंतणे आवश्यक आहे जेणेकरून तुम्ही चाचणी सर्व्हरवरील तुमच्या अर्जाच्या कॉन्फिगरेशनमधील ओळ बदलू शकता. (असा एक सिद्धांत आहे की प्रशासकांना प्रकल्पात स्वतःला महत्त्वाचे वाटणे अत्यावश्यक आहे, जर त्यांना कॉन्फिगन्समधील ओळी बदलण्यास सांगितले नाही तर त्यांची गरज भासणार नाही). बरं, नेहमीप्रमाणे, ते सोयीस्कर नाही का? हे पटकन कंटाळवाणे होते, प्रशासकाशी थेट संभाषण केल्यानंतर, आम्हाला आढळले की विकसकांचा जन्म वाईट कोड लिहिण्यासाठी झाला आहे, स्वभावाने ते अक्षम व्यक्तिमत्त्व आहेत आणि त्यांना उत्पादनापासून दूर ठेवणे चांगले आहे. परंतु येथे चाचणी सर्व्हरवरून देखील, फक्त बाबतीत. संघर्ष झपाट्याने वाढत आहे. प्रशासकाशी संवाद नाही. तो एकटा असल्याने परिस्थिती चिघळली आहे. खाली एक सामान्य चित्र आहे. सोडा. विशिष्ट कार्यक्षमता कार्य करत नाही. बर्याच काळापासून काय चालले आहे ते आम्ही शोधतो, विकासकांच्या विविध कल्पना चॅटमध्ये टाकल्या जातात, परंतु अशा परिस्थितीत प्रशासक सहसा असे गृहीत धरतो की विकासक दोषी आहेत. मग तो गप्पांमध्ये लिहितो, थांबा, मी दुरुस्त केले. समस्या काय आहे याबद्दल माहितीसह एक कथा मागे ठेवण्यास सांगितले असता, आम्हाला विषारी सबबी मिळतात. आपले नाक जिथे नाही तिथे चिकटवू नका. विकसकांनी कोड लिहावा. प्रोजेक्टमध्ये शरीराच्या अनेक हालचाली एकाच व्यक्तीद्वारे होतात आणि प्रत्येकाला आवश्यक असलेल्या ऑपरेशन्स करण्यासाठी फक्त त्यालाच प्रवेश असतो ही परिस्थिती अत्यंत दुःखद आहे. अशी व्यक्ती एक भयंकर अडथळे आहे. जर Devops कल्पनांचे उद्दिष्ट टाइम-टू-मार्केट कमी करणे असेल, तर असे लोक डेव्हॉप्स कल्पनांचे सर्वात वाईट शत्रू आहेत. दुर्दैवाने, येथे पडदा बंद होत आहे.

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

स्रोत: www.habr.com