11 महत्वपूर्ण बातें जो आपको देवो के बारे में जानना है - भाग एक

अनुवादक से

2009 में, विदेशों में एक आंदोलन शुरू हुआ जिसने खुद को DevOps कहा। पहली नज़र में, ये डेवलपर्स के कौशल के साथ सिस्टम प्रशासक और सिस्टम प्रशासक के कौशल के साथ डेवलपर्स हैं। लेकिन वास्तव में यह मामला नहीं है। इस दृष्टिकोण के स्पष्ट लक्ष्य, दर्शन, उपकरण और तरीके हैं जो केवल कुछ रूसी-भाषी कंपनियों का उपयोग करना शुरू कर रहे हैं। ऐसा लगता है कि इस दृष्टिकोण को हमारे द्वारा अनदेखा किया गया है और मैं उन 11 चीजों के बारे में बात करना चाहूंगा, जो आपको विशेष रूप से देवो के बारे में जानने की आवश्यकता है:

• DevOps क्या है
• इसके मूल्य क्या हैं
• इसे कैसे पेश किया जाता है
• वह किससे लाभान्वित होता है

मुझे आशा है कि आप इस पाठ का आनंद लेंगे।

1. DevOps क्या है और यह कहां से आया है?

शब्द "DevOps" को आमतौर पर उभरते पेशेवर आंदोलन कहा जाता है, जो डेवलपर्स और आईटी विभाग के बीच एक संयुक्त कार्य संबंध की वकालत करता है, जिसके परिणामस्वरूप योजनाबद्ध कार्य (उदाहरण के लिए, उच्च तैनाती दर) का तेजी से निष्पादन होता है, जबकि उत्पादन की विश्वसनीयता, स्थिरता, स्थिरता और सुरक्षा में वृद्धि होती है। पर्यावरण। क्यों डेवलपर्स और आईटी विभाग (बाद में संक्षिप्तता, प्रवेश के लिए)? क्योंकि, एक नियम के रूप में, मूल्य धारा व्यवसाय के बीच स्थित है (जहां आवश्यकताओं को परिभाषित किया गया है) और ग्राहक (जहां परिणाम वितरित किया जाता है)।

यह माना जाता है कि देवओप्स आंदोलन की उत्पत्ति 2009 में कई संबंधित और पारस्परिक रूप से मजबूत समुदायों के एक संघ के रूप में हुई: वेग सम्मेलन, जिसमें जॉन अल्लसॉ और पॉल हैमंड द्वारा "10 डिप्लॉय्स ए डे" का भाषण, "कोड के रूप में बुनियादी ढाँचा" (मार्क बर्गेस और ल्यूक) विशेष रूप से हड़ताली थे। कोंग्स), "एजाइल इन्फ्रास्ट्रक्चर" (एंड्रयू शैफर) और एजाइल (पैट्रिक डेबॉइस) पर सिस्टम प्रशासन, एरिक राइस का लीन स्टार्टअप अपने निरंतर एकीकरण के साथ-साथ क्लाउड और पाएस प्रौद्योगिकियों की व्यापक उपलब्धता के साथ।

DevOps Cookbook के सह-लेखकों में से एक, जॉन विलिस ने इस घटना के बारे में एक शानदार पोस्ट लिखा।

2. देवता चुस्त से कैसे अलग हैं?

एजाइल के सिद्धांतों में से एक बिग बैंग दृष्टिकोण के विपरीत, छोटे और अधिक लगातार रिलीज के साथ काम करने वाला सॉफ्टवेयर प्रदान करना है, जो झरना पद्धति में निहित है। इसलिए एजाइल प्रत्येक स्प्रिंट के अंत में एक संभावित रूप से तैयार उत्पाद का प्रयास करता है (आमतौर पर हर दो सप्ताह में एक बार)।

उच्च तैनाती दर इस तथ्य को जन्म देती है कि प्रशासक कार्यों के एक बड़े पहाड़ को संचित करते हैं। स्ट्रीमस्टेप के संस्थापक क्लाइड लोग्यू ने इसे इस तरह से पेश किया: “एजाइल ने व्यवसाय के विश्वास को बहाल करने के लिए विकसित करने में महत्वपूर्ण भूमिका निभाई, लेकिन उसने अनजाने में आईटी संचालन को पीछे छोड़ दिया। DevOps एक संपूर्ण के रूप में पूरे आईटी संगठन में विश्वास बहाल करने का एक तरीका है। ”

