अनाथ सेवाएं: (माइक्रो) सर्विस आर्किटेक्चर का रिवर्स साइड

Banki.ru पोर्टल के संचालन निदेशक आंद्रेई निकोल्स्की ने पिछले साल के सम्मेलन में अनाथ सेवाओं के बारे में मास्को के DevOpsDays से कहा: बुनियादी ढांचे में एक अनाथ की पहचान कैसे करें, क्या अनाथ सेवाएं हैं, उनके साथ क्या करना है, और कैसे कुछ भी मदद नहीं करता है।

कटौती के तहत रिपोर्ट का पाठ संस्करण है।


नमस्कार साथियों! मेरा नाम एंड्री है, मैं Banki.ru पर ऑपरेशन का नेतृत्व करता हूं।

हमारे पास महान सेवाएं हैं, ये अखंड सेवाएं हैं, अधिक शास्त्रीय अर्थ में सेवाएं हैं, बहुत छोटी हैं। मेरे कार्यकर्ता और किसान की शब्दावली में, मैं कहता हूं कि यदि सेवा सरल और छोटी है, तो यह सूक्ष्म है, और यदि यह बहुत सरल नहीं है और छोटी नहीं है, तो यह सिर्फ एक सेवा है।

सेवा पेशेवरों

मैं सेवाओं के फायदों पर जल्दी जाऊंगा



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



दूसरे, अलग-थलग विकास, जब आपके पास कई विकास दल होते हैं, प्रत्येक टीम में कई अलग-अलग डेवलपर्स होते हैं, और प्रत्येक टीम किसी तरह की सेवा को देखती है।

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



तस्वीर को देखो: वह एक अच्छा डेवलपर है, उसके बड़े हाथ हैं, वह बहुत कुछ कर सकता है। मुख्य समस्या यह है कि ये हाथ कहाँ से बढ़ते हैं।



सेवाएं विभिन्न प्रोग्रामिंग भाषाओं का उपयोग करना संभव बनाती हैं जो विभिन्न कार्यों के लिए अधिक उपयुक्त हैं। गो पर कुछ सेवा, कुछ एर्लांग पर, कुछ रूबी पर, कुछ PHP पर, कुछ पायथन पर। सामान्य तौर पर, आप बहुत व्यापक रूप से घूम सकते हैं। यहां बारीकियां भी हैं।



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

उदाहरण के लिए, आपके पास 20 सेवाएं हैं, और आपको अपने हाथों से तैनात करने की आवश्यकता है, आपके पास 20 कंसोल हैं, और आप एक निंजा की तरह "एन्टर" दबाते हैं। यह बहुत अच्छा नहीं है।

यदि आपके पास परीक्षण के बाद एक सेवा है (यदि परीक्षण है, तो निश्चित रूप से), और आपको इसे एक फ़ाइल के साथ समाप्त करने की भी आवश्यकता है ताकि यह उत्पादन में काम करे, मेरे पास आपके लिए भी बुरी खबर है।

यदि आप अमेज़ॅन की विशिष्ट सेवाओं और रूस में काम करने पर भरोसा करते हैं, तो दो महीने पहले आपके पास "सब कुछ आग पर है, मैं ठीक हूं, सब कुछ शांत है।"



हम तैनाती स्वचालन के लिए Ansible का उपयोग करते हैं, अभिसरण के लिए कठपुतली, तैनाती स्वचालन के लिए बांस, किसी भी तरह यह वर्णन करने के लिए Confluence।

मैं इस पर विस्तार से ध्यान नहीं दूंगा, क्योंकि यह रिपोर्ट बातचीत के अभ्यास के बारे में अधिक है, न कि तकनीकी कार्यान्वयन के बारे में।



उदाहरण के लिए, हमें समस्या थी कि सर्वर पर कठपुतली रूबी 2 के साथ काम करती है, और कुछ आवेदन रूबी 1.8 के तहत लिखे गए थे, और साथ में वे काम नहीं करते हैं। वहां किसी तरह का जाम होता है। और जब आपको एक ही मशीन पर रूबी के कई संस्करण रखने की आवश्यकता होती है, तो आपको आमतौर पर समस्याएं होती हैं।

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

