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

Banki.ru पोर्टलका सञ्चालन निर्देशक एन्ड्रे निकोल्स्कीले गत वर्षको सम्मेलनमा बोलेका थिए DevOpsDays मस्को अनाथ सेवाहरूको बारेमा: पूर्वाधारमा अनाथ कसरी पहिचान गर्ने, किन अनाथ सेवाहरू खराब छन्, तिनीहरूलाई के गर्ने, र यदि केहि पनि मद्दत गर्दैन भने के गर्ने।

कट तल रिपोर्ट को एक पाठ संस्करण छ।

नमस्ते सहकर्मीहरू! मेरो नाम एन्ड्री हो, म Banki.ru मा सञ्चालन गर्छु।

हामीसँग ठूला सेवाहरू छन्, यी त्यस्ता मोनोलिथिक सेवाहरू हुन्, त्यहाँ अधिक शास्त्रीय अर्थमा सेवाहरू छन्, र त्यहाँ धेरै साना छन्। मेरो मजदुर-किसान शब्दावलीमा म भन्छु, यदि कुनै सेवा सरल र सानो छ भने त्यो सूक्ष्म हो, र यदि यो धेरै सरल र सानो छैन भने त्यो सेवा मात्र हो।

सेवाहरूको फाइदाहरू

म चाँडै सेवाहरूको फाइदाहरूमा जानेछु।

पहिलो स्केलिंग छ। तपाईं चाँडै सेवा मा केहि गर्न र उत्पादन सुरु गर्न सक्नुहुन्छ। तपाईंले ट्राफिक प्राप्त गर्नुभयो, तपाईंले सेवा क्लोन गर्नुभएको छ। तपाईंसँग धेरै ट्राफिक छ, तपाईंले यसलाई क्लोन गर्नुभएको छ र यससँग बस्नुहोस्। यो एक राम्रो बोनस हो, र, सिद्धान्तमा, जब हामीले सुरु गर्यौं, यो हाम्रो लागि सबैभन्दा महत्त्वपूर्ण कुरा मानिन्थ्यो, हामी किन यो सबै गर्दैछौं।

दोस्रो, पृथक विकास, जब तपाईंसँग धेरै विकास टोलीहरू छन्, प्रत्येक टोलीमा धेरै फरक विकासकर्ताहरू छन्, र प्रत्येक टोलीले आफ्नै सेवा विकास गर्दछ।

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

तस्वीर हेर्नुहोस्: यो एक राम्रो विकासकर्ता हो, उहाँसँग ठूलो हात छ, उहाँले धेरै गर्न सक्नुहुन्छ। यी हातहरू कहाँबाट आउँछन् भन्ने मुख्य समस्या हो।

सेवाहरूले विभिन्न प्रोग्रामिङ भाषाहरू प्रयोग गर्न सम्भव बनाउँदछ जुन विभिन्न कार्यहरूको लागि अधिक उपयुक्त हुन्छ। केहि सेवा Go मा छ, केहि Erlang मा छ, केहि Ruby मा छ, केहि PHP मा छ, केहि पाइथन मा छ। सामान्यतया, तपाईं धेरै व्यापक रूपमा विस्तार गर्न सक्नुहुन्छ। यहाँ पनि सूक्ष्मताहरू छन्।

सेवा उन्मुख वास्तुकला मुख्यतया devops को बारे मा छ। त्यो हो, यदि तपाईंसँग स्वचालन छैन भने, त्यहाँ कुनै डिप्लोइमेन्ट प्रक्रिया छैन, यदि तपाईंले यसलाई म्यानुअल रूपमा कन्फिगर गर्नुभयो भने, तपाईंको कन्फिगरेसनहरू सेवा उदाहरणबाट उदाहरणमा परिवर्तन हुन सक्छ, र तपाईंले त्यहाँ केही गर्न जानु पर्छ, त्यसपछि तपाईं नरकमा हुनुहुन्छ।

उदाहरण को लागी, तपाईसँग 20 वटा सेवाहरू छन् र तपाईलाई हातले डिप्लोय गर्न आवश्यक छ, तपाईसँग 20 कन्सोलहरू छन्, र तपाईले एकै साथ निन्जा जस्तै "इन्टर" थिच्नुहोस्। यो धेरै राम्रो छैन।

