विकासकर्ताहरू मंगल ग्रहका हुन्, प्रशासकहरू शुक्रका हुन्

संयोगहरू अनियमित छन्, र वास्तवमा यो अर्को ग्रहमा थियो ...

म ब्याकएन्ड विकासकर्ताले व्यवस्थापकहरूसँग टोलीमा कसरी काम गर्दछ भन्ने बारे तीन सफलता र असफलता कथाहरू साझा गर्न चाहन्छु।

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

+ सबै शक्ति तपाईंको हातमा छ।
+ सर्भरमा पहुँचको लागि कसैलाई बिन्ती गर्न आवश्यक छैन।
+ सबै दिशाहरूमा द्रुत प्रतिक्रिया समय।
+ सीपहरू राम्रोसँग सुधार गर्दछ।
+ उत्पादन वास्तुकलाको पूर्ण बुझाइ छ।

- उच्च जिम्मेवारी।
- उत्पादन तोड्ने जोखिम।
- सबै क्षेत्रमा राम्रो विशेषज्ञ हुन गाह्रो छ।

चासो छैन, अगाडि बढौं

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

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

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

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

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

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

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

रूपान्तरण।
यो सबै धेरै लामो समयसम्म सहेर, टोलीसँग मिलेर हामीले हाम्रो लागि अझ सफल भएको दिशामा अघि बढ्न थाल्यौं। संक्षेपमा, हामीले कस्ता समस्याहरूको सामना गर्‍यौं?

• विकासकर्ता र प्रशासन विभाग बीच गुणस्तरीय सञ्चारको अभाव
• प्रशासकहरू, यो बाहिर निस्कन्छ (!), अनुप्रयोग कसरी संरचित छ, यो के निर्भरता छ र यसले कसरी काम गर्दछ भन्ने कुरा बुझ्दैनन्।
• विकासकर्ताहरूले उत्पादन वातावरणले कसरी काम गर्छ भनेर बुझ्दैनन् र परिणाम स्वरूप, प्रभावकारी रूपमा समस्याहरूको जवाफ दिन सक्दैनन्।
• परिनियोजन प्रक्रिया धेरै लामो लाग्छ।
• अस्थिर रिलीजहरू।

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

कथा तीन
स्टार्टअप। एक प्रशासक, सानो विकास विभाग। आइपुगेपछि म पूर्ण शून्य हुँ, किनकि... मसँग मेल बाहेक कतै पहुँच छैन। हामी प्रशासकलाई लेख्छौं र पहुँचको लागि सोध्छौं। थप रूपमा, त्यहाँ जानकारी छ कि उहाँ नयाँ कर्मचारी र लगइन/पासवर्ड जारी गर्न आवश्यक बारे सचेत हुनुहुन्छ। तिनीहरू भण्डार र VPN बाट पहुँच दिन्छन्। किन wiki, teamcity, rundesk मा पहुँच दिने? सम्पूर्ण ब्याकएन्ड भाग लेख्न बोलाइएको व्यक्तिको लागि बेकार चीजहरू। समयसँगै हामीले केही उपकरणहरूमा पहुँच प्राप्त गर्छौं। आगमन, अवश्य पनि, अविश्वास संग भेटिएको थियो। म बिस्तारै कुराकानी र प्रमुख प्रश्नहरू मार्फत परियोजनाको पूर्वाधारले कसरी काम गर्छ भनेर महसुस गर्ने प्रयास गर्दैछु। मूलतः म केहि चिन्दिन। उत्पादन पहिलेको जस्तै ब्ल्याक बक्स हो। तर त्यो भन्दा बढी, परीक्षणको लागि प्रयोग हुने स्टेज सर्भरहरू पनि ब्ल्याक बक्स हुन्। हामी त्यहाँ Git बाट शाखा तैनाती बाहेक अरू केहि गर्न सक्दैनौं। हामीले हाम्रो एप्लिकेसन .env फाइलहरू जस्तै कन्फिगर गर्न सक्दैनौं। त्यस्ता कार्यहरूको लागि पहुँच प्रदान गरिएको छैन। तपाईंले परीक्षण सर्भरमा तपाईंको आवेदनको कन्फिगरेसनमा लाइन परिवर्तन गर्नको लागि बिन्ती गर्नुपर्छ। (त्यहाँ एउटा सिद्धान्त छ कि प्रशासकहरूले आफूलाई परियोजनामा ​​​​महत्वपूर्ण महसुस गर्न महत्त्वपूर्ण छ; यदि उनीहरूलाई कन्फिगरेसनहरूमा लाइनहरू परिवर्तन गर्न भनिएन भने, तिनीहरूको आवश्यकता पर्दैन)। ठीक छ, सधैं जस्तै, यो सुविधाजनक छैन? यो चाँडै बोरिंग हुन्छ, प्रशासकसँग प्रत्यक्ष कुराकानी पछि हामीले पत्ता लगायौं कि विकासकर्ताहरू खराब कोड लेख्नको लागि जन्मेका थिए, स्वभावले अयोग्य व्यक्तिहरू हुन् र तिनीहरूलाई उत्पादनबाट टाढा राख्नु राम्रो हुन्छ। तर यहाँ पनि परीक्षण सर्भरबाट, केवल मामला मा। द्वन्द्व द्रुत गतिमा बढिरहेको छ । प्रशासकसँग कुनै सम्पर्क छैन। उनी एक्लै भएकाले अवस्था बिग्रिएको छ । निम्न एक सामान्य चित्र हो। रिलीज। निश्चित कार्यक्षमताले काम गर्दैन। के भइरहेको छ भनेर पत्ता लगाउन हामीलाई लामो समय लाग्छ, विकासकर्ताहरूबाट विभिन्न विचारहरू च्याटमा फ्याँकिन्छन्, तर यस्तो अवस्थामा प्रशासकले सामान्यतया विकासकर्ताहरू दोषी छन् भनी मान्छन्। त्यसपछि उसले च्याटमा लेख्छ, पर्ख, मैले उसलाई सच्याएँ। समस्या के थियो भन्ने जानकारीको साथ पछाडि कथा छोड्न सोध्दा, हामीले विषाक्त बहानाहरू पाउँछौं। जस्तै, आफ्नो नाक जहाँ यो सम्बन्धित छैन त्यहाँ टाँस्नुहोस्। विकासकर्ताहरूले कोड लेख्नु पर्छ। एक परियोजनामा ​​धेरै शरीरको आन्दोलनहरू एउटै व्यक्तिको माध्यमबाट जान्छ र सबैलाई आवश्यक अपरेशनहरू गर्नको लागि उसको मात्र पहुँच भएको अवस्था अत्यन्तै दुखद छ। यस्तो व्यक्ति एक भयानक बाधा हो। यदि Devops विचारहरूले समय-टु-मार्केट कम गर्न कोसिस गर्छ भने, त्यस्ता व्यक्तिहरू Devops विचारहरूको सबैभन्दा खराब शत्रु हुन्। दुर्भाग्यवश, पर्दा यहाँ बन्द छ।

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

स्रोत: www.habr.com