ऐसा होता है कि आपको किसी चीज के समर्थन के साथ किसी तरह के विशेष रूप से संकलित पैकेज की आवश्यकता होती है। यह काफी कठिन है। मैंने एक रिपोर्ट सुनी है जिसमें डॉकटर की छवि 45 जीबी है। लिनक्स में, निश्चित रूप से, यह सरल है, वहां सब कुछ छोटा है, लेकिन वैसे भी, पर्याप्त जगह नहीं होगी।

ठीक है, जब आपके पास एक संस्करण के पुस्तकालय के आधार पर एक परियोजना का एक टुकड़ा होता है, तो परस्पर निर्भरताएं होती हैं, एक अलग संस्करण पर परियोजना का एक और टुकड़ा होता है, और पुस्तकालयों को एक साथ नहीं रखा जाता है।



PHP 5.6 में हमारे पास साइटें और सेवाएं हैं, हम उनसे शर्मिंदा हैं, लेकिन क्या करें। यह हमारी एक साइट है। PHP 7 में साइटें और सेवाएँ हैं, उनमें से अधिक हैं, हम उनमें से शर्मिंदा नहीं हैं। और प्रत्येक डेवलपर का अपना आधार है, जहां वह खुशी से आरी देता है।

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



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



इसलिए, हमने प्रोग्रामिंग भाषा के बन्स को अलग-अलग फ्रेमवर्क के उपयोग के साथ बदल दिया, क्योंकि PHP में फ्रेमवर्क काफी अलग हैं, उनके पास अलग-अलग क्षमताएं, अलग-अलग समुदाय, अलग-अलग समर्थन हैं। और आप एक सेवा लिख ​​सकते हैं ताकि आपके पास पहले से ही इसके लिए कुछ तैयार हो।

प्रत्येक सेवा की अपनी टीम है।

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

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

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

और जब आपने अपनी सेवा को तोड़ दिया, और यह अनिवार्य रूप से होता है, तो आपने किसी और की सेवाओं को चोट नहीं पहुंचाई है, और अन्य टीमों के बिट्स वाले डेवलपर्स आपके लिए सहारा नहीं लेते हैं और वे यह नहीं कहते हैं: "अरे, ऐसा मत करो।"



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

यदि टीमें तैर रही हैं (यह कभी-कभी हमारे साथ भी उपयोग की जाती है), एक अच्छा तरीका है जिसे स्टार मैप कहा जाता है।



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

अनाथ सेवाएं कैसे दिखाई देती हैं?

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

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



उसी समय, समर्थन से और व्यवसाय से कार्य गायब नहीं होते हैं, वे बैकलॉग में बस जाते हैं। यदि सेवा के विकास के दौरान कोई वास्तु दोष था, तो वे बैकलॉग में भी बैठते हैं। सेवा धीरे-धीरे खराब हो रही है।

अनाथ की पहचान कैसे करें?

यह सूची स्थिति का अच्छी तरह से वर्णन करती है। बुनियादी ढांचे में किसने कुछ सीखा?



प्रलेखित वर्क-अराउंड के बारे में: एक सेवा है और सामान्य तौर पर, यह काम करता है, इसमें दो-पृष्ठ मैनुअल होता है, इसके साथ कैसे काम करना है, लेकिन किसी को नहीं पता कि यह अंदर कैसे काम करता है।

या, उदाहरण के लिए, लिंक शॉर्टनर का कुछ प्रकार है। उदाहरण के लिए, अब हम विभिन्न सेवाओं में विभिन्न उद्देश्यों के लिए तीन लिंक शॉर्टनर का उपयोग करते हैं। ये परिणाम हैं।



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

