AutoOffice - एक अंदर का नजारा

पिछले लेख में, "एक इंटरनेट व्यवसाय के लिए बिक्री के लिए त्वरित शुरुआत", ऑटोऑफिस सेवा की प्रमुख विशेषताओं का एक संक्षिप्त अवलोकन किया गया था।

आज मैं हमारे सीआरएम के डिजाइन और विकास के सभी चरणों से गुजरने की कोशिश करूंगा।

आइडिया, सिस्टम की कार्यक्षमता

हमारी कंपनी 8 से अधिक वर्षों से ऑनलाइन बेच रही है, इस समय हमारे पास अपने व्यवसाय को पूरी तरह से देखने के अवसर की कमी थी, पूरी तस्वीर देखने के लिए।

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

एक रामबाण की खोज करने के बाद, सभी पेशेवरों और विपक्षों की तुलना और वजन करने के लिए, प्रसिद्ध पश्चिमी समाधान salesforce.com ने रूसी बाजार में बढ़त हासिल की, दुर्भाग्य से, यह एक परियोजना खोजना संभव नहीं था जो सेट आवश्यकताओं को पूरा करती है ...

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

आर्किटेक्चर

आधार गुच्छा अपाचे + PHP + MySQL चुना गया था। इस संयोजन ने फेसबुक और Vkontakte जैसी प्रसिद्ध परियोजनाओं के संगठन द्वारा भुगतान और निर्णय लिया है, यह भारी भार को समझने में काफी सक्षम है।

एक काफी लोकप्रिय ग्रहण को विकास के माहौल के रूप में चुना गया था। बेशक, चुनाव लाजिमी है, लेकिन वह हमारे पास आया। पेशेवरों से: संयुक्त विकास, PHPUnit, phpDocumentor के लिए समर्थन, और यह भी मुफ़्त है।

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

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

संरचना

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

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

यहाँ यह कैसा दिखता है:


एक कर्नेल है (फ्रेमवर्क, डेटाबेस, मॉडल, सामान्य एक्सटेंशन, सामान्य घटक नियंत्रक) और उनके अनुवाद फ़ाइलों, उनके नियंत्रकों और विचारों (मॉड्यूल, किसी अच्छे कारण के लिए, डेटाबेस का उपयोग करने के लिए कर्नेल मॉडल का उपयोग करते हुए बहुत सारे स्वतंत्र मॉड्यूल हैं) )।

और अब डेटाबेस के बारे में ही

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

सुरक्षा बढ़ाने और कई कारणों से, दो अलग-अलग स्टोरों के डेटा को अलग-अलग डेटाबेस पर रखकर भौतिक रूप से अलग करने का निर्णय लिया गया।
आखिर ऐसा क्यों:

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

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

प्लेसमेंट

हमारे CRM को कहाँ रखें! घरेलू होस्टिंग कंपनियों के साथ काम करने का काफी अनुभव होने के बाद, हमने तुरंत पश्चिम में देखना शुरू कर दिया।

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

कुछ हफ्तों की खोज के बाद, कार्यशाला में हमारे एक सहकर्मी की सिफारिश पर, हमें फास्टवीपीएस मिला
लोगों ने जर्मन हेट्ज़नर बाजार में नेताओं में से एक की मेजबानी को फिर से संगठित किया और सबसे अच्छा, मेरे लिए, उन्होंने अपने सक्षम रूसी बोलने वाले तकनीकी समर्थन सेवा को हेट्ज़नर की गुणवत्ता में जोड़ा।
इस होस्टिंग कंपनी की अच्छी छोटी चीजों में से, सबसे खराब अपटाइम (Yandex.Metrica के अनुसार: 99.68%)


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

और भविष्य में, हम प्रोजेक्ट पर काम करते समय आने वाली समस्याओं के बारे में हैबे पर लेख प्रकाशित करने की योजना बनाते हैं और हमने कंपनी के काम को कैसे व्यवस्थित किया।

अद्यतन - 12/25/2013: हमारे सर्वरों की विश्वसनीयता बढ़ाने के लिए (अपटाइम संकेतक बढ़ाएँ), हमने अपने सर्वरों को एक नए क्लाउड होस्टिंग में स्थानांतरित कर दिया: DigitalOcean

अब अपेक्षित वार्षिक अपटाइम कम से कम 99.99% होना चाहिए