मोनोलिथ देखि माइक्रोसर्विसेस सम्म: M.Video-Eldorado र MegaFon को अनुभव

अप्रिल २५ मा, हामीले Mail.ru समूहमा बादल र वरपरका बारेमा एउटा सम्मेलन आयोजना गर्‍यौं - mailto: Cloud। केही हाइलाइटहरू:

• मुख्य रूसी प्रदायकहरू — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom डेटा सेन्टर र Yandex.Cloud ले हाम्रो क्लाउड बजार र तिनीहरूका सेवाहरूका बारेमा कुरा गरे;
• Bitrix24 का सहकर्मीहरूले उनीहरूलाई कसरी बताए मल्टीक्लाउडमा आयो;
• Leroy Merlin, Otkritie, बर्गर किंग र Schneider इलेक्ट्रिकले रोचक प्रदान गरे क्लाउड उपभोक्ताहरूबाट हेर्नुहोस् - तिनीहरूको व्यवसायले IT को लागि कुन कार्यहरू सेट गर्दछ र क्लाउडहरू सहित कुन प्रविधिहरू, तिनीहरू सबैभन्दा आशाजनक रूपमा देख्छन्।

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

प्यानलहरू

• सर्गेई Sergeev, समूह CIO "M.Video-Eldorado";
• अलेक्जेन्डर ड्युलिन, अनुसन्धान र व्यापार प्रणाली को विकास को लागि केन्द्र को प्रमुख मेगाफोन;
• मध्यस्थ - दिमित्री लाजारेन्को, PaaS निर्देशन प्रमुख Mail.ru क्लाउड समाधान.

अलेक्जेंडर Deulin को भाषण पछि "कसरी MegaFon ले माइक्रोसर्भिस प्लेटफर्म मार्फत आफ्नो व्यवसाय विस्तार गरिरहेको छ" उहाँ M.Video-Eldorado बाट Sergey Sergeev र छलफल मध्यस्थ Dmitry Lazarenko, Mail.ru Cloud Solutions बाट छलफलको लागि सामेल हुनुभएको छ।

तल हामीले तपाईंको लागि छलफलको ट्रान्सक्रिप्ट तयार गरेका छौं, तर तपाईंले भिडियो पनि हेर्न सक्नुहुन्छ:

माइक्रो सर्भिसेसहरूमा संक्रमण बजार आवश्यकताहरूको प्रतिक्रिया हो

दिमित्री:

के तपाइँसँग माइक्रोसर्भिसेसहरूमा माइग्रेट गर्ने कुनै सफल अनुभव छ? र सामान्यमा: माइक्रोसर्भिसेसहरू प्रयोग गर्दा वा मोनोलिथबाट माइक्रोसर्भिसेसमा सर्ने सबैभन्दा ठूलो व्यापारिक लाभ कहाँ देख्नुहुन्छ?

सर्गेई:

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

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

पहिलो सेवाहरू मध्ये एक, सबैभन्दा धेरै लोड गरिएको, मूल्य गणना सेवा थियो। प्रत्येक पटक तपाईं कुनै पनि च्यानलमा आउनुहुन्छ, कम्पनीहरूको M.Video-Eldorado समूहमा, यो वेबसाइट होस् वा खुद्रा पसल, त्यहाँ उत्पादन चयन गर्नुहोस्, वेबसाइट वा "बास्केट" मा मूल्य हेर्नुहोस्, लागत स्वचालित रूपमा हुन्छ। एक सेवा द्वारा गणना। यो किन आवश्यक छ: यो भन्दा पहिले, प्रत्येक प्रणाली प्रमोशन संग काम गर्न को लागी आफ्नै सिद्धान्त थियो - छूट संग र यस्तै। हाम्रो ब्याक अफिसले मूल्य निर्धारण गर्दछ; छुट कार्यक्षमता अर्को प्रणालीमा लागू गरिएको छ। यो केन्द्रीकृत हुन आवश्यक छ र एक व्यापार प्रक्रिया को रूप मा एक अद्वितीय, पृथक सेवा सिर्जना गर्न को लागी हामीलाई यो लागू गर्न अनुमति दिनेछ। हामीले यसरी सुरु गरेका थियौं।

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

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