मुख्य बात: आपके पास रक्त-लिखित संचरण प्रक्रियाएं होनी चाहिए। हमारे मामले में, मैं आमतौर पर इसका पालन करता हूं, क्योंकि मुझे काम करने के लिए इसकी आवश्यकता है। प्रबंधकों को इसे शीघ्रता से वितरित करने की आवश्यकता है, और बाद में उनके साथ क्या होगा यह उनके लिए इतना महत्वपूर्ण नहीं है।



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



उदाहरण के लिए, हमारे पास एक सेवा थी जिसमें स्फिंक्स विभिन्न अप्रत्याशित स्थानों पर था। मैं आपको बाद में बताऊंगा कि मुझे क्या करना था।

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

मैं कप्तानी करता रहूंगा। आउटसोर्सिंग से सेवा स्वीकार करना एक ऐसी प्रक्रिया है जिसकी आवश्यकता होती है। ऐसा कौन हुआ है कि एक आउटसोर्सर से एक सेवा आती है, लेकिन इसे कहीं भी स्वीकार नहीं किया जाता है? बेशक, यह सेवा अनाथ के रूप में लोकप्रिय नहीं है, लेकिन फिर भी।



सेवा की जांच होनी चाहिए, सेवा की समीक्षा की जानी चाहिए, पासवर्ड बदलना होगा। हमारे पास एक मामला था जब सेवा ने हमें फेंक दिया, वहां व्यवस्थापक पैनल "यदि लॉगिन == 'व्यवस्थापक' और& पासवर्ड == 'व्यवस्थापक' ..." कोड में सीधे लिखा गया है। हम बैठकर सोचते हैं, और लोग इसे 2018 में लिखते हैं?

भंडारण की मात्रा का परीक्षण भी एक जरूरी है। आपको यह देखने की जरूरत है कि एक लाख रिकॉर्ड पर क्या होगा, इससे पहले कि आप उत्पादन में कहीं इस सेवा को शुरू करें।



संशोधन के लिए सेवा भेजें शर्म नहीं आनी चाहिए। जब आप कहते हैं: "हम इस सेवा को स्वीकार नहीं करेंगे, हमारे पास 20 कार्य हैं, उन्हें करें, तो हम स्वीकार करेंगे", यह सामान्य है। विवेक इस तथ्य से आहत नहीं होना चाहिए कि आप एक प्रबंधक को स्थानापन्न करते हैं या एक व्यवसाय पैसा खर्च करता है। व्यवसाय फिर अधिक खर्च करेगा।

हमारे पास एक मामला था जब हमने आउटसोर्सिंग पर एक पायलट प्रोजेक्ट बनाने का फैसला किया।



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



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



और एक अनाथ सेवा प्राप्त करने का एक और तरीका: जब कोई टीम अचानक लोड हो जाती है, तो प्रबंधन कहता है: "आइए हम इस टीम की सेवा को किसी अन्य टीम में स्थानांतरित करते हैं, इसका भार कम है।" और फिर हम तीसरी टीम में स्थानांतरित करेंगे, और हम प्रबंधक को बदल देंगे। और अंत में, हमारे पास फिर से एक अनाथ है।

अनाथों के साथ क्या समस्या है?

कौन नहीं जानता, यह स्वीडन में उठी लाइन वासा का जहाज था, इस तथ्य के लिए प्रसिद्ध है कि यह लॉन्च होने के 5 मिनट बाद डूब गया। और वैसे, स्वीडन के राजा ने इसके लिए किसी को भी निष्पादित नहीं किया। यह इंजीनियरों की दो पीढ़ियों द्वारा बनाया गया था जो ऐसे जहाजों का निर्माण नहीं कर सकते थे। प्राकृतिक प्रभाव।

जहाज, वैसे, बहुत खराब हो सकता है, उदाहरण के लिए, जब राजा तूफान में कहीं सवारी करेगा। और इसलिए, वह तुरंत डूब गया, अजेल के अनुसार यह जल्दी विफल होने के लिए अच्छा था।