DevOps विशेष रूप से एजाइल के पूरक के रूप में अच्छा है, क्योंकि यह निरंतर एकीकरण और उत्पाद रिलीज की प्रक्रियाओं का विस्तार करता है और पूरक करता है, यह विश्वास दिलाता है कि कोड रिलीज़ के लिए तैयार है और ग्राहक के लिए मूल्य है।

DevOps आपको आईटी डिवीजन में बहुत अधिक निरंतर काम करने की अनुमति देता है। यदि कोड को ठेस नहीं पहुंचाई जाती है, तो उस रूप में, जिसे यह विकसित किया गया था (उदाहरण के लिए, डेवलपर्स हर दो सप्ताह में कोड वितरित करते हैं, लेकिन यह हर दो महीने में एक बार ही तैनात किया जाता है), इंस्टॉलेशन संचालन व्यवस्थापकों के सामने जमा हो जाएगा, ग्राहक अपने लिए महत्वपूर्ण कार्यक्षमता नहीं बनाएंगे। और इस मामले में स्थापना प्रक्रिया ही अराजकता और अव्यवस्था की ओर ले जाती है।

DevOps, अन्य चीजों के साथ, संस्कृति को बदल रहा है, साथ ही साथ डेवलपर्स और प्रवेश की प्रक्रियाओं और मैट्रिक्स को बदल रहा है। जॉन विलिस और डेमन एडवर्ड्स (कुकबुक देवओप्स के सह-लेखक) ने यहां इसके बारे में अधिक लिखा है ।

3. ITO और ITSM से अलग DevOps कैसे है?

हालाँकि कई लोग सोचते हैं कि DevOps ITIL (IT Infrastructure Library) और ITSM (IT Service Management) की प्रतिक्रिया है, लेकिन मेरा नज़रिया अलग है। ITIL और ITSM अभी भी IT विभाग के अंतर्गत आने वाली व्यावसायिक प्रक्रियाओं का सबसे अच्छा कोडीकरण है, क्योंकि वे वास्तव में कई चीजों का वर्णन करते हैं, जो IT टीम के लिए आवश्यक हैं ताकि वे DevOps प्रारूप में काम कर सकें।

निरंतर एकीकरण और रिलीज डेवलपर्स के काम का परिणाम है, जो बदले में प्रवेश के काम के लिए सामग्री है। DevOps में मौजूद तेजी से रिलीज लय के साथ बनाए रखने के लिए, कई आईटीआईएल प्रक्रियाओं को स्वचालन की आवश्यकता होती है, विशेष रूप से, सामान्य रूप से कॉन्फ़िगरेशन और रिलीज़ में परिवर्तन के साथ जुड़ा हुआ है।

DevOps का उद्देश्य नई कार्यक्षमता जारी करने की गति को बढ़ाना नहीं है, बल्कि इस कार्यक्षमता को उत्पादन में तैनात करना है, अराजकता के बिना और पहले से चल रहे एप्लिकेशन के विघटन के साथ-साथ जल्दी से समस्याओं का पता लगाने और उन्हें ठीक करने के लिए। यह ITIL को सेवाओं को कॉन्फ़िगर करने, घटनाओं और समस्याओं को प्रबंधित करने जैसी वस्तुओं में जोड़ता है।

4. DevOps, VisibleOps के समान कैसे है?

केविन बेहर और जॉर्ज स्पैफोर्ड के सहयोग से, मैंने 2004 में "विजिबल ऑप्स हैंडबुक" लिखी। विज़िबल ऑप्स मार्ग पर उच्च-प्रदर्शन वाले आईटी विभागों को "अच्छे से महान," में बदलने के लिए मार्गदर्शन प्रदान करता है और प्रमुख अवधारणाओं में से एक अनियोजित कार्य को सीमित करना और कम करना है।

बदले में, DevOps मुख्य रूप से विकास और प्रशासन पर नियोजित कार्यों की एक तेज और स्थिर धारा बनाने के तरीके पर ध्यान केंद्रित करता है। हालांकि, DevOps के पास अनियोजित कार्यों के व्यवस्थित उन्मूलन के लिए एक अधिक समग्र दृष्टिकोण है, जिम्मेदार प्रबंधन के सिद्धांतों को संबोधित करता है और तकनीकी ऋण को कम करता है।

5. देवो के सिद्धांत क्या हैं?