यदि तपाइँसँग परीक्षण पछि सेवा छ (यदि त्यहाँ परीक्षण छ, अवश्य), र तपाइँ अझै पनि फाइल संग समाप्त गर्न आवश्यक छ ताकि यो उत्पादन मा काम गर्दछ, म संग पनि तपाइँको लागि नराम्रो खबर छ।

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

हामी डिप्लोयमेन्टलाई स्वचालित गर्न Ansible, कन्भर्जन्सको लागि कठपुतली, डिप्लोयमेन्टलाई स्वचालित गर्न बाँस, र कुनै न कुनै रूपमा यो सबै वर्णन गर्न कन्फ्लुएन्स प्रयोग गर्छौं।

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

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

उदाहरणका लागि, हामी प्रत्येक विकासकर्तालाई एउटा प्लेटफर्म दिन्छौं जसमा हामीसँग लगभग सबै चीजहरू छन्, सबै सेवाहरू जुन विकास गर्न सकिन्छ, ताकि उहाँसँग पृथक वातावरण छ, उसले यसलाई तोड्न र आफूले चाहे अनुसार निर्माण गर्न सक्छ।

यस्तो हुन्छ कि तपाईलाई त्यहाँ केहिको लागि समर्थनको साथ केहि विशेष कम्पाइल गरिएको प्याकेज चाहिन्छ। यो एकदमै गाह्रो छ। मैले एउटा रिपोर्ट सुने जहाँ डकर छविको तौल 45 GB हुन्छ। लिनक्समा, निस्सन्देह, यो सरल छ, त्यहाँ सबै सानो छ, तर अझै, त्यहाँ पर्याप्त ठाउँ हुनेछैन।

ठीक छ, त्यहाँ विवादास्पद निर्भरताहरू छन्, जब परियोजनाको एक टुक्रा एउटा संस्करणको पुस्तकालयमा निर्भर हुन्छ, परियोजनाको अर्को टुक्रा अर्को संस्करणमा निर्भर हुन्छ, र पुस्तकालयहरू सँगै स्थापना हुँदैनन्।

हामीसँग PHP 5.6 मा साइटहरू र सेवाहरू छन्, हामी तिनीहरूलाई लज्जित छौं, तर हामी के गर्न सक्छौं? यो हाम्रो एक साइट हो। त्यहाँ PHP 7 मा साइटहरू र सेवाहरू छन्, तिनीहरूमध्ये धेरै छन्, हामी तिनीहरूलाई लाज मान्दैनौं। र प्रत्येक विकासकर्ताको आफ्नै आधार छ जहाँ उसले खुसीसाथ हेर्यो।

यदि तपाइँ एक कम्पनीमा एउटै भाषामा लेख्नुहुन्छ भने, त्यसपछि विकासकर्ता प्रति तीन भर्चुअल मेसिनहरू सामान्य लाग्दछ। यदि तपाइँसँग फरक प्रोग्रामिङ भाषाहरू छन् भने, त्यसपछि स्थिति खराब हुन्छ।

तपाईंसँग यसमा साइटहरू र सेवाहरू छन्, यसमा, त्यसपछि Go को लागि अर्को साइट, रुबीको लागि एउटा साइट, र छेउमा केही अन्य Redis। नतिजाको रूपमा, यो सबै समर्थन को लागी एक ठूलो क्षेत्र मा परिणत हुन्छ, र सबै समय यसको केहि तोड्न सक्छ।

तसर्थ, हामीले प्रोग्रामिङ भाषाका फाइदाहरूलाई विभिन्न फ्रेमवर्कहरूको प्रयोगमा प्रतिस्थापन गर्यौं, किनकि PHP फ्रेमवर्कहरू एकदम फरक छन्, तिनीहरूसँग फरक क्षमताहरू, फरक समुदायहरू, र फरक समर्थनहरू छन्। र तपाइँ एक सेवा लेख्न सक्नुहुन्छ ताकि तपाइँसँग पहिले नै यसको लागि केहि तयार छ।

प्रत्येक सेवाको आफ्नै टोली छ