यदि हम जल्दी असफल हो जाते हैं, तो आमतौर पर कोई समस्या नहीं होती है। उदाहरण के लिए, स्वीकृति के दौरान उन्होंने संशोधन के लिए भेजा। और अगर हम पहले ही उत्पादन में विफल हो गए हैं, जब पैसा लगाया जाता है, तो समस्याएं हो सकती हैं। परिणाम, जैसा कि उन्हें व्यवसाय में कहा जाता है।

खतरनाक अनाथ सेवाएं:

• सेवा अचानक टूट सकती है।
• सेवा लंबे समय तक मरम्मत की जाती है या बिल्कुल भी मरम्मत नहीं की जाती है।
• सुरक्षा के मुद्दे।
• सुधार और अद्यतन के साथ समस्या।
• यदि एक महत्वपूर्ण सेवा टूट जाती है, तो कंपनी की प्रतिष्ठा को नुकसान पहुंचता है।

अनाथ सेवाओं के साथ क्या करना है?

एक बार फिर, क्या करना है। सबसे पहले, प्रलेखन होना चाहिए। Banki.ru पर 7 साल के लिए मुझे सिखाया गया था कि परीक्षकों को डेवलपर्स के लिए एक शब्द नहीं लेना चाहिए, और ऑपरेशन में सभी के लिए एक शब्द नहीं लेना चाहिए। जांच करना आवश्यक है।



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



तीसरा, तकनीकी ऋण के साथ काम करें। जब आप कुछ बैसाखी बनाते हैं या सेवा स्वीकार करते हैं और कहते हैं कि कुछ करने की आवश्यकता है, तो आपको यह सुनिश्चित करने की आवश्यकता है कि वे ऐसा करते हैं। क्योंकि तब यह पता चल सकता है कि छोटा छेद इतना छोटा नहीं है, और आप वहां गिर जाते हैं।

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

एक अनाथ सेवा के साथ कार्य योजना

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

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



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

यही है, आप अजीब तकनीकी समाधानों के बिना, सेवा आवश्यकताओं को नए सिरे से लेते हैं और बेहतर मंच पर एक नई सेवा लिखते हैं। और युद्ध में इसके लिए पलायन।



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

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

यह वह सब है जिसके बारे में मैं बात करना चाहता था, मैं चर्चा के लिए तैयार हूं, विषय समग्र है, इसमें कई तैर रहे हैं।

स्लाइड्स पर यह इस तथ्य के बारे में था कि आप भाषाओं को एकीकृत करते हैं। एक उदाहरण चित्रों का आकार बदलना था। क्या वास्तव में एक भाषा का कठोरता से होना आवश्यक है? क्योंकि PHP में चित्रों का आकार बदलना, ठीक है, आप वास्तव में इसे गोलंग में कर सकते हैं।

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

अब हम Node.js पर सेवा को देख रहे हैं, और यह एक अलग भाषा के साथ प्रत्येक डेवलपर के लिए पास में एक मंच होगा। लेकिन हम यह सोचकर बैठे रहे कि खेल मोमबत्ती के लायक था। यानी यहां सवाल यह है कि बैठकर सोचिए।

आप अपनी सेवाओं की निगरानी कैसे करते हैं? आप लॉग को कैसे इकट्ठा और ट्रैक करते हैं?

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

कैसे कठपुतली और एक वातावरण में Ansible के साथ रहने के लिए?

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

आप संगतता कैसे बनाए रखते हैं? क्या आपके पास Ansible और कठपुतली दोनों में कॉन्फ़िगर है?

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

प्रस्तुति रूबी के विभिन्न संस्करणों के बारे में थी। समाधान क्या है?

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

इस साल, DevOpsDays मास्को सम्मेलन 7 दिसंबर को Technopolis में आयोजित किया जाएगा। 11 नवंबर तक, हम रिपोर्ट के लिए आवेदन स्वीकार करते हैं। अगर आप बोलना चाहते हैं तो हमें ईमेल करें।

प्रतिभागियों के लिए पंजीकरण खुला है, सम्मिलित हों!