डेवऑप्स क्या है?

DevOps की परिभाषा बहुत जटिल है, इसलिए हमें हर बार इसके बारे में फिर से चर्चा शुरू करनी पड़ती है। अकेले हेब्रे पर इस विषय पर एक हजार प्रकाशन हैं। लेकिन अगर आप इसे पढ़ रहे हैं, तो आप शायद जानते होंगे कि DevOps क्या है। क्योंकि मैं नहीं। हैलो मेरा नाम है अलेक्जेंडर टिटोव (@ऑस्मिनोग), और हम सिर्फ DevOps के बारे में बात करेंगे और मैं अपना अनुभव साझा करूंगा।

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

एक समय मैं विलय और अधिग्रहण की लहरों पर सवार था। सबसे पहले मैंने Qik नामक एक छोटे स्टार्टअप के लिए काम किया, फिर इसे Skype नामक थोड़ी बड़ी कंपनी ने खरीद लिया, जिसे बाद में Microsoft नामक थोड़ी बड़ी कंपनी ने खरीद लिया। उस क्षण, मैंने देखना शुरू किया कि विभिन्न आकार की कंपनियों में DevOps का विचार कैसे बदल रहा है। उसके बाद, मुझे DevOps को बाज़ार के दृष्टिकोण से देखने में दिलचस्पी हो गई, और मैंने और मेरे सहयोगियों ने Express 42 कंपनी की स्थापना की। अब 6 वर्षों से हम बाज़ार की लहरों के साथ आगे बढ़ रहे हैं।

अन्य बातों के अलावा, मैं DevOps मास्को समुदाय के आयोजकों में से एक हूं और DevOps-Days 2017 का आयोजक हूं, लेकिन मैंने 2018 का आयोजन नहीं किया। एक्सप्रेस 42 कई कंपनियों के साथ काम करता है। हम वहां DevOps विकसित करते हैं, देखते हैं कि यह कैसे होता है, निष्कर्ष निकालते हैं, विश्लेषण करते हैं, सभी को अपने निष्कर्ष बताते हैं और लोगों को DevOps प्रथाओं में प्रशिक्षित करते हैं। सामान्य तौर पर, हम इस संबंध में अपना अनुभव और विशेषज्ञता बढ़ाने की पूरी कोशिश कर रहे हैं।

DevOps क्यों

पहला प्रश्न जो हर किसी को हमेशा सताता रहता है वह है - क्यों? बहुत से लोग सोचते हैं कि DevOps केवल स्वचालन है या ऐसी ही एक चीज़ है जो हर कंपनी के पास पहले से मौजूद है।

— हमारे पास सतत एकीकरण था - इसका मतलब है कि हमारे पास पहले से ही DevOps थे, और इन सभी चीजों की आवश्यकता क्यों है? वे विदेश में मौज-मस्ती कर रहे हैं, लेकिन वे हमें काम करने से रोक रहे हैं!

समुदाय और कार्यप्रणाली के विकास के 9 वर्षों में, यह पहले ही स्पष्ट हो गया है कि यह अभी भी विपणन चमक नहीं है, लेकिन यह अभी भी पूरी तरह से स्पष्ट नहीं है कि इसकी आवश्यकता क्यों है। किसी भी उपकरण और प्रक्रिया की तरह, DevOps के विशिष्ट लक्ष्य होते हैं जिन्हें वह अंततः प्राप्त करता है।

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

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

स्वचालन अक्सर नहीं बदलता है, क्योंकि जब कोई कंपनी बुरी तरह से गर्त में चली जाती है, तो बदलने के लिए क्या बचा है? यह काम करता है - इसे मत छुओ। अब दुनिया में दृष्टिकोण बदल रहे हैं, और जिसे एजाइल कहा जाता है वह सुझाव देता है कि अंतिम बिंदु बी तुरंत दिखाई नहीं देता है।

जब कोई कंपनी बाजार में जाती है, ग्राहक के साथ काम करती है, तो वह लगातार बाजार का पता लगाती है और अंतिम बिंदु बी बदलती है। इसके अलावा, कंपनी जितनी बार अपनी दिशा बदलती है, अंत में वह उतनी ही अधिक सफल होती है, क्योंकि वह अधिक बाजार चुनती है निचे.

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

