नवीन परिस्थितींमध्ये ऑनलाइन व्यापाराशी जुळवून घेण्यास आम्हाला कशामुळे मदत झाली

हाय

माझे नाव मिखाईल आहे, मी स्पोर्टमास्टर कंपनीत आयटी उपसंचालक आहे. महामारीच्या काळात उद्भवलेल्या आव्हानांना आम्ही कसे सामोरे गेलो याची कथा मला सांगायची आहे.

नवीन वास्तविकतेच्या पहिल्या दिवसात, स्पोर्टमास्टरचे नेहमीचे ऑफलाइन ट्रेडिंग स्वरूप गोठले आणि आमच्या ऑनलाइन चॅनेलवरील लोड, मुख्यतः क्लायंटच्या पत्त्यावर पोहोचण्याच्या दृष्टीने, 10 पट वाढला. फक्त काही आठवड्यांमध्ये, आम्ही एका विशाल ऑफलाइन व्यवसायाचे ऑनलाइनमध्ये रूपांतर केले आणि आमच्या ग्राहकांच्या गरजेनुसार सेवा स्वीकारली.

मुळात, आमचे साइड ऑपरेशन जे होते ते आमचा मुख्य व्यवसाय बनला. प्रत्येक ऑनलाइन ऑर्डरचे महत्त्व अत्यंत वाढले आहे. क्लायंटने कंपनीकडे आणलेल्या प्रत्येक रूबलची बचत करणे आवश्यक होते. 

ग्राहकांच्या विनंत्यांना त्वरित प्रतिसाद देण्यासाठी, आम्ही कंपनीच्या मुख्य कार्यालयात एक अतिरिक्त संपर्क केंद्र उघडले आहे आणि आता दर आठवड्याला सुमारे 285 हजार कॉल प्राप्त करू शकतात. त्याच वेळी, आम्ही 270 स्टोअर्स एका नवीन संपर्करहित आणि सुरक्षित ऑपरेटिंग फॉरमॅटमध्ये हलवल्या, ज्यामुळे ग्राहकांना ऑर्डर आणि कर्मचाऱ्यांना त्यांच्या नोकऱ्या टिकवून ठेवता आल्या.

परिवर्तन प्रक्रियेदरम्यान, आम्हाला दोन मुख्य समस्या आल्या. प्रथम, आमच्या ऑनलाइन संसाधनांवरील भार लक्षणीय वाढला आहे (आम्ही हे कसे हाताळले ते सेर्गे तुम्हाला सांगेल). दुसरे म्हणजे, दुर्मिळ (प्री-COVID) ऑपरेशन्सचा प्रवाह अनेक पटींनी वाढला आहे, ज्यामुळे मोठ्या प्रमाणात जलद ऑटोमेशन आवश्यक आहे. या समस्येचे निराकरण करण्यासाठी, आम्हाला पूर्वी मुख्य असलेल्या क्षेत्रांमधून संसाधने त्वरित हस्तांतरित करावी लागली. आम्ही हे कसे हाताळले ते एलेना तुम्हाला सांगेल.

ऑनलाइन सेवांचे संचालन

कोलेस्निकोव्ह सेर्गे, ऑनलाइन स्टोअर आणि मायक्रोसर्व्हिसेसच्या ऑपरेशनसाठी जबाबदार

ज्या क्षणापासून आमची किरकोळ दुकाने अभ्यागतांच्या जवळ येण्यास सुरुवात झाली, तेव्हापासून आम्ही वापरकर्त्यांची संख्या, आमच्या अर्जामध्ये दिलेल्या ऑर्डरची संख्या आणि अर्जांच्या विनंतीची संख्या यासारख्या मेट्रिक्समध्ये वाढ नोंदवू लागलो. 

18 मार्च ते 31 मार्च पर्यंतच्या ऑर्डरची संख्याऑनलाइन पेमेंट मायक्रो सर्व्हिसेसच्या विनंत्यांची संख्यावेबसाइटवर दिलेल्या ऑर्डरची संख्या

पहिल्या आलेखामध्ये आपण पाहतो की वाढ अंदाजे 14 पट होती, दुसऱ्यामध्ये - 4 वेळा. आम्ही आमच्या अनुप्रयोगांचा प्रतिसाद वेळ मेट्रिक सर्वात सूचक मानतो. 

