DevOps को हो र यो कहिले आवश्यक छैन?

DevOps विगत केही वर्षहरूमा एक धेरै लोकप्रिय विषय भएको छ। धेरै मानिसहरू यसमा सामेल हुने सपना देख्छन्, तर, अभ्यासले देखाउँछ, प्राय: तलबको स्तरको कारणले।

केही व्यक्तिहरूले उनीहरूको पुन: सुरुवातमा DevOps सूचीबद्ध गर्छन्, यद्यपि तिनीहरू सधैं यो शब्दको सार जान्दैनन् वा बुझ्दैनन्। केही मानिसहरू सोच्छन् कि Ansible, GitLab, Jenkins, Terraform र यस्तै (सूची तपाईंको स्वाद अनुसार जारी राख्न सकिन्छ) को अध्ययन पछि, तपाईं तुरुन्तै "devopsist" बन्नुहुनेछ। यो, निस्सन्देह, सत्य होइन।

विगत केही वर्षदेखि, म मुख्यतया विभिन्न कम्पनीहरूमा DevOps को कार्यान्वयनमा संलग्न छु। त्यसअघि उनले प्रणाली प्रशासकदेखि आईटी निर्देशकसम्मको पदमा २० वर्षभन्दा बढी समय काम गरेका थिए। हाल Playgendary मा DevOps लीड इन्जिनियर।

DevOps को हो

एउटा लेख लेख्ने विचार अर्को प्रश्न पछि आयो: "DevOps को हो?" यो के हो वा को हो भनेर अझै कुनै स्थापित शब्द छैन। केही उत्तरहरू पहिले नै यसमा छन् видео। पहिले, म यसबाट मुख्य बुँदाहरू हाइलाइट गर्नेछु, र त्यसपछि म मेरा अवलोकन र विचारहरू साझा गर्नेछु।

DevOps एक विशेषज्ञ होइन जसलाई काममा लिन सकिन्छ, उपयोगिताहरूको सेट होइन, र इन्जिनियरहरू भएका विकासकर्ताहरूको विभाग होइन।

DevOps एक दर्शन र पद्धति हो।

अर्को शब्दहरूमा, यो अभ्यासहरूको सेट हो जसले विकासकर्ताहरूलाई सक्रिय रूपमा प्रणाली प्रशासकहरूसँग अन्तरक्रिया गर्न मद्दत गर्दछ। त्यो हो, एक अर्कामा कार्य प्रक्रियाहरू जडान र एकीकृत गर्न।

DevOps को आगमन संग, संरचना र विशेषज्ञहरु को भूमिका उस्तै रह्यो (त्यहाँ विकासकर्ताहरू छन्, त्यहाँ इन्जिनियरहरू छन्), तर अन्तरक्रियाका नियमहरू परिवर्तन भएका छन्। विभागहरू बीचको सिमाना धमिलो भएको छ।

DevOps को लक्ष्यहरू तीनवटा बिन्दुहरूमा वर्णन गर्न सकिन्छ:

• सफ्टवेयर नियमित रूपमा अद्यावधिक गर्नुपर्छ।
• सफ्टवेयर छिटो गर्नुपर्छ।
• सफ्टवेयर सजिलै र छोटो समयमा तैनात हुनुपर्छ।

DevOps को लागी कुनै एकल उपकरण छैन। धेरै उत्पादनहरू कन्फिगर, डेलिभरी र अध्ययन गर्नुको मतलब यो होइन कि DevOps कम्पनीमा देखा पर्‍यो। त्यहाँ धेरै उपकरणहरू छन् र ती सबै विभिन्न चरणहरूमा प्रयोग गरिन्छ, तर एक साझा उद्देश्यको सेवा गर्दछ।

र यो DevOps उपकरणहरूको मात्र अंश हो

म 2 वर्ष भन्दा बढी समय देखि DevOps ईन्जिनियर को स्थिति को लागी मान्छे को अन्तर्वार्ता गर्दै छु, र मैले यो शब्द को सार स्पष्ट रूप देखि बुझ्न कत्ति महत्त्वपूर्ण छ भनेर महसुस गर्न आएको छु। मैले विशेष अनुभव, अवलोकन र विचारहरू जम्मा गरेको छु जुन म साझा गर्न चाहन्छु।

अन्तर्वार्ता अनुभवबाट, मैले निम्न तस्विर हेर्छु: DevOps लाई जागिरको शीर्षक मान्ने विशेषज्ञहरूसँग सामान्यतया सहकर्मीहरूसँग गलतफहमी हुन्छ.

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

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