इस उत्पाद को यूनिलीवर ने 1 बिलियन डॉलर में खरीदा था। अब यह जिलेट के साथ प्रतिस्पर्धा करता है और इसने अमेरिकी बाजार में उपभोक्ताओं का एक महत्वपूर्ण हिस्सा छीन लिया है। वन बॉक्स शेव कहते हैं:

- 4 ब्लेड? आप गंभीरता से कर रहे हैं? आपको इसकी आवश्यकता क्यों है - इससे शेव की गुणवत्ता में सुधार नहीं होता है। एक विशेष रूप से चयनित क्रीम, सुगंध और दो ब्लेड वाला एक उच्च गुणवत्ता वाला रेजर उन बेवकूफ 4 जिलेट ब्लेड की तुलना में कहीं अधिक समस्याओं का समाधान करता है! क्या हम जल्द ही 10 तक पहुँच जायेंगे?

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

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

टाइम-टू-मार्केट विचार से अंतिम कार्यान्वयन तक के समय को कम करने के बारे में है।

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

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

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

1968 में, एक दूरदर्शी व्यक्ति मेल्विन कॉनवे ने निम्नलिखित विचार तैयार किया।

जो संगठन सिस्टम बनाता है वह एक ऐसे डिज़ाइन द्वारा बाध्य होता है जो उस संगठन की संचार संरचना को दोहराता है।

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

आदर कॉनवे के नियम के बारे में एक कर सकते हैं लिंक के माध्यम से. DevOps संस्कृति या दर्शन को समझने के लिए यह महत्वपूर्ण है क्योंकि एकमात्र चीज जो DevOps में मौलिक रूप से बदलती है वह है टीमों के बीच संचार की संरचना.

प्रक्रिया के दृष्टिकोण से, DevOps से पहले, सभी चरण: विश्लेषण, विकास, परीक्षण, संचालन, रैखिक थे।
DevOps के मामले में, ये सभी प्रक्रियाएँ एक साथ होती हैं।

समय-समय पर बाज़ार जाना ही ऐसा करने का एकमात्र तरीका है। पुरानी प्रक्रिया में काम करने वाले लोगों के लिए, यह कुछ हद तक लौकिक और आम तौर पर ऐसा ही लगता है।

तो आपको DevOps की आवश्यकता क्यों है?

डिजिटल उत्पाद विकास के लिए. यदि आपकी कंपनी के पास कोई डिजिटल उत्पाद नहीं है, तो DevOps की आवश्यकता नहीं है - यह बहुत महत्वपूर्ण है।

DevOps अनुक्रमिक सॉफ़्टवेयर उत्पादन की गति सीमाओं को पार कर जाता है. इसमें सभी प्रक्रियाएँ एक साथ होती हैं।

कठिनाई बढ़ जाती है. जब DevOps प्रचारक आपसे कहते हैं कि इससे आपके लिए सॉफ़्टवेयर जारी करना आसान हो जाएगा, तो यह बकवास है।

DevOps के साथ, चीजें और अधिक जटिल हो जाएंगी।

एविटो स्टैंड पर सम्मेलन में, आप देख सकते थे कि डॉकर कंटेनर को तैनात करना कैसा था - एक अवास्तविक कार्य। जटिलता निषेधात्मक हो जाती है; आपको एक ही समय में कई गेंदों का सामना करना पड़ता है।

DevOps कंपनी में प्रक्रिया और संगठन को पूरी तरह से बदल देता है - अधिक सटीक रूप से, यह DevOps नहीं है जो बदलता है, बल्कि डिजिटल उत्पाद है। DevOps में आने के लिए, आपको अभी भी इस प्रक्रिया को पूरी तरह से बदलना होगा।

किसी विशेषज्ञ के लिए प्रश्न

तुम्हारे पास क्या है? वे प्रश्न जो आप किसी कंपनी में काम करते समय और एक विशेषज्ञ के रूप में विकसित होते समय स्वयं से पूछ सकते हैं।

क्या आपके पास डिजिटल उत्पाद बनाने की कोई रणनीति है? अगर वहाँ है, तो वह पहले से ही अच्छा है। इसका मतलब है कि आपकी कंपनी DevOps की ओर बढ़ रही है।