माइक्रोसर्भिसेसमा माइग्रेट गर्ने सफलता कसरी मापन गर्ने

दिमित्री:

माइक्रो सर्भिसेसहरूमा माइग्रेट गर्ने सफलता कसरी निर्धारण गरिन्छ? प्रत्येक कम्पनीमा "पहिले" के थियो? संक्रमणको सफलता निर्धारण गर्न तपाईंले कुन मेट्रिक प्रयोग गर्नुभयो, र वास्तवमा कसले निर्धारण गर्यो?

सर्गेई:

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

अलेक्जेन्डर:

सफलता बरु एक आन्तरिक भावना हो। व्यवसायले सधैं थप चाहन्छ, र हाम्रो ब्याकलगको गहिराइ सफलताको प्रमाण हो। मलाई त्यस्तै लाग्छ।

सर्गेई:

हो, म सहमत छु। तीन वर्षमा हामीसँग दुई सयभन्दा बढी सेवा र ब्याकलग छन् । टोली भित्र स्रोतहरूको आवश्यकता मात्र बढिरहेको छ - वार्षिक 30% द्वारा। यो भइरहेको छ किनभने मानिसहरूले महसुस गरे: यो छिटो छ, यो फरक छ, त्यहाँ विभिन्न प्रविधिहरू छन्, यो सबै विकास भइरहेको छ।

माइक्रो सर्भिस आउँछन्, तर कोर भने रहनेछ

दिमित्री:

यो कहिल्यै अन्त्य नहुने प्रक्रिया जस्तै हो जहाँ तपाईं विकासमा लगानी गर्नुहुन्छ। व्यवसायका लागि माइक्रो सर्भिसेसहरूमा संक्रमण पहिले नै सकिएको छ कि छैन?

सर्गेई:

जवाफ दिन धेरै सजिलो छ। तपाई के सोच्नुहुन्छ: फोन प्रतिस्थापन एक अन्तहीन प्रक्रिया हो? हामी आफैं हरेक वर्ष फोन किन्छौं। र यो यहाँ छ: जबसम्म गतिको आवश्यकता छ, बजारमा अनुकूलनको लागि, केहि परिवर्तनहरू आवश्यक हुनेछ। यसको मतलब यो होइन कि हामीले मानक चीजहरू त्याग्यौं।

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

दिमित्री:

जीवन राम्रो अवस्थामा छ। (हाँसो)

अलेक्जेन्डर:

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

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

व्यवसायहरूलाई कसरी माइक्रोसेवाहरू बेच्ने

दिमित्री:

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

सर्गेई:

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

दिमित्री:

के तपाईंले कुनै न कुनै रूपमा पहिलो चरणको समय रेकर्ड गर्नुभयो?

सर्गेई:

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

अर्को व्यापार आवश्यकताहरू, अवसरहरू, स्रोतहरूको उपलब्धता र हाल काममा रहेका सबै कुराहरूमा आधारित व्यवस्थित काम आउँछ।

दिमित्री:

ठिक छ। अलेक्जेन्डर, के भन्नुहुन्छ?

अलेक्जेन्डर:

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

दिमित्री:

के यस्तो हुन्छ कि कुनै व्यवसायले तपाईंलाई गुगल जस्ता कामहरू गर्न अनुमति दिन्छ - हप्ताको एक दिन नि:शुल्क? के तपाईसँग यस्तो निर्देशन छ?

अलेक्जेन्डर:

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

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

माइक्रोसर्विसेस: हाइप वा आवश्यकता?

दिमित्री:

संख्याहरू संख्याहरू हुन्। र राजस्व वा पैसा बचत धेरै महत्त्वपूर्ण छ। अर्को तर्फ हेर्दा के हुन्छ ? यस्तो देखिन्छ कि माइक्रो सर्भिसेस एक प्रवृत्ति हो, एक प्रचार र धेरै कम्पनीहरूले यसको दुरुपयोग गर्दै छन्? माइक्रोसर्भिसेसमा अनुवाद गर्ने र नगर्ने कुरामा तपाईं कत्तिको स्पष्ट रूपमा फरक गर्नुहुन्छ? यदि विरासत अहिले छ भने, के तपाइँ अझै 5 वर्षमा विरासत पाउनुहुनेछ? M.Video-Eldorado र MegaFon मा 5 वर्षमा काम गर्ने सूचना प्रणालीहरूको उमेर कति हुनेछ? दश वर्ष, पन्ध्र वर्ष पुरानो सूचना प्रणाली हुनेछ कि नयाँ पुस्ता हुनेछ? यसलाई कसरी हेर्नुहुन्छ ?

सर्गेई:

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

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

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

हामी यो विकास देख्छौं:

• मुख्य सूचना प्रणाली (अधिकतर फिर्ता कार्यालय);
• माइक्रोसर्भिसेसको रूपमा मध्य तहहरू कोर जडान गर्नुहोस्, समग्र, क्यास सिर्जना गर्नुहोस्, र यस्तै;
• फ्रन्ट-लाइन प्रणालीहरू उपभोक्तामा लक्षित छन्;
• एकीकरण तह जुन सामान्यतया बजार, अन्य प्रणाली र इकोसिस्टमहरूमा एकीकृत हुन्छ। यो तह सकेसम्म हल्का, सरल छ, र न्यूनतम व्यापार तर्क समावेश गर्दछ।

तर यसका साथसाथै पुराना सिद्धान्तहरूलाई सही रूपमा प्रयोग गरिएमा त्यसलाई निरन्तरता दिनुपर्नेमा म समर्थक हुँ।

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

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

अलेक्जेन्डर:

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

दिमित्री:

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

कसरी भरपर्दो माइक्रोसर्भिसहरू विकास गर्ने

दिमित्री:

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

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

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

अलेक्जेन्डर:

असफल उदाहरणहरूमा प्राथमिकताहरू परिवर्तन गर्ने र परियोजनाहरू रद्द गर्ने व्यवसायहरू समावेश छन्। जब तयारीको राम्रो चरणमा (वास्तवमा, MVP तयार छ), व्यवसायले भन्यो: "हामीसँग नयाँ प्राथमिकताहरू छन्, हामी अर्को परियोजनामा ​​जाँदैछौं, र हामी यसलाई बन्द गर्दैछौं।"

हामीसँग माइक्रोसर्भिसेसको साथ कुनै विश्वव्यापी असफलता छैन। हामी शान्तिपूर्वक सुत्छौं, हामीसँग 24/7 ड्यूटी शिफ्ट छ जसले सम्पूर्ण BSS [व्यापार समर्थन प्रणाली] सेवा गर्दछ।

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

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

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

माइक्रो सर्भिसेस र एचआर

सर्गेई:

म समर्थनमा स्थानान्तरणको बारेमा मेरो सहकर्मीसँग सहमत छु - कामलाई सही रूपमा व्यवस्थित गर्न आवश्यक छ। तर पक्कै पनि अवस्थित समस्याहरूको बारेमा म तपाईंलाई बताउनेछु।

पहिलो, प्रविधि नयाँ छ। यो राम्रो तरिकाले प्रचार हो, र यो बुझ्न र सिर्जना गर्न सक्ने विशेषज्ञ खोज्नु ठूलो चुनौती हो। स्रोतहरूको लागि प्रतिस्पर्धा पागल छ, त्यसैले विशेषज्ञहरू सुनमा उनीहरूको वजनको लायक छन्।

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

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

