सामान्य ज्ञान के आधार पर: खरोंच से बढ़ते DevOps

DevOps Conf Russia 2018 की पूर्व संध्या पर, हमने मंच के विकास के चरणों के बारे में Uchi.ru के तकनीकी निदेशक अलेक्सी वाखोव से बात की, वे किस उपकरण का उपयोग करते हैं और देवो का ओवो कितना है।



एलेक्सी वाखोव - तकनीकी निदेशक यूची.व्ही। उन्होंने विशाल प्रणालियों (कोड की लाखों लाइनों के दसियों) पर C ++ डेवलपर के रूप में काम किया। पसंदीदा सर्वर तकनीक - रूबी ऑन रेल्स, शीर्ष 100 योगदानकर्ताओं में से एक है। वह वेब अनुप्रयोगों के आईटी उत्पादन, संचालन, वास्तुकला के संगठन के शौकीन हैं।

Uchi.ru एक रूसी शैक्षिक मंच है जहां 1-11 कक्षा के छात्र मजेदार और मनोरंजक तरीके से स्कूल के विषयों का अध्ययन करते हैं। मंच का उपयोग रूस, अमेरिका, ब्राजील, भारत, दक्षिण अफ्रीका और चीन में 2.5 मिलियन से अधिक छात्रों और 220 हजार शिक्षकों द्वारा किया जाता है। यह ई-लर्निंग प्लेटफार्मों की वैश्विक रैंकिंग में 36 वां स्थान लेता है। कंपनी में 400 से अधिक कर्मचारी हैं।

- यह सब कैसे शुरू हुआ? आपके आने पर कंपनी में कितने लोग थे?

- मुझे छह साल पहले यानी 2012 में कंपनी में आमंत्रित किया गया था। उस समय मैं पाँचवाँ या छठा कर्मचारी था, और एकमात्र डेवलपर। मैंने टाइप किया और सर्वर डेवलपमेंट किया। हमने पहला वेब एप्लिकेशन बनाया और इसे हरोकू पर पोस्ट किया।

"अब चीजें कैसी हैं?" कितनी टीमें और क्या आकार? कितना स्वतंत्र? वे एक दूसरे के साथ कैसे बातचीत करते हैं?

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

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

- कंपनी की इस वृद्धि दर के साथ, क्या आप अपनी खुद की विकी बनाने का प्रबंधन करते हैं? आप उसका समर्थन कैसे करते हैं?

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

- नियंत्रण में कमी के साथ तेज वृद्धि होती है। आप इससे कैसे निपटेंगे? आप कितनी टीमों के काम में समन्वय करते हैं?

- एक प्रबंधन पदानुक्रम का निर्माण करके सामान्य समन्वय प्राप्त किया जाता है। हमारे पास रेफरल समन्वयक हैं, और प्रत्येक टीम का अपना नेता है। यहां सब कुछ सरल है।

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

- कंपनी के गठन के कौन से चरण आप अपने लिए निकालते हैं?

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

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

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

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

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

लगभग 60 अनुप्रयोगों से शुरू होकर, हमारा बुनियादी ढांचा अलग हो गया है, जैसा कि हम उन्हें "साइट" कहते हैं। ये अपने स्वयं के सबनेट्स के साथ अलग-अलग बादल होते हैं, अपने स्वयं के टेराफॉर्म और ansible कॉन्फ़िगरेशन के साथ।

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

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

- आप मूल DevOps दृष्टिकोण पर कितनी मजबूती से खड़े हैं? क्या सब कुछ आपके अनुकूल है या आपने अपने लिए कुछ बदला है? क्या टीम का पुनर्निर्माण करना मुश्किल था?

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

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

चूंकि हमारे पास एक अच्छी तरह से स्थापित कंपनी नहीं थी, इसलिए, हमने काम के सिद्धांतों को बहुत तेज़ी से बढ़ाया। इसके अलावा, व्यवसाय ने हमें लगातार नए कार्य दिए, इसलिए हमने मुख्य रूप से सामान्य ज्ञान और आंतरिक आवश्यकताओं के आधार पर अपने बुनियादी ढांचे का निर्माण किया।

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

- यह जानना दिलचस्प होगा कि शुरुआती लोगों के लिए इतने आधुनिक उपकरणों के साथ अपने काम में शामिल होना कितना मुश्किल है। आपके काम का आयोजन लोगों के साथ कैसा है?

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

- हमें कंपनी की योजनाओं के बारे में बताएं। आप कहाँ बढ़ने की योजना बना रहे हैं और किन क्षेत्रों का विकास करना है? क्या वर्तमान तकनीक स्टैक आगे की वृद्धि के लिए आधार प्रदान करती है, या आपको इसे फिर से बदलना होगा?

- बिजनेस प्लान महत्वाकांक्षी हैं। आज, दो मिलियन से अधिक स्कूली बच्चे नियमित रूप से Uchi.ru में भाग लेते हैं, जो देश भर के सभी प्राथमिक स्कूल के छात्रों का लगभग 30% है। हम रूस में मंच के लिए नए उपयोगकर्ताओं को आकर्षित करना जारी रखेंगे और अंतर्राष्ट्रीय विकास में संलग्न होंगे।

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

---

दोस्तों, यदि आप अलेक्सी के अनुभव में रुचि रखते हैं, तो हम अपने DevOps Conf Russia 2018 को आमंत्रित करने की जल्दबाजी करते हैं, जो 1-2 अक्टूबर को आयोजित किया जाएगा। अपनी रिपोर्ट में, वह बादलों के उपयोग के अनुभव, देवओप्स पद्धति के अनुप्रयोग, उनकी टीम के मूल्यों और सिद्धांतों के बारे में बात करेंगे।

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

वैसे, वीडियो को YouTube चैनल पर अलग से मॉनिटर किया जा सकता है - हाल के वर्षों में एकत्र किए गए सभी वीडियो हैं और सूची लगातार अपडेट की जाती है।