क्या आपकी कंपनी पहले से ही एक डिजिटल उत्पाद बना रही है? इसका मतलब यह है कि आप एक और स्तर ऊपर उठ सकते हैं और चीजों को अधिक दिलचस्प तरीके से कर सकते हैं - फिर से DevOps के दृष्टिकोण से। मैं केवल इसी दृष्टिकोण से बात कर रहा हूं।

क्या आपकी कंपनी डिजिटल उत्पाद क्षेत्र में बाज़ार के अग्रणी नेताओं में से एक है? Spotify, Yandex, Uber ऐसी कंपनियाँ हैं जो अब तकनीकी प्रगति के चरम पर हैं।

अपने आप से ये प्रश्न पूछें, और यदि सभी उत्तर नहीं हैं, तो शायद आपको इस कंपनी में DevOps नहीं करना चाहिए। यदि DevOps का विषय वास्तव में आपके लिए दिलचस्प है, तो शायद... आपको किसी अन्य कंपनी में चले जाना चाहिए? यदि आपकी कंपनी DevOps में जाना चाहती है, लेकिन आपने सभी प्रश्नों का उत्तर "नहीं" दिया है, तो यह उस खूबसूरत गैंडे की तरह है जो कभी नहीं बदलेगा।

संगठन

जैसा कि मैंने कहा, कॉनवे के नियम के अनुसार, किसी कंपनी का संगठन बदल जाता है। मैं उस चीज़ से शुरुआत करूँगा जो संगठनात्मक दृष्टिकोण से DevOps को कंपनी के अंदर प्रवेश करने से रोकती है।

"कुओं" की समस्या

अंग्रेजी शब्द "साइलो" का यहां रूसी में अनुवाद "वेल" के रूप में किया गया है। इस समस्या का सार यही है टीमों के बीच सूचनाओं का कोई आदान-प्रदान नहीं होता है. प्रत्येक टीम नेविगेट करने के लिए एक सामान्य मानचित्र बनाए बिना, अपनी विशेषज्ञता में गहराई से उतरती है।

कुछ मायनों में यह मुझे एक ऐसे व्यक्ति की याद दिलाता है जो अभी-अभी मास्को आया है और अभी तक नहीं जानता कि मेट्रो मानचित्र को कैसे नेविगेट किया जाए। मस्कोवाइट्स आमतौर पर अपने क्षेत्र को अच्छी तरह से जानते हैं, और पूरे मॉस्को में वे मेट्रो मानचित्र का उपयोग करके नेविगेट कर सकते हैं। जब आप पहली बार मास्को आते हैं, तो आपके पास यह कौशल नहीं होता है, और आप बस भ्रमित हो जाते हैं।

DevOps का सुझाव है कि भटकाव के इस क्षण से उबरें और सभी विभाग मिलकर एक साझा इंटरेक्शन मानचित्र बनाएं।

दो कारक इसमें बाधक हैं।

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

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

- हम सिर्फ सीआई लॉन्च करना चाहते थे, लेकिन पता चला कि प्रबंधन को इसकी ज़रूरत नहीं थी।

ऐसा ठीक इसलिए होता है क्योंकि CI и सतत वितरण प्रक्रिया कई परीक्षाओं की सीमा पर हैं. संगठनात्मक स्तर पर "कुओं" की समस्या पर काबू पाए बिना, आप आगे नहीं बढ़ पाएंगे, चाहे आप कुछ भी करें और चाहे वह कितना भी दुखद क्यों न हो।

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

लोग कुछ सितारों या झंडों के लिए लड़ रहे हैं, हर कोई अपनी विशेषज्ञता तलाश रहा है।

परिणामस्वरूप, जब इन सबको एक साथ जोड़ने और एक सामान्य पाइपलाइन बनाने का कार्य उठता है, और सितारों और झंडों के लिए लड़ने की कोई आवश्यकता नहीं रह जाती है, तो सवाल उठता है - वैसे भी क्या किया जाए? हमें किसी तरह एक समझौते पर पहुंचने की जरूरत है, लेकिन स्कूल में किसी ने हमें यह नहीं सिखाया कि यह कैसे करना है। हमें स्कूल से ही सिखाया गया है: आठवीं कक्षा - वाह! - सातवीं कक्षा की तुलना में! यहाँ भी वैसा ही है.

क्या आपकी कंपनी में भी ऐसा ही है?

इसे जाँचने के लिए आप स्वयं से निम्नलिखित प्रश्न पूछ सकते हैं।