खैर, स्केलिंग स्रोतहरू। "राम्रो, जाऔं! र अब हामी छिटो, थप चाहन्छौं। के, तपाईं सक्नुहुन्न? एक वर्षमा दोब्बर वितरण गर्न सम्भव छैन? र किन?" यस्ता बढ्दो पीडाहरू सायद धेरै चीजहरू, धेरै दृष्टिकोणहरूका लागि मानक हुन्, र तपाईंले तिनीहरूलाई महसुस गर्न सक्नुहुन्छ।

अनुगमन सम्बन्धमा । मलाई लाग्छ कि सेवाहरू वा औद्योगिक अनुगमन उपकरणहरू पहिले नै सिकिरहेका छन् वा फरक, गैर-मानक मोडमा Docker र Kubernetes दुवैसँग काम गर्न सक्षम छन्। त्यसोभए, उदाहरणका लागि, तपाइँ 500 जाभा मेशिनहरूसँग समाप्त हुनुहुन्न जस अन्तर्गत यो सबै चलिरहेको छ, अर्थात्, यो एकत्रित हुन्छ। तर यी उत्पादनहरू अझै पनि परिपक्वताको कमी छन्; तिनीहरूले यो मार्फत जानुपर्छ। विषय साँच्चै नयाँ छ, यो विकास जारी छ।

दिमित्री:

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

सर्गेई:

हो, बिल्कुल।

अलेक्जेन्डर:

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

सूक्ष्म सेवाहरूको विकास

दिमित्री:

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

सर्गेई:

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

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

सुरक्षा धेरै महत्त्वपूर्ण छ। जब तपाइँ पहुँचयोग्य हुन सुरु गर्नुहुन्छ र तपाइँसँग एक सेवा छ जसको माध्यमबाट तपाइँ धेरै रोचक चीजहरू प्राप्त गर्न सक्नुहुन्छ, र धेरै चाँडै, विभाजित सेकेन्डमा, त्यसपछि यसलाई सबैभन्दा सुरक्षित तरिकामा प्राप्त गर्ने इच्छा छ। यसबाट टाढा हुन, हामीले परीक्षण र अनुगमनको दृष्टिकोण परिवर्तन गर्नुपर्‍यो। हामीले टोली, डेलिभरी व्यवस्थापन संरचना, CI/CD परिवर्तन गर्नुपर्‍यो।

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

पुनरावृत्तिमा, टेक्नोलोजीको दृष्टिकोणबाट प्रति वर्ष केहि राखिएको छ, ब्याकलग र आवश्यकताको दृष्टिकोणबाट केहि अर्को। हामी एक चीजलाई अर्कोसँग जोड्छौं। टोलीले टोलीको लागि प्राविधिक ऋण र प्राविधिक सहयोगमा 20%, व्यापार इकाईमा 80% खर्च गर्दछ। र हामी यो किन गर्दैछौं, हामी यी प्राविधिक सुधारहरू किन गर्दैछौं, तिनीहरूले के नेतृत्व गर्नेछन् भन्ने बुझाइका साथ अगाडि बढ्छौं। त्यस्तै।

दिमित्री:

कूल। MegaFon मा के छ?

अलेक्जेन्डर:

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

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

दिमित्री:

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

हामीले धेरै छलफल गर्‍यौं। मुख्य कुरा यो हो कि microservices को एक राम्रो डिजाइन र वास्तुकला आफैले तपाईंलाई धेरै गल्तीहरू जोगिन अनुमति दिन्छ। अवश्य पनि, प्रक्रिया पुनरावृत्ति र विकासवादी छ, तर यो भविष्य हो।

सबै सहभागीहरूलाई धन्यवाद, सर्गेई र अलेक्जेन्डरलाई धन्यवाद!

श्रोताहरुको जिज्ञासा

श्रोताको प्रश्न (१):

