आम्ही DevOps बद्दल समजण्यायोग्य भाषेत बोलतो

DevOps बद्दल बोलत असताना मुख्य मुद्दा समजणे कठीण आहे का? आम्ही तुमच्यासाठी ज्वलंत साधर्म्ये, लक्षवेधक फॉर्म्युलेशन आणि तज्ञांकडून सल्ले गोळा केले आहेत जे अगदी गैर-तज्ञांना देखील मुद्दे गाठण्यास मदत करतील. शेवटी, बोनस म्हणजे Red Hat कर्मचाऱ्यांचे स्वतःचे DevOps.

DevOps या शब्दाची उत्पत्ती 10 वर्षांपूर्वी झाली आहे आणि ती Twitter हॅशटॅगवरून IT जगतातील एका शक्तिशाली सांस्कृतिक चळवळीकडे गेली आहे, हे खरे तत्त्वज्ञान आहे जे विकसकांना गोष्टी जलद पूर्ण करण्यासाठी, प्रयोग करण्यासाठी आणि पुढे जाण्यासाठी प्रोत्साहित करते. DevOps डिजिटल परिवर्तनाच्या संकल्पनेशी अतूटपणे जोडलेले आहे. परंतु आयटी टर्मिनोलॉजीसह अनेकदा घडते, गेल्या दहा वर्षांत DevOps ने स्वतःबद्दल अनेक व्याख्या, व्याख्या आणि गैरसमज आत्मसात केले आहेत.

म्हणून, आपण अनेकदा DevOps बद्दल प्रश्न ऐकू शकता जसे की, ते चपळ आहे का? की ही काही खास पद्धत आहे? किंवा "सहयोग" या शब्दाचा हा दुसरा समानार्थी शब्द आहे?

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

DevOps म्हणजे काय: 6 व्याख्या आणि उपमा

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

1. DevOps ही एक सांस्कृतिक चळवळ आहे

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

2. DevOps हे विकासकांना सक्षम बनविण्याविषयी आहे.

"DevOps विकसकांना अॅप्लिकेशन्सची मालकी घेण्यास, ते चालवण्यास आणि सुरुवातीपासून शेवटपर्यंत वितरण व्यवस्थापित करण्यास सक्षम करते."

विमा कंपनी लिबर्टी म्युच्युअल मधील DevOps प्लॅटफॉर्मचे संचालक जय स्निप्प म्हणतात, “सामान्यत:, स्वयंचलित प्रक्रिया तयार करून आणि त्याची अंमलबजावणी करून उत्पादनासाठी ऍप्लिकेशन्सच्या वितरणास गती देण्याचा मार्ग म्हणून DevOps बद्दल बोलले जाते. "पण माझ्यासाठी ती खूप मूलभूत गोष्ट आहे." DevOps विकसकांना अॅप्लिकेशन्स किंवा सॉफ्टवेअरच्या विशिष्ट तुकड्यांची मालकी घेण्याचे, ते चालवण्याचे आणि त्यांचे वितरण सुरुवातीपासून शेवटपर्यंत व्यवस्थापित करण्याचे सामर्थ्य देते. DevOps जबाबदारीचे संभ्रम दूर करते आणि स्वयंचलित, विकासक-चालित पायाभूत सुविधा तयार करण्यात गुंतलेल्या प्रत्येकाला मार्गदर्शन करते.

3. DevOps हे अॅप्लिकेशन्स तयार करणे आणि वितरित करण्यात सहयोग आहे.

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

4. DevOps ही पाइपलाइन आहे

"सर्व भाग एकत्र बसल्यासच कन्व्हेयर असेंब्ली शक्य आहे."