क्या टीमें सामान्य उपकरणों का उपयोग करती हैं और उन सामान्य उपकरणों में बदलाव में योगदान देती हैं?

टीमें कितनी बार पुनर्गठित होती हैं—एक टीम के कुछ विशेषज्ञ दूसरी टीम में चले जाते हैं? DevOps परिवेश में यह सामान्य हो जाता है, क्योंकि कभी-कभी कोई व्यक्ति यह नहीं समझ पाता कि विशेषज्ञता का दूसरा क्षेत्र क्या कर रहा है। वह दूसरे विभाग में चला जाता है, इस विभाग के साथ अपने लिए अभिविन्यास और बातचीत का एक नक्शा बनाने के लिए दो सप्ताह तक वहां काम करता है।

क्या परिवर्तन समिति बनाना और चीज़ों को बदलना संभव है? या क्या इसके लिए सर्वोच्च प्रबंधन और निर्देशन के मजबूत हाथ की आवश्यकता है? मैंने हाल ही में फेसबुक पर लिखा था कि कैसे एक अल्पज्ञात बैंक ऑर्डर के माध्यम से उपकरण लागू कर रहा है: हम एक ऑर्डर लिखते हैं, हम इसे एक साल के लिए लागू करते हैं, और देखते हैं कि क्या होता है। निस्संदेह, यह लंबा और दुखद है।

प्रबंधकों के लिए कंपनी की उपलब्धियों पर विचार किए बिना व्यक्तिगत उपलब्धियाँ प्राप्त करना कितना महत्वपूर्ण है?

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

कोड के रूप में बुनियादी ढांचा

इस समस्या से गुज़रने के बाद, पहला महत्वपूर्ण अभ्यास है, जिसके बिना DevOps में आगे बढ़ना मुश्किल है कोड के रूप में बुनियादी ढांचा.

अक्सर, बुनियादी ढांचे को कोड के रूप में इस प्रकार माना जाता है:

- आइए बैश में सब कुछ स्वचालित करें, खुद को स्क्रिप्ट के साथ कवर करें ताकि व्यवस्थापकों को कम मैन्युअल काम करना पड़े!

लेकिन यह सच नहीं है.

कोड के रूप में इन्फ्रास्ट्रक्चर का मतलब है कि आप जिस आईटी सिस्टम के साथ काम करते हैं, उसकी स्थिति को लगातार समझने के लिए कोड के रूप में उसका वर्णन करें।

अन्य टीमों के साथ मिलकर, आप कोड के रूप में एक नक्शा बनाते हैं जिसे हर कोई समझ सकता है और नेविगेट और नेविगेट कर सकता है। इससे कोई फर्क नहीं पड़ता कि यह क्या किया गया है - शेफ, एन्सिबल, साल्ट, या कुबेरनेट्स में YAML फ़ाइलों का उपयोग करना - इसमें कोई अंतर नहीं है।

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

सहमत हूँ, व्यक्तिगत बैश स्क्रिप्ट आमतौर पर यह समझ प्रदान नहीं करती है। जिन कंपनियों में मैंने काम किया उनमें से एक में "केवल लिखें" स्क्रिप्ट का नाम भी था - जब स्क्रिप्ट लिखी जाती है, लेकिन इसे पढ़ना अब संभव नहीं है। मुझे लगता है यह बात आपसे भी परिचित है.

कोड के रूप में इन्फ्रास्ट्रक्चर है कोड जो बुनियादी ढांचे की वर्तमान स्थिति का वर्णन करता है. कई उत्पाद, बुनियादी ढांचे और सेवा दल इस कोड पर एक साथ काम करते हैं, और सबसे महत्वपूर्ण बात यह है कि उन सभी को यह समझने की आवश्यकता है कि यह कोड वास्तव में कैसे काम करता है।

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

कोड सभी इंजीनियरों के लिए एक सामान्य भाषा बन जाता है।

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

यह महत्वपूर्ण है: यदि आपने अभी तक यह चीज़ आज़माई नहीं है, तो याद रखें Ansible बैश नहीं है! दस्तावेज़ीकरण को ध्यान से पढ़ें, अध्ययन करें कि वे इसके बारे में क्या लिखते हैं।

कोड के रूप में इन्फ्रास्ट्रक्चर इन्फ्रास्ट्रक्चर कोड को अलग-अलग परतों में अलग करना है।

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


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