या आलेखामध्ये आम्ही मोर्चा आणि अनुप्रयोगांचा प्रतिसाद पाहतो आणि आम्ही स्वतः ठरवले की आम्हाला अशी कोणतीही वाढ लक्षात आली नाही.

हे प्रामुख्याने 2019 च्या शेवटी आम्ही तयारीचे काम सुरू केल्यामुळे आहे. आता आमच्या सेवा आरक्षित आहेत, भौतिक सर्व्हर, व्हर्च्युअलायझेशन सिस्टम, डॉकर्स आणि त्यामधील सेवांच्या पातळीवर दोष सहिष्णुता सुनिश्चित केली जाते. त्याच वेळी, आमच्या सर्व्हर संसाधनांची क्षमता आम्हाला एकाधिक भार सहन करण्यास अनुमती देते.

या संपूर्ण कथेत आम्हाला मदत करणारे मुख्य साधन म्हणजे आमची मॉनिटरिंग सिस्टम. खरे आहे, अगदी अलीकडेपर्यंत आमच्याकडे एकही प्रणाली नव्हती जी आम्हाला भौतिक उपकरणे आणि हार्डवेअरच्या पातळीपासून व्यवसाय मेट्रिक्सच्या पातळीपर्यंत सर्व स्तरांवर मेट्रिक्स गोळा करण्यास अनुमती देईल. 

औपचारिकरित्या, कंपनीमध्ये देखरेख होते, परंतु नियमानुसार ते विखुरलेले होते आणि विशिष्ट विभागांच्या जबाबदारीच्या क्षेत्रात होते. खरं तर, जेव्हा एखादी घटना घडली तेव्हा, नेमके काय घडले याबद्दल आम्हाला जवळजवळ कधीच सामान्य समज नव्हते, कोणताही संवाद नव्हता आणि अनेकदा यामुळे समस्या शोधण्यासाठी आणि वेगळे करण्यासाठी वर्तुळात धावणे होते जेणेकरून त्याचे निराकरण करता येईल.

काही क्षणी, आम्ही विचार केला आणि ठरवले की आमच्याकडे हे सहन करणे पुरेसे आहे - संपूर्ण चित्र पूर्ण पाहण्यासाठी आम्हाला एका एकीकृत प्रणालीची आवश्यकता आहे. आमच्या स्टॅकमध्ये समाविष्ट केलेली मुख्य तंत्रज्ञाने म्हणजे अॅलर्टिंग आणि मेट्रिक्स स्टोरेज सेंटर म्हणून Zabbix, अॅप्लिकेशन मेट्रिक्स गोळा आणि साठवण्यासाठी Prometheus, संपूर्ण मॉनिटरिंग सिस्टममधून डेटा लॉगिंग आणि स्टोअर करण्यासाठी स्टॅक ELK, तसेच व्हिज्युअलायझेशनसाठी Grafana, Swagger, Docker. आणि इतर उपयुक्त आणि तुम्हाला परिचित असलेल्या गोष्टी.

त्याच वेळी, आम्ही केवळ बाजारात उपलब्ध तंत्रज्ञानच वापरत नाही, तर स्वतःचे काही विकसित देखील करतो. उदाहरणार्थ, आम्‍ही एकमेकांशी सिस्‍टम समाकलित करण्‍यासाठी सेवा बनवतो, म्हणजेच मेट्रिक्स गोळा करण्‍यासाठी काही प्रकारचे API. तसेच आम्ही आमच्या स्वतःच्या मॉनिटरिंग सिस्टमवर काम करत आहोत - व्यवसाय मेट्रिक्सच्या पातळीवर आम्ही UI चाचण्या वापरतो. आणि संघांना सूचित करण्यासाठी टेलीग्राममध्ये एक बॉट देखील.

आम्ही देखरेख प्रणाली संघांसाठी प्रवेशयोग्य बनवण्याचा प्रयत्न करत आहोत जेणेकरुन ते स्वतंत्रपणे त्यांचे मेट्रिक्स संचयित करू शकतील आणि कार्य करू शकतील, ज्यामध्ये काही अरुंद मेट्रिक्ससाठी अलर्ट सेट करणे समाविष्ट आहे जे मोठ्या प्रमाणावर वापरले जात नाहीत. 