हाम्रो मुख्य फाइदा, जुन धेरै वर्षहरूमा क्रिस्टलाइज गरिएको छ, प्रत्येक सेवाको आफ्नै टोली छ। यो ठूलो परियोजनाको लागि सुविधाजनक छ, तपाइँ कागजातमा समय बचत गर्न सक्नुहुन्छ, प्रबन्धकहरूलाई उनीहरूको परियोजना राम्ररी थाहा छ।

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

नयाँ सुविधाहरू चाँडै सिर्जना भइरहेका छन्, किनभने जब तपाईंसँग एक परमाणु सेवा छ, तपाईं चाँडै यसमा केही पेच गर्न सक्नुहुन्छ।

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

सधैं जस्तै, त्यहाँ nuances छन्। हामीसँग स्थिर टोलीहरू छन्, प्रबन्धकहरू टोलीमा परेका छन्। त्यहाँ स्पष्ट कागजातहरू छन्, प्रबन्धकहरूले सबै कुरालाई नजिकबाट निगरानी गर्छन्। प्रबन्धक भएको प्रत्येक टोलीसँग धेरै सेवाहरू छन्, र त्यहाँ दक्षताको एक विशिष्ट बिन्दु छ।

यदि टोलीहरू तैरिरहेका छन् (हामी कहिलेकाहीँ यसलाई प्रयोग गर्छौं), त्यहाँ "स्टार नक्सा" भनिने राम्रो विधि छ।

तपाईंसँग सेवा र व्यक्तिहरूको सूची छ। तारा चिन्ह भनेको व्यक्ति यस सेवामा विशेषज्ञ हो, पुस्तकको अर्थ व्यक्तिले यो सेवा अध्ययन गरिरहेको हो भन्ने बुझिन्छ। व्यक्तिको कार्य तारा चिन्हको लागि पुस्तिका परिवर्तन गर्नु हो। र यदि सेवाको अगाडि केहि लेखिएको छैन भने, त्यसपछि समस्याहरू सुरु हुन्छन्, जसको बारेमा म थप कुरा गर्नेछु।

अनाथ सेवाहरू कसरी देखा पर्छन्?

पहिलो समस्या, तपाईंको पूर्वाधारमा अनाथ सेवा प्राप्त गर्ने पहिलो तरिका भनेको मानिसहरूलाई बर्खास्त गर्नु हो। कार्यहरू मूल्याङ्कन गर्नु अघि के कसैले कहिल्यै व्यापार पूरा गर्ने समयसीमा गरेको छ? कहिलेकाहीँ यो हुन्छ कि समयसीमा तंग छ र कागजातको लागि पर्याप्त समय छैन। "हामीले उत्पादनलाई सेवा हस्तान्तरण गर्न आवश्यक छ, त्यसपछि हामी यसलाई थप्नेछौं।"

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

एकै समयमा, समर्थन र व्यवसायबाट कार्यहरू हराउँदैनन्; तिनीहरू ब्याकलगमा समाप्त हुन्छन्। यदि सेवाको विकासको क्रममा कुनै वास्तु त्रुटिहरू थिए भने, तिनीहरू पनि ब्याकलगमा समाप्त हुन्छन्। सेवा विस्तारै बिग्रँदै गएको छ ।

अनाथ कसरी पहिचान गर्ने?

यो सूचीले स्थिति राम्रोसँग वर्णन गर्दछ। तिनीहरूको पूर्वाधारको बारेमा कसले केही सिके?

कागजात गरिएको कार्य-वरिपरि: त्यहाँ एक सेवा छ र, सामान्यतया, यसले काम गर्दछ, योसँग कसरी काम गर्ने भन्ने बारे दुई-पृष्ठ म्यानुअल छ, तर कसैलाई थाहा छैन कि यसले कसरी काम गर्छ।

वा, उदाहरण को लागी, त्यहाँ केहि प्रकारको लिङ्क छोटो छ। उदाहरणका लागि, हामीसँग हाल विभिन्न सेवाहरूमा विभिन्न उद्देश्यका लागि प्रयोगमा रहेका तीनवटा लिङ्क सर्टनरहरू छन्। यी त परिणाम मात्र हुन् ।