DevOps Cookbook और The Phoenix Project: A Novel About IT, DevOps और Helping Your Business Win में, हम उन अंतर्निहित सिद्धांतों का वर्णन करते हैं जिनके द्वारा थ्री वे दृष्टिकोण का उपयोग करके सभी DevOps पैटर्न प्राप्त किए जा सकते हैं। वे मूल्यों और दर्शन का वर्णन करते हैं, जो प्रक्रियाओं, प्रक्रियाओं, प्रथाओं, साथ ही अनिवार्य चरणों का आधार हैं।

फ़र्स्ट वे एक व्यक्तिगत इकाई या विभाग के प्रदर्शन के विपरीत, संपूर्ण प्रणाली के प्रदर्शन पर जोर देता है - यह या तो एक बड़ी इकाई हो सकती है (उदाहरण के लिए, विकास या आईटी विभाग) या व्यक्ति (उदाहरण के लिए, डेवलपर, सिस्टम प्रशासक)।

ध्यान आईटी में शामिल सभी मूल्य प्रवाह व्यापार प्रवाह पर है। दूसरे शब्दों में, यह तब शुरू होता है जब बुनियादी आवश्यकताओं को निर्धारित किया जाता है (उदाहरण के लिए, व्यापार या आईटी के लिए), वे विकास में समाप्त हो जाते हैं, और फिर आईटी विभाग में स्थानांतरित कर दिए जाते हैं, जिसमें सेवा के मूल्य को फिर सेवा के रूप में ग्राहक को दिया जाता है।

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

दूसरा तरीका दाईं ओर से बाईं ओर जाने वाला फीडबैक लूप बनाना है। लगभग किसी भी प्रक्रिया सुधार पहल का लक्ष्य फीडबैक को कम करना और मजबूत करना है ताकि आवश्यक संशोधनों को लगातार लागू किया जा सके।

दूसरे तरीके के परिणाम: सभी ग्राहकों की समझ और प्रतिक्रिया, दोनों आंतरिक और बाहरी, सभी प्रतिक्रिया छोरों को कम करना और मजबूत करना, और पर्यावरण के बारे में ज्ञान को गहरा करना जहां इसकी आवश्यकता है।

तीसरा तरीका एक ऐसी संस्कृति का निर्माण करना है जो दो चीजों को प्रभावित करती है: निरंतर प्रयोग, जिसमें सफलताओं और असफलताओं से जोखिम लेने और सीखने की आवश्यकता होती है, और यह समझना कि पुनरावृत्ति और अभ्यास महारत के लिए आवश्यक शर्तें हैं।

हमें इन दोनों सिद्धांतों की समान रूप से आवश्यकता है। जोखिमों को प्रयोग करना और स्वीकार करना यह सुनिश्चित करता है कि हम सुधार जारी रखें, भले ही इसका अर्थ है कि हम बहुत खतरनाक विल्ड्स में जा सकते हैं। और हमें ऐसे कौशल सीखने चाहिए जो हमें बहुत दूर जाने पर खतरे के क्षेत्र से बाहर निकलने में मदद कर सकते हैं।

थर्ड वे के परिणामों में दिन-प्रतिदिन के काम में सुधार करने के लिए समय निकालना, अनुष्ठान करना जो टीम को जोखिम लेने के लिए प्रोत्साहित करते हैं और संभवतः लंबे समय में स्थिरता बढ़ाने के लिए सिस्टम में खराबी पैदा करते हैं।

6. DevOps के कार्यान्वयन के क्षेत्र

"DevOps Cookbook" पुस्तक में, हमने DevOps को लागू करने के लिए 4 मॉडल की पहचान की है:

मॉडल 1 : वितरण में विकास प्रक्रियाओं को गहरा करना: इसमें निरंतर एकीकरण का विस्तार करना और लड़ाकू सर्वर पर रिलीज, परीक्षण और सूचना सुरक्षा का एकीकरण कार्य प्रक्रियाओं में शामिल है, जो रेडी-टू-डिलीवरी कोड, अनुकूलित वातावरण और इतने पर देता है।

मॉडल 2 : बिक्री से विकास तक की प्रतिक्रिया बनाना: इसमें समस्याओं को हल करने में मदद करने के लिए विकास और प्रशासन में घटनाओं का एक पूरा कालक्रम बनाना शामिल है, साथ ही डेवलपर्स को स्वयं सेवा सेवाओं का निर्माण करते समय, ठेस पर समस्याओं का विश्लेषण करने के लिए विकास टीम तक पहुंच प्रदान करना शामिल है, जहाँ भी यह संभव है, और सूचना रेडिएटर का निर्माण, परिवर्तन करते समय सिस्टम के व्यवहार में बदलाव को दर्शाता है।