संपूर्ण प्रणालीमध्ये, आम्ही शक्य तितक्या लवकर घटनांचे सक्रियता आणि स्थानिकीकरण करण्याचा प्रयत्न करतो. याव्यतिरिक्त, आमच्या मायक्रो सर्व्हिसेस आणि सिस्टमची संख्या अलीकडे लक्षणीय वाढली आहे आणि त्यानुसार एकत्रीकरणांची संख्या वाढली आहे. आणि समाकलन स्तरावर घटनांचे निदान करण्याच्या प्रक्रियेला अनुकूल करण्याचा एक भाग म्हणून, आम्ही एक प्रणाली विकसित करत आहोत जी तुम्हाला क्रॉस-सिस्टम तपासणी करण्यास आणि परिणाम प्रदर्शित करण्यास अनुमती देते, जी तुम्हाला आयात आणि सिस्टमच्या परस्परसंवादाशी संबंधित मुख्य समस्या शोधू देते. एकमेकांना 

अर्थात, ऑपरेटिंग सिस्टीमच्या बाबतीत आमच्याकडे अजूनही वाढ आणि विकासासाठी जागा आहे आणि आम्ही यावर सक्रियपणे काम करत आहोत. तुम्ही आमच्या मॉनिटरिंग सिस्टमबद्दल अधिक वाचू शकता येथे. 

तांत्रिक चाचण्या 

ऑर्लोव्ह सेर्गे, वेब आणि मोबाइल विकासासाठी सक्षमता केंद्राचे प्रमुख आहेत

भौतिक स्टोअर बंद होण्यास सुरुवात झाल्यापासून, आम्ही विकासाच्या दृष्टीकोनातून विविध आव्हानांचा सामना केला आहे. सर्व प्रथम, लोड लाट जसे. हे स्पष्ट आहे की जर योग्य उपाययोजना केल्या नाहीत, तर जेव्हा सिस्टमवर जास्त भार लागू केला जातो तेव्हा ते दुःखी आवाजाने भोपळ्यात बदलू शकते किंवा कार्यप्रदर्शन पूर्णपणे खराब होऊ शकते किंवा त्याची कार्यक्षमता देखील गमावू शकते.

दुसरा पैलू, जरा कमी स्पष्ट आहे, की उच्च भाराखालील प्रणाली व्यवसाय प्रक्रियेतील बदलांशी जुळवून घेत खूप लवकर बदलली पाहिजे. कधीकधी दिवसातून अनेक वेळा. बर्‍याच कंपन्यांचा नियम आहे की जर भरपूर मार्केटिंग क्रियाकलाप असेल तर सिस्टममध्ये कोणतेही बदल करण्याची आवश्यकता नाही. अजिबात नाही, जोपर्यंत ते कार्य करते तोपर्यंत काम करू द्या.

आणि आमच्याकडे मूलत: अंतहीन ब्लॅक फ्रायडे होता, ज्या दरम्यान सिस्टम बदलणे आवश्यक होते. आणि सिस्टममधील कोणतीही त्रुटी, समस्या किंवा अपयश व्यवसायासाठी खूप महाग असेल.

पुढे पाहताना, मी म्हणेन की आम्ही या चाचण्यांचा सामना करण्यास व्यवस्थापित केले, सर्व प्रणालींनी भार सहन केला, सहजतेने मोजले गेले आणि आम्हाला कोणत्याही जागतिक तांत्रिक बिघाडाचा अनुभव आला नाही.

असे चार खांब आहेत ज्यावर उच्च लाट भार सहन करण्याची प्रणालीची क्षमता टिकून आहे. त्यापैकी पहिले निरीक्षण आहे, ज्याबद्दल आपण वर वाचले आहे. अंगभूत मॉनिटरिंग सिस्टमशिवाय, सिस्टममधील अडथळे शोधणे जवळजवळ अशक्य आहे. एक चांगली देखरेख प्रणाली घरच्या कपड्यांसारखी असते; ती आरामदायक आणि तुमच्यासाठी अनुकूल असावी.