अब म स्पष्ट कप्तान हुनेछु। के गर्नुपर्छ? पहिले, हामीले सेवालाई अर्को प्रबन्धक, अर्को टोलीमा स्थानान्तरण गर्न आवश्यक छ। यदि तपाईंको टोलीको नेतृत्वले अझै छाडेको छैन भने, त्यसपछि यो अर्को टोलीमा, जब तपाईंले यो सेवा अनाथ जस्तै हो भनेर बुझ्नुहुन्छ, तपाईंले कम्तिमा पनि यसको बारेमा केही बुझ्ने व्यक्तिलाई समावेश गर्न आवश्यक छ।

मुख्य कुरा: तपाईसँग स्थानान्तरण प्रक्रियाहरू रगतमा लेखिएको हुनुपर्छ। हाम्रो केसमा, म सामान्यतया यो निगरानी गर्छु, किनकि मलाई यो सबै काम गर्न आवश्यक छ। प्रबन्धकहरूलाई यसलाई चाँडै डेलिभर गर्न आवश्यक छ, र पछि के हुन्छ उनीहरूका लागि त्यति महत्त्वपूर्ण छैन।

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

उदाहरणका लागि, हामीसँग विभिन्न अप्रत्याशित ठाउँहरूमा स्फिंक्स भएको सेवा थियो। मैले के गर्नुपर्‍यो म पछि बताउनेछु।

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

म कप्तानी जारी राख्छु। आउटसोर्स सेवा स्वीकार गर्नु अनिवार्य प्रक्रिया हो। के कसैले कहिल्यै आउटसोर्स सेवा आइपुगेको छ र कतै स्वीकार्य छैन? यो अनाथ सेवाको रूपमा लोकप्रिय छैन, तर अझै पनि।

सेवा जाँच गर्न आवश्यक छ, सेवा समीक्षा गर्न आवश्यक छ, पासवर्ड परिवर्तन गर्न आवश्यक छ। हामीसँग एउटा केस थियो जब उनीहरूले हामीलाई सेवा दिए, त्यहाँ एउटा प्रशासक प्यानल छ "यदि लगइन == 'प्रशासक' && पासवर्ड == 'प्रशासक'...", यो कोडमा लेखिएको छ। हामी बसेर सोच्छौं, र मानिसहरूले यो 2018 मा लेख्छन्?

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

सुधारका लागि सेवा पठाउन लाज मान्नुपर्दैन। जब तपाईं भन्नुहुन्छ: "हामी यो सेवा स्वीकार गर्दैनौं, हामीसँग 20 कार्यहरू छन्, तिनीहरूलाई गर्नुहोस्, त्यसपछि हामी स्वीकार गर्नेछौं," यो सामान्य हो। तपाईंले प्रबन्धक स्थापना गर्दै हुनुहुन्छ वा व्यवसायले पैसा बर्बाद गर्दै हुनुहुन्छ भन्ने तथ्यले तपाईंको अन्तस्करणलाई चोट पुर्याउनु हुँदैन। त्यसपछि व्यवसायले बढी खर्च गर्नेछ।

हामीले पाइलट प्रोजेक्टलाई आउटसोर्स गर्ने निर्णय गर्दा एउटा केस थियो।

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

त्यहाँ अर्को ठूलो अवधारणा छ - छापामार विकास। जब केहि विभाग, सामान्यतया मार्केटिङ विभाग, परिकल्पना परीक्षण गर्न चाहन्छ र सम्पूर्ण सेवा आउटसोर्स गर्न आदेश दिन्छ। त्यसमा ट्राफिक आउन थाल्छ, कागजात बन्द गर्छ, ठेकेदारसँग कागजातमा हस्ताक्षर गर्छ, सञ्चालनमा आउँछ र भन्छ: "साथीहरू, हामीसँग यहाँ सेवा छ, त्यहाँ पहिले नै ट्राफिक छ, हामीलाई पैसा ल्याउँछ, यसलाई स्वीकार गरौं।" हामी जस्तै थियौं, "ओपा, यो कसरी हुन सक्छ।"

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

अनाथको समस्या के छ ?