— DevOps ले तपाईंलाई व्यक्तिगत रूपमा के अर्थ राख्छ?
- सामान्य मा वा म यसलाई कसरी बुझ्छु?

मलाई उनको व्यक्तिगत विचारमा चासो थियो। उहाँलाई शब्दको सिद्धान्त र उत्पत्ति थाहा थियो, तर उहाँ तिनीहरूसँग कडा असहमत हुनुहुन्थ्यो। उहाँ विश्वास गर्नुहुन्छ कि DevOps एक नौकरी शीर्षक थियो। उनको समस्याको जरा यहीँ छ । साथै अन्य विज्ञहरू पनि उस्तै धारणा राख्छन्।

नियोक्ताहरू, "DevOps को जादू" को बारेमा धेरै सुनेका छन्, एक व्यक्ति खोज्न चाहन्छन् जो आएर यो "जादू" सिर्जना गर्नेछ। र "DevOps एउटा जागिर हो" श्रेणीका आवेदकहरूले यो दृष्टिकोणले उनीहरूले अपेक्षाहरू पूरा गर्न सक्ने छैनन् भनेर बुझ्दैनन्। र, सामान्यतया, तिनीहरूले आफ्नो रिजुमेमा DevOps लेखे किनभने यो एक प्रवृत्ति हो र तिनीहरूले यसको लागि धेरै तिर्छन्।

DevOps पद्धति र दर्शन

विधि सैद्धान्तिक र व्यावहारिक हुन सक्छ। हाम्रो अवस्थामा, यो दोस्रो हो। मैले माथि उल्लेख गरेझैं, DevOps उल्लेख गरिएका लक्ष्यहरू प्राप्त गर्न प्रयोग गरिने अभ्यास र रणनीतिहरूको सेट हो। र प्रत्येक अवस्थामा, कम्पनीको व्यापार प्रक्रियाहरूमा निर्भर गर्दछ, यो महत्त्वपूर्ण रूपमा फरक हुन सक्छ। जसले यसलाई राम्रो वा खराब बनाउँदैन।

DevOps पद्धति लक्ष्यहरू प्राप्त गर्ने माध्यम मात्र हो।

अब DevOps दर्शन के हो भन्ने बारे। र यो सायद सबैभन्दा कठिन प्रश्न हो।

यो छोटो र संक्षिप्त जवाफ बनाउन धेरै गाह्रो छ, किनभने यो अझै औपचारिक छैन। र जबदेखि DevOps दर्शनका अनुयायीहरू अभ्यासमा बढी संलग्न छन्, त्यहाँ दर्शनको लागि कुनै समय छैन। यद्यपि, यो एक धेरै महत्त्वपूर्ण प्रक्रिया हो। यसबाहेक, यो सीधा इन्जिनियरिङ गतिविधिहरु संग सम्बन्धित छ। त्यहाँ ज्ञान को एक विशेष क्षेत्र पनि छ - प्रविधिको दर्शन.

मेरो विश्वविद्यालयमा त्यस्तो कुनै विषय थिएन, मैले ९० को दशकमा भेट्टाउन सक्ने सामग्रीहरू प्रयोग गरेर आफैंले सबै कुरा अध्ययन गर्नुपर्थ्यो। विषय ईन्जिनियरिङ् शिक्षा को लागी ऐच्छिक छ, त्यसैले उत्तर को औपचारिकता को अभाव। तर ती मानिसहरू जो गम्भीर रूपमा DevOps मा डुबेका छन् उनीहरूले कम्पनीका सबै प्रक्रियाहरूको निश्चित "आत्मा" वा "अचेतन व्यापकता" महसुस गर्न थाल्छन्।

मेरो आफ्नै अनुभव प्रयोग गरेर, मैले यस दर्शनका केही "पोस्टुलेटहरू" लाई औपचारिक बनाउने प्रयास गरें। नतिजा निम्न छ:

• DevOps केहि स्वतन्त्र छैन जुन ज्ञान वा गतिविधि को एक अलग क्षेत्र मा अलग गर्न सकिन्छ।
• कम्पनीका सबै कर्मचारीहरूले आफ्ना गतिविधिहरू योजना बनाउँदा DevOps पद्धतिद्वारा निर्देशित हुनुपर्छ।
• DevOps ले कम्पनी भित्रका सबै प्रक्रियाहरूलाई असर गर्छ।
• DevOps यसको सेवाहरूको विकास र अधिकतम ग्राहक आराम सुनिश्चित गर्न कम्पनी भित्र कुनै पनि प्रक्रियाहरूको लागि समय लागत घटाउन अवस्थित छ।
• DevOps, आधुनिक भाषामा, कम्पनीका प्रत्येक कर्मचारीको सक्रिय स्थिति हो, समय लागत घटाउने र हाम्रो वरपरका IT उत्पादनहरूको गुणस्तर सुधार गर्ने उद्देश्यले।

मलाई लाग्छ कि मेरो "पोस्टुलेटहरू" छलफलको लागि छुट्टै विषय हो। तर अब निर्माण गर्न केहि छ।

DevOps ले के गर्छ

यहाँ मुख्य शब्द संचार हो। त्यहाँ धेरै संचारहरू छन्, जसको सुरुवातकर्ता ठ्याक्कै उही DevOps इन्जिनियर हुनुपर्छ। त्यो किन हो? किनभने यो दर्शन र पद्धति हो, र त्यसपछि मात्र इन्जिनियरिङ ज्ञान।

म पश्चिमी श्रम बजारको बारेमा 100% विश्वासका साथ बोल्न सक्दिन। तर मलाई रूसको DevOps बजारको बारेमा धेरै थाहा छ। सयौं अन्तर्वार्ताहरू बाहेक, गत डेढ वर्षमा मैले ठूला रूसी कम्पनीहरू र बैंकहरूको लागि "देवओप्सको कार्यान्वयन" सेवाको लागि सयौं प्राविधिक प्रिसेलहरूमा भाग लिएको छु।

रूस मा, DevOps अझै एक धेरै जवान छ, तर पहिले नै प्रचलन विषय हो। जहाँसम्म मलाई थाहा छ, मस्कोमा मात्र 2019 मा त्यस्ता विशेषज्ञहरूको अभाव 1000 भन्दा बढी व्यक्तिहरू थिए। र नियोक्ताहरूका लागि कुबर्नेट्स शब्द लगभग साँढेको लागि रातो र्याग जस्तै हो। यस उपकरणका अनुयायीहरू यसलाई आवश्यक नभएको र आर्थिक रूपमा लाभदायक भए पनि प्रयोग गर्न तयार छन्। रोजगारदाताले कुन अवस्थामा प्रयोग गर्न बढी उपयुक्त छ भन्ने कुरा सधैं बुझ्दैनन्, र उचित परिनियोजनको साथमा, परम्परागत क्लस्टर योजना प्रयोग गरी एउटा अनुप्रयोग प्रयोग गर्नुभन्दा 2-3 गुणा बढी लागत Kubernetes क्लस्टरलाई कायम राख्नुपर्छ। तपाईलाई साँच्चै चाहिने ठाउँमा यसलाई प्रयोग गर्नुहोस्।

DevOps लागू गर्नु पैसाको हिसाबले महँगो छ। र यो केवल न्यायसंगत छ जहाँ यसले अन्य क्षेत्रमा आर्थिक लाभ ल्याउँछ, र आफ्नै मा होइन।

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

साथै, एक DevOps ईन्जिनियरले समय समयमा प्रशासनिक स्रोत प्रयोग गर्न आवश्यक छ। उदाहरण को लागी, "वातावरणीय प्रतिरोध" लाई पार गर्न - जब टोली DevOps उपकरण र पद्धति स्वीकार गर्न तयार छैन।

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

तर त्यहाँ टोलीहरू छन् जुन, यसको विपरीत, नयाँ उपकरणहरू र विधिहरू परिचय गर्न खुसी छन्, र सक्रिय रूपमा यस प्रक्रियामा भाग लिन्छन्। यद्यपि यस अवस्थामा पनि, DevOps इन्जिनियर र टोली बीचको सञ्चार रद्द गरिएको थिएन।

जब DevOps आवश्यक पर्दैन

त्यहाँ अवस्थाहरू छन् जब DevOps आवश्यक पर्दैन। यो यथार्थ हो - यसलाई बुझ्न र स्वीकार गर्न आवश्यक छ।

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

DevOps आवश्यक हुन्छ जब तपाइँको ग्राहकको सन्तुष्टि र तपाइँमा फर्कने उनको इच्छा ग्राहक संग अन्तरक्रिया को लागी यी जानकारी सेवाहरु को उपलब्धता मा निर्भर गर्दछ, तिनीहरुको गुणस्तर र लक्ष्यीकरण।

