मोनोलिथ से लेकर माइक्रोसर्विसेज तक: एम.वीडियो-एल्डोरैडो और मेगाफोन का अनुभव

25 अप्रैल को, हमने Mail.ru ग्रुप में बादलों और उसके आस-पास के बारे में एक सम्मेलन आयोजित किया - मेलटू:क्लाउड. कुछ मुख्य बातें:

• मुख्य रूसी प्रदाता - Mail.ru क्लाउड सॉल्यूशंस, #CloudMTS, SberCloud, सेलेक्टेल, रोस्टेलकॉम डेटा सेंटर और Yandex.Cloud ने हमारे क्लाउड मार्केट और उनकी सेवाओं की विशिष्टताओं के बारे में बात की;
• Bitrix24 के सहकर्मियों ने बताया कि वे कैसे मल्टीक्लाउड पर आया;
• लेरॉय मर्लिन, ओटक्रिटी, बर्गर किंग और श्नाइडर इलेक्ट्रिक ने दिलचस्प प्रदान किया क्लाउड उपभोक्ताओं से देखें - उनका व्यवसाय आईटी के लिए कौन से कार्य निर्धारित करता है और क्लाउड समेत कौन सी तकनीकों को वे सबसे अधिक आशाजनक मानते हैं।

आप mailto:CLOUD कॉन्फ़्रेंस के सभी वीडियो देख सकते हैं по ссылке, और यहां आप पढ़ सकते हैं कि माइक्रोसर्विसेज के बारे में चर्चा कैसे हुई। मेगाफॉन बिजनेस सिस्टम अनुसंधान और विकास केंद्र के प्रमुख अलेक्जेंडर देउलिन और एम.वीडियो-एल्डोरैडो समूह के सूचना प्रौद्योगिकी निदेशक सर्गेई सर्गेव ने मोनोलिथ से छुटकारा पाने के अपने सफल मामलों को साझा किया। हमने आईटी रणनीति, प्रक्रियाओं और यहां तक ​​कि मानव संसाधन से संबंधित मुद्दों पर भी चर्चा की।

पैनल

• सर्गेई सर्गेव, ग्रुप सीआईओ "एम.वीडियो-एल्डोरैडो";
• अलेक्जेंडर देउलिन, व्यापार प्रणालियों के अनुसंधान और विकास केंद्र के प्रमुख मेगाफोन;
• मॉडरेटर-- दिमित्री लज़ारेंको, PaaS दिशा के प्रमुख Mail.ru क्लाउड सॉल्यूशंस.

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

नीचे हमने आपके लिए चर्चा का एक प्रतिलेख तैयार किया है, लेकिन आप वीडियो भी देख सकते हैं:

माइक्रोसर्विसेज में परिवर्तन बाजार की जरूरतों की प्रतिक्रिया है

दिमित्री:

क्या आपके पास माइक्रोसर्विसेज़ में माइग्रेट करने का कोई सफल अनुभव है? और सामान्य तौर पर: आप माइक्रोसर्विसेज का उपयोग करने या मोनोलिथ से माइक्रोसर्विसेज की ओर बढ़ने से सबसे बड़ा व्यावसायिक लाभ कहां देखते हैं?

सेर्गेई:

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

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

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

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

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

माइक्रोसर्विसेज में माइग्रेट करने की सफलता को कैसे मापें

दिमित्री:

माइक्रोसर्विसेज़ में माइग्रेट करने में सफलता कैसे निर्धारित की जाती है? प्रत्येक कंपनी में "पहले" क्या था? संक्रमण की सफलता निर्धारित करने के लिए आपने किस मीट्रिक का उपयोग किया और वास्तव में इसे किसने निर्धारित किया?

सेर्गेई:

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

अलेक्जेंडर:

सफलता बल्कि एक आंतरिक भावना है. व्यवसाय हमेशा अधिक चाहता है, और हमारे बैकलॉग की गहराई सफलता का प्रमाण है। मुझे तो ऐसा ही लगता है.

सेर्गेई:

हाँ मैं सहमत हूँ। तीन वर्षों में, हमारे पास पहले से ही दो सौ से अधिक सेवाएँ और बैकलॉग हैं। टीम के भीतर संसाधनों की आवश्यकता केवल बढ़ रही है - सालाना 30% की दर से। ऐसा इसलिए हो रहा है क्योंकि लोगों को लगा: यह तेज़ है, यह अलग है, अलग-अलग प्रौद्योगिकियाँ हैं, यह सब विकसित हो रहा है।

माइक्रोसर्विसेज आएंगी, लेकिन कोर बनी रहेगी

दिमित्री:

यह एक कभी न ख़त्म होने वाली प्रक्रिया की तरह है जहाँ आप विकास में निवेश करते हैं। क्या व्यवसाय के लिए माइक्रोसर्विसेज में परिवर्तन पहले ही समाप्त हो चुका है या नहीं?