कसलाई थाहा छैन, यो स्वीडेनमा उठाइएको वासा युद्धपोत हो, यो प्रक्षेपणको 5 मिनेट पछि डुबेको तथ्यको लागि प्रसिद्ध छ। र स्वीडेनका राजा, वैसे, यसको लागि कसैलाई मृत्युदण्ड दिएनन्। यो दुई पुस्ताका इन्जिनियरहरूले बनाएका थिए जसलाई त्यस्ता जहाजहरू कसरी बनाउने भनेर थाहा थिएन। प्राकृतिक प्रभाव।

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

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

किन अनाथ सेवाहरू खतरनाक छन्:

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

अनाथ सेवाहरू के गर्ने?

म फेरि के गर्ने भनेर दोहोर्याउँछु। पहिलो, त्यहाँ कागजात हुनुपर्छ। Banki.ru मा 7 वर्षले मलाई सिकाएको छ कि परीक्षकहरूले विकासकर्ताहरूको शब्द लिनु हुँदैन, र सञ्चालनहरूले सबैको शब्द लिनु हुँदैन। हामीले जाँच गर्नुपर्छ।

दोस्रो, यो अन्तर्क्रिया रेखाचित्रहरू लेख्न आवश्यक छ, किनभने यो हुन्छ कि सेवाहरू जुन धेरै राम्ररी प्राप्त नगरिएका छन् निर्भरताहरू समावेश छन् जसको बारेमा कसैले भनेन। उदाहरणका लागि, विकासकर्ताहरूले सेवालाई तिनीहरूको कुञ्जीमा केही Yandex.Maps वा Dadata मा स्थापना गरे। तपाईंले नि:शुल्क सीमा नाघेको छ, सबै कुरा टुटेको छ, र के भयो तपाईंलाई थाहा छैन। त्यस्ता सबै रेकहरू वर्णन गर्नुपर्छ: सेवाले Dadata, SMS, अरू केही प्रयोग गर्दछ।

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

आर्किटेक्चरल कार्यहरूसँग, हामीसँग स्फिन्क्सको बारेमा एउटा कथा थियो। सेवाहरू मध्ये एकले सूचीहरू प्रविष्ट गर्न Sphinx प्रयोग गर्‍यो। केवल एक पृष्ठन गरिएको सूची, तर यो हरेक रात पुन: अनुक्रमित गरिएको थियो। यो दुई अनुक्रमणिकाहरूबाट भेला गरिएको थियो: एउटा ठूलो अनुक्रमणिका हरेक रात, र त्यहाँ एउटा सानो अनुक्रमणिका पनि थियो जुन यसमा खराब गरिएको थियो। हरेक दिन, बम विस्फोटको 50% सम्भाव्यताको साथ, गणनाको क्रममा अनुक्रमणिका क्र्यास भयो, र हाम्रो समाचार मुख्य पृष्ठमा अद्यावधिक हुन बन्द भयो। सुरुमा परिसूचक पुन:सूचकांक हुन ५ मिनेट लाग्यो, त्यसपछि परिसूचक बढ्यो र कुनै बेला पुनः सूचक हुन ४० मिनेट लाग्न थाल्यो । जब हामीले यसलाई काट्यौं, हामीले राहतको सास फेर्‍यौं, किनभने यो स्पष्ट थियो कि अलि बढी समय बित्नेछ र हाम्रो अनुक्रमणिका पूर्ण समय पुन: अनुक्रमणिका हुनेछ। यो हाम्रो पोर्टलको लागि असफल हुनेछ, त्यहाँ आठ घण्टाको लागि कुनै समाचार छैन - यो हो, व्यापार बन्द भएको छ।

अनाथ सेवा संग काम गर्ने योजना

वास्तवमा, यो गर्न धेरै गाह्रो छ, किनभने devops संचारको बारेमा हो। तपाईं आफ्ना सहकर्मीहरूसँग राम्रो सर्तहरूमा रहन चाहनुहुन्छ, र जब तपाईंले आफ्ना सहकर्मीहरू र प्रबन्धकहरूलाई नियमहरूका साथ टाउकोमा हिर्काउनुहुन्छ, तिनीहरूसँग ती व्यक्तिहरूप्रति विवादास्पद भावनाहरू हुन सक्छन्।

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

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

