कुन कुराले हामीलाई नयाँ सर्तहरूमा अनलाइन व्यापारमा द्रुत रूपमा अनुकूलन गर्न मद्दत गर्‍यो

नमस्ते!

मेरो नाम मिखाइल हो, म Sportmaster कम्पनीमा IT को उप निर्देशक हुँ। म महामारीको समयमा आएका चुनौतीहरूलाई कसरी सामना गर्यौं भन्ने कथा साझा गर्न चाहन्छु।

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

मूलतया, के अनिवार्य रूपमा हाम्रो साइड अपरेशन थियो हाम्रो मुख्य व्यवसाय भयो। हरेक अनलाइन अर्डरको महत्त्व अत्यन्तै बढेको छ। ग्राहकले कम्पनीमा ल्याएको हरेक रूबल बचत गर्न आवश्यक थियो। 

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

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

अनलाइन सेवाहरूको सञ्चालन

Kolesnikov Sergey, अनलाइन स्टोर र microservices को सञ्चालन को लागी जिम्मेवार

हाम्रा खुद्रा स्टोरहरू आगन्तुकहरू नजिक हुन थालेको क्षणदेखि, हामीले मेट्रिक्समा वृद्धि रेकर्ड गर्न थाल्यौं जस्तै प्रयोगकर्ताहरूको संख्या, हाम्रो अनुप्रयोगमा राखिएका अर्डरहरूको संख्या, र अनुप्रयोगहरूमा अनुरोधहरूको संख्या। 

मार्च 18 देखि मार्च 31 सम्म आदेशहरूको संख्याअनलाइन भुक्तानी माइक्रो सेवाहरूमा अनुरोधहरूको संख्यावेबसाइटमा राखिएको अर्डरहरूको संख्या

पहिलो ग्राफमा हामी देख्छौं कि वृद्धि लगभग 14 पटक थियो, दोस्रोमा - 4 पटक। हामी हाम्रा अनुप्रयोगहरूको प्रतिक्रिया समय मेट्रिकलाई सबैभन्दा सूचक मान्दछौं। 

यस ग्राफमा हामी मोर्चाहरू र अनुप्रयोगहरूको प्रतिक्रिया देख्छौं, र हामीले आफैंले निर्धारण गर्यौं कि हामीले त्यस्तो कुनै वृद्धि देखेनौं।

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

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

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

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

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

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

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

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

प्राविधिक परीक्षणहरू 

Orlov Sergey, वेब र मोबाइल विकास को लागी योग्यता केन्द्र प्रमुख

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

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

र हामीसँग अनिवार्य रूपमा अन्तहीन कालो शुक्रबार थियो, जसको समयमा यो प्रणाली परिवर्तन गर्न आवश्यक थियो। र प्रणालीमा कुनै त्रुटि, समस्या, वा विफलता व्यवसायको लागि धेरै महँगो हुनेछ।

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

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

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

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

र यहाँ चेकलिस्ट छ

यसरी, धेरै लक्ष्यहरू प्राप्त हुन्छन्। यो रिलिज ट्रेनबाट बच्नको लागि API संस्करण र सुविधा टगल हो, र परीक्षण पूर्ण रूपमा स्वचालित छ, डिप्लोयमेन्टहरू निर्बाध छन्, र यस्तै स्तरमा विभिन्न परीक्षणहरूको कभरेज प्राप्त गर्दै।

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

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

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

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

केशी

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

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

थप रूपमा, हेजलकास्टमा क्रियोमा सिरियलाइजर परिवर्तनले हामीलाई राम्रो बढावा दियो। र ReplicatedMap बाट IMap + Near Cache मा Hazelcast मा ट्रान्जिसनले हामीलाई क्लस्टर भरि डाटाको आवागमन कम गर्न अनुमति दियो। 

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

प्रतिक्रियात्मक स्ट्याक

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

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

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

Elasticsearch

Elasticsearch प्रयोग गर्दा, प्रयोग नगरिएको डाटा चयन नगर्नुहोस्। यो, सिद्धान्त मा, पनि धेरै सरल सल्लाह छ, तर अक्सर यो बिर्सिएको छ। यदि तपाईंलाई एक पटकमा १० हजार भन्दा बढी रेकर्डहरू चयन गर्न आवश्यक छ भने, तपाईंले स्क्रोल प्रयोग गर्न आवश्यक छ। एक समानता प्रयोग गर्न, यो एक सापेक्ष डेटाबेस मा एक कर्सर जस्तै छ। 

आवश्यक नभएसम्म पोस्टफिल्टर प्रयोग नगर्नुहोस्। मुख्य नमूनामा ठूलो डाटाको साथ, यो अपरेशनले डाटाबेसलाई धेरै लोड गर्दछ। 

लागू हुने ठाउँमा बल्क अपरेशनहरू प्रयोग गर्नुहोस्।

एपीआई

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

र अन्तमा, डाटाको सम्पूर्ण गुच्छा बाहिर नफाल्नुहोस्, उपभोक्ताहरू र आपूर्तिकर्ताहरू बीचको सम्झौताको बारेमा स्पष्ट हुनुहोस्।

संगठनात्मक रूपान्तरण

Eroshkina Elena, IT को लागि उप निर्देशक

अहिले जब क्वारेन्टाइन भयो, र अनलाइन विकासको गतिलाई तिव्र गतिमा बढाउने र ओम्निच्यानल सेवाहरू लागू गर्ने आवश्यकता देखा पर्‍यो, हामी संगठनात्मक रूपान्तरणको प्रक्रियामा थियौं। 

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

भाग्यले, हाम्रो उत्पादन टोलीहरूको ठूलो संख्या अनलाइन र ओम्निच्यानल सेवाहरूको क्षेत्रमा थियो। यसले हामीलाई कम से कम सम्भावित समयमा (गम्भीर रूपमा, शाब्दिक रूपमा दुई दिनमा) दक्षताको हानि बिना टाढाको कार्य मोडमा स्विच गर्न अनुमति दियो। अनुकूलित प्रक्रियाले हामीलाई नयाँ कार्य अवस्थाहरूमा छिटो अनुकूलन गर्न र नयाँ कार्यक्षमताको डेलिभरीको एकदम उच्च गति कायम राख्न अनुमति दियो।

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

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

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

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

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

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

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

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

निष्कर्ष

यस कठिन समयमा, हामीले मुख्य सिद्धान्तहरू तयार गरेका छौं जसमा सफ्टवेयर विकास टिक्छ, जुन मलाई लाग्छ, यससँग सम्झौता गर्ने प्रत्येक कम्पनीको लागि सान्दर्भिक हुनेछ।

मान्छे। सबै कुरा यसैमा निर्भर छ। कर्मचारीहरूले आफ्नो कामको आनन्द लिनुपर्दछ र कम्पनीका लक्ष्यहरू र उनीहरूले काम गर्ने उत्पादनहरूको लक्ष्यहरू बुझ्नुपर्छ। र, निस्सन्देह, तिनीहरू व्यावसायिक रूपमा विकास गर्न सक्छन्। 

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

प्रक्रियाहरू। साझेदारको रूपमा काम गर्नका लागि व्यवसायसँग अन्तरक्रिया स्थापना गर्न, उत्पादन टोली र क्षमता केन्द्रहरूको कामलाई राम्रोसँग व्यवस्थित गर्न महत्त्वपूर्ण छ।

सामान्यतया, हामी कसरी बाँचेका छौं। हाम्रो समयको मुख्य थेसिस एक पटक फेरि पुष्टि भयो, निधारमा ठूलो क्लिकको साथ

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

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

स्रोत: www.habr.com