एउटा उल्लेखनीय उदाहरण एक प्रसिद्ध बैंक हो। कम्पनीसँग परम्परागत ग्राहक कार्यालयहरू छैनन्, कागजात प्रवाह मेल वा कुरियरहरू मार्फत गरिन्छ, र धेरै कर्मचारीहरू घरबाट काम गर्छन्। कम्पनी केवल एक बैंक हुन बन्द भएको छ र, मेरो विचारमा, विकसित DevOps टेक्नोलोजीहरूको साथ एक आईटी कम्पनीमा परिणत भएको छ।

धेरै अन्य उदाहरणहरू र व्याख्यानहरू विषयगत भेटघाट र सम्मेलनहरूको रेकर्डिङहरूमा फेला पार्न सकिन्छ। मैले ती मध्ये केही व्यक्तिगत रूपमा भ्रमण गरें - यो दिशामा विकास गर्न चाहनेहरूको लागि यो धेरै उपयोगी अनुभव हो। यहाँ DevOps मा राम्रो व्याख्यान र सामग्री संग YouTube च्यानल लिङ्कहरू छन्:

• DevOops
• DevOpsConf
• हाईलोड++
• फ्ल्यान्ट
• मेलरु क्लाउड समाधान

अब तपाइँको व्यवसाय हेर्नुहोस् र यस बारे सोच्नुहोस्: तपाइँको कम्पनी र यसको नाफा ग्राहक अन्तरक्रिया सक्षम गर्न आईटी उत्पादनहरूमा कति निर्भर गर्दछ?

यदि तपाइँको कम्पनीले सानो स्टोरमा माछा बेच्दछ र केवल आईटी उत्पादन दुई 1C हो: इन्टरप्राइज कन्फिगरेसनहरू (लेखा र UNF), त्यसोभए यसले DevOps को बारेमा कुरा गर्न गाह्रो हुन्छ।

यदि तपाईं ठूलो व्यापार र निर्माण उद्यममा काम गर्नुहुन्छ (उदाहरणका लागि, तपाईं शिकार राइफलहरू उत्पादन गर्नुहुन्छ), त्यसपछि तपाईंले यसको बारेमा सोच्नुपर्छ। तपाईंले पहल गर्न सक्नुहुन्छ र आफ्नो व्यवस्थापनलाई DevOps कार्यान्वयन गर्ने सम्भावनाहरू बताउन सक्नुहुन्छ। ठीक छ, र एकै समयमा, यो प्रक्रियाको नेतृत्व गर्नुहोस्। एक सक्रिय स्थिति DevOps दर्शनको महत्त्वपूर्ण सिद्धान्तहरू मध्ये एक हो।

तपाईंको कम्पनीलाई DevOps आवश्यक छ कि छैन भनेर निर्धारण गर्न वार्षिक वित्तीय कारोबारको आकार र मात्रा मुख्य मापदण्ड होइन।

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

तिनीहरूका ग्राहकहरू कार डिलरहरूको सीमित सूची हुन्। र प्रत्येकलाई निर्माताबाट एक विशेषज्ञ नियुक्त गरिएको छ। सबै आन्तरिक कागजात प्रवाह SAP ERP मार्फत हुन्छ। आन्तरिक कर्मचारीहरू अनिवार्य रूपमा सूचना प्रणालीका ग्राहक हुन्। तर यो IS क्लस्टर प्रणालीहरू व्यवस्थापन गर्ने शास्त्रीय माध्यमद्वारा नियन्त्रित छ। जसले DevOps अभ्यासहरू प्रयोग गर्ने सम्भावनालाई बहिष्कार गर्दछ।

तसर्थ निष्कर्ष: त्यस्ता उद्यमहरूको लागि, DevOps को कार्यान्वयन महत्वपूर्ण कुरा होइन, यदि हामीले लेखको सुरूबाट पद्धतिको लक्ष्यहरू सम्झन्छौं। तर म अस्वीकार गर्दिन कि उनीहरूले आज केहि DevOps उपकरणहरू प्रयोग गर्छन्।

अर्कोतर्फ, त्यहाँ धेरै साना कम्पनीहरू छन् जसले DevOps पद्धति, दर्शन, अभ्यास र उपकरणहरू प्रयोग गरेर सफ्टवेयर विकास गर्दछ। र तिनीहरू विश्वास गर्छन् कि DevOps कार्यान्वयनको लागत लागत हो जसले तिनीहरूलाई सफ्टवेयर बजारमा प्रभावकारी रूपमा प्रतिस्पर्धा गर्न अनुमति दिन्छ। यस्ता कम्पनीको उदाहरण देख्न सकिन्छ यहाँ.