सेर्गेई, तपाईको कम्पनीमा आईटी व्यवस्थापन कसरी परिवर्तन भएको छ? म बुझ्छु कि जब त्यहाँ धेरै प्रणालीहरूको ठूलो स्ट्याक हुन्छ, यसलाई कसरी व्यवस्थित गरिन्छ त्यो एकदम स्पष्ट र तार्किक प्रक्रिया हो। यति छोटो समयमा धेरै संख्यामा माइक्रो सर्भिसहरू एकीकृत भएपछि IT कम्पोनेन्टको व्यवस्थापनलाई कसरी पुनर्निर्माण गर्नुभयो?

सर्गेई:

म मेरो सहकर्मीसँग सहमत छु कि परिवर्तनको चालकको रूपमा वास्तुकला धेरै महत्त्वपूर्ण छ। हामीले आर्किटेक्चरल डिभिजन गरेर सुरु गर्यौं। आर्किटेक्टहरू एकै साथ कार्यक्षमताको वितरण र परिदृश्यमा यो कसरी देखा पर्नेछ भनेर आवश्यकताहरूको मालिक हुन्। त्यसैले तिनीहरू पनि यी परिवर्तनहरूको संयोजकको रूपमा काम गर्छन्। नतिजाको रूपमा, हामीले CI/CD प्लेटफर्म सिर्जना गर्दा एक विशिष्ट डेलिभरी प्रक्रियामा विशिष्ट परिवर्तनहरू थिए।

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

यो जस्तो छ, राम्रो तरिकामा, खोपको रूपमा एक सुईले देखायो: तपाइँ यसलाई यसरी गर्न सक्नुहुन्छ, तर तपाइँ यसलाई अर्को तरिकाले गर्न सक्नुहुन्छ। निस्सन्देह, कर्मचारीहरूमा, दक्षतामा, ज्ञानमा, प्रतिरोधमा समस्या छ।

श्रोताको प्रश्न (१):

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

अलेक्जेन्डर:

माइक्रोसर्भिसेसबाट प्लेटफर्ममा जाँदा कठिनाइहरू छन्, तर तिनीहरूलाई समाधान गर्न सकिन्छ।

उदाहरणका लागि, हामी 5-7 माइक्रो सेवाहरू समावेश भएको उत्पादन बनाउँदैछौं। हामीले मास्टर शाखामा सार्नको लागि हरियो बत्ती दिनको लागि सम्पूर्ण माइक्रोसर्भिसेस स्ट्याकमा एकीकरण परीक्षणहरू उपलब्ध गराउन आवश्यक छ। यो कार्य हाम्रो लागि नयाँ थिएन: हामीले यो लामो समयदेखि BSS मा गर्दै आएका थियौं, जब विक्रेताले हामीलाई पहिले नै पठाइएका समाधानहरू प्रदान गर्‍यो।

र हाम्रो समस्या सानो टोलीमा मात्र छ। एउटा सशर्त उत्पादनको लागि एक QA इन्जिनियर चाहिन्छ। र त्यसोभए, हामी 5-7 माइक्रो सेवाहरूको उत्पादन पठाउँछौं, जसमध्ये 2-3 तेस्रो पक्षहरूद्वारा विकास गर्न सकिन्छ। उदाहरणका लागि, हामीसँग एउटा उत्पादन छ जसको विकासमा हाम्रो बिलिङ प्रणाली विक्रेता, Mail.ru समूह र MegaFon R&D सहभागी छन्। हामीले यसलाई उत्पादनमा ढुवानी गर्नु अघि परीक्षणहरूको साथ कभर गर्न आवश्यक छ। QA इन्जिनियरले डेढ महिनादेखि यस उत्पादनमा काम गरिरहेको छ, र बाँकी टोली उनको समर्थन बिना छोडिएको छ।