“मी देवऑप्सची तुलना कार असेंबली लाईनशी करेन,” गुर स्टाफ पुढे सांगतो. - सर्व भाग अगोदरच डिझाईन आणि बनवण्याची कल्पना आहे जेणेकरून ते वैयक्तिक समायोजनाशिवाय एकत्र केले जाऊ शकतील. सर्व भाग एकत्र बसल्यासच कन्व्हेयर असेंब्ली शक्य आहे. जे इंजिन डिझाइन करतात आणि तयार करतात त्यांनी ते शरीरावर किंवा फ्रेमवर कसे बसवायचे याचा विचार केला पाहिजे. जे ब्रेक बनवतात त्यांनी चाकांबद्दल विचार केला पाहिजे, इत्यादी. सॉफ्टवेअरच्या बाबतीतही असेच असावे.

बिझनेस लॉजिक किंवा यूजर इंटरफेस तयार करणार्‍या डेव्हलपरने ग्राहकांची माहिती साठवणारा डेटाबेस, वापरकर्त्याच्या डेटाचे संरक्षण करण्यासाठी सुरक्षा उपाय आणि जेव्हा ही सेवा मोठ्या प्रमाणात, कदाचित लाखो-डॉलर वापरकर्ता प्रेक्षकांना सेवा देण्यास सुरुवात करते तेव्हा हे सर्व कसे कार्य करेल याचा विचार करणे आवश्यक आहे. ."

“केवळ त्यांच्या स्वतःच्या कामांवर लक्ष केंद्रित करण्याऐवजी इतर करत असलेल्या कामाच्या भागांबद्दल लोकांना सहकार्य करणे आणि विचार करणे हा सर्वात मोठा अडथळा आहे. जर तुम्ही हे करू शकत असाल, तर तुमच्याकडे डिजिटल ट्रान्सफॉर्मेशनची उत्तम संधी आहे,” गुर स्टाफ जोडतो.

5. DevOps हे लोक, प्रक्रिया आणि ऑटोमेशन यांचे योग्य संयोजन आहे

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

6. DevOps म्हणजे जेव्हा प्रोग्रामर फॉर्म्युला 1 टीमप्रमाणे काम करतात

"शर्यत सुरुवातीपासून शेवटपर्यंत नियोजित केलेली नाही, परंतु त्याउलट, समाप्तीपासून प्रारंभापर्यंत."

“जेव्हा मी DevOps उपक्रमाकडून काय अपेक्षा करावी याबद्दल बोलतो, तेव्हा मी NASCAR किंवा Formula 1 रेसिंग संघाचा एक उदाहरण म्हणून विचार करतो,” Chris Short, Red Hat येथील क्लाउड प्लॅटफॉर्म मार्केटिंगचे वरिष्ठ व्यवस्थापक आणि DevOps'ish वृत्तपत्राचे प्रकाशक म्हणतात. - अशा संघाच्या नेत्याचे एक ध्येय असते: शर्यतीच्या शेवटी, संघासाठी उपलब्ध संसाधने आणि त्याच्यासमोर येणारी आव्हाने लक्षात घेऊन सर्वोच्च स्थान मिळवणे. या प्रकरणात, शर्यत सुरुवातीपासून समाप्तीपर्यंत नाही तर त्याउलट, समाप्तीपासून प्रारंभापर्यंत नियोजित आहे. प्रथम, एक महत्त्वाकांक्षी ध्येय निश्चित केले जाते आणि नंतर ते साध्य करण्याचे मार्ग निश्चित केले जातात. मग ते सबटास्कमध्ये विभागले जातात आणि टीम सदस्यांना सोपवले जातात.

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

"हे 'योग्य गोष्ट' करण्याबद्दल नाही," शॉर्ट पुढे म्हणतात, "हे इच्छित परिणामाच्या मार्गात उभ्या असलेल्या शक्य तितक्या गोष्टी काढून टाकण्याबद्दल आहे. तुम्हाला रिअल टाइममध्ये मिळालेल्या फीडबॅकच्या आधारे सहयोग करा आणि जुळवून घ्या. विसंगतींसाठी तयार राहा आणि तुमच्या ध्येयाच्या दिशेने प्रगतीवर होणारा परिणाम कमी करण्यासाठी गुणवत्ता सुधारण्यासाठी काम करा. DevOps च्या जगात हेच आमची वाट पाहत आहे.”