दुसरा पैलू म्हणजे चाचणी. आम्ही हा मुद्दा खूप गांभीर्याने घेतो: आम्ही प्रत्येक सिस्टमसाठी क्लासिक युनिट्स, एकत्रीकरण चाचण्या, लोड चाचण्या आणि इतर अनेक लिहितो. आम्ही एक चाचणी धोरण देखील लिहित आहोत आणि त्याच वेळी चाचणीची पातळी वाढवण्याचा प्रयत्न करत आहोत की आम्हाला यापुढे मॅन्युअल तपासणीची आवश्यकता नाही.

तिसरा खांब CI/CD पाइपलाइन आहे. अनुप्रयोग तयार करणे, चाचणी करणे आणि उपयोजित करणे या प्रक्रिया शक्य तितक्या स्वयंचलित केल्या पाहिजेत; तेथे कोणताही मॅन्युअल हस्तक्षेप नसावा. CI/CD पाइपलाइनचा विषय खूप खोल आहे, आणि मी फक्त त्यावर थोडक्यात स्पर्श करेन. आमच्याकडे एक CI/CD पाइपलाइन चेकलिस्ट आहे, जी प्रत्येक उत्पादन टीम सक्षमता केंद्रांच्या मदतीने पार पाडते.

आणि येथे चेकलिस्ट आहे

अशा प्रकारे, अनेक उद्दिष्टे साध्य केली जातात. हे एपीआय व्हर्जनिंग आणि रिलीझ ट्रेन टाळण्यासाठी वैशिष्ट्य टॉगल आहे आणि विविध चाचण्यांचे कव्हरेज अशा स्तरावर प्राप्त करणे आहे की चाचणी पूर्णपणे स्वयंचलित आहे, तैनाती अखंड आहेत आणि असेच.

चौथा स्तंभ म्हणजे वास्तुशास्त्राची तत्त्वे आणि तांत्रिक उपाय. आर्किटेक्चरबद्दल आपण बर्‍याच काळासाठी खूप बोलू शकतो, परंतु मला काही तत्त्वांवर जोर द्यायचा आहे ज्यावर मी लक्ष केंद्रित करू इच्छितो.

प्रथम, आपल्याला विशिष्ट कार्यांसाठी विशेष साधने निवडण्याची आवश्यकता आहे. होय, हे स्पष्ट दिसते, आणि हे स्पष्ट आहे की नखे हातोड्याने चालवल्या पाहिजेत आणि मनगट घड्याळे विशेष स्क्रू ड्रायव्हर्सने वेगळे केले पाहिजेत. परंतु आमच्या युगात, अनेक साधने वापरकर्त्यांचा जास्तीत जास्त विभाग कव्हर करण्यासाठी सार्वत्रिकीकरणाचा प्रयत्न करतात: डेटाबेस, कॅशे, फ्रेमवर्क आणि उर्वरित. उदाहरणार्थ, तुम्ही MongoDB डेटाबेस घेतल्यास, तो बहु-दस्तऐवज व्यवहारांसह कार्य करतो आणि Oracle डेटाबेस json सह कार्य करतो. आणि असे दिसते की सर्वकाही प्रत्येक गोष्टीसाठी वापरले जाऊ शकते. परंतु जर आपण उत्पादकतेसाठी उभे राहिलो, तर आपल्याला प्रत्येक साधनाची ताकद आणि कमकुवतपणा स्पष्टपणे समजून घेणे आवश्यक आहे आणि आपल्या वर्गाच्या कार्यांसाठी आपल्याला आवश्यक असलेले वापरणे आवश्यक आहे. 

दुसरे म्हणजे, सिस्टम डिझाइन करताना, जटिलतेतील प्रत्येक वाढ न्याय्य असणे आवश्यक आहे. आपण हे सतत लक्षात ठेवले पाहिजे; कमी जोडणीचे तत्त्व प्रत्येकाला माहित आहे. माझा विश्वास आहे की ते विशिष्ट सेवेच्या स्तरावर आणि संपूर्ण प्रणालीच्या स्तरावर आणि आर्किटेक्चरल लँडस्केपच्या स्तरावर लागू केले जावे. लोड मार्गावर प्रत्येक सिस्टम घटक क्षैतिजरित्या मोजण्याची क्षमता देखील महत्त्वपूर्ण आहे. आपल्याकडे ही क्षमता असल्यास, स्केलिंग करणे कठीण होणार नाही.