त्यो हो, तपाईले सेवाको लागि आवश्यकताहरू नयाँ लिनुहोस् र नयाँ सेवा लेख्नुहोस्, राम्रो, राम्रो प्लेटफर्ममा, अनौठो प्राविधिक समाधानहरू बिना। र तपाईं युद्धमा त्यसमा बसाइरहनुहुन्छ।

हामीले Yii 1 मा सेवा लिँदा र यसलाई थप विकास गर्न नसक्ने महसुस गरेपछि हामीले Yii 1 मा राम्ररी लेख्न सक्ने विकासकर्ताहरूको अभाव भएको महसुस गरेका थियौं। सबै विकासकर्ताहरूले Symfony XNUMX मा राम्रोसँग लेख्छन्। के गर्ने? हामीले समय आवंटित गर्यौं, टोली आवंटित गर्‍यौं, प्रबन्धक आवंटित गर्‍यौं, परियोजना पुन: लेख्यौं र ट्राफिकलाई सहज रूपमा स्विच गर्यौं।

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

मैले बोल्न चाहेको कुरा यही हो, म छलफल गर्न तयार छु, विषय होलिभर हो, धेरैले यसमा डुबेका छन् ।

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

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

हामी हाल Node.js मा सेवा निर्माण गर्दैछौं, र यो एक अलग भाषाको साथ प्रत्येक विकासकर्ताको लागि नजिकैको प्लेटफर्म मात्र हुनेछ। तर हामी बस्यौं र सोच्यौं कि खेल मैनबत्तीको लायक थियो। त्यो हो, यो तपाईलाई बसेर सोच्ने प्रश्न हो।

तपाईं आफ्नो सेवाहरू कसरी निगरानी गर्नुहुन्छ? तपाईं लगहरू कसरी सङ्कलन र निगरानी गर्नुहुन्छ?

हामी Elasticsearch मा लगहरू सङ्कलन गर्छौं र तिनीहरूलाई Kibana मा राख्छौं, र यो उत्पादन वा परीक्षण वातावरणमा निर्भर गर्दछ, त्यहाँ विभिन्न सङ्कलनहरू प्रयोग गरिन्छ। कतै लम्बरज्याक, कतै अरु केहि, मलाई याद छैन। र त्यहाँ अझै पनि निश्चित सेवाहरूमा केही ठाउँहरू छन् जहाँ हामी टेलिग्राफ स्थापना गर्छौं र कतै अलग रूपमा शूट गर्छौं।

एउटै वातावरणमा कठपुतली र उत्तरदायीसँग कसरी बाँच्ने?

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

तपाईं कसरी अनुकूलता कायम राख्नुहुन्छ? के तपाइँसँग उत्तरदायी र पपेट दुबैमा कन्फिगहरू छन्?

यो हाम्रो ठुलो पीडा हो, हामी आफ्नो हातले अनुकूलता कायम राख्छौं र यो सबैबाट अब कतै कसरी अगाडि बढ्ने भनेर सोच्दछौं। यो पपेटले प्याकेजहरू रोल आउट गर्दछ र त्यहाँ केही लिङ्कहरू राख्छ, र Ansible, उदाहरणका लागि, कोड रोल आउट गर्दछ र त्यहाँ नवीनतम अनुप्रयोग कन्फिगहरू समायोजन गर्दछ।

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

हामीले यो एकै ठाउँमा सामना गर्यौं, र हामीले यसलाई सधैं हाम्रो टाउकोमा राख्नुपर्छ। हामीले केवल रुबीमा चलेको भाग बन्द गर्यौं जुन अनुप्रयोगहरूसँग असंगत थियो र यसलाई अलग राख्यौं।

यस वर्षको सम्मेलन DevOpsDays मस्को Technopolis मा डिसेम्बर 7 मा हुनेछ। हामी नोभेम्बर 11 सम्म रिपोर्टहरूको लागि आवेदनहरू स्वीकार गर्दैछौं। लेख्नुहोस् हामी बोल्न चाहनुहुन्छ भने।

सहभागीहरूको लागि दर्ता खुला छ, हामीसँग सामेल हुनुहोस्!

स्रोत: www.habr.com