सेवा स्तर - ये वे सेवाएँ हैं जो आप डेवलपर को प्रदान करते हैं: एक सेवा के रूप में लॉगिंग, एक सेवा के रूप में निगरानी, ​​एक सेवा के रूप में डेटाबेस, एक सेवा के रूप में बैलेंसर, एक सेवा के रूप में कतार, एक सेवा के रूप में सतत वितरण - सेवाओं का एक समूह जो व्यक्तिगत टीमें विकास को प्रदान कर सकता है। यह सब आपके कॉन्फ़िगरेशन प्रबंधन सिस्टम में अलग-अलग मॉड्यूल में वर्णित किया जाना चाहिए।

वह परत जहां अनुप्रयोग बनाए जाते हैं और वर्णन करता है कि वे पिछली दो परतों के ऊपर कैसे प्रकट होंगे।

नियंत्रण प्रश्न

क्या आपकी कंपनी के पास साझा बुनियादी ढांचा भंडार है? क्या आप अपने बुनियादी ढांचे में तकनीकी ऋण का प्रबंधन कर रहे हैं? क्या आप बुनियादी ढांचे के भंडार में विकास प्रथाओं का उपयोग करते हैं? क्या आपका बुनियादी ढांचा परतों में बंटा हुआ है? आप बेस-सर्विस-एपीपी आरेख की जांच कर सकते हैं। बदलाव लाना कितना कठिन है?

यदि आपने अनुभव किया है कि परिवर्तन करने में डेढ़ दिन लग गए, तो इसका मतलब है कि आप पर तकनीकी ऋण है और आपको इसके साथ काम करने की आवश्यकता है। आपको अभी-अभी अपने इंफ्रास्ट्रक्चर कोड में तकनीकी ऋण रेक का पता चला है। मुझे ऐसी कई कहानियाँ याद हैं, जब कुछ सीसीटीएल को बदलने के लिए, आपको आधे बुनियादी ढांचे के कोड को फिर से लिखने की आवश्यकता होती है, क्योंकि रचनात्मकता और हर चीज को स्वचालित करने की इच्छा ने इस तथ्य को जन्म दिया है कि हर जगह सब कुछ खराब हो गया है, सभी हैंडल हटा दिए गए हैं, और रिफैक्टर करना जरूरी है.

सतत वितरण

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

एक बार जब यह स्पष्ट हो जाता है कि यह आपके पास है और इसे कैसे प्रबंधित करना है, तो आप यह पता लगाना शुरू कर देते हैं कि डेवलपर कोड को जल्द से जल्द उत्पादन में कैसे भेजा जाए। मेरा मतलब डेवलपर के साथ मिलकर है - हम "कुओं" की समस्या के बारे में याद करते हैं, यानी, यह व्यक्तिगत लोग नहीं हैं जो इसके साथ आते हैं, बल्कि एक टीम है।

जब हम साथ हैं वान्या इवतुखोविच पहली किताब देखी जेज़ विनम्र और लेखकों के समूह "निरंतर वितरण", जो 2009 में रिलीज़ हुई थी, हमने लंबे समय तक सोचा कि इसके शीर्षक का रूसी में अनुवाद कैसे किया जाए। वे इसका अनुवाद "लगातार वितरण" करना चाहते थे, लेकिन, दुर्भाग्य से, इसका अनुवाद "निरंतर वितरण" के रूप में किया गया। मुझे ऐसा लगता है कि हमारे नाम में कुछ रूसी है, दबाव के साथ।

लगातार साधन पहुंचाना

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

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

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

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

विभिन्न परिनियोजन रणनीतियाँ। उदाहरण के लिए, आप अलग-अलग क्लाइंट पर कोड का अलग-अलग परीक्षण करने के लिए एबी परीक्षण या कैनरी परिनियोजन का उपयोग करते हैं, कोड कैसे काम करता है, इसके बारे में जानकारी प्राप्त करते हैं, और इसे 100 मिलियन उपयोगकर्ताओं के लिए रोल आउट करने से बहुत पहले।

"लगातार वितरित करें" इस तरह दिखता है।

डिलीवरी प्रक्रिया डेव, सीआई, टेस्ट, प्रीप्रोड, प्रोड एक अलग वातावरण नहीं है, ये अग्निरोधी रकम वाले चरण या स्टेशन हैं जिनके माध्यम से आपकी कलाकृतियां गुजरती हैं।