DevOps आवश्यक छ कि छैन भनेर बुझ्नको लागि मुख्य मापदण्ड: कम्पनी र ग्राहकहरूको लागि तपाइँको IT उत्पादनहरूको मूल्य कस्तो छ।

यदि नाफा उत्पन्न गर्ने कम्पनीको मुख्य उत्पादन सफ्टवेयर हो भने, तपाईंलाई DevOps चाहिन्छ। र यदि तपाइँ अन्य उत्पादनहरू प्रयोग गरेर वास्तविक पैसा कमाउनुहुन्छ भने यो महत्त्वपूर्ण छैन। यसमा अनलाइन स्टोरहरू वा खेलहरू भएका मोबाइल अनुप्रयोगहरू पनि समावेश छन्।

कुनै पनि खेलहरू उपलब्ध छन् कोषका लागि धन्यवाद: खेलाडीहरूबाट प्रत्यक्ष वा अप्रत्यक्ष। Playgendary मा, हामीले नि:शुल्क मोबाइल गेमहरू विकास गर्छौं जसमा 200 भन्दा बढी मानिसहरू प्रत्यक्ष रूपमा तिनीहरूको सिर्जनामा ​​संलग्न हुन्छन्। हामी कसरी DevOps प्रयोग गर्छौं?

हो, माथि उल्लेखित जस्तै। म निरन्तर विकासकर्ताहरू र परीक्षकहरूसँग कुराकानी गर्छु, र कर्मचारीहरूका लागि DevOps पद्धति र उपकरणहरूमा आन्तरिक प्रशिक्षण सञ्चालन गर्छु।

हामी अब सक्रिय रूपमा जेनकिन्सलाई CI/CD पाइपलाइन उपकरणको रूपमा प्रयोग गर्दैछौं जुन सबै एसेम्बली पाइपलाइनहरू Unity को साथ कार्यान्वयन गर्न र एप स्टोर र प्ले मार्केटमा त्यसपछिको तैनाथीको लागि। क्लासिक टुलकिटबाट थप:

• आसन - परियोजना व्यवस्थापनको लागि। जेनकिन्ससँग एकीकरण कन्फिगर गरिएको छ।
• Google Meet - भिडियो बैठकहरूको लागि।
• स्ल्याक - संचार र विभिन्न अलर्टहरूका लागि, जेनकिन्सबाट सूचनाहरू सहित।
• एटलासियन संगम - कागजात र समूह कार्य को लागी।

हाम्रा तत्काल योजनाहरूमा SonarQube प्रयोग गरी स्थिर कोड विश्लेषण र निरन्तर एकीकरण चरणमा Selenium प्रयोग गरेर स्वचालित UI परीक्षण सञ्चालन गर्ने समावेश छ।

बरु एक निष्कर्षमा को

म निम्न विचारको साथ समाप्त गर्न चाहन्छु: एक उच्च योग्य DevOps ईन्जिनियर बन्न, मानिसहरूसँग प्रत्यक्ष कुराकानी गर्ने तरिका सिक्नु महत्त्वपूर्ण छ।

एक DevOps ईन्जिनियर एक टोली खेलाडी हो। र अरु केहि छैन। सहकर्मीहरूसँग कुराकानी गर्ने पहल उहाँबाट आउनु पर्छ, र केही परिस्थितिहरूको प्रभावमा होइन। एक DevOps विशेषज्ञले टोलीको लागि उत्तम समाधान हेर्न र प्रस्ताव गर्नुपर्छ।

र हो, कुनै पनि समाधानको कार्यान्वयनको लागि धेरै छलफल आवश्यक पर्दछ, र अन्तमा यो पूर्ण रूपमा परिवर्तन हुन सक्छ। स्वतन्त्र रूपमा विकास गर्दै, आफ्ना विचारहरू प्रस्ताव र कार्यान्वयन गर्दै, यस्तो व्यक्ति टोली र रोजगारदाता दुवैको लागि बढ्दो मूल्य हो। जुन, अन्ततः, उसको मासिक पारिश्रमिकको रकम वा अतिरिक्त बोनसको रूपमा प्रतिबिम्बित हुन्छ।

स्रोत: www.habr.com