तांत्रिक उपायांबद्दल बोलताना, आम्ही उत्पादन कार्यसंघांना शिफारशी, कल्पना आणि उपायांचा एक नवीन संच तयार करण्यास सांगितले, जे त्यांनी पुढील वर्कलोडच्या तयारीसाठी लागू केले.

केशी

स्थानिक आणि वितरित कॅशेच्या निवडीकडे जाणीवपूर्वक संपर्क साधणे आवश्यक आहे. काहीवेळा एकाच सिस्टीममध्ये दोन्हीचा वापर करणे अर्थपूर्ण ठरते. उदाहरणार्थ, आमच्याकडे अशा सिस्टीम आहेत ज्यामध्ये काही डेटा अनिवार्यपणे एक शोकेस कॅशे असतो, म्हणजेच अपडेट्सचा स्रोत सिस्टीमच्या मागे स्थित असतो आणि सिस्टम बदलत नाहीत. हा डेटा. या दृष्टिकोनासाठी आम्ही स्थानिक कॅफीन कॅशे वापरतो. 

आणि असा डेटा आहे की ऑपरेशन दरम्यान सिस्टम सक्रियपणे बदलते आणि येथे आम्ही आधीच हेझेलकास्टसह वितरित कॅशे वापरत आहोत. हा दृष्टीकोन आम्हाला वितरित कॅशेचे फायदे वापरण्याची परवानगी देतो जिथे त्यांची खरोखर गरज आहे आणि हेझेलकास्ट क्लस्टर डेटा प्रसारित करण्याच्या सेवा खर्च कमी करू शकतो जेथे आम्ही त्याशिवाय करू शकतो. आम्ही कॅशेबद्दल बरेच काही लिहिले आहे. येथे и येथे.

याव्यतिरिक्त, हेझेलकास्टमधील क्रियोमध्ये सिरीयलायझर बदलल्याने आम्हाला चांगली चालना मिळाली. आणि ReplicatedMap वरून IMap + Near Cache मधील Hazelcast मधील संक्रमणामुळे आम्हाला संपूर्ण क्लस्टरमधील डेटाची हालचाल कमी करता आली. 

एक छोटासा सल्ला: मास कॅशे अवैध होण्याच्या बाबतीत, दुसरी कॅशे गरम करण्याची आणि नंतर त्यावर स्विच करण्याची युक्ती कधीकधी लागू होते. असे दिसते की या दृष्टीकोनातून आपल्याला दुप्पट मेमरी खप मिळायला हवी, परंतु सराव मध्ये, ज्या सिस्टममध्ये याचा सराव केला गेला होता तेथे मेमरी वापर कमी झाला.

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

आम्ही मोठ्या संख्येने सिस्टीममध्ये प्रतिक्रियाशील स्टॅक वापरतो. आमच्या बाबतीत, हे कोरुटिनसह वेबफ्लक्स किंवा कोटलिन आहे. रिऍक्टिव्ह स्टॅक विशेषत: चांगला असतो जेथे आम्ही धीमे इनपुट-आउटपुट ऑपरेशन्सची अपेक्षा करतो. उदाहरणार्थ, धीमे सेवांसाठी कॉल, फाइल सिस्टम किंवा स्टोरेज सिस्टमसह कार्य करणे.

कॉल ब्लॉक करणे टाळणे हे सर्वात महत्त्वाचे तत्व आहे. रिऍक्टिव्ह फ्रेमवर्कमध्ये हूड अंतर्गत चालणारे लाइव्ह सर्व्हिस थ्रेड्सची एक छोटी संख्या असते. जर आम्ही निष्काळजीपणे स्वत:ला थेट ब्लॉकिंग कॉल करण्याची परवानगी दिली, जसे की जेडीबीसी ड्रायव्हर कॉल, तर सिस्टम थांबेल. 