यदि आपके पास इंफ्रास्ट्रक्चर कोड है जिसे बेस सर्विस एपीपी के रूप में वर्णित किया गया है तो यह मदद करता है सभी स्क्रिप्ट न भूलें, और उन्हें इस आर्टिफैक्ट के लिए कोड के रूप में लिखें, कलाकृतियों को बढ़ावा देना और जाते ही इसे बदल दो।

स्व-परीक्षण प्रश्न

95% मामलों में फीचर विवरण से उत्पादन में रिलीज होने तक का समय एक सप्ताह से भी कम है? क्या पाइपलाइन के प्रत्येक चरण में कलाकृतियों की गुणवत्ता में सुधार होता है? क्या ऐसी कोई कहानी है जिससे यह गुज़रती है? क्या आप विभिन्न परिनियोजन रणनीतियों का उपयोग करते हैं?

यदि सभी उत्तर हाँ हैं, तो आप अविश्वसनीय रूप से अच्छे हैं! अपने उत्तर टिप्पणियों में लिखें - मुझे खुशी होगी)।

प्रतिक्रिया

यह सभी अभ्यासों में सबसे कठिन है। DevOpsConf सम्मेलन में, Infobip के एक सहयोगी, इसके बारे में बात करते हुए, अपने शब्दों में थोड़ा भ्रमित थे, क्योंकि यह वास्तव में इस तथ्य के बारे में एक बहुत ही जटिल अभ्यास है कि आपको हर चीज़ की निगरानी करने की आवश्यकता है!

उदाहरण के लिए, बहुत समय पहले, जब मैंने Qik में काम किया था और हमें एहसास हुआ कि हमें हर चीज़ पर नज़र रखने की ज़रूरत है। हमने ऐसा किया, और अब हमारे पास ज़ैबिक्स में 150 आइटम हैं, जिनकी लगातार निगरानी की जाती है। यह डरावना था, तकनीकी निदेशक ने अपनी कनपटी पर उंगली घुमाई:

- दोस्तों, आप किसी अस्पष्ट चीज़ के साथ सर्वर का बलात्कार क्यों कर रहे हैं?

लेकिन तभी एक ऐसी घटना घटी जिससे पता चला कि ये वाकई बहुत बढ़िया रणनीति है.

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

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

— दोस्तों, डेढ़ सप्ताह पहले आपके साथ क्या हुआ था?

जवाब में, हमने एक दिलचस्प कहानी सुनी कि कैसे उन्होंने यूआई को फिर से डिज़ाइन किया था। इसकी संभावना नहीं है कि कोई तुरंत कहेगा कि उन्होंने HTTP लाइब्रेरी बदल दी है। एंड्रॉइड ग्राहकों के लिए, यह बाथरूम में साबुन बदलने जैसा है - उन्हें याद ही नहीं रहता। परिणामस्वरूप, 40 मिनट की बातचीत के बाद, हमें पता चला कि उन्होंने HTTP लाइब्रेरी बदल दी है, और इसकी डिफ़ॉल्ट टाइमिंग बदल गई है। इससे एपीआई सर्वर पर ट्रैफिक का व्यवहार बदल गया, जिससे ऐसी स्थिति पैदा हो गई कि ब्रोकर के भीतर प्रतिस्पर्धा शुरू हो गई और वह क्रैश होने लगा।

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

वितरण प्रक्रिया के प्रत्येक चरण में कलाकृतियों के साथ क्या होता है, इसके बारे में सभी जानकारी एकत्र करें - उत्पादन में नहीं।

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

नहीं तो इसका पता लगाना मुश्किल हो जाएगा. मैंने पहले ही कहा था कि DevOps अधिक जटिल है। इस जटिलता से निपटने के लिए, आपके पास सामान्य विश्लेषण होना आवश्यक है.

आत्म-नियंत्रण के लिए प्रश्न

क्या आपकी निगरानी और लॉगिंग आपके लिए विकास उपकरण है? कोड लिखते समय, क्या आप सहित आपके डेवलपर यह सोचते हैं कि इसकी निगरानी कैसे की जाए?

