अनाथ सेवाएँ: (सूक्ष्म) सेवा वास्तुकला का नकारात्मक पक्ष

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

कट के नीचे रिपोर्ट का एक पाठ संस्करण है।

नमस्ते सहयोगियों! मेरा नाम एंड्री है, मैं 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 या Dadata पर अपनी कुंजी पर सेवा स्थापित की। आपकी मुफ़्त सीमा समाप्त हो गई है, सब कुछ टूट गया है, और आप बिल्कुल भी नहीं जानते कि क्या हुआ। ऐसे सभी रेक का वर्णन किया जाना चाहिए: सेवा दादाटा, एसएमएस, कुछ और का उपयोग करती है।

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

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

किसी अनाथ सेवा के साथ काम करने की योजना बनाएं

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

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

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

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

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

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

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

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

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

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

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

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

पपेट और अन्सिबल के साथ एक ही वातावरण में कैसे रहें?

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

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

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

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

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

इस वर्ष का सम्मेलन डेवऑप्सडेज़ मॉस्को 7 दिसंबर को टेक्नोपोलिस में होगा। हम 11 नवंबर तक रिपोर्ट के लिए आवेदन स्वीकार कर रहे हैं। लिखना यदि आप बात करना चाहें तो हमसे।

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

स्रोत: www.habr.com