आपल्या स्वतःच्या रनटाइम अपवादामध्ये त्रुटी बदलण्याचा प्रयत्न करा. कार्यक्रम अंमलबजावणीचा वास्तविक प्रवाह प्रतिक्रियाशील फ्रेमवर्कमध्ये बदलतो आणि कोडची अंमलबजावणी नॉनलाइनर होते. परिणामी, स्टॅक ट्रेस वापरून समस्यांचे निदान करणे खूप कठीण आहे. आणि प्रत्येक त्रुटीसाठी स्पष्ट, वस्तुनिष्ठ रनटाइम अपवाद तयार करणे हा येथे उपाय असेल.

Elasticsearch

Elasticsearch वापरताना, न वापरलेला डेटा निवडू नका. हा, तत्त्वतः, अगदी सोपा सल्ला देखील आहे, परंतु बहुतेकदा हेच विसरले जाते. तुम्हाला एकावेळी 10 हजाराहून अधिक रेकॉर्ड निवडायचे असल्यास, तुम्हाला स्क्रोल वापरण्याची आवश्यकता आहे. साधर्म्य वापरण्यासाठी, ते रिलेशनल डेटाबेसमधील कर्सरसारखे आहे. 

आवश्यक नसल्यास पोस्टफिल्टर वापरू नका. मुख्य नमुन्यातील मोठ्या डेटासह, हे ऑपरेशन डेटाबेस मोठ्या प्रमाणात लोड करते. 

जेथे लागू असेल तेथे मोठ्या प्रमाणात ऑपरेशन्स वापरा.

API

एपीआय डिझाइन करताना, प्रसारित डेटा कमी करण्यासाठी आवश्यकता समाविष्ट करा. हे विशेषतः समोरच्या संदर्भात सत्य आहे: या जंक्शनवर आम्ही आमच्या डेटा सेंटरच्या चॅनेलच्या पलीकडे जातो आणि आम्हाला क्लायंटशी कनेक्ट करणार्‍या चॅनेलवर आधीपासूनच कार्य करत आहोत. जर त्यात थोडीशी समस्या असेल तर, जास्त रहदारीमुळे वापरकर्त्याचा नकारात्मक अनुभव येतो.

आणि शेवटी, संपूर्ण डेटा फेकून देऊ नका, ग्राहक आणि पुरवठादार यांच्यातील कराराबद्दल स्पष्ट रहा.

संघटनात्मक परिवर्तन

इरोश्किना एलेना, आयटीचे उपसंचालक

ज्या क्षणी अलग ठेवणे घडले, आणि ऑनलाइन विकासाची गती झपाट्याने वाढवण्याची आणि सर्वचॅनेल सेवा सुरू करण्याची गरज निर्माण झाली, तेव्हा आम्ही आधीच संस्थात्मक परिवर्तनाच्या प्रक्रियेत होतो. 

आमच्या संरचनेचा काही भाग उत्पादन दृष्टिकोनाच्या तत्त्वे आणि पद्धतींनुसार कार्य करण्यासाठी हस्तांतरित केला गेला. संघ तयार केले गेले आहेत जे आता प्रत्येक उत्पादनाच्या ऑपरेशन आणि विकासासाठी जबाबदार आहेत. अशा टीममधील कर्मचारी 100% गुंतलेले असतात आणि स्क्रॅम किंवा कानबॅन वापरून त्यांचे काम तयार करतात, त्यांच्यासाठी काय श्रेयस्कर आहे यावर अवलंबून, उपयोजन पाइपलाइन स्थापित करणे, तांत्रिक पद्धती लागू करणे, गुणवत्ता हमी पद्धती आणि बरेच काही.

नशिबाने, आमच्या उत्पादन संघातील बहुतांश भाग ऑनलाइन आणि सर्वचॅनेल सेवांच्या क्षेत्रात होता. यामुळे आम्हाला कमीत कमी वेळेत (गंभीरपणे, अक्षरशः दोन दिवसात) कार्यक्षमता कमी न होता रिमोट वर्क मोडवर स्विच करण्याची परवानगी मिळाली. सानुकूलित प्रक्रियेमुळे आम्हाला नवीन कामकाजाच्या परिस्थितीशी झटपट जुळवून घेण्याची आणि नवीन कार्यक्षमतेच्या वितरणाची उच्च गती राखण्याची परवानगी दिली.