DevOps कसे मोजायचे: तज्ञांकडून 10 टिपा

DevOps आणि mass DevOps या पूर्णपणे वेगळ्या गोष्टी आहेत. पहिल्यापासून दुस-या मार्गातील अडथळ्यांवर मात कशी करायची ते आम्ही तुम्हाला सांगू.

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

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

हे पाहणे सोपे आहे की परिणाम "आपण" आणि "ते" यांच्यातील विभाजनाची संस्कृती आहे.

“अनेकदा, इतर लोक त्या मार्गाचा अवलंब करण्यास सक्षम असतील किंवा इच्छुक असतील की नाही याचा विचार न करता, संस्था मुख्य प्रवाहातील DevOps साठी मार्ग मोकळा करतील असा विचार करून हे पायनियरिंग प्रकल्प सुरू करतात,” बेन ग्रिनेल स्पष्ट करतात. - अशा प्रकल्पांच्या अंमलबजावणीसाठी संघ सहसा आत्मविश्वास असलेल्या "वॅरेंजियन्स" कडून नियुक्त केले जातात ज्यांनी आधीच इतर ठिकाणी असेच काहीतरी केले आहे, परंतु ते तुमच्या संस्थेसाठी नवीन आहेत. त्याच वेळी, त्यांना इतर सर्वांसाठी बंधनकारक असलेले नियम तोडण्यासाठी आणि नष्ट करण्यासाठी प्रोत्साहित केले जाते. हे पाहणे सोपे आहे की परिणाम "आम्ही" आणि "त्यांच्या" ची संस्कृती आहे जी ज्ञान आणि कौशल्यांचे हस्तांतरण प्रतिबंधित करते.

"आणि ही सांस्कृतिक समस्या हे फक्त एक कारण आहे की DevOps मोजणे कठीण आहे. DevOps संघांना वाढत्या तांत्रिक आव्हानांना सामोरे जावे लागत आहे जे वेगाने वाढणाऱ्या IT-प्रथम कंपन्यांचे वैशिष्ट्य आहे,” स्टीव्ह न्यूमन म्हणाले, Scalyr चे संस्थापक आणि अध्यक्ष.

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

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

1. लक्षात ठेवा की संस्कृती बदलण्यासाठी वेळ लागतो.

जेन ग्रोल, कार्यकारी संचालक, DevOps संस्था: “माझ्या मते, DevOps चा विस्तार चपळ विकास (आणि तितकाच संस्कृतीला स्पर्श करणारा) म्हणून वाढीव आणि पुनरावृत्ती करणारा असावा. चपळ आणि DevOps लहान संघांवर जोर देतात. परंतु जसजसे या संघांची संख्या आणि एकत्रीकरण वाढत जाते, तसतसे आम्ही अधिक लोक काम करण्याच्या नवीन पद्धतींचा अवलंब करतो आणि परिणामी मोठ्या प्रमाणात सांस्कृतिक परिवर्तन होते.

2. नियोजन आणि व्यासपीठ निवडण्यासाठी पुरेसा वेळ घालवा

एरन किन्सब्रुनर, परफेक्टो येथे लीड टेक्निकल इव्हँजेलिस्ट: “स्केलिंग कार्य करण्यासाठी, DevOps संघांनी प्रथम पारंपारिक प्रक्रिया, साधने आणि कौशल्ये एकत्र करणे शिकले पाहिजे आणि नंतर हळूहळू DevOps च्या प्रत्येक वैयक्तिक टप्प्याचे पालनपोषण आणि स्थिरीकरण केले पाहिजे. हे सर्व वापरकर्त्याच्या कथा आणि मूल्य प्रवाहाच्या काळजीपूर्वक नियोजनाने सुरू होते, त्यानंतर ट्रंक-आधारित विकास किंवा ब्रँचिंग आणि कोड विलीन करण्यासाठी सर्वोत्तम अनुकूल इतर पद्धती वापरून सॉफ्टवेअर आणि आवृत्ती नियंत्रण लिहिणे.

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