सेर्गेई:

इसका उत्तर देना बहुत आसान है. आप क्या सोचते हैं: फ़ोन बदलना एक अंतहीन प्रक्रिया है? हम खुद हर साल फोन खरीदते हैं. और यहाँ यह है: जब तक बाजार में अनुकूलन के लिए गति की आवश्यकता है, तब तक कुछ बदलावों की आवश्यकता होगी। इसका मतलब यह नहीं है कि हम मानक चीजों को त्याग दें।

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

दिमित्री:

जीवन अच्छी स्थिति में है. (हंसते हुए)

अलेक्जेंडर:

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

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

व्यवसायों को माइक्रोसर्विसेज कैसे बेचें

दिमित्री:

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

सेर्गेई:

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

दिमित्री:

क्या आपने किसी तरह पहले चरण का समय रिकॉर्ड किया?

सेर्गेई:

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

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

दिमित्री:

ठीक है। अलेक्जेंडर, आप क्या कहते हैं?

अलेक्जेंडर:

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

दिमित्री:

क्या ऐसा होता है कि कोई व्यवसाय आपको Google जैसी चीज़ें करने की अनुमति देता है - सप्ताह में एक निःशुल्क दिन? क्या आपके पास ऐसी कोई दिशा है?

अलेक्जेंडर:

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

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

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

दिमित्री:

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

सेर्गेई:

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

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

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

हम यह विकास देखते हैं:

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

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

मान लीजिए कि आपके पास एक क्लासिक एंटरप्राइज सिस्टम है। यह एक विक्रेता के परिदृश्य में स्थित है और इसमें दो मॉड्यूल शामिल हैं जो एक दूसरे के साथ काम करते हैं। एक मानक एकीकरण इंटरफ़ेस भी है. इसे फिर से क्यों करें और वहां एक माइक्रोसर्विस क्यों लाएं?

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

अलेक्जेंडर:

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

दिमित्री:

यहां प्रमाणन एक कहानी है। संभवतः अधिक समर्थन. यदि आप समर्थन पर बहुत कम खर्च करते हैं या सिस्टम को समर्थन और संशोधन की आवश्यकता नहीं है, तो इसे न छूना बेहतर है। एक उचित समझौता.

विश्वसनीय माइक्रोसर्विसेज कैसे विकसित करें

दिमित्री:

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

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

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

अलेक्जेंडर:

असफल उदाहरणों में व्यवसायों द्वारा प्राथमिकताएँ बदलना और परियोजनाओं को रद्द करना शामिल है। जब तैयारी के अच्छे चरण में (वास्तव में, एमवीपी तैयार है), व्यवसाय ने कहा: "हमारी नई प्राथमिकताएँ हैं, हम दूसरे प्रोजेक्ट पर आगे बढ़ रहे हैं, और हम इसे बंद कर रहे हैं।"

माइक्रोसर्विसेज के मामले में हमें कोई वैश्विक विफलता नहीं मिली। हम शांति से सोते हैं, हमारे पास 24/7 ड्यूटी शिफ्ट है जो पूरे बीएसएस [बिजनेस सपोर्ट सिस्टम] को सेवा प्रदान करती है।

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

मान लीजिए कि हम अपनी स्टेटलेस सेवाएं तैनात करते हैं - हमारे पास वे कुबेरनेट्स में हैं। इससे सभी को ऑटो-स्केलिंग और सेवाओं की ऑटो-रेज़िंग के कारण शांति से सोने की अनुमति मिलती है, और ड्यूटी शिफ्ट में घटनाएं बढ़ती हैं।

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

माइक्रोसर्विसेज और एचआर

सेर्गेई:

मैं समर्थन में स्थानांतरण के बारे में अपने सहकर्मी से सहमत हूं - कि कार्य को सही ढंग से व्यवस्थित करने की आवश्यकता है। लेकिन मैं आपको उन समस्याओं के बारे में बताऊंगा जो निस्संदेह मौजूद हैं।

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

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

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

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

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

दिमित्री:

हाँ, बहुत दिलचस्प है. और यह बात एचआर पर लागू होती है. शायद आपकी HR प्रक्रिया और HR ब्रांड इन 3 वर्षों में थोड़ा बदल गया है। आपने विभिन्न योग्यताओं वाले अन्य लोगों को भर्ती करना शुरू किया। और संभवतः इसके पक्ष और विपक्ष दोनों हैं। पहले, ब्लॉकचैन और डेटा विज्ञान प्रचारित थे, और उनमें विशेषज्ञों की कीमत लाखों में थी। अब लागत गिर रही है, बाजार संतृप्त हो रहा है, और माइक्रोसर्विसेज में भी इसी तरह की प्रवृत्ति है।

