डेवलपर्स मंगल ग्रह से हैं, व्यवस्थापक शुक्र ग्रह से हैं

संयोग यादृच्छिक हैं, और वास्तव में यह किसी अन्य ग्रह पर था...

मैं सफलता और असफलता की तीन कहानियां साझा करना चाहूंगा कि एक बैकएंड डेवलपर एडमिन के साथ एक टीम में कैसे काम करता है।

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

+ सारी शक्ति आपके हाथ में है।
+ सर्वर तक पहुंच के लिए किसी से भीख मांगने की जरूरत नहीं है।
+ सभी दिशाओं में तेज़ प्रतिक्रिया समय।
+ कौशल को अच्छी तरह से सुधारता है।
+ उत्पाद वास्तुकला की पूरी समझ हो।

- उच्च जिम्मेदारी.
-उत्पादन टूटने का खतरा।
- सभी क्षेत्रों में एक अच्छा विशेषज्ञ बनना कठिन है।

कोई दिलचस्पी नहीं है, चलिए आगे बढ़ते हैं

दूसरी कहानी.
बड़ी कंपनी, बड़ा प्रोजेक्ट. 5-7 कर्मचारियों और कई विकास समूहों वाला एक प्रशासन विभाग है। जब आप ऐसी कंपनी में काम करने आते हैं तो हर एडमिन यही सोचता है कि आप यहां किसी उत्पाद पर काम करने नहीं, बल्कि कुछ तोड़ने आये हैं। न तो हस्ताक्षरित एनडीए और न ही साक्षात्कार में चयन अन्यथा इंगित करता है। नहीं, यह आदमी हमारे चुंबन उत्पादन को बर्बाद करने के लिए अपने गंदे छोटे हाथों के साथ यहां आया था। इसलिए, ऐसे व्यक्ति के साथ आपको न्यूनतम संचार की आवश्यकता होती है; कम से कम, आप प्रतिक्रिया में एक स्टिकर फेंक सकते हैं। प्रोजेक्ट आर्किटेक्चर के बारे में प्रश्नों का उत्तर न दें। यह सलाह दी जाती है कि जब तक टीम लीड न कहे, प्रवेश न दें। और जब वह मांगेगा, तो वह उन्हें मांगे गए विशेषाधिकारों से भी कम विशेषाधिकारों के साथ वापस दे देगा। ऐसे व्यवस्थापकों के साथ लगभग सभी संचार विकास विभाग और प्रशासन विभाग के बीच ब्लैक होल द्वारा अवशोषित कर लिए जाते हैं। समस्याओं का तुरंत समाधान करना असंभव है. लेकिन आप व्यक्तिगत रूप से नहीं आ सकते - व्यवस्थापक 24/7 बहुत व्यस्त हैं। (आप हर समय क्या कर रहे हैं?) कुछ प्रदर्शन विशेषताएँ:

• उत्पादन में औसत तैनाती का समय 4-5 घंटे है
• उत्पादन में अधिकतम तैनाती समय 9 घंटे
• एक डेवलपर के लिए, उत्पादन में एक एप्लिकेशन एक ब्लैक बॉक्स है, बिल्कुल उत्पादन सर्वर की तरह। कुल कितने हैं?
• रिलीज़ की निम्न गुणवत्ता, बार-बार त्रुटियाँ
• डेवलपर रिलीज़ प्रक्रिया में भाग नहीं लेता है

खैर, मुझे क्या उम्मीद थी, बेशक, नए लोगों को उत्पादन में अनुमति नहीं है। ठीक है, ठीक है, धैर्य रखने से हम दूसरों का विश्वास हासिल करना शुरू करते हैं। लेकिन किसी कारण से, व्यवस्थापकों के साथ चीज़ें इतनी सरल नहीं हैं।