यो जटिलता केवल स्केलिंग को कारण हो। हामी बुझ्छौं कि सूक्ष्म सेवाहरू शून्यमा अवस्थित हुन सक्दैन; निरपेक्ष अलगाव अवस्थित छैन। एउटा सेवा परिवर्तन गर्दा, हामी सधैं API सम्झौता सुरक्षित गर्ने प्रयास गर्छौं। यदि हुड अन्तर्गत केहि परिवर्तन भयो भने, अगाडि सेवा रहन्छ। यदि परिवर्तनहरू घातक छन् भने, केही प्रकारको वास्तु परिवर्तन हुन्छ र हामी पूर्ण रूपमा भिन्न डेटा मेटामोडेलमा जान्छौं, जुन पूर्ण रूपमा असंगत छ - त्यसपछि मात्र हामी v2 सेवा API स्पेसिफिकेशन देखा पर्ने बारे कुरा गर्छौं। हामी पहिलो र दोस्रो संस्करणलाई एकै साथ समर्थन गर्छौं, र सबै उपभोक्ताहरूले दोस्रो संस्करणमा स्विच गरेपछि, हामी केवल पहिलो संस्करण बन्द गर्छौं।

सर्गेई:

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

अघिल्लो कार्यक्षमता कायम राख्न महत्त्वपूर्ण छ, र यो अतिरिक्त ओभरहेड हो। यदि तपाइँ अर्को प्रोटोकलमा टेक्नोलोजी पुन: लेख्नुहुन्छ भने, तपाइँ यसलाई पूर्ण रूपमा बन्द नगरेसम्म तपाइँ यसलाई पुन: लेख्नुहोस्।

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

अलेक्जेन्डर:

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

श्रोताको प्रश्न (१):

जहाँसम्म मैले बुझेको छु, माइक्रोसेवाहरू सुरुमा छुट्टै टोलीबाट बढेको थियो र अहिले यो मोडेलमा अवस्थित छ। यसको फाइदा र बेफाइदा के हो?

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

तदनुसार, हाम्रो सञ्चालन प्रणालीहरूमा पनि जान्छ, अर्थात्, हामी यो विषय विकेन्द्रीकरण गर्दैछौं। तपाईको दृष्टिकोण के हो र तपाईको लक्ष्य कथा के हो?

अलेक्जेन्डर:

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

सर्गेई:

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

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

एकै समयमा, प्रक्रिया सामान्य, नियन्त्रित रहन्छ, यो सामान्य प्राविधिक सिद्धान्तहरू अनुसार अगाडि बढ्छ, एकाइ परीक्षण र यस्तै अन्य - शीर्षमा निर्मित सबै। उत्पादन दृष्टिकोणको विभिन्न विभागहरूबाट सङ्कलन गरिएका स्रोतहरूको रूपमा स्तम्भहरू हुन सक्छन्।

अलेक्जेन्डर:

सेर्गेई, तपाईं वास्तवमा प्रक्रियाको मालिक हुनुहुन्छ, हैन? के कार्य ब्याकलग साझा गरिएको छ? यसको वितरणको जिम्मेवारी कसको हो ?

सर्गेई:

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

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

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

छलफलको अन्त्य, तर सबै होइन

मेलटो: क्लाउड सम्मेलन आयोजना गरिएको थियो Mail.ru क्लाउड समाधान.

हामी अन्य कार्यक्रमहरू पनि गर्छौं - जस्तै @Kubernetes भेटघाट, जहाँ हामी सधैं उत्कृष्ट वक्ताहरू खोजिरहेका छौं:

• हाम्रो टेलिग्राम च्यानलमा @Kubernetes र अन्य @Meetup समाचारहरू पछ्याउनुहोस् t.me/k8s_mail
• @Meetups मध्ये एकमा बोल्न इच्छुक हुनुहुन्छ? लागि अनुरोध छोड्नुहोस् mcs.mail.ru/speak

स्रोत: www.habr.com