हमने लेरॉय मर्लिन में इसे कैसे विकसित किया: चलते-फिरते एक इंजन का पुनर्निर्माण

चार साल पहले, प्रत्येक स्टोर में एक ग्राहक आधार अलग से रखा गया था, साथ ही साइट पर एक और।

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

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

मोर्चे पर (हम जल्द ही इस बारे में लिखेंगे), हमारे पास एक राक्षस है - AEM, और इसके पीछे पीछे दो बड़े अनुप्रयोग थे: OPUS और MoVe। पहला प्रत्येक उत्पाद के गुणों का एक डेटाबेस है (आयामों से विवरण तक), दूसरा चेकआउट के लिए जिम्मेदार है, अर्थात्, कैश डेस्क मोनोलिथ। अगर बहुत सरलीकृत किया जाए।

ओपस में क्या गलत था?

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

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

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

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

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

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

MoVe के साथ क्या गलत था?

कुछ खास नहीं, इस तथ्य के अलावा कि हमने सभी कोड बाहर फेंकने का फैसला किया, क्योंकि यह:

1. एक पुराने ढेर पर प्राचीन था।
2. उन्होंने IFs की श्रृंखला में प्रत्येक क्षेत्र "लेरॉय मर्लिन" की विशेषताओं को ध्यान में रखा।
3. इसे पढ़ना और बनाए रखना इतना कठिन था कि सबसे अच्छा रिफैक्टिंग तरीका था "फिर से लिखना और तुरंत सामान्य रूप से दस्तावेज़।"

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

चूंकि हमने टुकड़ों से मंच का निर्माण किया, इसलिए परियोजना का नाम लेगो रखा गया।

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

आपको यह सब फिर से लिखने की आवश्यकता क्यों थी?

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

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

दूसरा कारण संघीय बॉक्स ऑफिस कानून था: सभी देशों के लिए एक सामान्य प्रणाली (और परीक्षण) के लिए हमारे विकास की समयसीमा के साथ, हम जुर्माना के लिए जुर्माना करेंगे।

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

पिक्सिस ने वास्तव में केवल कैश रजिस्टर से ऑर्डर देने की अनुमति दी थी। हमने तीन चरणों में स्थिति बदली:

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

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

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

प्रतिस्थापन का निर्णय कैसे किया गया था?

मैं कदम रखता हूं। बिजनेस मॉडल को निखारें।

हमने जाँच की, और वास्तव में: मॉडल, जैसा कि रूस में है - हर दिन कम कीमत - सफल है। यूरोप में लेरॉय मर्लिन काफी अधिक महंगा है, लेकिन यह रूस में है कि यह हमारी जगह है: एक निर्माण स्टोर जहां आप निश्चित रूप से सर्वोत्तम मूल्य पर सामान पा सकते हैं।

द्वितीय चरण। एक क्लाइंट स्क्रिप्ट बनाएं।

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

तृतीय चरण। एक वास्तुकला का निर्माण।

उच्चतर विस्तार के साथ विशिष्ट टीके और वास्तुकला में इस दृष्टि को तोड़ दें। इसने 110 परियोजनाएं शुरू कीं, जिन्हें हमने पाँच वर्षों के लिए पाँच श्रेणियों में विभाजित किया।

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

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

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

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

दूसरा महत्वपूर्ण फोकस भू-विकास में था। फिर साल में 20 स्टोर खोले (अब थोड़ा धीमा)। छह हजार कर्मचारी। कई क्षेत्र। दुकानों की आधारभूत संरचना को बढ़ाने के लिए प्रक्रियाओं को विकसित करने के लिए, पूरी आपूर्ति श्रृंखला को फिर से लिखना आवश्यक था।

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

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

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

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