पुढील टप्पा उत्पादनासाठी तैनात आहे आणि हे ऑर्केस्ट्रेशन साधने आणि कंटेनर वापरून पूर्णपणे स्वयंचलित असावे. DevOps (उत्पादन सिम्युलेटर, QA वातावरण आणि वास्तविक उत्पादन वातावरण) च्या सर्व टप्प्यांवर आभासी वातावरण असणे महत्त्वाचे आहे आणि संबंधित निष्कर्ष मिळविण्यासाठी नेहमी फक्त चाचण्यांसाठी नवीनतम डेटा वापरा. अॅनालिटिक्स स्मार्ट आणि जलद आणि कृती करण्यायोग्य फीडबॅकसह मोठ्या डेटावर प्रक्रिया करण्यास सक्षम असणे आवश्यक आहे.

3. जबाबदारीतून अपराधीपणा बाहेर काढा.

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

4. पुढे जाण्याचा मार्ग मोकळा करा

बेन ग्रिनेल, व्यवस्थापकीय संचालक आणि कन्सल्टन्सी नॉर्थ हायलँडचे डिजिटल प्रमुख: "प्रमाण प्राप्त करण्यासाठी, मी पायनियरिंग प्रकल्पांसह "पाथ क्लिअरिंग" प्रोग्राम सुरू करण्याची शिफारस करतो. या कार्यक्रमाचे उद्दिष्ट हे आहे की DevOps पायनियर्स मागे टाकलेला कचरा, कालबाह्य नियम आणि त्यासारख्या गोष्टी साफ करणे, जेणेकरून पुढे जाण्याचा मार्ग स्पष्ट राहील.”

“काम करण्याच्या नवीन मार्गांच्या यशाचा मोठ्या प्रमाणावर उत्सव साजरा करून अग्रगण्य गटाच्या पलीकडे जाणाऱ्या संप्रेषणाद्वारे लोकांना संघटनात्मक समर्थन आणि गती द्या. DevOps प्रकल्पांच्या पुढील लहरींमध्ये सहभागी असलेल्या आणि पहिल्यांदा DevOps वापरण्याबद्दल चिंताग्रस्त असलेल्या लोकांना प्रशिक्षण द्या. आणि लक्षात ठेवा की हे लोक पायनियरांपेक्षा खूप वेगळे आहेत.”

5. साधने लोकशाहीकरण

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

6. टीम वर्कसाठी आदर्श परिस्थिती निर्माण करा

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

7. Conway's Law आणि Kanban बोर्ड बद्दल विसरू नका

लोगन डायगल, CollabNetVersionOne येथे सॉफ्टवेअर वितरण आणि DevOps स्ट्रॅटेजीचे संचालक: “कॉनवेच्या कायद्याचे परिणाम समजून घेणे महत्त्वाचे आहे. माझ्या सैल वाक्यात, हा कायदा सांगतो की आम्ही तयार करत असलेली उत्पादने आणि आम्ही ते करण्यासाठी वापरत असलेल्या प्रक्रिया, देवऑप्ससह, आमच्या संस्थेप्रमाणेच संरचित केल्या जातात.”

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

“स्केलिंगचा आणखी एक महत्त्वाचा पैलू म्हणजे सर्व प्रगतीपथावर असलेले काम (WIP, workinprogress) Kanban बोर्डवर प्रदर्शित करणे. जेव्हा एखाद्या संस्थेकडे अशी जागा असते जिथे लोक या गोष्टी पाहू शकतात, तेव्हा ते सहकार्याला मोठ्या प्रमाणात प्रोत्साहन देते, ज्याचा स्केलिंगवर सकारात्मक प्रभाव पडतो.”

8. जुन्या चट्टे पहा

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