क्या आप ग्राहकों से समस्याओं के बारे में सुनते हैं? क्या आप मॉनिटरिंग और लॉगिंग से क्लाइंट को बेहतर ढंग से समझते हैं? क्या आप मॉनिटरिंग और लॉगिंग से सिस्टम को बेहतर ढंग से समझते हैं? क्या आप सिस्टम को सिर्फ इसलिए बदल देते हैं क्योंकि आपने देखा कि सिस्टम में चलन बढ़ रहा है और आप समझते हैं कि अगले 3 हफ्तों में सब कुछ खत्म हो जाएगा?

एक बार जब आपके पास ये तीन घटक हों, तो आप सोच सकते हैं कि आपकी कंपनी में किस प्रकार का बुनियादी ढांचा मंच है।

बुनियादी ढांचा मंच

मुद्दा यह नहीं है कि यह अलग-अलग उपकरणों का एक सेट है जो हर कंपनी के पास होता है।

बुनियादी ढांचे के मंच का उद्देश्य यह है कि सभी टीमें इन उपकरणों का उपयोग करें और उन्हें एक साथ विकसित करें।

यह स्पष्ट है कि अलग-अलग टीमें हैं जो बुनियादी ढांचे के मंच के अलग-अलग हिस्सों के विकास के लिए जिम्मेदार हैं। लेकिन साथ ही, प्रत्येक इंजीनियर बुनियादी ढांचे के मंच के विकास, प्रदर्शन और प्रचार की जिम्मेदारी वहन करता है। आंतरिक स्तर पर यह एक सामान्य उपकरण बन जाता है.

सभी टीमें बुनियादी ढांचे का मंच विकसित करती हैं और इसे अपनी आईडीई के रूप में सावधानीपूर्वक व्यवहार करती हैं. अपने IDE में आप हर चीज़ को अच्छा और तेज़ बनाने के लिए अलग-अलग प्लगइन्स इंस्टॉल करते हैं, और हॉटकी कॉन्फ़िगर करते हैं। जब आप सब्लिम, एटम या विज़ुअल स्टूडियो कोड खोलते हैं, तो कोड त्रुटियां आ रही हैं और आपको एहसास होता है कि काम करना बिल्कुल असंभव है, आप तुरंत दुखी महसूस करते हैं और आप अपनी आईडीई को ठीक करने के लिए दौड़ते हैं।

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

बुनियादी ढांचा मंच गुणवत्ता में निरंतर सुधार के साथ कलाकृतियों को विकास से ग्राहक तक स्थानांतरित करना सुनिश्चित करता है. आईपी ​​को कहानियों के एक सेट के साथ प्रोग्राम किया जाता है जो उत्पादन में कोड के साथ घटित होता है। विकास के वर्षों में, ऐसी बहुत सी कहानियाँ हैं, उनमें से कुछ अनोखी हैं और केवल आपसे संबंधित हैं - उन्हें Google पर नहीं खोजा जा सकता है।

इस बिंदु पर, बुनियादी ढांचा मंच आपका प्रतिस्पर्धात्मक लाभ बन जाता है, क्योंकि इसमें कुछ ऐसा अंतर्निहित है जो प्रतिस्पर्धी के टूल में नहीं है। आपका आईपी जितना गहरा होगा, टाइम-टू-मार्केट के संदर्भ में आपका प्रतिस्पर्धात्मक लाभ उतना ही अधिक होगा। यहाँ दिखाई देता है विक्रेता लॉक समस्या: आप किसी और का प्लेटफ़ॉर्म ले सकते हैं, लेकिन किसी और के अनुभव का उपयोग करके आप यह नहीं समझ पाएंगे कि यह आपके लिए कितना प्रासंगिक है। हां, हर कंपनी Amazon जैसा प्लेटफॉर्म नहीं बना सकती। यह एक कठिन रेखा है जहां कंपनी का अनुभव बाजार में उसकी स्थिति के लिए प्रासंगिक है, और आप वहां विक्रेता लॉक का उपयोग नहीं कर सकते हैं। इस पर भी विचार करना जरूरी है.

ड्राइविंग

यह एक इंफ्रास्ट्रक्चर प्लेटफ़ॉर्म का एक बुनियादी आरेख है जो आपको DevOps कंपनी में सभी प्रथाओं और प्रक्रियाओं को स्थापित करने में मदद करेगा।

आइए देखें कि इसमें क्या शामिल है।