अधिनियम 1. व्यवस्थापक अदृश्य है.
रिलीज का दिन, डेवलपर और व्यवस्थापक संवाद नहीं करते हैं। व्यवस्थापक के पास कोई प्रश्न नहीं है. लेकिन आप बाद में समझेंगे कि क्यों। एडमिन एक सिद्धांतवादी व्यक्ति है, उसके पास कोई संदेशवाहक नहीं है, वह किसी को अपना फ़ोन नंबर नहीं देता है, और सोशल नेटवर्क पर उसकी कोई प्रोफ़ाइल नहीं है। उसकी तो कहीं फोटो भी नहीं है, तुम क्या लग रहे हो यार? हम जिम्मेदार प्रबंधक के साथ लगभग 15 मिनट तक हतप्रभ होकर बैठे रहते हैं, इस वोयाजर 1 के साथ संचार स्थापित करने की कोशिश करते हैं, फिर कॉर्पोरेट ईमेल में एक संदेश आता है कि उसने काम पूरा कर लिया है। क्या हम मेल द्वारा पत्र-व्यवहार करने जा रहे हैं? क्यों नहीं? सुविधाजनक, है ना? अच्छा, ठीक है, चलो शांत हो जाओ। प्रक्रिया पहले से ही चल रही है, अब पीछे मुड़ना संभव नहीं है। संदेश दोबारा पढ़ें. "मैंने पूरा कर लिया"। आपने क्या ख़त्म किया? कहाँ? मुझे तुम्हें कहाँ ढूँढ़ना चाहिए? यहां आप समझेंगे कि रिलीज के लिए 4 घंटे का समय सामान्य क्यों है। हमें विकास का झटका मिलता है, लेकिन हम रिलीज़ ख़त्म कर देते हैं। अब छूटने की इच्छा नहीं रही.

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

अधिनियम 3, संक्षिप्त
अत्यावश्यक टिकट, मुख्य कार्यक्षमता उत्पादन में किसी एक उपयोगकर्ता के लिए काम नहीं करती है। हम कुछ घंटे खोजबीन और जाँच में बिताते हैं। विकास के माहौल में, सब कुछ काम करता है। एक स्पष्ट समझ है कि php-fpm लॉग्स को देखना एक अच्छा विचार होगा। उस समय प्रोजेक्ट पर ELK या प्रोमेथियस जैसे कोई लॉग सिस्टम नहीं थे। हम प्रशासन विभाग के लिए एक टिकट खोलते हैं ताकि वे सर्वर पर php-fpm लॉग तक पहुंच प्रदान कर सकें। यहां आपको यह समझने की आवश्यकता है कि हम एक कारण के लिए पहुंच मांग रहे हैं, क्या आपको ब्लैक होल और व्यवस्थापकों के 24/7 व्यस्त रहने के बारे में याद नहीं है? यदि आप उनसे स्वयं लॉग देखने के लिए कहते हैं, तो यह "इस जीवन में नहीं" प्राथमिकता वाला कार्य है। टिकट बनाया गया था, हमें प्रशासन विभाग के प्रमुख से तत्काल प्रतिक्रिया मिली: "आपको उत्पादन लॉग तक पहुंच की आवश्यकता नहीं होनी चाहिए, बग के बिना लिखें।" एक पर्दा।

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

परिवर्तन.
काफी समय तक यह सब सहने के बाद, टीम के साथ मिलकर हम उस दिशा में आगे बढ़ने लगे जो हमारे लिए अधिक सफल थी। संक्षेप में बताएं तो हमें किन समस्याओं का सामना करना पड़ा?

• डेवलपर्स और प्रशासन विभाग के बीच गुणवत्तापूर्ण संचार का अभाव
• प्रशासक, यह पता चला है (!), यह बिल्कुल नहीं समझते हैं कि एप्लिकेशन कैसे संरचित है, इसकी क्या निर्भरताएं हैं और यह कैसे काम करता है।
• डेवलपर्स यह नहीं समझते हैं कि उत्पादन वातावरण कैसे काम करता है और परिणामस्वरूप, समस्याओं का प्रभावी ढंग से जवाब नहीं दे पाते हैं।
• परिनियोजन प्रक्रिया में बहुत लंबा समय लगता है.
• अस्थिर रिलीज़.

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

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

PS लोगों के साथ चैट में डेवलपर्स बनाम एडमिन के बारे में थोड़ी बात करने के बाद, मैं ऐसे लोगों से मिला जिन्होंने मेरा दर्द साझा किया। लेकिन ऐसे लोग भी थे जिन्होंने कहा कि उन्होंने कभी इस तरह का सामना नहीं किया है। एक डेवॉप्स सम्मेलन में, मैंने एंटोन इसानिन (अल्फा बैंक) से पूछा कि वे व्यवस्थापक के रूप में बाधा की समस्या से कैसे निपटते हैं, जिस पर उन्होंने कहा: "हमने उन्हें बटनों से बदल दिया है।" वैसे одкаст उसकी भागीदारी के साथ. मैं यह विश्वास करना चाहूंगा कि दुश्मनों से कहीं अधिक अच्छे व्यवस्थापक हैं। और हाँ, शुरुआत की तस्वीर एक वास्तविक पत्राचार है।

स्रोत: www.habr.com