सेर्गेई:

हां बिल्कुल।

अलेक्जेंडर:

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

माइक्रोसर्विसेज का विकास

दिमित्री:

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

सेर्गेई:

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

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

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

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

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

दिमित्री:

ठंडा। मेगाफोन में क्या है?

अलेक्जेंडर:

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

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

दिमित्री:

सुनहरे शब्द! ऐसी चुनौतियाँ टीम और व्यवसाय को सक्रिय रखती हैं और भविष्य का निर्माण करती हैं। जीडीपीआर ने मुख्य डेटा सुरक्षा अधिकारी बनाए, और वर्तमान चुनौतियों ने मुख्य माइक्रोसर्विसेज और आर्किटेक्चर अधिकारी बनाए। और यह प्रसन्न करता है.

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

सभी प्रतिभागियों को धन्यवाद, सर्गेई और अलेक्जेंडर को धन्यवाद!

दर्शकों से प्रश्न

दर्शकों से प्रश्न (1):

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

सेर्गेई:

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

लेकिन विकास, व्यवसाय विश्लेषण, परीक्षण और विकास के मानक, बुनियादी सिद्धांतों को रद्द नहीं किया गया है। हमने अभी गति जोड़ी है। पहले, चक्र में बहुत अधिक समय लगता था, परीक्षण वातावरण पर इंस्टॉलेशन में बहुत अधिक समय लगता था। अब व्यवसाय लाभ देखता है और कहता है: "हम अन्य स्थानों पर भी ऐसा क्यों नहीं कर सकते?"

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

दर्शकों से प्रश्न (2):

माइक्रोसर्विस आर्किटेक्चर के आलोचकों का कहना है कि परीक्षण और विकास कठिन हैं। यह तर्कसंगत है जहां चीजें जटिल हो जाती हैं। आपकी टीम को किन चुनौतियों का सामना करना पड़ा और आपने उनसे कैसे पार पाया? सभी के लिए प्रश्न.

अलेक्जेंडर:

माइक्रोसर्विसेज़ से किसी प्लेटफ़ॉर्म पर जाने में कठिनाइयाँ आती हैं, लेकिन उन्हें हल किया जा सकता है।

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

और हमारी समस्या छोटी टीम में ही है. एक सशर्त उत्पाद के लिए एक QA इंजीनियर की आवश्यकता होती है। और इसलिए, हम 5-7 माइक्रोसर्विसेज का एक उत्पाद भेजते हैं, जिनमें से 2-3 को तीसरे पक्ष द्वारा विकसित किया जा सकता है। उदाहरण के लिए, हमारे पास एक उत्पाद है जिसके विकास में हमारे बिलिंग सिस्टम विक्रेता, Mail.ru ग्रुप और मेगाफोन R&D भाग लेते हैं। उत्पादन के लिए भेजने से पहले हमें इसे परीक्षणों से कवर करना होगा। क्यूए इंजीनियर इस उत्पाद पर डेढ़ महीने से काम कर रहा है, और टीम के बाकी सदस्य उसके समर्थन के बिना रह गए हैं।

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

सेर्गेई:

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

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

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

अलेक्जेंडर:

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

दर्शकों से प्रश्न (3):

जहां तक ​​मैं समझता हूं, माइक्रोसर्विसेज शुरू में एक अलग टीम से विकसित हुई और अब इस मॉडल में मौजूद हैं। इसके पक्ष और विपक्ष क्या हैं?

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

तदनुसार, हमारा संचालन भी सिस्टम तक जाता है, अर्थात हम इस विषय का विकेंद्रीकरण कर रहे हैं। आपका दृष्टिकोण क्या है और आपकी लक्ष्य कहानी क्या है?

अलेक्जेंडर:

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

सेर्गेई:

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

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

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

अलेक्जेंडर:

सर्गेई, आप वास्तव में इस प्रक्रिया के स्वामी हैं, है ना? क्या कार्य का बैकलॉग साझा किया गया है? इसके वितरण के लिए कौन जिम्मेदार है?

सेर्गेई:

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

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

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

चर्चा का अंत, लेकिन संपूर्ण नहीं

mailto:CLOUD सम्मेलन का आयोजन किया गया Mail.ru क्लाउड सॉल्यूशंस.

हम अन्य कार्यक्रम भी करते हैं - उदा. @कुबेरनेट्स मीटअप, जहां हम हमेशा अच्छे वक्ताओं की तलाश में रहते हैं:

• हमारे टेलीग्राम चैनल में @Kubernetes और अन्य @Meetup समाचारों को फ़ॉलो करें t.me/k8s_mail
• @Meetups में से किसी एक पर बोलने में रुचि है? के लिए एक अनुरोध छोड़ें mcs.mail.ru/speak

स्रोत: www.habr.com