याव्यतिरिक्त, आम्हाला त्या संघांना बळकट करण्याची आवश्यकता आहे जे ऑनलाइन व्यवसायाच्या सीमेवर आहेत. त्या क्षणी हे स्पष्ट झाले की आम्ही केवळ अंतर्गत संसाधनांचा वापर करून हे करू शकतो. आणि दोन आठवड्यांत सुमारे 50 लोकांनी आधी काम केलेले क्षेत्र बदलले आणि त्यांच्यासाठी नवीन असलेल्या उत्पादनावर काम करण्यात गुंतले. 

यासाठी कोणत्याही विशेष व्यवस्थापन प्रयत्नांची आवश्यकता नव्हती, कारण आमची स्वतःची प्रक्रिया, उत्पादनाची तांत्रिक सुधारणा आणि गुणवत्ता हमी पद्धती आयोजित करण्याबरोबरच, आम्ही आमच्या कार्यसंघांना प्रशासकीय संसाधनांचा समावेश न करता स्वत: ची उत्पादन प्रक्रिया व्यवस्थापित करण्यास - स्वयं-व्यवस्थित करण्यास शिकवतो.

आम्‍ही आमच्‍या व्‍यवस्‍थापन संसाधनांवर त्या क्षणी आवश्‍यकता होती - व्‍यवसायासह एकत्रितपणे समन्वय साधण्‍यावर लक्ष केंद्रित करण्‍यात सक्षम झालो: आम्‍हाच्‍या क्लायंटसाठी आत्ता काय महत्‍त्‍वाचे आहे, कोणती कार्यक्षमता प्रथम अंमलात आणली जावी, आमची थ्रुपुट क्षमता वाढवण्यासाठी काय करण्‍याची आवश्‍यकता आहे ऑर्डर वितरित आणि प्रक्रिया करण्यासाठी. हे सर्व आणि स्पष्ट रोल मॉडेलमुळे या कालावधीत आमचे उत्पादन मूल्य प्रवाह खरोखर महत्वाचे आणि आवश्यक असलेले लोड करणे शक्य झाले. 

हे स्पष्ट आहे की दूरस्थ काम आणि बदलाच्या उच्च गतीसह, जेव्हा व्यवसाय निर्देशक प्रत्येकाच्या सहभागावर अवलंबून असतात, तेव्हा आपण केवळ मालिकेतील अंतर्गत भावनांवर अवलंबून राहू शकत नाही “आमच्याबरोबर सर्व काही ठीक चालले आहे का? हो, छान वाटतंय." उत्पादन प्रक्रियेचे वस्तुनिष्ठ मेट्रिक्स आवश्यक आहेत. आमच्याकडे हे आहेत, ते उत्पादन संघांच्या मेट्रिक्समध्ये स्वारस्य असलेल्या प्रत्येकासाठी उपलब्ध आहेत. सर्व प्रथम, संघ स्वतः, व्यवसाय, उपकंत्राटदार आणि व्यवस्थापन.

दर दोन आठवड्यांनी एकदा, प्रत्येक संघासह एक स्थिती आयोजित केली जाते, जिथे 10 मिनिटांसाठी मेट्रिक्सचे विश्लेषण केले जाते, उत्पादन प्रक्रियेतील अडथळे ओळखले जातात आणि एक संयुक्त उपाय विकसित केला जातो: या अडथळ्यांना दूर करण्यासाठी काय केले जाऊ शकते. संघांच्या प्रभावक्षेत्राच्या बाहेर कोणतीही ओळखलेली समस्या किंवा आधीच तत्सम समस्येचा सामना करणार्‍या सहकार्‍यांचे तज्ञ असल्यास येथे तुम्ही व्यवस्थापनाकडून त्वरित मदत मागू शकता.

तथापि, आम्ही समजतो की अनेक वेळा वेग वाढवण्यासाठी (आणि हेच ध्येय आम्ही स्वतःसाठी निश्चित केले आहे), आम्हाला अजूनही बरेच काही शिकण्याची आणि आमच्या दैनंदिन कामात त्याची अंमलबजावणी करणे आवश्यक आहे. आत्ता आम्ही इतर संघ आणि नवीन उत्पादनांसाठी आमचा उत्पादन दृष्टिकोन स्केल करणे सुरू ठेवत आहोत. हे करण्यासाठी, आम्हाला आमच्यासाठी एक नवीन स्वरूप प्राप्त करावे लागले - पद्धतशास्त्रज्ञांची ऑनलाइन शाळा.