“एखाद्या संस्थेच्या आयटी प्रणालीमध्ये जुने डाग असतील - प्रक्रिया आणि व्यवस्थापन यंत्रणा ज्या मागील घटनांच्या परिणामी लागू केल्या गेल्या, परंतु त्यांची प्रासंगिकता गमावली (उत्पादने, तंत्रज्ञान किंवा प्रक्रियांमधील बदलांमुळे) - तर ते नक्कीच काढले जाणे आवश्यक आहे. किंवा अकार्यक्षम किंवा अनावश्यक प्रक्रिया स्वयंचलित करण्याऐवजी गुळगुळीत करा.”

9. DevOps पर्यायांची पैदास करू नका

अँथनी एडवर्ड्स, एग्प्लान्टचे संचालन संचालक: “DevOps ही अतिशय अस्पष्ट संज्ञा आहे, म्हणून प्रत्येक संघाची स्वतःची DevOps आवृत्ती संपते. आणि यापेक्षा वाईट काहीही नाही जेव्हा एखाद्या संस्थेकडे अचानक 20 प्रकारचे DevOps असतात जे एकत्र येत नाहीत. तीन डेव्हलपमेंट टीम्सपैकी प्रत्येकासाठी डेव्हलपमेंट आणि प्रोडक्ट मॅनेजमेंटमध्ये स्वतःचा, विशेष इंटरफेस असणे अशक्य आहे. किंवा उत्पादन सिम्युलेटरमध्ये हस्तांतरित केल्यावर फीडबॅक हाताळण्यासाठी उत्पादनांची स्वतःची विशिष्ट अपेक्षा असू नये. अन्यथा, तुम्ही कधीही DevOps स्केल करू शकणार नाही.”

10. DevOps च्या व्यावसायिक मूल्याचा प्रचार करा

स्टीव्ह न्यूमन, स्केलरचे संस्थापक आणि अध्यक्ष: “DevOps चे मूल्य ओळखण्यासाठी कार्य करा. शिका आणि तुम्ही जे काही करता त्याच्या फायद्यांबद्दल मोकळ्या मनाने बोला. DevOps हा एक अविश्वसनीय वेळ आणि पैसा वाचवणारा आहे (फक्त विचार करा: कमी डाउनटाइम, पुनर्प्राप्तीसाठी कमी वेळ), आणि DevOps संघांनी व्यवसायाच्या यशासाठी या उपक्रमांच्या महत्त्वावर अथकपणे जोर दिला पाहिजे (आणि प्रचार केला पाहिजे). अशा प्रकारे तुम्ही अनुयायांचे वर्तुळ वाढवू शकता आणि संस्थेतील DevOps चा प्रभाव वाढवू शकता.”

बोनस

वर रेड हॅट फोरम रशिया आमचे स्वतःचे DevOps 13 सप्टेंबर रोजी पोहोचतील - होय, Red Hat, सॉफ्टवेअर निर्माता म्हणून, त्याच्या स्वतःच्या DevOps कार्यसंघ आणि पद्धती आहेत.

आमचा अभियंता मार्क बिर्गर, जो संपूर्ण संस्थेत इतर गटांसाठी अंतर्गत ऑटोमेशन सेवा विकसित करतो, त्याची स्वतःची गोष्ट स्पष्ट रशियन भाषेत सांगेल - Red Hat DevOps टीमने हॅट व्हर्च्युअलायझेशन व्हर्च्युअल वातावरणातून अॅन्सिबलद्वारे व्यवस्थापित केलेल्या अॅप्लिकेशन्सला पूर्ण कंटेनर फॉरमॅटवर कसे स्थलांतरित केले. OpenShift प्लॅटफॉर्म.

पण एवढेच नाही:

एकदा का संस्थांनी वर्कलोड कंटेनरवर हलवले की, पारंपारिक ऍप्लिकेशन मॉनिटरिंग पद्धती कदाचित काम करणार नाहीत. दुस-या चर्चेत आम्ही लॉगिंग करण्याच्या पद्धतीत बदल करण्यामागची आमची प्रेरणा स्पष्ट करू आणि आधुनिक लॉगिंग आणि मॉनिटरिंग पद्धतींकडे नेणारा मार्ग चालू ठेवू.

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