मॉडल 3 : विकास और प्रशासन के संयोजन: समस्या-समाधान श्रृंखला में विकास टीम को शामिल करना, डेवलपर्स को ठेस की समस्याओं को हल करने के लिए डेवलपर्स की नियुक्ति करना और साथ ही साथ डेवलपर्स और प्रशासकों के बीच आपसी प्रशिक्षण में वृद्धि की संख्या को कम करना।

मॉडल 4 : विकास में एक आईटी टीम को शामिल करना: आईटी और विकास के बीच समावेश या घनिष्ठ संबंध शामिल हैं, बहु-मंच उपयोगकर्ता कहानियों का निर्माण (जिसमें उत्पादन में तैनाती, कोड प्रबंधन आदि), और सभी में उपयोग किए जा सकने वाले गैर-कार्यात्मक आवश्यकताओं का निर्धारण। परियोजनाओं।

7. देवो का मूल्य क्या है?

मेरा मानना ​​है कि तीन व्यावसायिक लाभ हैं जो संगठनों को DevOps पर स्विच करने से मिलते हैं: तेजी से बाजार में प्रवेश (जैसे, तेज चक्र समय और तेज तैनाती), बेहतर गुणवत्ता (जैसे, बढ़ी हुई उपलब्धता, कम दुर्घटनाएं, आदि) , और संगठनात्मक प्रभावशीलता में वृद्धि (उदाहरण के लिए, नुकसान की तुलना में उत्पाद का मूल्य बढ़ाने से संबंधित गतिविधियों पर अधिक समय व्यतीत किया जाता है, ग्राहक को हस्तांतरित कार्यक्षमता की मात्रा बढ़ जाती है)।

बाजार के लिए तेजी से समय

2007 में, आईटी प्रोसेस इंस्टीट्यूट में, हमने 1,500 से अधिक आईटी संगठनों का परीक्षण किया और इस निष्कर्ष पर पहुंचे कि उच्च प्रदर्शन वाले आईटी संगठन अपने कम-प्रदर्शन वाले साथियों की तुलना में अधिक उत्पादक के औसत 5-7x ऑर्डर पर थे। उन्होंने 14 गुना अधिक बदलाव किए, केवल आधे मामलों में समस्याओं को प्राप्त किया, जबकि पहली बार समस्याओं को ठीक करने की गति 4 गुना अधिक थी, और डाउनटाइम की 10 गुना कम अवधि भी थी। उनके पास रि-ऑडिट के परिणामों की तुलना में 4 गुना कम था, वे आंतरिक नियंत्रण की स्वचालित प्रणाली के कारण उल्लंघन का पता लगाने के लिए 5 गुना अधिक थे, और 8 बार परियोजना की समय सीमा को बेहतर रूप से फिट करते हैं।

उच्च प्रदर्शन करने वाली टीमों की एक विशेषता यह है कि वे भीड़ से बहुत आगे निकल जाती हैं। दूसरे शब्दों में, सबसे अच्छा बेहतर हो रहा है। यह अनुप्रयोग परिनियोजन गति में होता है। एक्सेंचर ने हाल ही में इंटरनेट कंपनियों पर क्या कर रहे हैं, इस पर एक अध्ययन किया, और अमेज़ॅन ने यह कहकर एक रिकॉर्ड बनाया है कि वे प्रति दिन 1,000 से अधिक तैनाती कर रहे हैं, 99.999% सफल परिवर्तन दर बनाए रखते हैं!

उच्च तैनाती दर को बनाए रखने की क्षमता (उदाहरण के लिए, तेजी से चक्र समय) को दो मुख्य तरीकों से व्यावसायिक मूल्य में बदल दिया जाता है: संगठन कितनी जल्दी एक विचार से किसी चीज को स्थानांतरित कर सकता है जिसे ग्राहक को हस्तांतरित किया जा सकता है और संगठन कितने प्रयोगों को एक साथ कर सकता है।

एक शक के बिना, अगर मैं एक संगठन में काम करता हूं, जहां मैं हर नौ महीने में केवल एक तैनाती कर सकता हूं, और मेरा प्रतियोगी प्रति दिन 10 स्थापना कर सकता है, मेरे पास महत्वपूर्ण, संरचनात्मक प्रतिस्पर्धी कमजोरियां हैं।