संसाधन ऑर्केस्ट्रेशन प्रणाली, जो एप्लिकेशन और अन्य सेवाओं को सीपीयू, मेमोरी, डिस्क प्रदान करता है। इसके शीर्ष पर - निम्न स्तर की सेवाएँ: मॉनिटरिंग, लॉगिंग, सीआई/सीडी इंजन, आर्टिफैक्ट स्टोरेज, सिस्टम कोड के रूप में बुनियादी ढांचा।

उच्च स्तरीय सेवाएँ: एक सेवा के रूप में डेटाबेस, एक सेवा के रूप में कतारें, एक सेवा के रूप में लोड बैलेंस, एक सेवा के रूप में छवि का आकार बदलना, एक सेवा के रूप में बिग डेटा फैक्ट्री। इसके शीर्ष पर - पाइपलाइन जो आपके क्लाइंट को लगातार संशोधित कोड वितरित करती है.

आप इस बारे में जानकारी प्राप्त करते हैं कि आपका सॉफ़्टवेयर क्लाइंट के लिए कैसे काम करता है, इसे बदलें, इस कोड को दोबारा प्रदान करें, जानकारी प्राप्त करें - और इस प्रकार आप लगातार इंफ्रास्ट्रक्चर प्लेटफ़ॉर्म और अपने सॉफ़्टवेयर दोनों को विकसित करते हैं।

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

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

मंच का निर्माण

यह एक जटिल संचार प्रक्रिया है. जब आपके पास बुनियादी अभ्यास होते हैं, तो आप विभिन्न इंजीनियरों और विशेषज्ञों के बीच संचार शुरू करते हैं जो आवश्यकताओं और मानकों को विकसित करते हैं, और उन्हें लगातार विभिन्न उपकरणों और दृष्टिकोणों में बदलते हैं। DevOps में हमारे पास जो संस्कृति है वह यहां महत्वपूर्ण है।

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

तुम्हारे पास क्या है?

फिर से, प्रश्न आप स्वयं से पूछ सकते हैं।

क्या बुनियादी ढांचा मंच समर्पित है? इसके विकास के लिए कौन जिम्मेदार है? क्या आप अपने इन्फ्रास्ट्रक्चर प्लेटफॉर्म के प्रतिस्पर्धात्मक लाभों को समझते हैं?

आपको खुद से लगातार ये सवाल पूछने की जरूरत है। यदि कुछ तृतीय-पक्ष सेवाओं में स्थानांतरित किया जा सकता है, तो इसे स्थानांतरित किया जाना चाहिए; यदि कोई तृतीय-पक्ष सेवा आपके आंदोलन को अवरुद्ध करना शुरू कर देती है, तो आपको अपने भीतर एक सिस्टम बनाने की आवश्यकता है।

तो, DevOps...

...यह एक जटिल प्रणाली है, इसमें होना चाहिए:

• डिजिटल उत्पाद.
• व्यावसायिक मॉड्यूल जो इस डिजिटल उत्पाद को विकसित करते हैं।
• उत्पाद टीमें जो कोड लिखती हैं।
• सतत वितरण प्रथाएँ।
• एक सेवा के रूप में प्लेटफार्म.
• एक सेवा के रूप में बुनियादी ढाँचा।
• कोड के रूप में इन्फ्रास्ट्रक्चर।
• विश्वसनीयता बनाए रखने के लिए DevOps में निर्मित अलग-अलग प्रथाएँ।
• एक फीडबैक अभ्यास जो यह सब बताता है।

आप इस आरेख का उपयोग कर सकते हैं, इसमें इस बात पर प्रकाश डाल सकते हैं कि आपकी कंपनी में पहले से ही किसी न किसी रूप में क्या है: क्या यह विकसित हो चुका है या अभी भी इसे विकसित करने की आवश्यकता है।

यह कुछ हफ़्ते में ख़त्म हो जाएगा DevOpsConf 2019. आरआईटी++ के भाग के रूप में। सम्मेलन में आएं, जहां आपको निरंतर डिलीवरी, कोड के रूप में बुनियादी ढांचे और DevOps परिवर्तन के बारे में कई अच्छी रिपोर्टें मिलेंगी। अपने टिकट बुक करें, अंतिम कीमत की समय सीमा 20 मई है

स्रोत: www.habr.com