मेथोडॉलॉजिस्ट, जे लोक संघांना प्रक्रिया तयार करण्यात, संप्रेषण स्थापित करण्यात आणि कार्य क्षमता सुधारण्यात मदत करतात, ते मूलत: बदलाचे एजंट असतात. सध्या, आमच्या पहिल्या गटातील पदवीधर संघांसोबत काम करत आहेत आणि त्यांना यशस्वी होण्यासाठी मदत करत आहेत. 

मला असे वाटते की सध्याची परिस्थिती आपल्यासाठी संधी आणि संभावना उघडते ज्याची कदाचित आपल्याला स्वतःला अद्याप पूर्ण जाणीव नाही. परंतु आत्ता आम्हाला मिळत असलेला अनुभव आणि सराव हे पुष्टी करतो की आम्ही विकासाचा योग्य मार्ग निवडला आहे, आम्ही भविष्यात या नवीन संधी गमावणार नाही आणि स्पोर्टमास्टरला ज्या आव्हानांना सामोरे जावे लागेल तितक्याच प्रभावीपणे प्रतिसाद देऊ शकू.

निष्कर्ष

या कठीण काळात, आम्ही मुख्य तत्त्वे तयार केली आहेत ज्यावर सॉफ्टवेअर डेव्हलपमेंट अवलंबून आहे, जे मला वाटते, याशी संबंधित असलेल्या प्रत्येक कंपनीसाठी उपयुक्त असेल.

लोक. यावर सर्व काही अवलंबून आहे. कर्मचार्‍यांनी त्यांच्या कामाचा आनंद घेतला पाहिजे आणि कंपनीची उद्दिष्टे आणि ते काम करत असलेल्या उत्पादनांची उद्दिष्टे समजून घेतली पाहिजेत. आणि, अर्थातच, ते व्यावसायिकरित्या विकसित होऊ शकतात. 

तंत्रज्ञान. कंपनीने आपल्या तंत्रज्ञानाच्या स्टॅकसह कार्य करण्यासाठी परिपक्व दृष्टीकोन घेणे आणि खरोखर आवश्यक असलेल्या ठिकाणी सक्षमता निर्माण करणे आवश्यक आहे. हे खूप सोपे आणि स्पष्ट वाटते. आणि बरेचदा दुर्लक्ष केले जाते.

प्रक्रिया. उत्पादन कार्यसंघ आणि सक्षमता केंद्रांचे कार्य योग्यरित्या आयोजित करणे, व्यवसायात भागीदार म्हणून कार्य करण्यासाठी त्याच्याशी संवाद स्थापित करणे महत्वाचे आहे.

सर्वसाधारणपणे, आम्ही कसे जगलो तेच आहे. आमच्या काळातील मुख्य प्रबंधाची पुष्टी पुन्हा एकदा कपाळावर जोरदार क्लिक करून झाली

जरी तुम्‍ही अनेक स्‍टोअर्स आणि तुम्‍ही चालत असलेल्‍या अनेक शहरांसह मोठा ऑफलाइन व्‍यवसाय असले तरीही तुमचा ऑनलाइन व्‍यवसाय विकसित करा. हे केवळ अतिरिक्त विक्री चॅनेल किंवा एक सुंदर अनुप्रयोग नाही ज्याद्वारे आपण काहीतरी खरेदी देखील करू शकता (आणि प्रतिस्पर्ध्यांकडे देखील सुंदर आहेत म्हणून). तुम्हाला वादळाचा सामना करण्यास मदत करण्यासाठी हे फक्त-इन-केस स्पेअर टायर नाही.

ही परम गरज आहे. ज्यासाठी केवळ तुमची तांत्रिक क्षमता आणि पायाभूत सुविधाच नव्हे तर तुमचे लोक आणि प्रक्रियाही तयार असायला हवीत. शेवटी, तुम्ही काही तासांत अतिरिक्त मेमरी, जागा, नवीन उदाहरणे, इत्यादि त्वरीत खरेदी करू शकता. परंतु यासाठी लोक आणि प्रक्रिया आधीच तयार असणे आवश्यक आहे.

स्त्रोत: www.habr.com