उच्च परिनियोजन दर प्रयोग को जल्दी और लगभग निरंतर करने की अनुमति देती है। स्कॉट कुक, इंटुइट के संस्थापक, संगठन के सभी स्तरों पर "प्रचंड नवाचार संस्कृति" के सबसे उत्साही समर्थकों में से एक थे। मेरे पसंदीदा उदाहरणों में से एक नीचे है :

»प्रत्येक कर्मचारी [तेज] उच्च गति के प्रयोगों का संचालन करने में सक्षम होना चाहिए ... डैन मौरर हमारे उपभोक्ता मंडल का नेतृत्व करता है, जिसमें टर्बोटेक्स वेबसाइट लॉन्च करना भी शामिल है। जब उन्होंने इस परियोजना पर काम करना शुरू किया, तो हमने एक साल में लगभग सात प्रयोग किए। एक अभिनव संस्कृति की शुरुआत के माध्यम से, वे अब कर के तीन महीनों में 165 प्रयोग कर रहे हैं। व्यवसाय का परिणाम? वेबसाइट रूपांतरण दर 50 प्रतिशत तक है। कर्मचारियों के लिए परिणाम? लोग उनसे सिर्फ इसलिए प्यार करते हैं क्योंकि अब उनके विचारों से बाजार प्रभावित हो सकता है। ”

मेरे लिए, स्कॉट कुक की कहानी का सबसे चौंकाने वाला हिस्सा यह है कि उन्होंने इन सभी प्रयोगों को टैक्स फाइलिंग सीज़न के चरम पर किया! अधिकांश संगठन पीक सीज़न के दौरान बदलाव को रोकते हैं। लेकिन अगर आप सीजन के चरम पर रूपांतरण दर और बिक्री को बढ़ा सकते हैं, जब आपका प्रतियोगी नहीं कर सकता है, तो यह एक वास्तविक प्रतिस्पर्धी लाभ है।

इसके लिए आवश्यक शर्तें में ग्राहक सेवा में रुकावट के बिना कई छोटे बदलाव जल्दी से करने में सक्षम होना शामिल है।

आईटी विभाग के घाटे को कम करें

माइक ओरजेन और मैंने एक बार आईटी स्ट्रीम में लंबे समय तक गिरावट, काम का धीमा हस्तांतरण, अनियोजित काम और परिवर्तनों के कारण बड़े नुकसान के बारे में बात की थी। माइकल क्रिग्समैन के लेख के लिए, हमने अनुमान लगाया कि देवओप्स के सिद्धांतों को लागू करके हम कितना उपयोगी काम कर सकते हैं।

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

मुझे लगता है कि यह महत्वपूर्ण है, खासकर जब मैं एक ऐसी दुनिया के बारे में सोचता हूं जिसमें मेरे तीन बच्चे रहेंगे। श्रम उत्पादकता, जीवन स्तर और समृद्धि पर संभावित आर्थिक प्रभाव पहले डालता है।

हालांकि, एक और प्रकार का नुकसान है। अधिकांश आईटी संगठनों में लोग अक्सर बाहर छोड़ दिया और निराश महसूस करते हैं। लोगों को ऐसा लगता है कि जैसे वे कभी-कभी दोहराई जाने वाली डरावनी फिल्म में फंस गए हैं और अंत को बदलने के लिए असहाय हैं। प्रबंधन आईटी के लिए अपनी जिम्मेदारी का त्याग करता है, जो अक्सर विकास, आईटी और सूचना सुरक्षा विभागों के बीच अंतहीन युद्ध की ओर जाता है। और यह केवल तब खराब होता है जब ऑडिटर यह सब प्रकट करते हैं। आईटी पेशेवरों का जीवन अक्सर निराश और निराशा से भरा होता है, जो एक नियम के रूप में, शक्तिहीनता की भावना की ओर जाता है और जीवन के हर पहलू में प्रवेश करने वाले तनावों से भर जाता है।

मनुष्य के रूप में, हम बनाने और महसूस करने का प्रयास करते हैं कि हम किसी बड़ी चीज का हिस्सा हैं। हालाँकि, सभी अक्सर, जब आईटी पेशेवर अपने संगठन से समर्थन मांगते हैं, तो वे सुनते हैं कि "आप समझे नहीं", या इससे भी बदतर, बमुश्किल गुप्त, "आप कोई नहीं हैं।"